CLAUDE.md ที่ใช้ได้จริงตอนสร้าง Terminal — และจุดที่มันเอาไม่อยู่ ต้องใช้ hook แทน

CLAUDE.md คือกฎที่ AI agent อ่านทุก session แต่เอกสารทางการเองก็บอกว่ามันเป็น 'context ไม่ใช่ config ที่บังคับได้' นี่คือวิธีวางกฎที่ใช้จริงใน repo ของ Boom Leverage: ไฟล์กฎที่ถูก generate และล็อกไม่ให้แก้มือ, ไฟล์ความจำที่มีงบ byte ตายตัว และด่านที่ย้ายจากคำขอร้องไปเป็น hook

โดย วรัญชัย ยิ่งคำนึง (Boom) · เผยแพร่ครั้งแรก 24 มิถุนายน 2569 · ตรวจทานล่าสุด 27 กันยายน 2569

ทุกคนที่เริ่มใช้ Claude Code จริงจังจะมาถึงจุดเดียวกัน: เขียนกฎใน CLAUDE.md ไว้ชัดเจน แล้ววันหนึ่ง agent ก็ทำผิดกฎนั้นอยู่ดี ความรู้สึกแรกคือ "มันไม่อ่านเหรอ" คำตอบคือมันอ่าน — แต่การอ่านไม่เท่ากับการถูกบังคับ

บทความนี้รวมสองบทความเดิม (ออกแบบ CLAUDE.md ให้รอด context compaction + อย่าฝากความหวังไว้กับ CLAUDE.md) และเล่าจากระบบจริงที่ใช้สร้าง Boom Leverage Terminal

CLAUDE.md คืออะไร และมันรับประกันอะไรได้บ้าง?

CLAUDE.md คือไฟล์ markdown ที่ Claude Code อ่านตอนเริ่มทุก session ใช้บอกกติกาของโปรเจกต์: โครงสร้าง ข้อห้าม วิธีตรวจงาน ข้อดีคือไม่ต้องเล่าใหม่ทุกเช้า

แต่เอกสารทางการเขียนขอบเขตไว้ชัด:

Claude treats them as context, not enforced configuration. To block an action regardless of what Claude decides, use a PreToolUse hook instead. The more specific and concise your instructions, the more consistently Claude follows them.

แปลว่ามีกฎสองชนิดที่ต้องแยกให้ออก:

ความผิดพลาดที่พบบ่อยที่สุดคือเอาเส้นตายไปเขียนเป็นแนวทาง แล้วหวังว่ามันจะไม่พลาด

ใน repo ของ Terminal วางกฎกันยังไง?

ผมเลิกแก้ CLAUDE.md ด้วยมือมาตั้งแต่ ก.ค. 2026 ตอนนี้มันเป็นไฟล์ที่ generate มาจากหน้า wiki 9 หน้า (ไฟล์ .py) แล้วล็อกสิทธิ์เป็นอ่านอย่างเดียว บรรทัดแรกๆ ของไฟล์เขียนไว้ว่า:

🤖 GENERATED FILE — ห้ามแก้ CLAUDE.md ด้วยมือ. ไฟล์นี้ render จาก wiki/canon/*.py

ทำไมต้องยุ่งขนาดนี้? เพราะเจอปัญหาจริงสามอย่าง:

1. กฎขัดกันเอง — แก้ที่หนึ่ง ลืมอีกที่ พอมีต้นฉบับเดียว (wiki) ความขัดแย้งหายไปโดยโครงสร้าง
2. agent แก้กฎตัวเอง — agent ที่ติดกฎบางข้ออาจ "แก้ปัญหา" ด้วยการแก้ไฟล์กฎ พอไฟล์เป็น chmod 444 มันเขียนไม่ได้
3. กฎบวม — ทุกเหตุการณ์กลายเป็นกฎใหม่หนึ่งบรรทัด จนไฟล์ยาวเกินที่จะทำตามได้

ไฟล์ความจำต้องมีงบประมาณไหม?

ต้องมี เพราะทุกไบต์ในไฟล์ที่โหลดทุก session คือ "ภาษี" ที่จ่ายทุกครั้ง ผมตั้งงบให้ MEMORY.md (ไฟล์ความจำที่ agent โหลดอัตโนมัติ) แบบตายตัว และให้สคริปต์ที่ render มันเป็นคนบังคับ:

กติกาของ MEMORY.md คือ: ของที่สำคัญระดับวิกฤตเท่านั้นที่ได้เข้า (เสียหายจริง, ต้องรู้ก่อนพิมพ์คำสั่งแรก, หาเองไม่เจอ, ไม่ซ้ำกับ CLAUDE.md, ไม่เน่าตามเวลา) ถ้าเกินงบ สคริปต์จะ fail ดังๆ ให้คนไปตัดเอง ไม่ใช่ตัดเงียบๆ

จุดที่ระบบนี้ยังพลาดอยู่คืออะไร?

ต้องยอมรับตรงๆ: เอกสาร Claude Code แนะนำให้ CLAUDE.md "under 200 lines" แต่ CLAUDE.md หลักของ lab ยาว 401 บรรทัด — เกินเท่าตัว และ AGENTS.md ของเว็บก็ 413 บรรทัด

ความเสี่ยงที่ตามมาคือ ยิ่งไฟล์ยาว กฎแต่ละข้อยิ่งถูกเจือจาง — ตรงข้ามกับที่เอกสารบอกว่ากฎที่เจาะจงและกระชับถูกทำตามสม่ำเสมอกว่า ทางแก้ที่ใช้อยู่และกำลังทำต่อ:

• ย้ายเส้นตายไปเป็น hook — เช่น การอ่านไฟล์ลับทั้งก้อน ตอนนี้ถูกบล็อกโดย hook ก่อนรัน ไม่ได้พึ่งกฎในไฟล์ (ดูตัวอย่างจริงใน ทำไมผมสร้าง Terminal ด้วย Claude Code)
• ย้ายขั้นตอนเฉพาะงานไปเป็นเอกสารที่โหลดเมื่อจำเป็น — CLAUDE.md ของ lab มีตาราง "โหลดไฟล์นี้ก่อนทำงานประเภทนี้" แทนการยัดทุกอย่างไว้ในไฟล์เดียว เอกสารทางการก็แนะนำให้ย้ายขั้นตอนเฉพาะไปเป็น skill ที่โหลดตอนเรียกใช้
• เขียนกฎให้เจาะจง — "ห้าม rm — mv → .archive/YYYY-MM-DD/" ทำตามได้ดีกว่า "ระวังเรื่องการลบไฟล์" มาก

กฎรอดข้าม context compaction ได้ยังไง?

เมื่อบทสนทนายาวจนใกล้เต็ม Claude Code จะสรุปประวัติเก่าเพื่อคืนพื้นที่ (auto-compaction) เนื้อหาที่เคยโหลดกลางทางอาจหายไปจาก context ผมใช้สองวิธี:

1. กฎที่ต้องรอดทุกกรณีอยู่ในไฟล์ที่โหลดใหม่เสมอ (CLAUDE.md ราก + MEMORY.md) ไม่ใช่ในข้อความที่พิมพ์กลางแชต
2. เขียนใน CLAUDE.md ว่าหลัง compaction ให้โหลดเอกสารอ้างอิงที่จำเป็นซ้ำ ก่อนทำงานประเภทนั้นต่อ และใช้ hook ก่อน compact เพื่อแนบสถานะงานที่ค้างเข้าไปในบริบทหลังสรุป

สรุป

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