วิธีที่สมบูรณ์แบบในการทำให้ AI โกหกไม่ได้ - leceipts

เวลาใช้เครื่องมือเขียนโค้ดด้วย AI มักจะเจอสถานการณ์เดิม ๆ อย่างน่าประหลาด

พออธิบายบั๊กไป
→ “แก้ปัญหาแล้ว”
→ ลองรันดูก็ยังพังเหมือนเดิม

เรื่องนี้ไม่ใช่แค่ปัญหาของ AI เท่านั้น
แต่ยังเป็นแพตเทิร์นที่คุ้นเคยในการรีวิวโค้ดของคนด้วย
• “น่าจะใช้วิธีนี้ได้”
• “บนเครื่องโลคัลผมใช้ได้ปกติ”
• “ยังไม่ได้รันเทสต์ แต่ดูแล้วไม่น่ามีปัญหา”

leceipts พยายามแก้เรื่องนี้ด้วยกระบวนการ
ไม่ใช่ด้วยทัศนคติหรือวัฒนธรรม

ทุกครั้งที่มีการเปลี่ยนโค้ด ระบบจะบังคับให้บันทึกข้อมูลต่อไปนี้อย่างเป็นโครงสร้าง:
• Root cause: ปัญหาเกิดขึ้นเพราะอะไร
• Change: มีการแก้ไขอะไรเข้าไปจริงบ้าง
• Recurrence prevention: จะป้องกันไม่ให้ปัญหาเดิมเกิดซ้ำได้อย่างไร
• Verification: ตรวจสอบอย่างไร และผลลัพธ์เป็นอย่างไร
• Remaining risk: ส่วนไหนที่ยังไม่ได้ตรวจสอบ

หัวใจสำคัญตรงนี้คือ “Verification”
ไม่ใช่แค่บอกว่า “ทดสอบแล้ว”
แต่ต้องบันทึกด้วยว่าตรวจสอบด้วยวิธีไหน และผลออกมาเป็นอย่างไร

พอมีโครงสร้างนี้ขึ้นมา ก็จะเกิดการเปลี่ยนแปลงหลายอย่าง

1. ป้องกัน AI พูดเกินจริง
   แทนที่จะพูดแค่ว่า “fixed” ก็ต้องแนบผลการรันจริงไว้ด้วย
   → ถ้ายังไม่ได้รันก็จะเห็นได้ทันที
2. คุณภาพการรีวิวโค้ดของคนดีขึ้น
   คำอธิบาย PR เปลี่ยนจากการใช้ “ความรู้สึก” ไปเป็นการอิง “หลักฐาน”
3. ประวัติการดีบักกลายเป็นทรัพย์สิน
   สะสมไว้ได้ว่าพังเพราะอะไร และแก้อย่างไร
   → ช่วยป้องกันไม่ให้ปัญหาเดิมเกิดซ้ำ
4. เกณฑ์ของคำว่า ‘Done’ ชัดเจนขึ้น
   แก้เสร็จ ≠ เสร็จสมบูรณ์
   ต้องตรวจสอบครบด้วยถึงจะถือว่าเสร็จ

จุดที่น่าสนใจคือ มันไม่ใช่เทสต์เฟรมเวิร์กแบบใหม่
หรือเครื่องมือซับซ้อนอะไร

แต่เป็นแนวทางแบบง่าย ๆ ที่ว่า
“แค่บังคับรูปแบบการอธิบาย ก็เปลี่ยนกระบวนการพัฒนาได้”

ยิ่ง AI coding ถูกใช้งานมากขึ้นเรื่อย ๆ
ก็ยิ่งทำให้คิดว่า workflow แบบ “verification-first” ลักษณะนี้
อาจกลายเป็นค่ามาตรฐานเริ่มต้นในอนาคตได้