เขียนเทสต์ก่อน แล้ววนแก้จาก failure และ interview pattern
แนวคิด
test-driven iteration คือการเขียน test suite ให้ครอบพฤติกรรมที่คาดหวัง edge case และข้อกำหนดด้านประสิทธิภาพก่อน แล้วค่อย iterate ด้วยการแชร์ผล test failure ให้ Claude เป็นตัวชี้ทาง เทสต์ทำหน้าที่เป็น check ที่ให้สัญญาณผ่านหรือไม่ผ่านที่ Claude อ่านได้เอง มันจึงลงมือทำ รันเทสต์ อ่านผล แล้ววนแก้จนผ่านโดยไม่ต้องให้เราคอยเป็นวงจรตรวจสอบเอง
รูปแบบที่เอกสารแนะนำชัดคือ อธิบายอาการของบั๊ก บอกตำแหน่งที่น่าจะเป็น แล้วสั่งให้ "เขียน failing test ที่ reproduce ปัญหาก่อน แล้วจึงแก้" การมีเทสต์ที่ล้มเหลวอยู่ตรงหน้าทำให้ทั้งเรารู้ว่าปัญหาถูก reproduce จริง และทำให้ Claude มีเป้าที่วัดได้ว่าแก้สำเร็จเมื่อเทสต์เขียว
ทำไมสำคัญ
เหตุผลที่ต้องมี check ที่รันได้คือ Claude หยุดเมื่องาน "ดูเหมือนเสร็จ" ถ้าไม่มีอะไรให้รันตรวจ คำว่าดูเหมือนเสร็จคือสัญญาณเดียวที่มี และเราจะกลายเป็นวงจรตรวจสอบเอง ทุกความผิดพลาดต้องรอให้เราเห็น การให้เทสต์ที่คืนผลผ่านหรือไม่ผ่านทำให้ loop ปิดได้เอง นี่คือความต่างระหว่าง session ที่ต้องเฝ้ากับ session ที่เดินจากไปได้ และควรให้ Claude แสดงหลักฐาน เช่น output ของเทสต์ ไม่ใช่แค่ยืนยันลอย ๆ ว่าสำเร็จ
อีกเทคนิคที่คู่กันในงานที่เราไม่คุ้น domain คือ interview pattern คือให้ Claude สัมภาษณ์เราก่อนลงมือ เพื่อดึงข้อพิจารณาที่เราอาจยังนึกไม่ถึงออกมา เริ่มด้วย prompt สั้น ๆ แล้วสั่งให้มัน interview เราด้วย AskUserQuestion tool มันจะถามเรื่อง implementation ทางเทคนิค UI/UX edge case และ tradeoff ที่เรายังไม่ได้คิด เช่น กลยุทธ์ cache invalidation หรือ failure mode ต่าง ๆ พอครบแล้วให้มันเขียน spec ที่สมบูรณ์ออกมา แล้วเริ่ม session ใหม่ที่ context สะอาดเพื่อลงมือ interview pattern จึง surface การตัดสินใจเชิงออกแบบก่อนที่จะลงมือใน domain ที่ไม่คุ้น
ตัวอย่าง
# test-driven iteration — เขียน failing test ก่อน แล้ววนแก้
"ผู้ใช้รายงานว่า login ล้มเหลวหลัง session timeout เช็ค flow ใน src/auth/
โดยเฉพาะ token refresh เขียน failing test ที่ reproduce ปัญหาก่อน
แล้วจึงแก้ รันเทสต์ให้ผ่านและแสดง output เป็นหลักฐาน"
# interview pattern — ให้ Claude สัมภาษณ์ก่อนลงมือ
"อยากสร้างระบบ notification แบบ real-time สัมภาษณ์ผมอย่างละเอียดด้วย
AskUserQuestion เจาะเรื่อง implementation, edge case, และ tradeoff
ที่ผมอาจยังไม่ได้คิด พอครบแล้วเขียน spec ลง SPEC.md"
เช็คความเข้าใจ
ทำไมการเขียนเทสต์ก่อนแล้ววนแก้จาก failure จึงทำให้ Claude ทำงานได้โดยไม่ต้องเฝ้า
interview pattern ช่วยอะไรในงานที่เราไม่คุ้น domain