CLAUDE.md ที่รอดจาก Context Compaction: ออกแบบกฎให้ AI ไม่ลืมกลางทาง

ถ้าคุณเคยเขียนกฎไว้ใน CLAUDE.md อย่างดี แล้วพองานยาวขึ้น Claude ก็เริ่มทำตัวเหมือนไม่เคยอ่านกฎนั้นเลย — คุณไม่ได้คิดไปเอง มันคืออาการของ context compaction ที่เกิดกับงานจริงทุกงานที่ยาวพอ ผมทำ model risk กับ data ในแบงก์ และใช้ Claude Code รันงานยาว ๆ ทั้งวัน บทเรียนที่แลกมาด้วยความเจ็บปวดคือ "กฎที่เขียนไว้" กับ "กฎที่ AI ยังจำได้ตอนชั่วโมงที่สาม" เป็นคนละเรื่องกัน บทความนี้คือวิธีออกแบบ CLAUDE.md ให้กฎสำคัญ รอด ไม่ใช่แค่ถูกเขียน

1. ทำไม CLAUDE.md ถึง "หาย" กลางทาง

CLAUDE.md ไม่ใช่กฎเหล็กที่ AI ยึดตายตัว — มันคือข้อความที่ถูกใส่เข้าไปใน context เหมือนข้อความอื่น ๆ พอบทสนทนายาวจนเกินงบ context window ระบบจะ สรุปย่อ (compaction) ของเก่าทิ้งเพื่อเอาที่ว่าง สิ่งที่โดนสรุปก่อนมักเป็นรายละเอียดกลาง ๆ ที่ดู "ไม่ใช่งานตรงหน้า" — ซึ่งบ่อยครั้งคือกฎ governance ของคุณนั่นเอง

ผมเขียนเรื่องนี้แยกไว้แล้วว่าทำไม การมี CLAUDE.md ไม่ใช่หลักประกันว่า AI จะทำตาม ประเด็นสำคัญคือ ยิ่งคุณยัดกฎลงไฟล์เดียวเยอะเท่าไหร่ โอกาสที่กฎสำคัญจะถูกกลบหรือถูกสรุปทิ้งก็ยิ่งสูง การออกแบบที่ดีจึงไม่ใช่ "เขียนให้ครบ" แต่คือ "ทำให้กฎที่ถูกตัวมาอยู่ในหัว AI ตอนที่ต้องใช้"

ทำไมมันสำคัญกับเรา: สำหรับคนทำงาน risk/compliance นี่คือเรื่องเดียวกับ control ที่ "มีอยู่บนกระดาษ" แต่ไม่ทำงานตอน production — ผู้ตรวจไม่สนว่าคุณเขียนนโยบายไว้สวยแค่ไหน เขาสนว่ามันบังคับใช้จริงตอนไหน CLAUDE.md ก็เหมือนกัน

2. Load-trigger hierarchy: อย่าโหลดทุกกฎพร้อมกัน

หลักแรกที่เปลี่ยนเกมคือ เลิกคิดว่า CLAUDE.md ต้องบรรจุทุกกฎไว้ตลอดเวลา ให้แยกกฎออกเป็นชั้น แล้วกำหนด "ทริกเกอร์" ว่ากฎชุดไหนควรถูกโหลดก่อนทำอะไร เช่น กฎเกี่ยวกับการแก้ไฟล์ตั้งค่าให้โหลดก่อนแตะไฟล์ตั้งค่า กฎการเขียนเนื้อหาให้โหลดก่อนเขียนเนื้อหา

หน้าตาแบบย่อ ๆ คือตารางสั้น ๆ ในไฟล์หลัก ที่บอกว่า "ก่อนทำ X → อ่านไฟล์กฎ Y":

| โหลดก่อน | เมื่อจะทำ... |
|---|---|
| @rules/data-handling.md | แตะข้อมูลลูกค้า/ข้อมูลอ่อนไหว |
| @rules/deploy.md | push หรือแก้ pipeline |

ประโยชน์มีสองชั้น: (1) context หลักเบาลง เพราะกฎรายละเอียดไม่ได้ถูกแบกตลอดเวลา และ (2) กฎที่ "เพิ่งถูกอ่าน" จะอยู่ใกล้ปลายบทสนทนา = รอดจากการถูกสรุปทิ้งมากกว่ากฎที่อยู่บนสุดมาตั้งแต่ต้น

ทำไมมันสำคัญกับเรา: มันคือหลัก "least privilege" แต่ใช้กับ context — เอาเฉพาะกฎที่จำเป็น ณ ขณะนั้นเข้ามา ลดทั้ง noise และโอกาสที่ AI จะหยิบกฎผิดบริบทมาใช้

3. @-reference: แตกกฎเป็นไฟล์ย่อยแล้วลิงก์

เครื่องมือที่ทำให้ load-trigger เป็นจริงคือ @-reference — แทนที่จะเขียนกฎ 500 บรรทัดในไฟล์เดียว ให้แตกเป็นไฟล์ย่อยตามหัวข้อ (@wiki/data-rules.md, @tools/deploy-reference.md) แล้วในไฟล์หลักอ้างถึงมันเฉพาะจุดที่เกี่ยว ไฟล์หลักจึงสั้น อ่านง่าย และทำหน้าที่เป็น "สารบัญกฎ" มากกว่าจะเป็นกองกฎ

