บรีฟ AI ว่า “verify ให้ด้วย”
แล้วมันเลือกทางที่ผ่านง่ายที่สุด

ช่วงที่ 1คืนที่รายงานเขียวทุกข้อ แต่ของจริงพัง

คืนนั้นเรากำลังย้ายระบบ federation ของฝูง agent ที่บ้าน จาก runtime ตัวเก่าไปตัวใหม่ที่เร็วกว่า งานใหญ่พอที่จะไม่อยากนั่งทำเอง เราเลยส่ง agent ตัวหนึ่งไปทำ พร้อมบรีฟที่เราคิดว่าเขียนชัดแล้ว “จับหลักฐานจริงมาพิสูจน์ว่า client ตัวเก่าคุยกับ server ตัวใหม่ได้”

รายงานที่กลับมาสวยมาก agent ยิง endpoint ไปสองตัว ได้ 200 ทั้งคู่ แนบ output จริงครบทุกบรรทัด แล้วสรุปว่าพิสูจน์แล้ว สองระบบคุยกันได้จริง

แต่พอเรารัน client ตัวจริงเองก่อนจะเชื่อรายงาน ภาพกลับตรงข้ามเลย client ตัวจริงที่ cron เรียกทุก 10 นาที เปิดการคุยด้วย endpoint อีกตัวหนึ่ง ที่ server ใหม่ยังไม่มี ผลคือทั้งฝูงมองว่า node ใหม่ตายสนิท ทั้งที่รายงานบอกว่าเขียว เรา rollback กลับภายในหนึ่งนาที แล้วก็ได้นั่งอ่านรายงาน “เสร็จสมบูรณ์” อีกฉบับที่เพิ่งเดินทางมาถึง หลังเรา rollback ระบบไปเรียบร้อยแล้ว

จุดที่อยากให้เห็นคือ agent ไม่ได้โกหกสักคำ endpoint ที่มันทดสอบตอบ 200 จริง หลักฐานเป็นของจริงทั้งหมด มันแค่เลือกความหมายของคำว่า “พิสูจน์” แบบที่มันทำสำเร็จได้ง่ายที่สุด เพราะมันไม่มีทางรู้ว่า production เรียกใช้อะไรจริง คนที่รู้มีอยู่คนเดียว คือคนเขียนบรีฟ

ช่วงที่ 2คำคุณศัพท์คือช่องโหว่ ไม่ใช่คำสั่ง

ลองนับดูว่าบรีฟที่เราเขียนให้ AI มีคำพวกนี้บ่อยแค่ไหน prove ให้ด้วย verify ให้ด้วย confirm ว่าใช้ได้ ทุกคำฟังเหมือนคำสั่ง แต่ที่จริงมันทำหน้าที่เป็นคำคุณศัพท์ เปิดช่องตีความไว้กว้างมาก และ agent จะตีความแบบที่ผ่านง่ายที่สุดเสมอ ไม่ใช่เพราะขี้โกง แต่เพราะในบรรดาความหมายทั้งหมดที่เป็นไปได้ มันมองไม่ออกว่าความหมายไหนคือของจริงสำหรับระบบของเรา

ทางปิดช่องนี้สั้นแค่บรรทัดเดียว เขียน acceptance เป็นคำสั่งกับผลที่ต้องเห็น

Acceptance: <คำสั่ง> → <ผลที่ต้องเห็น>
ของจริงจากคืนนั้น: peers probe-all → ต้องได้ 1/1 ok

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

อีกเรื่องที่คืนนั้นสอน รายงานของ agent คือ snapshot ณ เวลาที่มันเขียน ไม่ใช่ความจริง ณ เวลาที่เราอ่าน รายงาน “เสร็จสมบูรณ์ ไม่ได้ rollback” ฉบับนั้นเขียนก่อนเรา rollback แต่มาถึงทีหลัง ถ้าเราถือรายงานเป็นความจริง ก็เท่ากับเชื่อว่าระบบอยู่ในสถานะที่มันไม่ได้อยู่แล้ว ก่อนปิดงานทุกครั้ง reconcile กับผลที่รันเองล่าสุดเสมอ

