unlazy คือสกิลโอเพนซอร์สที่สร้างขึ้นมาแก้ปัญหา AI agent ชอบ "ชิงบอกว่างานเสร็จ" ทั้งที่ยังทำไม่ครบ

ลองนึกภาพเวลาเราสั่งงาน AI agent ไป 7 ข้อ แล้วมันตอบกลับมาอย่างมั่นใจว่าทำเสร็จครบเรียบร้อยแล้ว แต่พอเข้าไปตรวจดูงานจริง กลับพบว่าทำเสร็จจริงแค่ 3 ข้อ อีก 2 ข้อทำค้างไว้ครึ่งทาง ส่วนอีก 2 ข้อหายไปเงียบๆ เหมือนไม่เคยอยู่ในคำสั่งตั้งแต่แรก

จุดที่ชวนเข้าใจผิดคือการมองว่าโมเดลยังไม่เก่งพอ ทั้งที่จริงแล้ว ปัญหาคือไม่มีใครนิยามคำว่า "เสร็จ" ให้อยู่ในเกณฑ์ที่ตรวจสอบได้ตั้งแต่ก่อนเริ่มงาน พอไม่มีเกณฑ์วัดที่ชัดเจน หน้าที่ตัดสินว่างานเสร็จหรือไม่จึงตกไปอยู่ที่ตัวโมเดลเอง ซึ่งตัดสินจากสิ่งที่ "มันคิดว่าทำไปแล้ว" ไม่ใช่ผลลัพธ์ของคำสั่งที่รันจริง

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

ปัญหานี้ไม่ได้คิดไปเอง แต่มีงานวิจัยรองรับชัดเจน

ใน repo ของ unlazy ไม่ได้ยกปัญหานี้ขึ้นมาลอยๆ แต่รวบรวมงานวิจัยที่พบพฤติกรรมแบบเดียวกันนี้ไว้อย่างชัดเจน เริ่มจากงานวิจัย Quantifying Laziness ที่พบว่า เมื่อเจอกับคำสั่งที่มีรายละเอียดมากและมีหลายขั้นตอน โมเดลในการทดสอบก็ยังคงทำงานไม่ครบ และมักจะชิงตัดจบบอกว่าเสร็จก่อนงานจะเสร็จจริง

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

ตัวเลขที่สะท้อนภาพนี้ได้ชัดเจนที่สุดมาจาก SlopCodeBench ชุดทดสอบวัดผล AI agent ที่เขียนโค้ดในงานยาวและต้องแก้ไขซ้ำหลายรอบ ผลลัพธ์คือ ไม่มี agent ตัวไหนในกลุ่มทดสอบที่แก้โจทย์จบได้สมบูรณ์ทั้งงานเลยแม้แต่ตัวเดียว และตัวที่ทำคะแนนได้ดีที่สุด ก็ผ่านจุดตรวจย่อยระหว่างทางได้เพียง 14.8% เท่านั้น

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

GATES.md ไฟล์เกณฑ์ตรวจงานที่ต้องเขียนก่อนเริ่ม ไม่ใช่เขียนหลังทำเสร็จ

หัวใจสำคัญของ unlazy คือไฟล์ชื่อ GATES.md ที่กำหนดเกณฑ์ที่ต้องเขียนขึ้นมาก่อนเริ่มทำงาน ไม่ใช่รายงานสรุปที่มาเขียนหลังทำเสร็จ โดยแต่ละข้อในไฟล์นี้ประกอบด้วย 3 ส่วนหลักเสมอ:

1. ชื่อของผลลัพธ์ที่ต้องการ
2. บรรทัด CHECK: คำสั่งจริงที่จะรันในเครื่องเพื่อพิสูจน์ผลงานในข้อนั้น
3. บรรทัด EXPECT: ข้อความที่ต้องปรากฏในผลลัพธ์จากการรันคำสั่ง จึงจะนับว่าข้อนั้นผ่าน

