Agent Dev Thai Academyprinciples · patterns · architecture

Spec-Driven Development: ผมไม่เคยกลัว /clear กับ /compact

ผมไม่กลัว /clear กับ /compact เพราะให้ Claude อัพเดท spec.md กับ data contract ทุกครั้งที่ทำ task เสร็จ session ใหม่แค่สั่ง read spec.md ก็ทำต่อได้ทันที

ผมไม่เคยกลัว /clear กับ /compact

ใช้ Claude Code มาหลายเดือน พิมพ์ /clear ทุกวัน /compact ก็เจอบ่อย session crash ก็มี แต่ไม่เคยต้องนั่งอธิบายใหม่ว่า "ที่ทำอยู่คืออะไร ถึงไหนแล้ว architecture ตกลงกันไว้ยังไง"

เพราะผมไม่ได้พึ่ง context window แต่พึ่ง spec.md


ปัญหาที่ทุกคนเจอ

/clear หรือ /compact → context หายหมด → ใช้เวลา 15-20 นาทีอธิบายว่า "เรากำลังสร้างอะไร" "ทำถึงไหนแล้ว" "API contract ตกลงไว้ยังไง" "ทำไมเลือก approach นี้"

ทุกครั้งที่ต้องอธิบายซ้ำ เสียทั้งเวลาและ token

ยิ่งถ้าทำงานข้าม 3 repos พร้อมกันเหมือนผม context ที่ต้องโหลดกลับมาทุก session เยอะมาก

บางคนแก้ปัญหานี้ด้วยการหวังว่า context window จะยาวขึ้น หรือ copy-paste chat เก่ามาให้อ่าน

ทั้งสองวิธี scale ไม่ค่อยได้


วิธีของผม: spec.md คือ save point

ทุก task ที่ Claude ทำเสร็จ มันอัพเดท spec.md ให้เอง ไม่ต้องสั่งทุกครั้ง ใส่เป็น rule ใน CLAUDE.md ครั้งเดียวจบ

spec.md มี 4 ส่วน:

  1. สถาปัตยกรรมปัจจุบัน — component อะไรบ้าง เชื่อมกันยังไง ใช้ tech อะไร
  2. สิ่งที่ทำเสร็จแล้ว — ไม่ใช่ list หยาบๆ แต่บอกด้วยว่าตัดสินใจอะไรไปบ้าง ทำไมเลือก approach นี้
  3. สิ่งที่ยังไม่ได้ทำ — backlog ที่ update ทุกครั้ง ไม่ใช่ backlog ที่เขียนวันแรกแล้วไม่เคยแตะ
  4. current state — ส่วนที่สำคัญที่สุด บอกว่า "ตอนนี้กำลังทำอะไร" "ค้างอยู่ตรงไหน" "ต้องทำอะไรต่อ"

current state คือ save point จริงๆ เหมือนเล่นเกมแล้ว save ก่อนปิด เปิดมาใหม่โหลด save ได้เลย


data contract คือ boundary ที่ Claude ข้ามไม่ได้

นอกจาก spec.md ผมให้ Claude เขียน data contract ด้วย — interface definition ระหว่าง component

เช่น frontend ส่ง field อะไรมาให้ backend, API response มี shape ยังไง, event payload มีอะไรบ้าง — พวกนี้เขียนเป็น type definition ไว้ใน spec

ทำไมเรื่องนี้สำคัญ — เพราะ session ใหม่จะไม่มีทางรู้ว่า "frontend ส่ง field อะไรมาให้ backend" ถ้าไม่มี contract เขียนไว้

ถ้าไม่มี contract → session ใหม่เดา → เดาผิด → เสียเวลา debug สิ่งที่ session เก่าตกลงไว้แล้ว

ถ้ามี contract → session ใหม่อ่าน → ทำต่อได้ทันที → ไม่มีเดา


rule ที่ใส่ใน CLAUDE.md

ผมไม่ได้สั่ง "อัพเดท spec.md ด้วยนะ" ทุกรอบ ใส่เป็น rule ครั้งเดียว:

## After completing any task:
1. Update spec.md — current state, decisions made, what's next
2. Update data contracts if any interface changed
3. Never claim "done" without updating spec.md first

แค่นี้ Claude ทำเองทุกครั้ง ไม่ต้องจำ ไม่ต้องเตือน


ใช้จริงเป็นยังไง

session เก่า: ทำ API endpoint เสร็จ 3 ตัว กำลังทำตัวที่ 4 อยู่ token หมด

session ใหม่: พิมพ์ "read spec.md" → Claude รู้บริบทที่ต้องใช้ทำงานต่อทันที → ทำ endpoint ตัวที่ 4 ต่อได้เลย

ไม่ต้องอธิบาย ไม่ต้อง copy-paste chat เก่า ไม่ต้องจำว่า "เมื่อวานทำถึงไหน"

spec.md จำให้


ทำไม spec.md ดีกว่า context window ยาวขึ้น

ต่อให้ context window ไม่จำกัด — spec.md ก็ยังดีกว่า implicit context

เพราะ explicit spec บังคับให้ Claude จัดระเบียบความเข้าใจ ไม่ใช่แค่ "จำ" สิ่งที่เกิดขึ้นใน chat

chat ยาว 100,000 token = Claude อาจจะจำได้ว่าตกลงอะไรไว้
spec.md ไม่กี่ร้อยบรรทัด = reference ที่ชัดกว่า chat ยาวๆ มาก

implicit context เสื่อมไปเรื่อยๆ ตาม token ที่ใช้ เหมือน RAM ที่เริ่ม swap
explicit spec คงที่ ไม่เปลี่ยนตาม session length


เริ่มยังไง

ไม่ต้องทำซับซ้อน เริ่มจาก:

  1. สร้าง spec.md ใน root ของ project
  2. ใส่ 4 section: architecture, done, todo, current state
  3. เพิ่ม rule ใน CLAUDE.md ว่า "update spec.md after every task"
  4. session ใหม่เริ่มด้วย "read spec.md" ทุกครั้ง

ลองกับ project ถัดไปที่เปิด Claude Code แล้วจะรู้เลยว่า — token หมดไม่ใช่ปัญหาอีกต่อไป เพราะ context ไม่ได้อยู่ใน session มันอยู่ใน file