ช่วงที่ 3กฎที่ไม่มีใครตรวจ ยังไม่ใช่กฎ

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

ชั้นแรก ประกาศ ให้บอทประจำฝูงโพสต์กฎลงห้องรวมที่ทุกตัวอ่านได้ ผลคือความเงียบ ไม่มีตัวไหนขยับ ไม่มีตัวไหนเปลี่ยนพฤติกรรม การประกาศคือการสื่อสาร ไม่ใช่การบังคับใช้ มนุษย์ในองค์กรก็เป็นแบบนี้ไม่ใช่เหรอ

ชั้นที่สอง ฝังในที่ที่ agent อ่านจริง เราเพิ่มกฎลงกติกากลางของฝูง ไฟล์เดียวที่ daemon ทุกตัวโหลดเข้า system prompt ตอนบูต และตัวที่เกิดใหม่ทุกตัวได้รับตั้งแต่วินาทีแรก คำสำคัญของชั้นนี้คือ “อ่านจริง” เราเกือบเอากฎไปฝังในไฟล์ที่ฟังดูใช่มาก แต่ระบบไม่ได้โหลดเข้า prompt เลย เรื่องนั้นยาวพอจะเป็นบันทึกของตัวเอง ไว้เล่าตอนหน้า

ชั้นที่สาม ให้มีตัวตรวจทุกเช้า กฎที่นั่งอยู่ใน system prompt ก็ยังเป็นแค่ตัวหนังสือ ถ้าไม่มีใครเช็คว่ามีคนทำตาม เราเลยเพิ่มหน้าที่ให้ตัวตรวจรอบเช้าของฝูง สแกนงานที่ agent มอบหมายต่อกัน บรีฟไหนมีคำว่า prove verify หรือ confirm แต่ไม่มีบรรทัด Acceptance ก็ทักเจ้าของงานให้เติมก่อนปิด

แล้วก็ชั้นที่คนมักลืม พิสูจน์ตัวตรวจเอง ตัวตรวจที่ไม่เคยจับอะไรได้เลย อาจแปลว่าทุกคนทำถูกหมด หรือแปลว่าตัวตรวจตาบอด สองแบบนี้หน้าตาเหมือนกันเป๊ะเมื่อมองจากข้างนอก วิธีแยกคือ positive control ป้อนของที่รู้อยู่แล้วว่าผิดให้มันดู เผอิญมีใบงานจริงอยู่ใบหนึ่งบนบอร์ดที่ขาดบรรทัด Acceptance พอดี ไม่ต้องปลูกของปลอมเลย แค่รอดูว่ารอบเช้าวันแรก ตัวตรวจจะจับใบนี้ได้ไหม เรื่องตัวตรวจที่โกหกทั้งที่เขียว เราเขียนแยกไว้ละเอียดแล้วในโพสต์ mutation testing

ช่วงที่ 4เช้าวันตัดสิน

แผนเดิมคือรอรอบ 07:30 แต่พอทุกอย่างพร้อม เราก็ไม่อยากรอถึงเช้า ตีสองครึ่งของวันที่ 6 เลยกดรันหน่วย production ตัวเดียวกับที่ timer จะเรียก ใบงาน coa-migration ที่ขาดบรรทัด Acceptance ยังนั่งอยู่บนบอร์ดที่เดิม

สองนาทีถัดมาตัวตรวจตอบกลับมา รายงานดูดีมาก สแกนบอร์ดครบทั้งสี่ใบ ถึงขั้นยกใบ coa-migration ขึ้นมาเตือนเราว่าค้างเกินสามวันแล้ว แต่พอถึงหน้าที่เช็คบรรทัด Acceptance มันเขียนสั้นๆ ว่า “ไม่มีบรีฟ delegate ใหม่รอบนี้ ขอข้าม” ใบที่เรารู้อยู่แล้วว่าผิด นอนอยู่ในรายงานฉบับเดียวกันนั้นแหละ ไม่โดนทักสักคำ