หน้าตาของไฟล์นี้เข้าใจง่ายกว่าที่คิด ตัวอย่างจริงจากต้นทางมีลักษณะดังนี้:

# Gates: pricing behavior
- [ ] G1: pricing fixtures render the expected tiers
  CHECK: node scripts/verify-pricing.mjs
  EXPECT: pricing verification passed
  EVIDENCE: pending
- [ ] G2: checkout integration succeeds from its package
  CHECK: node scripts/verify-checkout.mjs
  EXPECT: checkout verification passed
  CWD: packages/checkout
  EVIDENCE: pending

สิ่งที่ทำให้ไฟล์นี้แตกต่างจากเช็กลิสต์ธรรมดาทั่วไปคือเงื่อนไขการผ่านเกณฑ์ โดยแต่ละข้อจะผ่านได้ก็ต่อเมื่อคำสั่งใน CHECK: รันเสร็จสิ้นด้วย Exit Code เป็น 0 ซึ่งหมายความว่าทำงานสำเร็จโดยไม่มีข้อผิดพลาด และผลลัพธ์ที่แสดงออกมาต้องมีข้อความตรงกับที่ระบุไว้ใน EXPECT: เมื่อครบทั้งสองเงื่อนไขพร้อมกันเท่านั้น ช่องติ๊กถูก [x] หน้าข้อจึงไม่ใช่สิ่งที่ AI จะมาแอบเติมเองตามใจชอบได้

อีกกติกาที่สำคัญไม่แพ้กันคือ หลักฐานการผ่านงานจะผูกกับเงื่อนไขของข้อนั้นโดยตรง ระบบจะนำคำสั่งใน CHECK:, ข้อความใน EXPECT: และโฟลเดอร์ที่ใช้รัน มาคำนวณเป็นค่าตรวจสอบ บันทึกควบคู่ไปกับ Exit Code และผลลัพธ์ที่รันผ่าน ถ้ามีการย้อนกลับไปแก้คำสั่งหรือแก้ข้อความที่คาดหวังในภายหลัง หลักฐานเดิมจะไม่ตรงกับเงื่อนไขใหม่ และข้อนั้นจะถูกตีกลับเป็น "ยังไม่ผ่าน" ทันที ต่อให้ช่องหน้าข้อยังติ๊กถูกค้างไว้อยู่ก็ตาม AI จึงแอบลดหย่อนเงื่อนไขให้ตัวเองผ่านงานง่ายๆ ไม่ได้อีกต่อไป

อย่างไรก็ตาม ผู้พัฒนาระบุขอบเขตของกลไกนี้ไว้อย่างชัดเจนว่า ระบบนี้ออกแบบมาเพื่อตรวจจับความผิดปกติของโครงสร้างเท่านั้น ไม่ใช่ระบบป้องกันการปลอมแปลง ถ้าใครแก้ไขไฟล์ GATES.md ได้โดยตรง ก็ย่อมสร้างหลักฐานปลอมให้ดูเหมือนผ่านได้เช่นกัน unlazy จึงเป็นเครื่องมือสร้างวินัยในการทำงานที่ทำให้ AI "หลอกตัวเองได้ยากขึ้น" มากกว่าจะเป็นระบบความปลอดภัย

วิธีเขียนเช็กลิสต์ที่ดี แม้ไม่ลงสกิลก็หยิบไปใช้ได้ทันที

สิ่งที่เรานำไปปรับใช้ได้ทันทีแม้ไม่ได้ติดตั้งสกิล unlazy คือหลักการเขียนเช็กลิสต์ที่ต้นทางสรุปไว้ในเอกสาร โดยมีกฎสำคัญ 5 ข้อที่ช่วยปิดช่องโหว่ในการตรวจงานแต่ละแบบ:

• ตรวจจากเนื้อหาจริง ไม่ใช่ดูแค่ผลทางอ้อม: หลีกเลี่ยงการเช็กแบบมักง่าย เช่น การตรวจแค่ว่ามีไฟล์สร้างขึ้นมาหรือไม่ แทนที่จะเปิดดูเนื้อหาข้างในไฟล์ว่าสิ่งที่ผู้ใช้ต้องเห็นนั้นถูกต้องจริงไหม
• สั่งพิมพ์ข้อความยืนยันหลังเงื่อนไขทุกอย่างผ่านจริงเท่านั้น: เพื่อป้องกันปัญหาสคริปต์ที่พิมพ์ข้อความว่าทำงานสำเร็จทิ้งไว้ตั้งแต่บรรทัดแรกๆ แล้วโค้ดดันไปพังเงียบๆ จนตัวตรวจหลงเชื่อข้อความใน EXPECT: ทั้งที่ขั้นตอนจริงล้มเหลวไปแล้ว
• ถ้าเป็นเงื่อนไขแบบ "ต้องไม่พบสิ่งผิดปกติ" ให้ทดสอบกับกรณีที่รู้ว่ามีสิ่งนั้นอยู่ด้วยเสมอ: ป้องกันกรณีที่สคริปต์พังจนค้นหาอะไรไม่เจอเลย แล้วระบบกลับตีความว่า "ผ่าน" เพราะไม่พบสิ่งผิดปกติ ทั้งที่ตัวสคริปต์เองไม่ได้ทำงาน
• ใช้ตัวเลขจากการรันจริง อย่าก๊อปปี้ตัวเลขเป้าหมายมาใส่ในเงื่อนไข: สำหรับงานที่มีเกณฑ์ตัวเลขชัดเจน เช่น เวลาตอบสนอง หรือความครอบคลุมของการทดสอบ ต้องให้คำสั่งคำนวณตัวเลขจากการรันจริงออกมาแสดง
• งานที่มีความเสี่ยงสูงและต้องใช้คนตรวจ ควรให้เวลารีวิวตามระดับความเสี่ยง: ใช้กับผลลัพธ์ที่โปรแกรมอัตโนมัติพิสูจน์แทนสายตามนุษย์ไม่ได้

และประโยคเตือนใจที่ผู้พัฒนาเขียนไว้อย่างตรงประเด็นที่สุดคือ:

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

วิธีติดตั้ง unlazy และการสั่งใช้งาน

การติดตั้ง unlazy ทำได้ง่ายๆ ผ่านเครื่องมือจัดการสกิลโอเพนซอร์สอย่าง skills CLI ด้วยคำสั่งเดียว:

npx skills add Leonxlnx/unlazy

ถ้าต้องการติดตั้งสำหรับผู้ใช้ทั้งเครื่อง ให้เติมออปชัน -g หรือใส่ --all เพื่อติดตั้งให้ AI agent ทุกตัวที่ระบบตรวจพบ

แต่ถ้าต้องการติดตั้งด้วยตัวเอง ให้คัดลอกหรือโคลนโปรเจกต์ไปไว้ที่โฟลเดอร์:

• ~/.claude/skills/unlazy สำหรับเครื่องมือสั่ง AI เขียนโค้ดผ่านเทอร์มินัลอย่าง Claude Code
• ~/.codex/skills/unlazy สำหรับ Codex CLI เครื่องมือเขียนโค้ดสายเดียวกัน

ตัวสคริปต์ตรวจและ Hook ที่คอยดักจับเหตุการณ์อัตโนมัติ ต้องใช้ Node.js เวอร์ชัน 16 ขึ้นไป โดยไม่ต้องติดตั้งแพ็กเกจภายนอกเพิ่มเติม เมื่อติดตั้งเสร็จแล้ว ก็เรียกใช้คำสั่ง /unlazy ในเครื่องมือที่รองรับ หรือคำสั่ง $unlazy ใน Codex ได้ทันที ส่วนใครที่สนใจว่าสกิลลักษณะนี้ออกแบบโครงสร้างอย่างไรให้ AI อ่านแล้วเข้าใจได้ทันที ใน คู่มือสร้าง Claude Skills มีอธิบายไว้โดยละเอียด

