AI 智能體為何受驗證工作拖慢，以及如何讓它們自行驗證？

โดย Nokka (นก-กา) | ตรวจข้อมูล 25 ต.ค. 2026 · ตอนที่ 4 จาก 6 ของชุด "หนึ่งคนกับทีม agent"

บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)

ประโยคที่ผมคิดว่าสรุปทั้งตอนนี้ได้อยู่ในคู่มือ pstack บรรทัดเดียว

"It compiles" is not evidence.

คอมไพล์ผ่านไม่ใช่หลักฐานว่างานเสร็จ [1]

และถ้าคุณยังใช้ "ดูแล้วน่าจะโอเค" เป็นเกณฑ์ตัดสิน คุณจะไม่มีวันปล่อย agent ทำงานเองได้จริง

ทำไมการตรวจถึงช้ากว่าทุกขั้น

ขั้นที่รอคนตลอด

คู่มือ pstack เขียนตรง ๆ ว่า การตรวจคือขั้นที่ช้าที่สุดในงานของ agent เพราะเป็นขั้นที่มักรอคน [1]

ถ้า agent ตรวจเองได้ คุณจะพ้นจากตำแหน่งคอขวด แต่ถ้าข้ามขั้นนี้ไป การเพิ่มจำนวน agent จะได้แค่งานที่ยังไม่ได้ตรวจเพิ่มขึ้นตามไปด้วย [1]

ผมคิดว่านี่คือเหตุผลที่หลายทีมลอง agent แล้วถอยกลับ เพราะเพิ่มกำลังฝั่งผลิตไว้ แต่คอขวดฝั่งตรวจยังเท่าเดิม

ตัวอย่างร้านอาหารเช้าอีกครั้ง

ตอนที่ 2 ผมเล่าเปรียบเทียบเรื่องไข่สามนาทีไปแล้ว ตอนนี้ผมจะขยายว่ามันแปลว่าอะไรในทางปฏิบัติ

ถ้าการทำซ้ำบั๊กใช้เวลา 20 นาที และคุณเป็นคนเดียวที่ทำได้ การแก้โค้ดเร็วแค่ไหนก็ไม่ทำให้งานออกเร็วขึ้น เพราะคิวจะไปติดที่คุณ

ทางออกจึงไม่ใช่ซื้อ agent เพิ่ม แต่คือสอน agent ให้ทำขั้นที่คุณเคยทำ

ตั้งเกณฑ์เสร็จตั้งแต่ประโยคแรก

ตัวอย่างที่วัดได้

คู่มือแนะนำให้ใส่ความหมายของ "เสร็จ" ลงไปใน prompt แรกด้วยถ้อยคำที่ตรงกับงาน [1]

/poteto-mode เพิ่ม output แบบ json ให้คำสั่งนี้
ข้อความเดิมต้องเหมือนเดิมทุกไบต์ json ต้อง parse ผ่าน
ทั้งสองแบบต้องรันกับโปรเจกต์ตัวอย่างได้
ขอหลักฐานมาให้ดู

แบบนี้ agent มีสามเกณฑ์ที่รันตรวจได้ ไม่ใช่อารมณ์ที่ต้องเดาใจ [1]

ถ้ามีเกณฑ์ข้อไหนรันไม่ได้ คำตอบที่ดีควรบอกว่า "สรุปไม่ได้" ไม่ใช่รายงานว่าเสร็จ [1]

ผมชอบตรงนี้เพราะมันกลับด้านนิสัยของเครื่องมือส่วนใหญ่ ที่มักตอบเข้าข้างตัวเอง

จับคู่การตรวจกับชนิดงาน

คู่มือแยกให้ชัดว่าตรวจอะไรกับงานแบบไหน [1]

• งาน CLI ให้รันคำสั่งจริง
• งาน UI ให้เดิน flow ที่เปลี่ยนในแอปที่รันอยู่
• งาน parser หรือ migration ให้เล่นซ้ำ input ที่บันทึกไว้
• งาน perf ให้เทียบ profile ก่อนกับหลัง
• งาน storage ให้อ่านค่าที่เขียนกลับมา

ถ้าต้องเทียบภาพระดับพิกเซล คู่มือแนะนำให้ใช้ playbook visual-parity เทียบกับ baseline ที่ตรึงไว้ ไม่ใช่ให้คนดูด้วยตา [1]

ตัวเลขที่วัดมาแล้ว ก็เชื่อไม่ได้ทันที

