ยก "ถูกต้องทางเทคนิค" ขึ้นเป็น "สินค้าสำเร็จรูป" — เปลี่ยนความล้มเหลวของเอเจนต์ให้เป็นด่านตรวจในคำสั่ง

บทนำ

การปรับจูนที่พบบ่อยที่สุดในทางปฏิบัติคือ การปรับจูนพรอมป์ต (prompt tuning) แต่มันไม่ใช่งานเขียนคำสั่งฉลาด ๆ ให้ถูกในครั้งเดียว การสร้างสองระบบไปพร้อมกันแล้วให้เอเจนต์ลงมือพัฒนา ทำให้ผมพบว่าการปรับจูนพรอมป์ตแท้จริงคือ — การสังเกตความล้มเหลวที่เอเจนต์เจอในการพัฒนาจริง สืบหาสาเหตุ แล้วพับมันเข้าไปใน “ด่านตรวจก่อนลงมือ” และ “มุมมองการรีวิว” ในคำสั่ง เพื่อยก “ถูกต้องทางเทคนิค” ขึ้นสู่ “สินค้าสำเร็จรูป”: วงจรการประเมินหนึ่ง

ความต่างจากการทำ fine-tuning ซึ่งแตะที่น้ำหนักของโมเดล อยู่ใน “prompt tuning” กับ “fine-tuning” ต่างกันตรงไหน การจัดวางเอเจนต์เป็น “กอง” อยู่ใน สร้างแพลตฟอร์มสตรีมมิงและธนาคารไปพร้อมกัน

การปรับจูนไม่ใช่การเขียนคำสั่ง แต่คือการแก้พฤติกรรม

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

[แบบง่าย] พยายามเขียนคำสั่งสมบูรณ์แบบในครั้งเดียว ─▶ ถูกทรยศแน่นอนโดยสิ่งที่ไม่ได้คาด

[จริง] สังเกตพฤติกรรม ─▶ สืบหาสาเหตุ ─▶ พับเข้าด่านตรวจ/มุมมองรีวิว ─▶ ฆ่าความล้มเหลวเดิม
          ▲                                                              │
          └──────────────────── วนอีกครั้งกับความล้มเหลวถัดไป ───────────┘

ต่อไปนี้คือความล้มเหลวที่ผมพับเข้าไปจริง ๆ ผ่านวงจรนี้

”ถูกต้องทางเทคนิค” ไม่ใช่ “สินค้าสำเร็จรูป”

นี่คือบทเรียนที่สำคัญที่สุด ผมให้ผู้ลงมือ (coder) สร้างหน้าจอฝั่งลูกค้าของแพลตฟอร์ม แล้วให้ผู้ตรวจสอบ (reviewer) รีวิว ชั้นเทคนิคเขียวหมด — แต่ไม่มีใครดูความสมบูรณ์จากฝั่งผู้ใช้

เมื่อรีวิวหน้าจอที่สร้างเสร็จ
  ชั้นเทคนิค : การเชื่อม API ✓  การตรวจสอบสคีมาอินพุต ✓  การป้องกัน CSRF ✓  การจัดการข้อผิดพลาด ✓  → reviewer "ไม่มี must-fix"
  ชั้นผลิตภัณฑ์ : ประกอบกันเป็นสินค้าสำเร็จรูปในสายตาผู้ใช้หรือไม่? ✗
                 เทียบกับการนำทาง/UI ร่วมในเอกสารออกแบบแล้วหรือยัง? ✗   → ไม่มีใครดู

(CSRF = คำขอปลอมที่ส่งมาจากกับดักบนเว็บไซต์อื่น โดยสวมรอยเป็นผู้ใช้ที่ล็อกอินอยู่; การป้องกันจะปัดมันทิ้ง)

สาเหตุคือมุมมองที่ขาดหายในวินัย (พรอมป์ต) ของผู้ตรวจสอบ ในเวลานั้น คำสั่งของ reviewer มีเฉพาะวินัยวิศวกรรมทั่วไป — การตรวจชนิด ความปลอดภัย การหลีกเลี่ยงการทำเกิน — โดยไม่มีมุมมองฝั่งผลิตภัณฑ์ มันจึงเห็นความถูกต้องทางเทคนิค แต่ปล่อยความสมบูรณ์ผ่านไป การแก้คือเพิ่มมุมมองนั้นเข้าไปในวินัย

# มุมมองที่วินัยของผู้ตรวจสอบขาดไป (เพิ่มจากความล้มเหลวในการพัฒนาจริง)
(เดิม) ตรวจชนิด ความปลอดภัย เลี่ยงการทำเกิน ห้ามแจ้ง "เสร็จ" เอง … วิศวกรรมทั่วไปเท่านั้น
(เพิ่ม) ✓ ประกอบกันเป็น "สินค้าสำเร็จรูป" ในสายตาผู้ใช้หรือไม่?
        ✓ เทียบกับการนำทาง/สเปก UI ร่วมในเอกสารออกแบบแล้วหรือยัง?

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