วิธีคิดที่ผมใช้คือมองไฟล์หลักเป็น router ไม่ใช่ database: มันไม่ได้เก็บความรู้ทั้งหมด แต่ชี้ทางว่าความรู้แต่ละก้อนอยู่ไหนและควรดึงมาเมื่อไหร่ แนวคิดนี้ต่อยอดได้ดีกับการใช้ wiki เป็น second brain ให้ Claude — ความรู้อยู่ใน wiki ส่วน CLAUDE.md แค่บอกว่าเมื่อไหร่ควรเปิดหน้าไหน

ข้อควรระวังคือ ไฟล์ที่ถูก @-อ้างแบบ nested (ไฟล์ย่อยที่อ้างไฟล์ย่อยอีกที) มักเป็นกลุ่มแรกที่หายหลัง compaction เพราะมันไม่ได้ถูก re-inject อัตโนมัติเหมือนไฟล์หลัก ตรงนี้เองที่นำไปสู่หลักข้อสุดท้าย

ทำไมมันสำคัญกับเรา: การแยกไฟล์ทำให้ "เวอร์ชันของกฎ" ตรวจสอบได้ทีละก้อน — เปลี่ยนกฎ data handling ก็เห็น diff เฉพาะไฟล์นั้น ไม่ใช่ commit ที่ปนกันทั้งนโยบาย เป็นวินัยเดียวกับการทำ change management ที่ auditable

4. ออกแบบให้รอด compaction: re-inject และ post-compaction reload

กฎที่ต้อง "อยู่ตลอด" จริง ๆ (เช่น ห้ามส่งข้อมูลอ่อนไหวออกนอกเครื่อง) ต้องวางในจุดที่ระบบ re-inject ให้อัตโนมัติหลัง compaction — โดยทั่วไปคือไฟล์ CLAUDE.md หลักและ memory index ไม่ใช่ไฟล์ย่อยที่ถูก @-อ้าง เพราะกลุ่มหลังจะเงียบหายหลังถูกสรุป

เทคนิคที่ผมใช้คู่กันคือ post-compaction reload: เขียนกฎสั้น ๆ ในไฟล์หลักว่า "ถ้าเห็นสัญญาณว่าเพิ่งมีการ compaction ให้ถือว่าไฟล์ที่ @-โหลดไว้ถูกล้างแล้ว → โหลดซ้ำก่อนทำงานชิ้นถัดไป" เท่ากับสอนให้ AI กู้กฎของตัวเองกลับมาเอง แทนที่จะรอให้เรามาเตือน และควรตั้งให้ระบบ compaction ทำงานเร็วขึ้นเล็กน้อยกว่าค่า default เพื่อกันไม่ให้ของสำคัญหลุดตอนใกล้เต็มจริง ๆ

แนวทางนี้เข้ากันกับการวาง ritual และ hooks ต้น/ท้าย session: hook บังคับขั้นตอนที่ "ลืมไม่ได้" ด้วยกลไกระดับ harness ส่วน CLAUDE.md ดูแลกฎเชิงดุลพินิจ — สองชั้นนี้เสริมกัน ชั้นหนึ่งกันพลาดแบบ deterministic อีกชั้นกันพลาดแบบ contextual

ทำไมมันสำคัญกับเรา: นี่คือ "control ที่ฟื้นตัวเองได้" — ใน model risk เราชอบ control ที่ไม่พึ่งความจำของคน ระบบที่รู้ว่าตัวเองเพิ่งลืมแล้วไปหยิบกฎกลับมา ปลอดภัยกว่าระบบที่หวังว่ากฎจะยังอยู่

ภาพรวม

CLAUDE.md ที่ดีไม่ได้วัดกันที่ "เขียนกฎไว้กี่ข้อ" แต่วัดกันที่ "กฎสำคัญยังทำงานอยู่ไหมตอนชั่วโมงที่สาม" สามเสาหลักคือ load-trigger (โหลดกฎเฉพาะตอนใช้), @-reference (แตกเป็นไฟล์ย่อย ไฟล์หลักเป็น router), และ post-compaction reload (สอนให้ AI กู้กฎกลับมาเอง) ใครที่เพิ่งเริ่ม ลองอ่านทำไมคนสายการเงินควรเรียน Claude Code เป็นจุดตั้งต้นก่อนได้ และถ้าอยากลงลึกเรื่องการคุมงบ context ระหว่างงานยาว ๆ ผมแยกเทคนิคไว้ในContext Budget: 6 เทคนิคทำให้ Claude Code ไม่ลืมงานกลางทาง

ส่วนตัว CLAUDE.md เต็ม ๆ ที่ผมใช้จริง — ทั้ง load-trigger matrix, โครงไฟล์ย่อยทั้งชุด, และเช็คลิสต์ compaction-survival ที่ผม calibrate มากับงานแบงก์จริง — ผมรวมไว้ให้ก็อปไปปรับใช้ได้เลยในคอร์ส Claude Code พร้อม workspace ตัวอย่างที่ทำงานได้จริง