เจ็ดคำถามก่อนเชื่อคำว่าเร็วขึ้น

ปัญหาที่สกิล benchmark-checklist ถูกออกแบบมาจับคือตัวเลขก่อนกับหลัง ซึ่งเป็นหลักฐานที่ผิดพลาดง่ายที่สุด [1]

แคชที่ยังอุ่น build ที่ต่างกัน หรือโค้ดที่ไม่ได้รันในช่วงที่จับเวลา ก็ทำให้ได้ความเร็วปลอมได้ทั้งนั้น [1]

สกิล benchmark-checklist ถามเจ็ดข้อ [4] ตั้งแต่ อะไรเป็นตัวจำกัดตัวเลข ทำไมไม่เร็วเป็นสองเท่า ทุกฝั่งรันด้วยการตั้งค่าแบบเดียวกับของจริงหรือไม่ ผลลัพธ์เกินขีดจำกัดทางกายภาพอย่างแบนด์วิดท์ดิสก์หรือจำนวนคอร์หรือไม่ มีอะไร error หรือคืนค่าผิดหรือไม่ ทำซ้ำหลายรอบสลับกันแล้วได้ค่ากลางเท่าไร งานที่จับเวลาเกิดขึ้นจริงในช่วงนั้นหรือไม่ และผลนั้นสำคัญจริงในเส้นทาง end-to-end ที่ผู้ใช้ต้องรอหรือไม่ [1]

คำตอบต้องเป็น เร็วขึ้น ช้าลง ไม่ต่าง หรือสรุปไม่ได้ พร้อมจำนวนรอบและช่วงค่า ถ้าบอกตัวจำกัดไม่ได้ ก็ต้องตอบว่าสรุปไม่ได้ [1]

แบบที่คู่มือยกตัวอย่าง คือแคชยังอุ่นทำให้ตัวเลขดูดี และนั่นคือเหตุผลที่ผมเห็นด้วยกับกฎนี้

verification skill คือของจริงของทั้งระบบ

โครงที่ agent ตัวต่อไปอ่านรู้เรื่อง

สกิล create-verification-skill เขียนไฟล์ให้โปรเจกต์ โดยมีหัวข้อบังคับห้าส่วนคือ Launch, Doctor, Drive, Evidence และ Cleanup พร้อมส่วน Helpers เมื่อสกิลมีสคริปต์แนบ [3]

พร้อมกันนั้นมันสร้าง feature map ไว้ในโฟลเดอร์ features ซึ่งจัดเรียงว่าแอปทำอะไรได้ และผลลัพธ์แบบไหนที่พิสูจน์ว่าฟีเจอร์นั้นทำงาน [1]

ก่อนส่งมอบ มันต้องพิสูจน์ตัวเองหนึ่งรอบเต็ม ตั้งแต่เปิดแอป ตรวจความพร้อม ขับหนึ่งฟีเจอร์ เก็บหลักฐาน ล้าง environment แล้วยืนยันว่าหลักฐานยังอยู่หลังล้าง [1]

ถ้าการพิสูจน์นั้นล้มเหลว คู่มือบอกตรง ๆ ว่าอย่าใช้ผลลัพธ์ที่มันสร้าง [1]

ดูแลไม่ให้โกหก

แอปเปลี่ยนตลอด แผนที่ฟีเจอร์จึงเก่าได้ คู่มือแนะนำให้รัน maintain-verification-skill อย่างน้อยวันละครั้ง หรือตั้งเป็น automation [1]

ผลลัพธ์มีสามแบบคือ clean แปลว่าครบไม่มีอะไรต้องแก้ changed แปลว่ามี PR แก้เฉพาะโฟลเดอร์ของ skill นี้ และ blocked แปลว่าติดอะไรบางอย่างที่ต้องบอกคน [1]

สิ่งสำคัญคือมันห้ามแก้โค้ดผลิตภัณฑ์ และถ้าเจอ regression ของจริง มันต้องรายงาน ไม่ใช่กลบด้วยการแก้เอกสาร [1]

ผมคิดว่านี่คือมาตรฐานที่ทีมส่วนใหญ่ยังไม่มี และเป็นเหตุผลที่งาน agent จำนวนมากจบด้วยคำว่า "ทดสอบแล้ว" ที่ตรวจย้อนหลังไม่ได้

เมื่อการทดสอบปกติไปไม่ถึง

ตรวจคุณสมบัติด้วยเครื่องมือพิสูจน์