หยุด “การไล่ทำเชิงกลไก” ที่หลงลืมเป้าหมาย

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

[ไล่ทำเชิงกลไก] งาน A ✓ → งาน B ✓ → งาน C ✓ … (แต่ละอันถูกต้องในตัวเอง)
                                        └─ แต่หลงลืม "ทำไปเพื่ออะไร" ×

[ผูกกลับสู่เป้าหมาย] ก่อนเริ่ม ยืนยัน "นี่เป็นการต่อจากอะไร / ตรงกับเจตนาหรือไม่" → แล้วค่อยลงมือ

การแก้คือเพิ่มขั้นนี้เข้าไปในด่านตรวจก่อนลงมือ

# CLAUDE.md ด่านตรวจก่อนลงมือ (ตัดตอน)
1. ยืนยันกับเอกสารออกแบบ (ถ้าเมโม/ความทรงจำขัดกับเอกสารออกแบบ เอกสารออกแบบชนะ)
2. งานนี้ต่อจากอะไร / ตรงกับเจตนาล่าสุดของเจ้าตัวหรือไม่ (การไล่ทำหลงลืมเป้าหมายหรือเปล่า)
3. ก่อนปฏิบัติการทำลาย: สำรองข้อมูล + จับคู่ลายนิ้วมือของปลายทาง
→ อย่าเข้าสู่ Write / Edit / รัน ก่อนผ่านขั้นนี้

ยิ่งมือเร็ว ก็ยิ่งวิ่งออกนอกเป้าหมายเร็วอย่างอันตราย ก่อนไล่ทำงานหนึ่ง ให้ผูกมันกลับสู่ “ทำไม”

อย่าทำให้เอเจนต์รีวิวเป็นแนวป้องกันสุดท้าย

แม้ให้เอเจนต์ตรวจสอบ ก็ยังรอด เมื่อผมรันการตรวจแบบกลไกในขั้นท้ายกับผลงานที่ควรจะผ่านเอเจนต์เอกสาร (ผู้ลงมือ ผู้ตรวจสอบ) มาแล้ว บั๊กจริง 9 ตัวโผล่ออกมา

การรีวิวโดยเอเจนต์เอกสาร ─▶ ผ่านด้วย "ไม่มีปัญหา"
        │
แทรกการตรวจแบบกลไก (สคริปต์) ที่ท้ายสุด ─▶ ตรวจพบบั๊กจริง 9 ตัว
        └─ เช่น ตัวอักษรที่หายไปตอนสร้างแองเคอร์จากหัวข้อภาษาญี่ปุ่น —
           ความหมายถูก แต่ส่วนที่กำหนดโดยกลไกนั้นเพี้ยน (จับด้วยตาได้ยาก)

บทเรียนคือ อย่าทำให้การรีวิวของ LLM เป็นแนวป้องกันสุดท้าย การอ่านความหมายเป็นจุดแข็งของเอเจนต์ แต่ความถูกต้องที่กำหนดโดยกลไก (ความสอดคล้องของลิงก์ กฎการตั้งชื่อ รูปแบบ) ควรถูกขนาบด้วยการตรวจแบบชี้ขาด (สคริปต์) สายตาของคน/เอเจนต์ กับการตรวจแบบกลไก ปิดช่องคนละช่อง

ไม่ใช่การยิงครั้งเดียวที่สมบูรณ์แบบ แต่คือการเปลี่ยนความล้มเหลวเป็นโครงสร้างไปเรื่อย ๆ

การให้เอเจนต์ลงมือในการพัฒนาจริง สิ่งที่ตกผลึกคือ แก่นของการปรับจูนพรอมป์ตไม่ใช่ความประณีตของคำสั่ง เปลี่ยนความล้มเหลวเป็นข้อมูลการสังเกต (ทั้งโค้ดที่ไม่ดูเสร็จสมบูรณ์ การไล่ทำที่หลงลืมเป้าหมาย บั๊กจริงที่รอดผ่าน — อย่าให้อันใดจบเป็นอุบัติเหตุครั้งเดียว) เขียนมุมมองที่อยากให้ดูอย่างชัดเจน (เพิ่ม “ประกอบเป็นสินค้าสำเร็จรูปหรือไม่” ไม่ใช่แค่ “ถูกต้องทางเทคนิคหรือไม่” ลงในคำสั่ง) และอย่าทำให้ LLM เป็นแนวป้องกันสุดท้าย (ขนาบความถูกต้องเชิงกลไกด้วยการตรวจแบบชี้ขาด) ด้วยสามสิ่งนี้ “ถูกต้องทางเทคนิค” ขยับเข้าใกล้ “สินค้าสำเร็จรูป” ทีละน้อย

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