Claude Code ในมอนอรีโป: จำกัดบริบทและคงความแม่นยำ

ทำไมมอนอรีโปขนาดใหญ่ทำให้ Claude แม่นยำน้อยลง

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 วิธีเพื่อค้นหามัน”

กำหนดขอบเขตที่ชัดเจนที่ Claude ห้ามข้าม

ในมอนอรีโปใหญ่ ความแม่นยำลดลงเมื่อโมเดลเริ่ม “ช่วยเหลือ” โดยดึงโค้ดใกล้เคียงที่ไม่เกี่ยวกับงาน วิธีแก้คือง่าย: กำหนดสิ่งที่อยู่ในขอบเขตและนอกขอบเขตก่อนขอเปลี่ยน

เริ่มจากขอบเขตที่สอดคล้องกับการจัดระเบียบรีโปของคุณ: แพ็กเกจ เซอร์วิส แอป หรือไลบรารีแชร์ ถ้าการเปลี่ยนคือ “อัปเดต 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

สรุปท้องถิ่นที่มีประโยชน์ตอบคำถามห้าข้อนี้:

• แพ็กเกจ/เซอร์วิสนี้ใช้ทำอะไร และไม่ทำอะไร (ขอบเขต)
• งานเริ่มที่ไหน (entry points เช่น ไฟล์หลัก routes คำสั่ง หรือคอมโพเนนต์)
• อะไรปลอดภัยที่จะเรียกจากภายนอก (public APIs, โมดูลที่ export, เหตุการณ์, endpoints)
• พึ่งพาอะไรบ้าง (ฐานข้อมูล คิว แคช config บริการภายนอก)
• มีกฎอะไรที่สำคัญที่นี่ (รูปแบบการตั้งชื่อ สไตล์การจัดการข้อผิดพลาด การล็อก และวิธีเขียนเทสต์)

เพิ่มบรรทัด “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) ข้างแต่ละแพ็กเกจ เซอร์วิส หรือแอป แทนเอกสารใหญ่รวมที่รากรีโป

โครงสร้างที่เรียบง่ายและทำซ้ำได้ช่วยได้ เก็บสั้นพอที่คนจะยังรักษามัน:

• โฟลเดอร์นี้คืออะไร (จุดประสงค์ 1–2 ประโยค)
• พื้นผิวสาธารณะ (entry points, โมดูลที่ export, หรือ API หลัก)
• พึ่งพาหลัก (ภายในและภายนอก)
• ขอบเขต (ห้าม import หรือแก้ไขอะไร)
• วิธีทดสอบ (การตรวจสอบเร็วสุด)
• Last updated: YYYY-MM-DD - \u003cwhat changed in one sentence\u003e

สรุปจะกลายเป็นล้าสมัยด้วยสาเหตุที่คาดได้ จัดการการอัปเดตเหมือนการอัปเดตคำจำกัดความของไทป์: เป็นส่วนหนึ่งของการทำงานเสร็จ ไม่ใช่งานแยก

อัปเดตสรุปเมื่อการรีแฟกเตอร์เปลี่ยนโครงสร้างหรือชื่อ โมดูลใหม่กลายเป็นวิธีหลักในการทำสิ่งหนึ่ง API/event/schema เปลี่ยน (แม้เทสต์ยังผ่าน) ขอบเขตระหว่างแพ็กเกจเปลี่ยน หรือลบ/แทนที่ dependency

นิสัยเชิงปฏิบัติ: เมื่อคุณ merge การเปลี่ยน ให้เพิ่มบรรทัด “Last updated” ว่ามีอะไรเปลี่ยน Tools อย่าง Koder.ai สามารถช่วยเร่งการเปลี่ยนแปลงโค้ด แต่สรุปคือสิ่งที่รักษาความแม่นยำในการเปลี่ยนในอนาคต

เวิร์กโฟลว์ทีละขั้นตอนเพื่อให้อยู่ในบริบทที่ถูกต้อง

ความแม่นยำมักขึ้นอยู่กับจังหวะการคุย ให้ Claude หา context ทีละชิ้นแทนการเดาจากสแนปช็อตใหญ่

ขั้นตอนที่ 1: ขอแผนที่สั้น ๆ ก่อน

