05 ม.ค. 2569·2 นาที
Claude Code ในมอนอรีโป: จำกัดบริบทและคงความแม่นยำ
Claude Code ในมอนอรีโปอาจเบี่ยงเมื่อรีโปใหญ่เกินไป เรียนรู้การตั้งขอบเขต สรุปท้องถิ่น และเวิร์กโฟลว์ที่ทำซ้ำได้เพื่อให้คำตอบแม่นยำ
Claude Code ในมอนอรีโปอาจเบี่ยงเมื่อรีโปใหญ่เกินไป เรียนรู้การตั้งขอบเขต สรุปท้องถิ่น และเวิร์กโฟลว์ที่ทำซ้ำได้เพื่อให้คำตอบแม่นยำ
Claude Code ในมอนอรีโปอาจรู้สึกไม่แน่นอนได้ด้วยเหตุผลง่าย ๆ: รีโปใหญ่กว่าพื้นที่ทำงานที่โมเดลเก็บไว้ได้ในคราวเดียว
“บริบท” คือชุดไฟล์ สนิปเพ็ต โน้ต และคำสั่งที่ Claude ได้เห็นสำหรับงานนี้ บวกกับสิ่งที่มันอนุมานได้จากพวกนั้น เมื่อรายละเอียดสำคัญหายไป Claude จะเติมช่องว่างด้วยการเดา ในรีโปขนาดใหญ่ เรื่องนี้จะเกิดบ่อยขึ้น
จะมีโหมดความล้มเหลวสามแบบที่พบบ่อย ๆ:
ประการแรก ไฟล์ที่พลาด การเปลี่ยนแปลงที่ดูปลอดภัยในโฟลเดอร์หนึ่งอาจขึ้นกับไทป์ที่แชร์ กฎ config หรือขั้นตอน build ที่นิยามอยู่ที่อื่น ถ้า dependency นั้นไม่อยู่ในบริบท Claude อาจแก้ไขผิดที่อย่างมั่นใจหรือหยุดก่อนเพราะมันมองไม่เห็นแหล่งความจริงจริง
ประการที่สอง ความคล้ายเท็จ มอนอรีโปมักมีแพ็กเกจหลายตัวที่ดูคล้ายกัน: สองโมดูล auth, สามไคลเอนต์ API, หรือหลายแอป React ที่มีโฟลเดอร์โครงสร้างคล้ายกัน Claude อาจผสมแพทเทิร์นระหว่างพวกมัน อัปเดต helper ในแพ็กเกจผิด หรือ import จากชื่อโมดูลที่ “เกือบถูก”
ประการที่สาม การลื่นของเวลา ฐานโค้ดใหญ่ ๆ มักมีวิธีเก่าและใหม่ในการทำงานเดียวกัน ถ้า Claude เห็นเฉพาะไฟล์เก่า มันอาจก็อปปี้แพทเทิร์นที่ล้าสมัย (ตัวเลือก config ถูกเลิกใช้, API แบบเดิม) แม้ว่าทีมจะเปลี่ยนไปแล้วก็ตาม
ตัวอย่างในโลกจริงที่พบบ่อย: คุณขอการเปลี่ยนแปลงเล็ก ๆ ใน UI ของการคิดเงิน แล้ว Claude แก้ payments component ที่ถูกแชร์โดยแอปอื่นเพราะมันไม่เคยเห็น wrapper เฉพาะแอปที่ควรถูกแก้
เป้าหมายไม่ใช่โชว์ Claude ทั้งมอนอรีโป เป้าหมายคือให้ข้อมูลเข้าเล็ก ๆ และตั้งใจที่ยังตอบคำถามได้: แพ็กเกจที่คุณกำลังแก้ ไฟล์ dependency โดยตรง และหนึ่งหรือสอง “แหล่งความจริง” สำหรับไทป์และ config ระบุโซนที่ห้ามแตะ (แอปอื่น ๆ, infra, โค้ดที่สร้างขึ้นอัตโนมัติ) และยืนยันว่าแพ็กเกจไหนเป็นเจ้าของพฤติกรรม
ความแม่นยำขึ้นอยู่กับการอธิบายงานให้ชัดเจน ไม่ใช่จำนวนโค้ดที่คุณวาง
เริ่มจากผลลัพธ์ที่คุณต้องการ: แก้ไขเฉพาะที่ การรีแฟกเตอร์ หรือตอบคำถาม “คำถามเกี่ยวกับโค้ด” อาจอยู่ในระดับสูงได้ แต่คำขอ “ทำการเปลี่ยนแปลง” ต้องการขอบเขต อินพุต และการตรวจสอบความสำเร็จ
ก่อนจะแชร์อะไร เขียนประโยคเดียวที่เติมวลีนี้ให้เสร็จ: “หลังจากเสร็จ ฉันควรจะสามารถ…”。ตัวอย่าง: “รันยูนิตเทสต์สำหรับแพ็กเกจ X โดยไม่มีข้อผิดพลาด” หรือ “เห็นฟิลด์ใหม่ในผลตอบ API สำหรับ endpoint Y” ประโยคนั้นจะเป็นเข็มทิศเมื่อต้องทำงานกับรีโปขนาดใหญ่
สำหรับการเปลี่ยนแปลง ให้แชร์ชุดชิ้นงานเล็กที่สุดที่พิสูจน์ได้ว่าการเปลี่ยนถูกต้อง: จุดเข้า (entry point), ไทป์/อินเทอร์เฟซหรือสคีมาที่เกี่ยวข้อง, เทสต์ที่ล้มเหลวหนึ่งตัวหรือขั้นตอน repro พร้อมผลลัพธ์ที่คาดหวัง, และ config ที่มีผลกับเส้นทางนี้ (routing, feature flags, build หรือ lint rules) ถ้าช่วยได้ ให้เพิ่มแผนผังโฟลเดอร์สั้น ๆ ของแพ็กเกจเพื่อให้ Claude เข้าใจว่าแต่ละไดเรกทอรีคืออะไร
ระบุอย่างชัดเจนว่าไม่ให้มองอะไร พูดว่า: “ไม่สนใจไฟล์ที่สร้างอัตโนมัติ โฟลเดอร์ vendor ผลลัพธ์ build snapshots และ lockfiles ยกเว้นฉันขอ” นั่นช่วยป้องกันการเสียเวลาและการแก้ไขในที่ที่คุณจะไม่ตรวจ
ตั้งความคาดหวังสำหรับความไม่แน่นอนด้วย ขอให้ Claude ทำเครื่องหมายสมมติฐานและสิ่งที่ไม่รู้แทนที่จะเดา ตัวอย่าง: “ถ้าคุณมองไม่เห็นว่าฟังก์ชันนี้ถูกเรียกที่ไหน ให้บอกและเสนอ 2 วิธีเพื่อค้นหามัน”
ในมอนอรีโปใหญ่ ความแม่นยำลดลงเมื่อโมเดลเริ่ม “ช่วยเหลือ” โดยดึงโค้ดใกล้เคียงที่ไม่เกี่ยวกับงาน วิธีแก้คือง่าย: กำหนดสิ่งที่อยู่ในขอบเขตและนอกขอบเขตก่อนขอเปลี่ยน
เริ่มจากขอบเขตที่สอดคล้องกับการจัดระเบียบรีโปของคุณ: แพ็กเกจ เซอร์วิส แอป หรือไลบรารีแชร์ ถ้าการเปลี่ยนคือ “อัปเดต checkout UI” ขอบเขตน่าจะเป็นแพ็กเกจแอปหนึ่งตัว ไม่ใช่ทุกที่ที่มีคำว่า “checkout” ปรากฏ
สัญญาณที่ช่วยให้ Claude อยู่ในขอบเขตได้แก่ ข้อบ่งชี้โฟลเดอร์ (apps/, services/, packages/, libs/), manifests ของแพ็กเกจ (exports และ dependencies), จุดเข้าใช้สาธารณะ (ไฟล์ index, คอมโพเนนต์ที่ export, handlers) และเทสต์ (มักเผยพื้นผิวที่ตั้งใจให้ใช้) README ภายในโฟลเดอร์สามารถเป็นตัวบอกขอบเขตได้อย่างรวดเร็ว
ขอบเขตทำงานได้ดีที่สุดเมื่อคุณระบุสะพานระหว่างพวกมัน ชี้ให้เห็นอินเทอร์เฟซเฉพาะที่ Claude อาจแตะและถือทุกอย่างอื่นเป็นห้ามแตะ สะพานทั่วไปคือสัญญา HTTP API หัวข้อเหตุการณ์และ payloads ไทป์ที่แชร์ หรือฟังก์ชันที่ export เพียงไม่กี่ตัว
นอกจากนี้ ให้ระบุโซนที่ห้ามแตะเมื่อการเปลี่ยนไม่ควรกระทบพวกมัน โซนทั่วไปคือ config โครงสร้างพื้นฐานและ deployment, ลอจิกความปลอดภัยและการยืนยันตัวตน, การคิดเงินและการชำระ, มิเกรชันข้อมูลและสคีมาผลิตจริง, และไลบรารีแชร์ที่ทีมหลายทีมใช้
รายละเอียดพรอมต์ที่ช่วยได้:
“ทำการเปลี่ยนเฉพาะใน packages/cart/ และเทสต์ของมันเท่านั้น คุณอาจอ่านไทป์ที่แชร์ใน packages/types/ แต่ห้ามแก้ไข ห้ามแก้ infra, auth หรือ billing”
ความแม่นยำดีขึ้นเมื่อคุณให้แผนที่เล็ก ๆ และเสถียรของพื้นที่ที่ต้องการเปลี่ยน “สรุปท้องถิ่น” คือแผนที่นั้น: สั้นพออ่านเร็ว แต่เฉพาะพอป้องกันการเดา
เก็บแต่ละสรุปไว้ราว 10–20 บรรทัด เขียนเหมือนมอบโค้ดให้เพื่อนร่วมทีมใหม่ที่ต้องแตะเฉพาะขอบเขตนี้ ไม่ใช่รีโปทั้งชุด ใช้ภาษาธรรมดาและชื่อจริงจากโค้ด: โฟลเดอร์ แพ็กเกจ ฟังก์ชันที่ export
สรุปท้องถิ่นที่มีประโยชน์ตอบคำถามห้าข้อนี้:
เพิ่มบรรทัด “gotchas” หนึ่งบรรทัด นี่คือที่ป้องกันความผิดพลาดที่มีค่า: แคชชิงที่ซ่อนอยู่ feature flags ขั้นตอนมิเกรชัน และสิ่งใด ๆ ที่ทำให้ล้มโดยไม่มีสัญญาณเตือน
นี่คือเทมเพลตกะทัดรัดที่คัดลอกได้:
Local summary: \u003cpackage/service name\u003e
Purpose: \u003c1 sentence\u003e
Scope: \u003cwhat to touch\u003e | Not: \u003cwhat not to change\u003e
Entry points: \u003cfiles/routes/commands\u003e
Public surface: \u003cexports/endpoints/events\u003e
Data sources: \u003ctables/collections/queues/caches\u003e
Conventions: errors=\u003chow\u003e, logging=\u003chow\u003e, tests=\u003cwhere/how\u003e
Gotchas: \u003cflags/caching/migrations/edge cases\u003e
ตัวอย่าง: ถ้าคุณกำลังแก้แพ็กเกจ billing ให้ระบุฟังก์ชันที่สร้าง invoice ชื่อโต๊ะที่เขียนลงไป และกฎสำหรับข้อผิดพลาดที่ retry ได้ แล้ว Claude จะโฟกัสที่ขอบเขตนั้นแทนที่จะตะเกียกตะกายเข้าไปใน auth, config หรือแพ็กเกจที่ไม่เกี่ยว
สรุปที่ดีที่สุดคือสรุปที่ Claude เห็นเมื่อมันต้องการ มันวางข้างโค้ดที่อธิบายเพื่อให้มองไม่พลาดและแก้ไขได้ง่าย ตัวอย่าง: เก็บ SUMMARY.md สั้น ๆ (หรือส่วนใน README.md) ข้างแต่ละแพ็กเกจ เซอร์วิส หรือแอป แทนเอกสารใหญ่รวมที่รากรีโป
โครงสร้างที่เรียบง่ายและทำซ้ำได้ช่วยได้ เก็บสั้นพอที่คนจะยังรักษามัน:
YYYY-MM-DD - \u003cwhat changed in one sentence\u003eสรุปจะกลายเป็นล้าสมัยด้วยสาเหตุที่คาดได้ จัดการการอัปเดตเหมือนการอัปเดตคำจำกัดความของไทป์: เป็นส่วนหนึ่งของการทำงานเสร็จ ไม่ใช่งานแยก
อัปเดตสรุปเมื่อการรีแฟกเตอร์เปลี่ยนโครงสร้างหรือชื่อ โมดูลใหม่กลายเป็นวิธีหลักในการทำสิ่งหนึ่ง API/event/schema เปลี่ยน (แม้เทสต์ยังผ่าน) ขอบเขตระหว่างแพ็กเกจเปลี่ยน หรือลบ/แทนที่ dependency
นิสัยเชิงปฏิบัติ: เมื่อคุณ merge การเปลี่ยน ให้เพิ่มบรรทัด “Last updated” ว่ามีอะไรเปลี่ยน Tools อย่าง Koder.ai สามารถช่วยเร่งการเปลี่ยนแปลงโค้ด แต่สรุปคือสิ่งที่รักษาความแม่นยำในการเปลี่ยนในอนาคต
ความแม่นยำมักขึ้นอยู่กับจังหวะการคุย ให้ Claude หา context ทีละชิ้นแทนการเดาจากสแนปช็อตใหญ่
ก่อนจะแก้ใด ๆ ขอให้ Claude อธิบายสิ่งที่มันเห็นและสิ่งที่ต้องการ แผนที่ที่ดีสั้น: แพ็กเกจหลักที่เกี่ยวข้อง, จุดเข้าใช้ของ flow, และที่เทสต์หรือไทป์อยู่
พรอมต์:
“Create a map of this change: packages involved, main flow, and likely touch points. Do not propose code yet.”
เลือกสไลซ์แคบ ๆ: ฟีเจอร์หนึ่ง แพ็กเกจหนึ่ง หรือ flow หนึ่ง ระบุขอบเขตให้ชัด (เช่น: “Only change packages/billing-api. Do not touch shared-ui or infra.”)
เวิร์กโฟลว์ที่ช่วยให้คุณควบคุม:
ถ้า Claude ขาดอะไร มันควรบอก ให้สั่งให้มันเขียน: (1) สมมติฐานที่มันทำ (2) สิ่งที่จะล้มล้างสมมติฐานเหล่านั้น และ (3) ไฟล์ถัดไปที่ต้องยืนยัน
ตัวอย่าง: คุณต้องเพิ่มฟิลด์ให้ Invoice response ในแพ็กเกจหนึ่ง Claude ขอ handler, DTO/type definition, และเทสต์หนึ่งตัว คุณแชร์เฉพาะพวกนั้น ถ้าคุณใช้เครื่องมือแชทแบบสร้างโปรเจกต์ เช่น Koder.ai กฎเดียวกันใช้: ให้ชุดไฟล์เล็กที่สุด แล้วค่อยขยายเมื่อจำเป็นจริง ๆ
การป้องกันการแก้ผิดที่ดีที่สุดคือ “สัญญา” เล็ก ๆ ในพรอมต์: อะไรที่ Claude สัมผัสได้ วิธีที่คุณจะตัดสินความสำเร็จ และกฎที่มันต้องปฏิบัติตาม
เริ่มจากขอบเขตที่ปฏิบัติตามได้และตรวจสอบได้ ระบุอย่างชัดที่จะแก้และชื่อโซนที่ห้ามแตะเพื่อไม่ให้เกิดความอยากย้ายขอบเขต
เทมเพลตสัญญา:
packages/payments/ เท่านั้นpackages/auth/, infra/, หรือ config ร่วมใด ๆจากนั้นกำหนดเกณฑ์ยอมรับ ถ้าไม่มีอมตะ Claude อาจผลิตโค้ดที่ดูถูกแต่ขัดกับกฎจริงของรีโป
ข้อจำกัดด้านสไตล์ก็สำคัญ บอก Claude ว่าให้ทำตามแพทเทิร์นอะไรและห้ามทำอะไร ตามสิ่งที่รีโปคุณใช้ เช่น: “ใช้ helper ข้อผิดพลาดที่มีอยู่ในแพ็กเกจนี้; ห้ามเพิ่ม dependency ใหม่; รักษาชื่อฟังก์ชันเป็น camelCase; อย่าเพิ่มชั้นสถาปัตยกรรมใหม่”
สุดท้าย บังคับให้มีแผนแก้ก่อนแก้จริง:
“Before editing, list the 3-5 files you expect to touch and the exact behavior change. Wait for approval.”
ตัวอย่าง:
“Fix rounding in invoice totals. Only edit packages/billing/src/ and tests under packages/billing/test/. Acceptance: pnpm -C packages/billing test and typecheck. Follow existing money utils; do not rewrite API types. Provide a 4-step plan first.”
วิธีเร็วที่สุดที่จะได้การแก้ผิดในมอนอรีโปคือให้ Claude มากเกินไปในครั้งเดียว เมื่อคุณวางโค้ดกองใหญ่ลงไป มันมักถอยไปใช้แพทเทิร์นทั่วไปแทนที่จะใช้ดีไซน์เฉพาะของรีโปคุณ
ข้อผิดพลาดอีกอย่างคือปล่อยให้มันเดาสถาปัตยกรรม ถ้าคุณไม่โชว์จุดเข้าใช้จริง มันอาจเลือกไฟล์แรกที่ดูเป็นไปได้และต่อสายโลจิกตรงนั้น ในทางปฏิบัติ ความแม่นยำมาจากชุดไฟล์ “แหล่งความจริง” เล็ก ๆ (entry modules, routers, service registries, package boundary docs) ถ้าไฟล์พวกนั้นไม่อยู่ในบริบท โมเดลจะเติมช่องว่าง
ชื่ิอไฟล์ก็หลอกได้ มอนอรีโปมักมีแพ็กเกจอย่าง ui, ui-kit, shared-ui หรือ helper ซ้ำอย่าง date.ts สองที่ ถ้าคุณผสมสนิปเพ็ตจากทั้งสอง Claude อาจแพตช์ไฟล์หนึ่งขณะที่คิดถึงอีกไฟล์หนึ่ง ตัวอย่าง: คุณขอเปลี่ยนสไตล์ปุ่ม แต่มันแก้ packages/ui/Button.tsx ในขณะที่แอป import จาก packages/ui-kit/Button.tsx ผล diff ดูดี แต่ในโปรดักชันไม่มีอะไรเปลี่ยน
config ก็เป็นแหล่งของการเบี่ยงที่เงียบ ๆ พฤติกรรมอาจขึ้นกับ env vars, feature flags, การตั้งค่า build หรือ tooling ของ workspace ถ้าคุณไม่กล่าวถึงสิ่งเหล่านี้ Claude อาจลบเช็คที่ “แปลก” ซึ่งมีความหมายเมื่อ flag เปิด หรือเพิ่มโค้ดที่ทำให้ขั้นตอน build พัง
ธงแดงที่บ่งชี้ว่าคุณกำลังเบี่ยง:
ถือว่าการ import ข้ามแพ็กเกจเป็นการตัดสินใจ ไม่ใช่ค่าดีฟอลต์ เก็บการแก้ให้อยู่ภายในเว้นแต่คุณจะขยายขอบเขตจริง ๆ
วิธีเร็วที่สุดที่จะได้การแก้ถูกคือเริ่มจากข้อจำกัด ไม่ใช่ปริมาณ พรอมต์ที่ดีจะค่อนข้างเข้มข้น: บอก Claude ให้ดูที่ไหน ไม่ต้องดูอะไร และ “เสร็จ” แปลว่าอะไร
ก่อนวางโค้ด ให้เขียนคำนำสั้น ๆ ที่ปักงานไว้ที่จุดหนึ่งในรีโป ระบุแพ็กเกจ โฟลเดอร์ที่แน่นอน และเป้าหมายเฉพาะ แล้วใส่สรุปท้องถิ่น (จุดประสงค์ พึ่งพาหลัก ข้อบังคับสำคัญ) และไฟล์ entry ที่ยึดการเปลี่ยน
เช็กลิสต์:
\u003cpackage\u003e/\u003cpath\u003e. เป้าหมาย: \u003cone sentence\u003e. ไม่สนใจส่วนอื่นเว้นแต่ขอ\u003c5-10 lines\u003e. ไฟล์ entry: \u003cpath/to/file\u003e\u003c...\u003e. ห้ามเปลี่ยน: \u003cfolders/files or APIs\u003e. รักษาพฤติกรรม: \u003cwhat must stay true\u003eถ้า Claude เสนอการเปลี่ยนแปลงนอกขอบเขต ให้ถือเป็นสัญญาณ: ปรับพรอมต์ให้เข้มขึ้น หรือขยายขอบเขตโดยจงใจและบอกใหม่อย่างชัดเจน
สมมติรีโปของคุณมี apps/web-store (แอป React) และ packages/ui-kit (ปุ่ม อินพุต และสไตล์ที่แชร์) คุณอยากได้ฟีเจอร์เล็ก ๆ: เพิ่มปุ่ม “Save for later” ในหน้า cart โดยใช้ SaveIcon ใหม่จาก ui-kit ไม่มีอะไรอื่นควรถูกเปลี่ยน
ก่อนขอแก้ ให้สร้างสองสรุปท้องถิ่นที่ทำหน้าที่เป็นขอบเขต เก็บให้สั้น เจาะจง และมีความเห็นชัดเจนเกี่ยวกับสิ่งที่สำคัญ
# apps/web-store/LOCAL_SUMMARY.md
Purpose: Customer shopping UI.
Entry points: src/routes.tsx, src/pages/cart/CartPage.tsx
Cart rules: cart state lives in src/cart/useCart.ts
Do not touch: checkout flow (src/pages/checkout), payments, auth.
Tests: npm test -w apps/web-store
# packages/ui-kit/LOCAL_SUMMARY.md
Purpose: shared UI components.
Exports: src/index.ts
Icons: src/icons/*, add new icons by exporting from index.
Do not touch: theming tokens, build config.
Tests: npm test -w packages/ui-kit
จากนั้นรักษาการวนรอบให้แคบ:
CartPage and ui-kit icons. No checkout/auth edits.”CartPage, useCart, ไอคอน ui-kit, ui-kit index)หลังการเปลี่ยน ให้บันทึกเพื่อให้บริบทในอนาคตยังคงเล็ก:
ถ้ามันได้ผลสำหรับคนคนเดียวแต่ไม่ใช่คนทั้งทีม ส่วนที่หายไปมักเป็นการทำซ้ำได้ ทำให้ “สุขอนามัยบริบทที่ดี” เป็นค่าเริ่มต้น ไม่ใช่นิสัยส่วนบุคคล
บันทึกพรอมต์โครงที่เพื่อนร่วมทีมคัดลอกและกรอก คงให้สั้นแต่เข้มงวด รวมเป้าหมาย (คำว่า “เสร็จ” แปลว่าอะไร) ขอบเขตที่อนุญาต ขอบเขตห้ามแตะ และสัญญาผลลัพธ์ (แผนก่อน แล้วเป็นแพตช์ตามไฟล์พร้อมเทสต์)
ข้ามการรีวิวใหญ่เดือนละครั้งที่ไม่มีใครทำ ผนวกการอัปเดต summary เข้ากับงานปกติ: เมื่อการเปลี่ยนแปลงทำให้พฤติกรรม พึ่งพา หรือ API เปลี่ยน ให้แก้ SUMMARY.md ใน PR เดียวกัน
กฎง่าย ๆ: ถ้าเพื่อนร่วมทีมจะถามว่า “นี่อยู่ที่ไหน?” หรือ “อะไรขึ้นกับสิ่งนี้?” แปลว่าสรุปล้าสมัยแล้ว
ถ้าคุณชอบเวิร์กโฟลว์แบบแชทก่อน Koder.ai ช่วยให้การวนรอบนี้ปลอดภัยขึ้น โหมดวางแผนช่วยให้ตกลงขอบเขตก่อนแก้ และสแนปช็อตกับการยกเลิกช่วยให้ลองเปลี่ยนแล้วย้อนกลับได้หากการเดาผิด
Claude จะแม่นยำน้อยลงเมื่อมันไม่สามารถ “เห็น” แหล่งความจริงที่แท้จริงได้เลย。
ในมอนอรีโปขนาดใหญ่ โมเดลมักพลาดไฟล์ที่เป็น dependency สับสนกับแพ็กเกจที่คล้ายกัน หรือก็อปปี้รูปแบบเก่าที่อยู่ในบริบทเพราะนั่นคือสิ่งที่มันเห็นอยู่
อย่าพยายามใส่ทั้งรีโปเข้าไป เริ่มจากชุดไฟล์เล็กที่สุดที่พิสูจน์ได้ว่าการเปลี่ยนแปลงถูกต้อง。
ค่าเริ่มต้นที่ดีคือ:
แชร์สิ่งที่ยึดพฤติกรรมไว้ ไม่ใช่ทุกไฟล์ที่มีชื่อคล้ายกัน。
ชุดปฏิบัติได้จริงคือ:
เลือกขอบเขตหนึ่งที่สอดคล้องกับการจัดระเบียบรีโปของคุณ: แพ็กเกจ แอป หรือเซอร์วิส แล้วบอกให้ชัดว่าอะไรเป็น out-of-scope ตัวอย่างข้อจำกัด:
packages/cart/ และเทสต์ของมัน”เพราะมอนอรีโปมักมีโมดูลที่ดูคล้ายกัน (ui, ui-kit, shared-ui) และ helper ซ้ำ (date.ts หลายที่)。
Claude อาจนำแนวคิดที่ถูกต้องไปแก้แพ็กเกจที่ผิด หรือ import จากชื่อโมดูลที่ “เกือบถูก” ป้องกันด้วยการระบุแพ็กเกจและจุดเข้าใช้อย่างเจาะจง
Local summary คือแผนที่สั้น ๆ ของพื้นที่ที่คุณต้องการเปลี่ยน มักยาว 10–20 บรรทัด。
ใส่:
วางมันข้างโค้ดที่เกี่ยวข้องเพื่อให้หาได้ง่ายและแก้ไขได้ทันที。
ค่าเริ่มต้นง่าย ๆ:
SUMMARY.md หรือส่วนเล็ก ๆ ใน README.md ของแพ็กเกจบอก Claude ให้ทำเครื่องหมายสมมติฐานและสิ่งที่ไม่รู้ แทนการเดา。
กฎที่มีประโยชน์:
ใช้ลูปแน่น ๆ ที่บังคับให้ต้องหา context เป็นชิ้นเล็ก ๆ:
เขียน “สัญญา” เล็ก ๆ ในพรอมต์และทำให้มันบังคับใช้ได้:
สิ่งนี้ทำให้การรีวิวง่ายขึ้นและลดการแก้ไขข้ามแพ็กเกจโดยไม่ตั้งใจ