ทดลองก่อนแก้: กฎที่ทำให้ AI agent ปรับระบบ Terminal โดยไม่ต้องเดา (และไม่เผาเงิน)

ตอนสร้าง Boom Leverage Terminal ผมห้ามทั้งตัวเองและ AI agent แก้ระบบจริงตามความรู้สึก ทุกการเปลี่ยนแปลงต้องผ่านการทดลองที่ทำซ้ำได้ก่อน นี่คือโปรโตคอล 5 ส่วนที่ใช้จริง ตัวเลขจาก lab log และ 2 เคสที่การทดลองพลิกความเชื่อตั้งต้น

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

ตอนสร้าง Boom Leverage Terminal ด้วย AI agent ผมเจอกับดักเดิมซ้ำๆ: ระบบช้าหรือผลแปลก แล้วทั้งผมและ agent ก็อยากลงมือแก้ทันทีตามสิ่งที่ "น่าจะใช่" นิสัยนี้ดูขยัน แต่ในงานที่มีลูกค้าใช้จริง มันคือการเดิมพันด้วยระบบ production

พื้นหลังของผมคืองาน model validation ในธนาคาร ที่นั่นไม่มีใครเปลี่ยนโมเดลเพราะ "รู้สึกว่าดีขึ้น" ต้องมีหลักฐานที่คนอื่นทำซ้ำได้ ผมเอาวินัยเดียวกันมาใส่ใน harness ของ agent (ถ้ายังไม่คุ้นคำนี้ อ่าน Harness คืออะไร ก่อน)

ทำไม "แก้เลย" ถึงแพงกว่าที่คิด?

เพราะต้นทุนจริงไม่ได้อยู่ที่การแก้ แต่อยู่ที่ การแก้ผิดจุด ซึ่งมาพร้อม 3 อย่าง:

• เวลาที่เสียไปกับตัวแปรที่ไม่ใช่ต้นเหตุ — แก้แล้วดูดีขึ้นนิดหน่อยเพราะ noise แล้วก็เชื่อว่าแก้ถูก
• ความเสี่ยงต่อระบบที่ลูกค้าใช้อยู่ — ทุกการแก้ใน production คือโอกาสพังใหม่
• เงิน — ถ้าการแก้เกี่ยวกับ LLM ที่คิดเงินต่อ token การลองผิดลองถูกบนโมเดลแพงคือการเผาเงินตรงๆ

AI agent ทำให้ปัญหานี้หนักขึ้น เพราะมันแก้โค้ดได้เร็วมาก ความเร็วที่ไม่มีวินัยกำกับ = ความผิดพลาดที่มาถึงเร็วขึ้น

กฎเดียวที่มาก่อนทุกอย่างคืออะไร?

เขียนโปรโตคอลก่อน แล้วค่อยแตะระบบ ในไฟล์กฎหลักที่ agent ต้องโหลดทุก session เขียนไว้ว่า:

เจอปัญหา → ออกแบบ experiment → รัน → เสนอเปลี่ยน session ถัดไป. design ไม่ได้ → ดู log → ขอ deep research จาก Boom.

สังเกตคำว่า "เสนอเปลี่ยน session ถัดไป" — แม้การทดลองจะออกมาดี ก็ยังไม่เปลี่ยนทันทีใน session เดียวกัน เพราะคนที่เพิ่งรันการทดลองมักมองผลตัวเองดีเกินจริง การเว้นระยะหนึ่งรอบบังคับให้มีการมองซ้ำ

โปรโตคอล 5 ส่วนหน้าตาเป็นยังไง?

ก่อนรันอะไร ต้องตอบ 5 ข้อนี้ให้ครบ ถ้าตอบไม่ได้ แปลว่ายังไม่พร้อมทดลอง:

ทุกการทดลองเก็บไว้ในโฟลเดอร์เดียวที่มีโครงตายตัว — protocol, โค้ดที่ใช้รัน, คำสั่งที่รันแบบคำต่อคำ, ผลดิบ ทุก call และสรุปการตัดสินใจ ส่วนที่คนมักทิ้งคือผลดิบ ซึ่งเป็นส่วนที่ประหยัดเงินที่สุด เพราะอยากวิเคราะห์ใหม่เมื่อไหร่ก็อ่านไฟล์ได้เลย ไม่ต้องยิง API ซ้ำ

ทำไม pilot ผ่านแล้วยังไม่พอ?