ก่อนจะแก้ใด ๆ ขอให้ Claude อธิบายสิ่งที่มันเห็นและสิ่งที่ต้องการ แผนที่ที่ดีสั้น: แพ็กเกจหลักที่เกี่ยวข้อง, จุดเข้าใช้ของ flow, และที่เทสต์หรือไทป์อยู่

พรอมต์:

“Create a map of this change: packages involved, main flow, and likely touch points. Do not propose code yet.”

ขั้นตอนที่ 2: เริ่มจากสไลซ์เดียวและขอบเขตเดียว

เลือกสไลซ์แคบ ๆ: ฟีเจอร์หนึ่ง แพ็กเกจหนึ่ง หรือ flow หนึ่ง ระบุขอบเขตให้ชัด (เช่น: “Only change packages/billing-api. Do not touch shared-ui or infra.”)

เวิร์กโฟลว์ที่ช่วยให้คุณควบคุม:

• กำหนดเป้าหมายและขอบเขตในหนึ่งประโยค
• บังคับให้มีการระบุสมมติฐานและสิ่งที่ไม่รู้ (Claude ต้องรายการ)
• ขอให้บอกไฟล์ที่ต้องการต่อไป (จำกัด 3–6 ไฟล์)
• ให้ไฟล์เหล่านั้นเท่านั้น แล้วทำซ้ำ
• ขอแผนสั้นก่อนแพตช์ใด ๆ

ขั้นตอนที่ 3: บังคับให้สมมติฐานและคำขอไฟล์ชัดเจน

ถ้า Claude ขาดอะไร มันควรบอก ให้สั่งให้มันเขียน: (1) สมมติฐานที่มันทำ (2) สิ่งที่จะล้มล้างสมมติฐานเหล่านั้น และ (3) ไฟล์ถัดไปที่ต้องยืนยัน

ตัวอย่าง: คุณต้องเพิ่มฟิลด์ให้ Invoice response ในแพ็กเกจหนึ่ง Claude ขอ handler, DTO/type definition, และเทสต์หนึ่งตัว คุณแชร์เฉพาะพวกนั้น ถ้าคุณใช้เครื่องมือแชทแบบสร้างโปรเจกต์ เช่น Koder.ai กฎเดียวกันใช้: ให้ชุดไฟล์เล็กที่สุด แล้วค่อยขยายเมื่อจำเป็นจริง ๆ

ใช้ข้อจำกัดและสัญญาในพรอมต์ของคุณ

การป้องกันการแก้ผิดที่ดีที่สุดคือ “สัญญา” เล็ก ๆ ในพรอมต์: อะไรที่ Claude สัมผัสได้ วิธีที่คุณจะตัดสินความสำเร็จ และกฎที่มันต้องปฏิบัติตาม

เริ่มจากขอบเขตที่ปฏิบัติตามได้และตรวจสอบได้ ระบุอย่างชัดที่จะแก้และชื่อโซนที่ห้ามแตะเพื่อไม่ให้เกิดความอยากย้ายขอบเขต

เทมเพลตสัญญา:

• แก้เฉพาะไฟล์ใต้ packages/payments/ เท่านั้น
• ห้ามแก้ packages/auth/, infra/, หรือ config ร่วมใด ๆ
• ถ้าต้องการการเปลี่ยนแปลงนอกขอบเขต ให้หยุดแล้วถามก่อน
• ทำการเปลี่ยนแปลงให้น้อยที่สุด: แก้บั๊ก หลีกเลี่ยงการรีแฟกเตอร์

จากนั้นกำหนดเกณฑ์ยอมรับ ถ้าไม่มีอมตะ Claude อาจผลิตโค้ดที่ดูถูกแต่ขัดกับกฎจริงของรีโป

• รันยูนิตเทสต์สำหรับแพ็กเกจ (ระบุคำสั่ง)
• รัน lint/format (ระบุเครื่องมือ หรือบอกว่า “ใช้ config ที่มีอยู่”)
• รัน typecheck/build สำหรับแพ็กเกจ
• ยืนยันว่าแอปยังเริ่มได้ (คำสั่งรันง่าย ๆ ก็พอ)