สคริปต์ตัวตรวจหลักคือ gate-check.mjs มี 4 โหมดการทำงานที่ควรเข้าใจก่อนใช้งาน:

node <path-to-skill>/scripts/gate-check.mjs --status GATES.md
node <path-to-skill>/scripts/gate-check.mjs GATES.md
node <path-to-skill>/scripts/gate-check.mjs --approve GATES.md
node <path-to-skill>/scripts/gate-check.mjs --reverify GATES.md

• --status เป็นโหมดเดียวที่จะไม่รันคำสั่งใดๆ ทั้งสิ้น ใช้สำหรับเปิดดูสถานะของแต่ละข้อในไฟล์เฉยๆ
• โหมดปกติ (ไม่ใส่ออปชัน): ถ้าคำสั่งชุดนั้นยังไม่เคยอนุมัติมาก่อน ระบบจะพิมพ์คำสั่งจริงที่จะรัน ข้อความเงื่อนไขที่คาดหวัง โฟลเดอร์ที่จะใช้รัน โปรแกรมเชลล์ และตัวแปรระบบอย่าง PATH ออกมาให้เราอ่านตรวจสอบก่อน แต่ยังไม่รันคำสั่งจริง
• --approve ใช้ยืนยันว่าเราตรวจสอบคำสั่งครบถ้วนแล้ว และยินยอมให้ระบบรันคำสั่งจริงได้
• --reverify รันคำสั่งตรวจใหม่ทุกข้อ รวมถึงข้อที่เคยผ่านไปแล้วด้วย เหมาะสำหรับใช้ตรวจงานรอบสุดท้ายเมื่อ AI ส่งงานกลับมา

Hook ป้องกันไม่ให้ Claude Code ชิงตัดจบงานก่อนเสร็จ

ส่วนที่ทำงานร่วมกับ Claude Code โดยตรงคือตัว Hook ที่จะทำงานเมื่อ AI agent กำลังจะส่งสัญญาณจบเทิร์นว่าทำงานเสร็จแล้ว โดยจะเข้าไปอ่านสถานะของเช็กลิสต์ในเซสชันนั้น ถ้ายังมีข้อที่ไม่ผ่าน หรือยังมีงานย่อยที่ยังทำไม่ครบ Hook จะส่งคำสั่งระงับแบบ block กลับไปตามระบบของ Claude Code เพื่อสั่งให้ agent ทำงานต่อ โดยตัว Hook ไม่ได้รันคำสั่งตรวจเอง แต่ทำหน้าที่กั้นไม่ให้ agent ตัดจบงาน

จุดที่ออกแบบมาอย่างรอบคอบคือ ระบบจะไม่บล็อก agent ไปเรื่อยๆ จนค้าง เพราะการบล็อกไม่รู้จบก็เป็นปัญหาอีกรูปแบบหนึ่ง unlazy จึงใช้วิธีนับจำนวนครั้งที่บล็อก ถ้าบล็อกติดต่อกันครบ 6 ครั้งโดยที่เช็กลิสต์ไม่มีความคืบหน้าจริง ระบบจะยอมปล่อยให้ agent จบเทิร์นได้ และการแก้ไขไฟล์เพียงแค่ขยับ metadata เล็กๆ น้อยๆ โดยไม่มีเนื้องานจริง จะไม่ทำให้ตัวนับนี้เริ่มนับหนึ่งใหม่

การติดตั้ง Hook เป็นขั้นตอนเสริมที่ต้องเลือกติดตั้งเอง ไม่ได้เปิดใช้งานมาพร้อมกับสกิลตั้งแต่แรก:

node <path-to-skill>/scripts/install-hooks.mjs