นี่คือเคสจริงที่อธิบายได้ดีที่สุด ระบบ Terminal ถอดเสียงคลิป Opportunity Day (งานที่บริษัทจดทะเบียนตอบคำถามนักวิเคราะห์) เป็นข้อความ แต่ตัวถอดเสียงมักได้ยินตัวเลขผิด ผมเลยทดลองใช้ speech-to-text อีกตัวช่วย "กู้" ตัวเลขที่พลาด โดยตั้งเกณฑ์ไว้ก่อนรันว่า ต้องกู้ได้อย่างน้อย 20% ถึงจะคุ้มเปิดใช้

ถ้าเราเชื่อ pilot ที่ n = 8 ระบบจะถูกเปิดใช้กับทุกคลิป ทั้งที่ผลจริงต่ำกว่าเกณฑ์เกือบ 3 เท่า สิ่งที่ได้จากการทดลองรอบจริงไม่ใช่แค่ "ไม่ผ่าน" แต่คือคำตอบที่แม่นกว่า: ใช้เฉพาะตัวเลขประเภทปีเท่านั้น (ซึ่งยังต้องเก็บตัวอย่างเพิ่ม เพราะ n = 12 ยังน้อย)

นี่คือเหตุผลที่เกณฑ์ ROBUST ต้องการผลทิศเดียวกัน อย่างน้อย 2 ครั้ง ครั้งเดียว — โดยเฉพาะครั้งที่ตัวอย่างน้อย — ยังเป็นแค่สมมติฐาน

การทดลองเคยพลิกสิ่งที่ผมมั่นใจไหม?

เคย และบ่อยกว่าที่อยากยอมรับ ตัวอย่างหนึ่งคือตอนหน้าเว็บหลักโหลดช้า (LCP เกิน 2.5 วินาที) ผมมั่นใจว่าตัวต้นเหตุคือไฟล์วิดีโอพื้นหลังที่แย่ง bandwidth แผนแรกจึงจัดให้การแก้วิดีโอเป็นอันดับหนึ่ง ก่อนลงมือ แผนถูกส่งเข้าด่านตรวจแบบ adversarial ซึ่งเรียกร้องหลักฐาน แล้วการทดลองแบบแยกตัวแปรให้ผลนี้:

the isolation experiment (block-one-suspect, 3 reps each, medians) confirmed contention is real but showed Mux is NOT the lever.

แปลตรงๆ คือ ปิดผู้ต้องสงสัยทีละตัว รันตัวละ 3 รอบ ดูค่ามัธยฐาน แล้วพบว่าการแย่ง bandwidth มีจริง แต่วิดีโอ ไม่ใช่ จุดที่แก้แล้วได้ผล ถ้าผมแก้ตามความมั่นใจ จะได้งานที่เหนื่อยแต่ไม่ขยับตัวเลข

แล้วเมื่อไหร่ถึงจะยอมเปลี่ยนระบบจริง?

เมื่อผ่านเกณฑ์ ROBUST ซึ่งเขียนไว้ในกฎหลักว่า:

ใช้ซ้ำ ≥2 sessions AND ≥2 lab PASS ทิศเดียวกัน (= ROBUST)

และยังมีข้อยกเว้นที่ไม่ต้องรอ คือการจัดเอกสารและย้ายไฟล์เข้าถังพัก ซึ่งย้อนกลับได้ง่าย ส่วนอะไรที่แตะพฤติกรรมของระบบ ต้องผ่านเกณฑ์นี้ก่อนเสมอ

ตัวเลขนี้ไม่ได้บอกว่าผมทดลองเยอะ มันบอกว่า ไอเดียส่วนใหญ่ไม่ได้ถูกรันเลย — เพราะการเขียนโปรโตคอลบังคับให้ถามว่า "คุ้มไหม" ก่อนเสียเงินจริง และหลายไอเดียตกตั้งแต่ขั้นนั้น

สรุป

ความเร็วของ AI agent เป็นข้อดีก็ต่อเมื่อมีวินัยกำกับ กฎ "ทดลองก่อนแก้" ไม่ได้ทำให้ช้าลง มันทำให้ แก้ถูกจุดตั้งแต่ครั้งแรก บ่อยขึ้น: เขียนโปรโตคอล 5 ส่วน, รัน pilot ก่อนของแพง, อย่าเชื่อผลครั้งเดียว และเปลี่ยนระบบจริงเมื่อผ่าน ROBUST

สำหรับคนสร้าง product การเงิน นี่คือวินัยเดียวกับที่ธนาคารใช้ validate โมเดล แค่ย้ายมาอยู่ใน harness ของ agent (ดูตัวอย่างอื่นของ harness ใน ทำไมผมสร้าง Terminal ด้วย Claude Code)