ตัวตรวจไม่ได้พัง มันแค่ตีความหน้าที่แบบที่ผ่านง่ายที่สุด กฎบอกให้เช็คบรีฟของ card ที่ delegate งานย่อย มันเลยอ่านเป็น “บรีฟใหม่ของรอบนี้” ซึ่งไม่มี ก็เลยข้ามได้อย่างสมเหตุสมผลตามการอ่านของมันเอง ตัวตรวจที่เราสร้างมาไว้จับการตีความหลวม ล้มรอบแรกด้วยการตีความหลวมเสียเอง ถ้าเช้านี้ไม่มี positive control เราคงอ่านความเงียบว่าทุกใบผ่าน แล้วเชื่อแบบนั้นไปอีกนาน

ทางถอยเราเขียนไว้ตั้งแต่ก่อนรู้ผล แพ้เมื่อไหร่ก็เปลี่ยนชั้นนี้เป็นตัวตรวจแบบกลไก คืนเดียวกันนั้นเลยได้ script สั้นๆ มาหนึ่งตัว เจอ prove verify confirm ที่ไม่มีบรรทัด Acceptance ก็ติดธงทุกครั้ง ไม่ต้องตีความ แล้วธงติดไปกับโพสต์ของ sweep เองเลย ไม่ต้องรอให้ใครนึกได้ รันรอบถัดมา ธงขึ้นสองใบ ใบ coa ที่เป็น positive control กับอีกใบที่เราไม่ได้วางไว้ด้วยซ้ำ คราวนี้ไม่ต้องลุ้นว่าตัวตรวจจะตีความว่ายังไง ธงอยู่ในโพสต์ตั้งแต่วินาทีแรก บทเรียนข้อที่สามเลยแถมมาเอง ตัวตรวจที่ใช้วิจารณญาณ พิสูจน์วันนี้ก็ใช้ได้แค่วันนี้ ตัวตรวจที่เป็นกลไกต่างหาก ที่พิสูจน์ครั้งเดียวแล้วใช้ได้ทุกวัน

ช่วงที่ 5เอาไปใช้กับ agent ของคุณ

ไม่ต้องมีฝูง agent เก้าตัวถึงจะใช้หลักนี้ได้ Claude Code ตัวเดียวบนเครื่องคุณก็เริ่มได้เลย

• ทุกครั้งที่บรีฟมีคำว่า prove verify confirm หรือ “เช็คให้หน่อย” เติมหนึ่งบรรทัด Acceptance: <คำสั่ง> → <ผลที่ต้องเห็น>
• ตัวอย่างที่ใช้บ่อย npm test → 0 failed · curl -s .../health → {"ok":true} · wc -l data.csv → จำนวนแถวเท่าต้นทาง
• เขียนบรรทัดนี้ไม่ออก แปลว่ายังไม่พร้อมส่งงาน นี่คือของแถมที่มีค่าที่สุดของบรรทัดนี้ มันตรวจคนเขียนบรีฟก่อนตรวจ agent
• รายงานของ agent อ่านได้ แต่ก่อนเชื่อ รันคำสั่ง acceptance เองหนึ่งครั้งเสมอ ผลของคำสั่งคือความจริง รายงานคือ snapshot
• ถ้าจะตั้งเป็นกฎทีม กฎต้องมีสามอย่างครบ ที่อยู่ที่ agent อ่านจริง ตัวตรวจเป็นรอบ และการพิสูจน์ตัวตรวจ ขาดอย่างใดอย่างหนึ่ง มันจะค่อยๆ กลายเป็นแค่ข้อความในไฟล์

บรรทัดเดียวที่ถูกที่ ถูกกว่าหนึ่ง rollback เสมอ ลองกลับไปเปิดบรีฟล่าสุดที่คุณส่งให้ AI ดู มีคำว่า verify ไหม แล้วมีบรรทัด Acceptance หรือยัง