ถ้าต้องการถอนการติดตั้ง ให้ใส่คำสั่งพร้อมออปชัน --uninstall โดยตัวติดตั้งจะเก็บ Hook อื่นๆ ที่มีอยู่เดิมในระบบไว้ ปฏิเสธไฟล์ตั้งค่าที่รูปแบบผิดพลาด และสำรองไฟล์ตั้งค่าเดิมไว้ในชื่อ .unlazy.bak ก่อนเขียนทับเสมอ

Depth Tree กับคำอ้างที่ผู้พัฒนาถอยเองในเอกสารฉบับปัจจุบัน

Depth Tree คือแนวคิดการซอยงานใหญ่ออกเป็นชั้นๆ ที่มาคู่กับสกิลนี้ คำอธิบายบน GitHub repo ที่ยังค้างอยู่ทุกวันนี้ระบุว่า การซอยงานลงไปลึก N ชั้น จะช่วยเพิ่มความพยายามในการทำงานเป็นทวีคูณตามระดับความลึก ซึ่งฟังดูเหมือนสูตรคณิตศาสตร์ที่คำนวณผลลัพธ์ได้ชัดเจน แต่ในเอกสาร method.md ฉบับปัจจุบัน Leonxlnx ผู้พัฒนา unlazy กลับเตือนไว้ชัดเจนว่า อย่ามองระดับความลึกเป็นหลักประกันทางคณิตศาสตร์ว่าจะเพิ่มแรงทำงานหรือจำนวนโทเคนได้จริง พร้อมเล่าว่าจากการทดสอบเปรียบเทียบรอบเล็กๆ พบว่า ตัว agent มองระดับความลึกเป็นเพียง "สัญญาณ" ที่บอกให้มันทำงานละเอียดขึ้นเท่านั้น ไม่ได้แปลว่ามันจะลงแรงทำงานเพิ่มขึ้นตามสูตรคณิตศาสตร์จริงๆ

ยิ่งไปกว่านั้น ใน README ยังระบุไว้อย่างโปร่งใสว่า ข้อมูลดิบจากการทดสอบรอบเก่าไม่ได้เก็บไว้ใน repo จึงนำมารันซ้ำเพื่อยืนยันตัวเลขเดิมไม่ได้ และแนะนำให้ถือว่าข้อมูลเหล่านั้นเป็นเพียงประวัติการออกแบบ ไม่ใช่หลักฐานวัดผลทางสถิติ

หลักการใช้งานจริงของ Depth Tree ตามเอกสารปัจจุบัน จึงไม่ใช่การมานั่งนับชั้นความลึก แต่คือการแบ่งงานตามขอบเขตงานจริง:

• แบ่งงานตามประเภทงาน ส่วนประกอบของระบบ หรือขอบเขตที่ใช้ตรวจผลจริง
• งานย่อยแต่ละชิ้นที่ปลายผังต้องมีผลลัพธ์ที่ส่งมอบได้ในตัว และมีผู้รับผิดชอบชัดเจน
• ต้องตกลงโครงสร้างข้อมูลที่จะส่งต่อกัน และกำหนดให้ชัดเจนว่าใครเป็นเจ้าของไฟล์ส่วนไหน ก่อนจะเริ่มแตกงานออกไป
• ห้ามสร้างชั้นงานว่างๆ ขึ้นมาเพียงเพื่อให้ครบตามตัวเลขความลึกที่ผู้ใช้สั่ง ถ้าระดับความลึกที่ขอมาไม่มีเนื้องานจริงรองรับ สกิลจะต้องแจ้งให้ทราบ และซอยงานออกมาเฉพาะเท่าที่มีเนื้องานจริงเท่านั้น ใครที่เคยใช้ ปลั๊กอิน Medley ที่ให้ Claude Code แตกงานเป็นผังให้ดูก่อนปล่อย agent ลุย ก็จะคุ้นเคยกับหลักคิดแบบเดียวกันนี้

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

บรรทัด CHECK: คือคำสั่งที่จะรันจริงบนเครื่องของคุณ