คู่มือระบุว่าบางบั๊กอยู่บนเส้นทางที่ไม่มีใครเดิน เช่น การ retry สองครั้งที่ซ้อนกัน ล็อกที่หมดอายุกลางการเขียน หรือเหตุการณ์ที่มาผิดลำดับ [1]

สำหรับโค้ดที่ความผิดพลาดแบบนี้แพง มีสกิล create-formal-verification-skill ที่เลือกเป้าหมายจากโค้ดเอง แล้วเลือกเครื่องมือตามคำถาม [1]

ถ้าคำถามคือ "เหตุการณ์สลับลำดับกันได้ไหม" เครื่องมือที่เหมาะคือ model checker อย่าง TLA+ [1]

และมันต้องแสดงให้เห็นว่าคุณสมบัตินั้นพังบนโค้ดเวอร์ชันที่จงใจทำเสีย เพราะการตรวจที่ไม่เคยเห็นความล้มเหลวไม่พิสูจน์อะไรเลย [1]

ตัวอย่างจากงานจริง

StyleX กับ PR สี่แสนบรรทัด

ตอนที่ 2 ผมเล่าตัวเลขนี้ไปแล้ว แต่ผมอยากกลับมาดูวิธีตรวจ

agent ของเธอสร้างสคริปต์ที่เทียบค่า computed style ระหว่าง SCSS เดิมกับ StyleX ใหม่ และเก็บภาพสถานะที่วัดมาเทียบกันได้ครบ [2]

เมื่อนำไปใช้จริงกับโค้ดทั้งระบบ ยังเจอบั๊ก z-index, คลาสที่ถูกใช้จากที่อื่น และศึก specificity ที่ซ่อนอยู่ [2]

เธอจึงเปลี่ยน automation ให้ย้ายทีละ leaf component เก็บภาพ hover, focus, active, disabled และสถานะเฉพาะของคอมโพเนนต์นั้น ครบทั้ง light, dark และ high contrast แล้วให้ agent อีกตัวตรวจสื่อที่เก็บมา [2]

ถ้า build ล้มหรือค่าไม่ตรง ให้หยุดทันที [2]

ผลคือได้ PR เล็ก ๆ ที่มีภาพและวิดีโอครบ แทนที่จะเป็น PR ยักษ์ที่ตามตรวจแทบไม่ไหว

สามอย่างที่เริ่มได้สัปดาห์นี้

ไม่ต้องรอมีทีม agent ก่อน

หนึ่ง เขียนเกณฑ์เสร็จให้เป็นตัวเลขหรือเงื่อนไข ถ้าคุณเขียนว่า "ทำให้เร็วขึ้น" agent จะเดาแทนคุณ [1]

สอง เก็บหลักฐานทุกครั้งที่สั่งงาน ขอภาพหน้าจอ วิดีโอ หรือ output ของคำสั่ง ไม่ใช่คำอธิบาย [2]

สาม ทำให้การตรวจเป็นสคริปต์ เริ่มจากคำสั่งเดียวที่เปิดแอปและเดินหนึ่งฟีเจอร์ให้ได้ก่อน แล้วค่อยขยาย [1]

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

สิ่งที่ตอนต่อไปจะตอบ

ตอนนี้เรารู้แล้วว่าจะตรวจอย่างไร แต่ยังเหลือคำถามที่ใหญ่กว่า คือถ้าอยากให้ agent ทำงานตอนเราไม่เฝ้า ต้องเตรียมอะไรบ้าง

ตอนที่ 5 ผมจะลงไปใน playbook ว่าด้วย autopilot, orchestrate และการรันข้ามคืน ว่ามันมีด่านไหนที่หยุดงานได้ และมีอะไรที่พลาดบ่อย

ผมจะเขียนทีละตอนและรายงานความคืบหน้าให้คุณดูเหมือนเดิม

REF

[1] Cursor (2026) · Verify the result and open a PR (คู่มือ pstack ตอนที่ 6). https://github.com/cursor/plugins/blob/main/pstack/docs/guide/06-verify-and-ship.md
[2] Lauren Tan (24 มิ.ย. 2026) · Loops You Can Trust. https://x.com/poteto/article/2069824386283319343
[3] Cursor (2026) · pstack skill: create-verification-skill. https://github.com/cursor/plugins/blob/main/pstack/skills/create-verification-skill/SKILL.md
[4] Cursor (2026) · pstack skill: benchmark-checklist. https://github.com/cursor/plugins/blob/main/pstack/skills/benchmark-checklist/SKILL.md