ข้อจำกัดด้านสไตล์ก็สำคัญ บอก 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 ข้ามขอบเขตแพ็กเกจ
• มองข้าม feature flags หรือ branches ที่ขึ้นกับ env
• แนะนำการเพิ่ม dependency ให้แพ็กเกจแชร์หลัก

ถือว่าการ import ข้ามแพ็กเกจเป็นการตัดสินใจ ไม่ใช่ค่าดีฟอลต์ เก็บการแก้ให้อยู่ภายในเว้นแต่คุณจะขยายขอบเขตจริง ๆ

เช็กลิสต์ด่วนก่อนขอ Claude ทำอะไร

วิธีเร็วที่สุดที่จะได้การแก้ถูกคือเริ่มจากข้อจำกัด ไม่ใช่ปริมาณ พรอมต์ที่ดีจะค่อนข้างเข้มข้น: บอก 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
• ขอไฟล์ก่อน: “Before proposing changes, list the minimum files you need to see (max 5) and why.”
• รูปแบบผลลัพธ์: “Reply with a short plan first. After I confirm, give patch-style suggestions by file.”

ถ้า 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

จากนั้นรักษาการวนรอบให้แคบ:

1. Map: “This change is limited to CartPage and ui-kit icons. No checkout/auth edits.”
2. Assumptions: บังคับให้รายการสมมติฐานและรอการยืนยัน
3. File requests: อนุมัติเฉพาะไฟล์ที่ต้องการจริง ๆ (CartPage, useCart, ไอคอน ui-kit, ui-kit index)
4. Plan: ยืนยันว่าตรงขอบเขต
5. Edits: ทำ diff ที่เล็กที่สุด แล้วขอเทสต์ที่อัปเดต

หลังการเปลี่ยน ให้บันทึกเพื่อให้บริบทในอนาคตยังคงเล็ก:

• อัปเดตสรุปท้องถิ่นทั้งสองด้วยการ export ใหม่และไฟล์ที่ถูกแก้จริง
• เพิ่มคอมเมนต์หัวหน้าหน้า cart ว่าปุ่มทำอะไรและสถานะถูกจัดการที่ไหน
• บันทึกคำสั่งเทสต์ที่ผ่าน (และ snapshots ที่อัปเดตถ้ามี)

ขั้นตอนถัดไป: ทำให้ทีมทำตามได้ซ้ำ ๆ

ถ้ามันได้ผลสำหรับคนคนเดียวแต่ไม่ใช่คนทั้งทีม ส่วนที่หายไปมักเป็นการทำซ้ำได้ ทำให้ “สุขอนามัยบริบทที่ดี” เป็นค่าเริ่มต้น ไม่ใช่นิสัยส่วนบุคคล

แปลงพรอมต์ที่ดีที่สุดของคุณเป็นเทมเพลตทีม

บันทึกพรอมต์โครงที่เพื่อนร่วมทีมคัดลอกและกรอก คงให้สั้นแต่เข้มงวด รวมเป้าหมาย (คำว่า “เสร็จ” แปลว่าอะไร) ขอบเขตที่อนุญาต ขอบเขตห้ามแตะ และสัญญาผลลัพธ์ (แผนก่อน แล้วเป็นแพตช์ตามไฟล์พร้อมเทสต์)

ทำให้สรุปทันสมัยด้วยจังหวะเบา ๆ

ข้ามการรีวิวใหญ่เดือนละครั้งที่ไม่มีใครทำ ผนวกการอัปเดต summary เข้ากับงานปกติ: เมื่อการเปลี่ยนแปลงทำให้พฤติกรรม พึ่งพา หรือ API เปลี่ยน ให้แก้ SUMMARY.md ใน PR เดียวกัน

กฎง่าย ๆ: ถ้าเพื่อนร่วมทีมจะถามว่า “นี่อยู่ที่ไหน?” หรือ “อะไรขึ้นกับสิ่งนี้?” แปลว่าสรุปล้าสมัยแล้ว

ถ้าคุณชอบเวิร์กโฟลว์แบบแชทก่อน Koder.ai ช่วยให้การวนรอบนี้ปลอดภัยขึ้น โหมดวางแผนช่วยให้ตกลงขอบเขตก่อนแก้ และสแนปช็อตกับการยกเลิกช่วยให้ลองเปลี่ยนแล้วย้อนกลับได้หากการเดาผิด