ก่อนจะนำไปลองใช้งาน มีเรื่องสำคัญด้านความปลอดภัยที่มองข้ามไม่ได้ เพราะข้อความในบรรทัด CHECK: ของไฟล์เช็กลิสต์ไม่ใช่แค่คำอธิบายทั่วไป แต่เป็นคำสั่งเชลล์ที่จะรันจริงบนเครื่องของคุณ และผู้พัฒนาย้ำชัดเจนว่า การกดอนุมัติคือการยินยอมให้รันในสภาพแวดล้อมจริง ไม่ใช่การรันใน Sandbox หรือพื้นที่จำลองที่จำกัดสิทธิ์ไว้

ในทางปฏิบัติ หมายความว่าคำสั่งเหล่านี้จะรันด้วยสิทธิ์ทั้งหมดเท่าที่บัญชีผู้ใช้ของคุณมี ทั้งสิทธิ์อ่านเขียนไฟล์ การเข้าถึงตัวแปรระบบอย่าง Environment ข้อมูลลับอย่างคีย์ API ตลอดจนการเชื่อมต่อไปยังเครือข่ายภายนอก ยิ่งถ้าไฟล์เช็กลิสต์นั้น AI เป็นคนเขียนขึ้นมาเอง การกด --approve โดยไม่อ่านคำสั่งให้ละเอียดก่อน จึงอันตรายและไม่ควรทำอย่างยิ่ง

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

เวอร์ชันปัจจุบันยังไม่มีแท็ก Release อย่างเป็นทางการ

เวอร์ชันของ unlazy ที่เอกสารชุดนี้อ้างอิงถึงคือ 2.1.0 ซึ่งปัจจุบันยังไม่ได้ปล่อย Release อย่างเป็นทางการบน GitHub ทางผู้พัฒนาจึงแนะนำว่า ถ้าต้องการความเสถียรในการทำงาน ควรล็อกรหัส Commit hash ประจำเวอร์ชันที่ต้องการใช้งานไว้เสมอ อย่าเพิ่งดึงเวอร์ชันล่าสุดจาก branch หลักมาใช้โดยตรง

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

กฎ 3 บรรทัดที่นำไปใช้ได้ทันทีตั้งแต่งานหน้า

ถ้าคุณยังไม่อยากติดตั้งสกิลหรือโปรแกรมใดๆ เพิ่มเติม สิ่งที่หยิบไปปรับใช้ได้ทันที คือการต่อท้ายคำสั่งด้วย "3 บรรทัดนี้" ทุกครั้งที่ต้องสั่งงาน AI ยาวๆ:

1. บรรทัดแรก: ระบุผลลัพธ์ที่ต้องได้รับให้ชัดเจน
2. บรรทัดที่สอง: ระบุคำสั่งจริงที่จะต้องรันเพื่อพิสูจน์ผลลัพธ์
3. บรรทัดที่สาม: ระบุข้อความที่ต้องปรากฏในผลลัพธ์ จึงจะถือว่างานผ่าน

เพียงเท่านี้ คุณก็ดึงหน้าที่ตัดสินความสำเร็จของงานออกจากตัวโมเดลไปได้ครึ่งทางแล้ว เพราะคำสั่งกว้างๆ อย่าง "ช่วยทำให้เรียบร้อยด้วยนะ" เป็นสิ่งที่ไม่มีทางตรวจวัดได้ แต่คำสั่งอย่าง "รันคำสั่งนี้แล้วต้องเห็นข้อความนี้" เป็นเกณฑ์ที่ตรวจสอบได้ชัดเจนเสมอ ไม่ว่าจะสั่งให้ AI หรือใครทำให้ก็ตาม

เพราะคำว่า "งานเสร็จ" ที่ตรวจสอบไม่ได้ ก็เท่ากับว่ายังไม่มีใครนิยามความหมายของมันไว้ตั้งแต่แรกนั่นเอง

ที่มา:

• โปรเจกต์ unlazy จาก Leonxlnx บน GitHub
• เอกสาร references/method.md จาก Leonxlnx บน GitHub