วิธีแก้ปัญหา Coding Agent ทำงานไม่เสร็จด้วย unlazy skill

หน้าที่ของ unlazy skill

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

เครื่องมือนี้เผยแพร่โดย Leonxlnx ที่ github.com/Leonxlnx/unlazy ภายใต้สัญญาอนุญาต MIT คู่มือนี้เขียนขึ้นโดยอ้างอิงเวอร์ชัน 2.0.0 ซึ่งเผยแพร่เมื่อ 2026-08-10 ทักษะในด้านนี้มีการเปลี่ยนแปลงอย่างรวดเร็ว ดังนั้นโปรดอ่าน CHANGELOG ของ repository ก่อนที่คุณจะคัดลอกสิ่งเหล่านี้ไปใช้ในระบบที่เปิดใช้งานจริง

คำว่า skill ในที่นี้หมายถึงสิ่งที่เป็นปกติทั่วไป นั่นคือไฟล์ SKILL.md ที่ harness จะโหลดเข้าสู่ context ของโมเดลเมื่อภารกิจตรงกับคำอธิบายของมัน หากกลไกนี้เป็นเรื่องใหม่สำหรับคุณ ให้เริ่มต้นที่ ทักษะของ agent คืออะไรและ harness โหลดอย่างไร unlazy เป็นเพียงไฟล์ markdown รวมกับ Node script สองสามไฟล์ จึงไม่จำเป็นต้องใช้เซิร์ฟเวอร์และไม่มี API key เป็นของตัวเอง

เหตุใดเอเจนต์จึงหยุดทำงานที่ 80 เปอร์เซ็นต์และข้ามคำสั่งที่สามของคุณ

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

README ของ unlazy อธิบายปรากฏการณ์นี้โดยอ้างอิงจากงานวิจัยที่ตีพิมพ์เกี่ยวกับความเฉื่อยชาของโมเดล โดยอ้างถึง "การตัดทอนคำตอบก่อนกำหนดและการปฏิบัติตามคำขอหลายส่วนเพียงบางส่วน" (อ้างอิงจาก arXiv 2512.20662) README ฉบับเดียวกันระบุหลักการออกแบบไว้อย่างชัดเจนว่า ข้อความไม่สามารถบังคับใช้ข้อความได้ การบอกให้เอเจนต์พยายามให้มากขึ้นก็เป็นเพียงข้อความอีกชุดหนึ่งที่ถูกเพิ่มเข้าไปในบริบทเดิมที่ทำให้เกิดข้อผิดพลาดตั้งแต่แรก

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

Depth Tree ทีละชั้น

Depth Tree คือการย่อยงานโดยมีกฎว่างานจริงต้องเกิดขึ้นที่จุดใด อ้างอิงจากวิธีปฏิบัติ:

แยกงานตามรอยต่อที่เป็นธรรมชาติ โดยเน้นการแยกแบบทวิภาค (binary) หากรอยต่อเอื้ออำนวย และทำลึกลงไป N ชั้น

ใบ (leaves) คือจุดเดียวที่งานจริงเกิดขึ้น ส่วนทุกชั้นที่อยู่เหนือขึ้นไปคือการย่อยและการรวมงาน

ใบมีขนาดใหญ่กว่าหัวข้อรายการทั่วไป โดยวิธีปฏิบัติได้กำหนดเกณฑ์ขั้นต่ำไว้ว่า:

ใบคือหน่วยงานจริง ต้องใช้ความพยายามอย่างจดจ่อ 10 นาทีขึ้นไป มีผลลัพธ์ที่ชัดเจนหนึ่งอย่าง และมีไฟล์ที่เกี่ยวข้องหนึ่งชุด

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

จากนั้นแต่ละใบจะต้องผ่านการทำงาน 4 รอบ: ลงมือทำจนเสร็จสมบูรณ์โดยไม่มีตัวยึดตำแหน่ง (placeholders), อ่านทวนในมุมมองของผู้เชี่ยวชาญเฉพาะด้าน, ตรวจหาข้อบกพร่อง และขัดเกลาในส่วนที่ทำได้โดยง่าย การทำงาน 4 รอบนี้เป็นอีกเหตุผลที่ใบต้องมีขนาดขั้นต่ำ เพราะการทำงาน 4 รอบกับงานที่ใช้เวลาเพียง 2 นาทีนั้นถือเป็นการแสดงละครมากกว่าการทำงานจริง

คุณสามารถเลือกระดับความลึกได้เมื่อเรียกใช้ทักษะ:

/unlazy tree 5 refactor the payment module

การใช้ภาษาทั่วไปก็ได้ผลเช่นกัน เพราะคำอธิบายของทักษะจะจับคู่กับเจตนามากกว่าการใช้ slash command:

tree 3 build the landing page and do not stop until every gate is checked

เอกสารอ้างอิงได้กำหนดช่วงความลึกไว้ ดังนี้: tree 2 หรือ 3 เหมาะสำหรับฟีเจอร์, การไล่ล่าบั๊ก หรือเอกสาร ซึ่งทำคนเดียวได้ในเซสชันเดียวโดยใช้ใบงาน 2 ถึง 4 ใบ tree 4 หรือ 5 เหมาะสำหรับระบบย่อย, การปรับโครงสร้างโค้ด (refactor) หรือการตรวจสอบงานระดับจริงจัง ซึ่งการมีใบงาน 8 ถึง 16 ใบถือว่า "เกินกว่าที่บริบทเดียวจะรองรับได้ดี" tree 6 หรือ 7 เหมาะสำหรับโครงการขนาดใหญ่ทั้งโครงการ โดยดำเนินการในโหมดประสานงานและแบ่งใบงานออกเป็นหน่วยงานที่ไม่ซ้อนทับกัน

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

ลักษณะของไฟล์ gates

ก่อนเริ่มงานใดๆ เอเจนต์จะเขียนเกณฑ์การยอมรับลงในไฟล์ gates โดยแต่ละ gate จะเป็นช่องทำเครื่องหมายที่มีคำสั่งกำกับอยู่ด้านล่าง

# Gates: pricing section

- [ ] G1: three tiers render with real copy
  CHECK: node check.js pricing --tiers
  EXPECT: 3/3 tiers ok
  EVIDENCE: pending

- [ ] G2: annual toggle changes both price and label
  CHECK: node check.js pricing --toggle
  EXPECT: toggle ok
  EVIDENCE: pending

CHECK คือคำสั่ง ส่วน EXPECT คือผลลัพธ์ที่ถือว่าผ่านเกณฑ์ EVIDENCE จะเริ่มต้นที่ pending และต้องถูกแทนที่ด้วยสิ่งที่คำสั่งพิมพ์ออกมาจริง ตัว skill จะมาพร้อมกับ scripts/gate-check.mjs สำหรับสแกนไฟล์เหล่านั้นและรายงานว่า gate ใดที่ยังเปิดอยู่ ซึ่งหมายความว่าคุณสามารถตรวจสอบการทำงานได้โดยไม่ต้องอ่านบันทึกการทำงานทั้งหมด

ปรัชญานี้สรุปได้ในบรรทัดเดียว และ SKILL.md ได้เขียนไว้ดังนี้:

รายงานคือชุดของข้ออ้างที่ได้รับการสนับสนุนโดยบัญชีแยกประเภท ไม่ใช่ความรู้สึกว่างานเสร็จสิ้นแล้ว

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

จงเขียน gate ที่คนอื่นสามารถนำไปรันต่อได้ "ดูดี" ไม่ใช่การตรวจสอบ การที่ test -s dist/index.html && echo ok พิมพ์ ok ออกมาถือเป็นการตรวจสอบ เพราะมันจะล้มเหลวอย่างชัดเจนหากไฟล์ว่างเปล่าหรือไม่มีอยู่จริง

สัญญาใน PLAN.md ก่อนเริ่มงานแบบขนาน

เมื่อโครงสร้างต้นไม้ขยายกว้างจนกระทั่งส่วนปลาย (leaves) ทำงานในบริบทที่แยกจากกัน ส่วนปลายเหล่านั้นจะเลิกใช้สมมติฐานร่วมกัน การอ้างอิงวิธีการนี้จึงวางสัญญาไว้หน้าการกระจายงาน (fan-out):

สัญญาต้องมาก่อนการกระจายงาน อินเทอร์เฟซ, ความเป็นเจ้าของข้อมูล, การตั้งชื่อ และข้อตกลงเรื่องข้อผิดพลาด ต้องระบุไว้ใน PLAN.md ก่อนที่ส่วนปลายใดๆ จะเริ่มทำงาน

เหตุผลนั้นชัดเจน หากสั่งให้ subagent สองตัว "เพิ่มการจัดการข้อผิดพลาด" ทั้งคู่จะสร้างรูปแบบข้อผิดพลาดที่แตกต่างกัน และส่วนปลายทั้งสองจะผ่านเกณฑ์ของตนเองได้สำเร็จเพราะแต่ละส่วนถูกต้องในระดับท้องถิ่น ความล้มเหลวจะปรากฏขึ้นเมื่อทั้งสองส่วนมาบรรจบกัน เกณฑ์ของกิ่งก้าน (branch gates) จึงมีไว้สำหรับช่วงเวลานั้น: เกณฑ์ของกิ่งก้านจะพิสูจน์ว่า "ลูกข่ายรวมเข้าด้วยกันแล้ว, อินเทอร์เฟซตรงกัน, พฤติกรรมแบบ end-to-end ทำงานได้ และไม่มีการถดถอยของส่วนประกอบข้างเคียง"

ในโหมดการจัดการ (orchestrated mode) ตัวขับเคลื่อน (driver) จะส่งเฉพาะส่วนสัญญาของ PLAN.md ให้กับ subagent แต่ละตัว ไม่ใช่ส่งทั้งไฟล์หรือประวัติของตัวขับเคลื่อนเอง พร้อมกับส่งไฟล์เกณฑ์ของส่วนปลายนั้นๆ ไปให้แบบคำต่อคำ เมื่อ subagent ส่งงานกลับมา ตัวขับเคลื่อนจะรันการตรวจสอบด้วยตนเองอีกครั้ง หาก subagent ใด "ทำเครื่องหมายว่าตรวจสอบแล้วโดยไม่มีหลักฐาน" จะถูกส่งกลับไปพร้อมระบุเกณฑ์ที่ยังไม่ผ่านอย่างชัดเจน

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

คุณจะติดตั้ง unlazy skill ได้อย่างไร

วิธีที่รองรับคือการใช้ skills CLI:

npx skills add Leonxlnx/unlazy

การติดตั้งด้วยตนเองคือการ clone ลงในไดเรกทอรี skills ของเอเจนต์ของคุณ:

git clone https://github.com/Leonxlnx/unlazy ~/.claude/skills/unlazy

git clone https://github.com/Leonxlnx/unlazy ~/.codex/skills/unlazy

จากนั้นตรวจสอบว่าไฟล์ถูกติดตั้งเรียบร้อยแล้ว:

ls ~/.claude/skills/unlazy/SKILL.md

หากแสดง path กลับมา หมายความว่าไฟล์อยู่ในดิสก์แล้ว No such file or directory หมายความว่าการ clone ไปยังตำแหน่งอื่น ซึ่งมักเกิดจากไดเรกทอรี skills ไม่มีอยู่จริงตามชื่อที่คุณคาดไว้และ git ได้สร้างไดเรกทอรีใหม่ขึ้นมา อย่าเชื่อคำบอกของเอเจนต์เพียงอย่างเดียว คำสั่งติดตั้งใน README เองก็จบด้วยคำเตือนเดียวกันว่า: "อย่าบอกว่าติดตั้งแล้วจนกว่าคุณจะตรวจสอบไฟล์ในดิสก์ด้วยตนเองจริงๆ"

สำหรับ harness ที่ไม่มีตัวโหลด skill ให้คัดลอกเนื้อหาของ SKILL.md ไปวางใน system prompt หรือไฟล์กฎ นี่คือวิธีสำรองที่ระบุไว้ในเอกสาร และเป็นเหตุผลว่าทำไมวิธีนี้จึงทำงานได้บน Claude Code, Codex, Cursor และเครื่องมืออื่นๆ ที่อ่านไฟล์คำสั่งที่เป็น markdown ธรรมดาได้ หากคุณต้องการทราบว่าอะไรทำให้ SKILL.md โหลดได้อย่างน่าเชื่อถือตั้งแต่แรก การเขียน agent skill ของคุณเอง จะครอบคลุมถึงส่วน frontmatter และการจับคู่คำอธิบายซึ่งเป็นตัวตัดสินว่า skill นั้นจะทำงานหรือไม่

Stop hook ทำงานนอก Claude Code หรือไม่

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

node <path-to-skill>/scripts/install-hooks.mjs            # this project only (settings.local.json)
node <path-to-skill>/scripts/install-hooks.mjs --global   # every project
node <path-to-skill>/scripts/install-hooks.mjs --uninstall

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

มันมีกลไกการปลดล็อก (release valve) ซึ่งมีความสำคัญมากกว่าที่คิด หากเอเจนต์ไม่มีความคืบหน้าในส่วนของ gate เลยตลอดการพยายามหยุดทำงานที่ถูกบล็อกติดต่อกัน 6 ครั้ง hook จะยอมให้เอเจนต์หยุดทำงานพร้อมคำเตือนแทนที่จะขังเอเจนต์ไว้ บรรทัด ABANDON: <gate> <reason> จะได้รับความเคารพเสมอในฐานะการออกที่สุจริต หากไม่มีทางออกทั้งสองนี้ gate ที่เป็นไปไม่ได้ในสภาพแวดล้อมของคุณจะเผาผลาญโทเค็นไปเรื่อยๆ จนกว่าคุณจะยุติเซสชันด้วยตัวเอง

บน Codex, Cursor หรือ harness อื่นๆ install-hooks.mjs ไม่มีที่ให้ติดตั้ง คุณยังคงได้รับไฟล์ gates และการตรวจสอบที่รันได้ แต่จะไม่มีสิ่งใดในเชิงโครงสร้างที่หยุดไม่ให้โมเดลจบเทิร์นก่อนกำหนดได้ ในกรณีนั้น ไฟล์ gates จะเป็นเพียงเอกสารที่คุณต้องอ่านด้วยตนเอง

unlazy หรือ ponytail: คุณต้องการแบบไหน?

ทักษะทั้งสองนี้ได้รับความนิยมในช่วงเวลาเดียวกันและมีทิศทางการทำงานที่ตรงข้ามกันในแง่ของปริมาณงาน ซึ่งทำให้สับสนได้ง่าย

ponytail ทำให้ agent ทำตัวเหมือนนักพัฒนาอาวุโสที่คำถามแรกคือโค้ดนี้จำเป็นต้องมีอยู่จริงหรือไม่ มันจะลดขอบเขตงาน เลือกใช้ standard library และทำให้ diff มีขนาดเล็กลง ส่วน unlazy จะตั้งสมมติฐานว่าขอบเขตงานได้ตกลงกันไว้เรียบร้อยแล้ว และเร่งผลักดันให้งานทุกส่วนเสร็จสมบูรณ์และผ่านการตรวจสอบ

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

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

ค่าใช้จ่ายด้านความลึก (depth) บนเอเจนต์ที่โฮสต์บน VPS คืออะไร

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

[
  {
    "label": "Skill run vs no skill, output tokens",
    "low_multiplier": 1.6,
    "high_multiplier": 3.9
  },
  {
    "label": "tree 6 vs tree 3, total cost",
    "low_multiplier": 1.0,
    "high_multiplier": 1.5
  }
]

ตัวเลขดังกล่าวเป็นข้อมูลจากผู้เขียนที่ได้จากการทดสอบเมื่อวันที่ 2026-08-10 เรายังไม่ได้ทำการทดสอบซ้ำ ดังนั้นโปรดอ่านเพื่อทำความเข้าใจแนวโน้มมากกว่าการคาดการณ์ ผลลัพธ์จากการใช้ Solo discipline เพิ่มขึ้นประมาณ 1.6 ถึง 3.9 เท่าของค่าพื้นฐาน ในขณะที่การขยับจาก tree 3 ไปยัง tree 6 ภายใน context เดียวกันเพิ่มขึ้นเพียง 1.0 ถึง 1.5 เท่า ซึ่งน้อยกว่าแปดเท่าที่คุณอาจคาดหวังจากการแตกกิ่งแบบ binary เพิ่มอีกสามระดับ

ความลึกที่มากขึ้นไม่ได้หมายถึงค่าใช้จ่ายที่เพิ่มขึ้นเป็นสัดส่วนโดยตรง เพราะความลึกเป็นการกระจายความพยายามใหม่แทนที่จะเป็นการเพิ่ม context ข้อมูลอ้างอิงด้าน token-economy ระบุไว้อย่างชัดเจนว่าตัวคูณที่แท้จริงอยู่ที่ใด: "สิ่งที่คูณค่าใช้จ่ายคือการจัดลำดับ (orchestration) และมันควรจะเป็นเช่นนั้น เพราะแต่ละ leaf จะต้องใช้ context ใหม่เสมอ" โหมด Solo จะคูณจำนวน output tokens ภายใน context เดียว ส่วนโหมด Orchestrated จะคูณจำนวน context และทุก context ใหม่จะต้องอ่านสัญญาและไฟล์ gates ใหม่ก่อนที่จะเริ่มทำงานที่มีประโยชน์

มีค่าใช้จ่ายอีกประเภทหนึ่งที่มองข้ามได้ง่าย และเอกสารอ้างอิงเดียวกันก็ได้ระบุไว้ การรันงานแบบลึกในรูปแบบ monolithic ในการทดสอบของพวกเขา "ใช้ cached input tokens ไปประมาณ 58 ล้านโทเค็น" เนื่องจาก context เดียวที่ขยายใหญ่ขึ้นเรื่อยๆ แบกรับทุกอย่างไว้ Cached input มีราคาต่อโทเค็นที่ถูกกว่า แต่ด้วยปริมาณขนาดนั้น มันยังคงปรากฏอยู่ในใบแจ้งหนี้

การตั้งค่าสี่ประการต่อไปนี้เป็นสิ่งที่ควรปฏิบัติ:

• เลือกความลึกที่น้อยที่สุดที่ leaf สามารถทำงานได้จริงแล้วหยุด ความลึกที่คุณไม่จำเป็นต้องใช้คือค่าใช้จ่ายที่คุณไม่จำเป็นต้องเสีย
• อยู่ในโหมด solo หากงานใช้เวลาไม่เกินครึ่งชั่วโมง เพราะต้นทุนในการตั้งค่า subagent สูงกว่าผลตอบแทนที่ได้จาก context ใหม่
• ติดตั้ง Stop hook หากคุณใช้ Claude Code นี่เป็นส่วนเดียวของกระบวนการนี้ที่ทำงานโดยไม่มีค่าใช้จ่าย
• กำหนดเพดานค่าใช้จ่ายสูงสุดที่ระดับบัญชีก่อนเริ่มงานที่ใช้เวลานาน

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

สิ่งที่ผู้เขียนได้วัดผลและสิ่งที่พิสูจน์ได้

repository นี้เผยแพร่การทดสอบของตนเอง ซึ่งเป็นสิ่งที่พบได้น้อยกว่าที่ควรจะเป็น การตั้งค่าการทดสอบของพวกเขาอ้างอิงจาก README ดังนี้: "งานสร้างจากศูนย์ 2 งาน (เว็บไซต์การตลาดและระบบสุริยะ three.js) โดยมี 3 เงื่อนไขในแต่ละงาน (ไม่มีทักษะ, tree 3, tree 6) ใช้โฟลเดอร์ใหม่และเซสชันใหม่ในทุกการรัน ใช้โมเดลเดียวกัน และใช้เนื้อหา prompt เดียวกัน ผลลัพธ์ทุกรายการได้รับการตรวจสอบโค้ดโดยเอเจนต์อิสระ มีการตรวจสอบซ้ำแบบปรปักษ์ และทดสอบการใช้งานจริงในเบราว์เซอร์"

[
  {
    "label": "Self-found defects fixed, skill runs",
    "low_count": 4,
    "high_count": 10
  },
  {
    "label": "Wrong numbers in report, skill runs",
    "low_count": 1,
    "high_count": 3
  },
  {
    "label": "Wrong numbers in report, baseline runs",
    "low_count": 0,
    "high_count": 0
  }
]

โปรดอ่านแถวกลางซ้ำสองรอบ ในการทดสอบของผู้เขียนเอง การรันด้วยทักษะพบข้อบกพร่องจำนวน 4 ถึง 10 รายการที่เอเจนต์พบด้วยตนเองก่อนส่งงาน และการรันด้วยทักษะทุกครั้งจะส่งรายงานฉบับสุดท้ายที่มีตัวเลขผิดพลาด 1 ถึง 3 รายการ เทียบกับ 0 รายการในการรันแบบพื้นฐาน การทำงานที่มากขึ้นทำให้ได้งานสร้างที่ดีขึ้นแต่ได้สรุปผลที่แย่ลง นี่คือข้อค้นพบที่อยู่เบื้องหลังกฎ ledger และคำสั่งให้วัดค่าตัวเลขใหม่ทุกครั้งในขณะทำรายงาน หรือทำเครื่องหมายว่ายังไม่ได้ตรวจสอบ

ผลลัพธ์อีกประการหนึ่งของพวกเขาที่ควรค่าแก่การจดจำคือ: "ความล้มเหลวในการใช้งานจริงที่รุนแรงเพียงอย่างเดียวคือการสร้างแบบพื้นฐาน และรายงานระบุว่ากรณีดังกล่าวได้รับการจัดการแล้ว" การสรุปผลอย่างมั่นใจบนงานสร้างที่พังทลายคือสิ่งที่ gates มุ่งเน้นที่จะป้องกัน

มาถึงข้อจำกัด: การรัน 6 ครั้ง, งานสร้าง 2 งาน, โมเดล 1 โมเดล, ดำเนินการและรายงานโดยผู้เขียนทักษะนั้นเอง ไม่มีสิ่งใดที่นี่เป็นการทำซ้ำโดยอิสระ และเรากำลังอ้างอิงสิ่งนี้ในฐานะคำกล่าวอ้างของผู้เขียน ณ วันที่ 2026-08-10 ให้ทดสอบกับงานของคุณเองแทน: รันงานเดิมสองครั้ง ครั้งหนึ่งแบบปกติและอีกครั้งหนึ่งโดยใช้ไฟล์ gates จากนั้นนับจำนวน gates ที่ปิดลงพร้อมหลักฐานที่คุณสามารถรันซ้ำได้ด้วยตนเอง จำนวนนั้นคือตัวเลขเดียวในส่วนนี้ที่เป็นของคุณอย่างแท้จริง

FAQ

Depth Tree ใน unlazy skill คืออะไร?

เป็นวิธีการย่อยงาน (decomposition) โดยงานจะถูกแบ่งออกตามจุดเชื่อมต่อที่เป็นธรรมชาติผ่าน N เลเยอร์ และนับเฉพาะส่วนที่เป็น leaf (ใบ) ที่อยู่ล่างสุดเท่านั้นว่าเป็นเนื้องาน ทักษะนี้กำหนดว่า leaf คือความพยายามที่จดจ่ออย่างน้อย 10 นาที โดยมีผลลัพธ์ที่ชัดเจนหนึ่งอย่างและไฟล์ gates หนึ่งไฟล์ ดังนั้นหาก leaf ที่คุณทำเสร็จได้ใน 2 นาที แสดงว่าการแบ่งงานลึกเกินไปหนึ่งเลเยอร์ ทุกเลเยอร์ที่อยู่เหนือ leaf คือการย่อยและการรวมงาน โดยแต่ละกิ่งจะมี gates ของตัวเองเพื่อพิสูจน์ว่าลูกกิ่งได้รวมเข้าด้วยกันแล้วและอินเทอร์เฟซตรงกัน คุณสามารถเลือกระดับความลึกได้เมื่อเรียกใช้งาน เช่น tree 5 และค่าเริ่มต้นที่ระบุไว้คือความลึกที่น้อยที่สุดซึ่ง leaf เป็นหน่วยงานที่แท้จริง

unlazy skill ใช้งานนอก Claude Code ได้หรือไม่?

ได้บางส่วน ทักษะนี้เป็น markdown ธรรมดา ดังนั้น Codex, Cursor และเครื่องมือใดก็ตามที่อ่านไฟล์ SKILL.md หรือ system prompt สามารถใช้ Depth Tree, ไฟล์ gates, การตรวจสอบที่รันได้ และการทำ 4 รอบต่อหนึ่ง leaf ได้ แต่การบังคับใช้ที่เข้มงวดนั้นแตกต่างกัน ตัว Stop hook ที่บล็อกการสิ้นสุดเทิร์นในขณะที่ gates ยังไม่ผ่านเป็นฟีเจอร์ของ Claude Code ซึ่งติดตั้งด้วย node <path-to-skill>/scripts/install-hooks.mjs ในที่อื่นไม่มีสิ่งใดป้องกันเชิงโครงสร้างไม่ให้โมเดลจบเทิร์นก่อนกำหนด ดังนั้นคุณจึงเป็นผู้ที่ต้องอ่านไฟล์ gates และส่งกลับไปให้โมเดล

unlazy skill เพิ่มค่าใช้จ่าย token มากน้อยเพียงใด?

ผู้เขียนรายงานว่าอยู่ที่ 1.6 ถึง 3.9 เท่าของ output token เมื่อเทียบกับการรันแบบไม่มีทักษะในโหมดเดี่ยว โดยมีค่า overhead เพิ่มเติมอีกไม่กี่ร้อย token สำหรับไฟล์ gates เอง การเจาะลึกภายใน context เดียวกันนั้นแทบไม่มีค่าใช้จ่ายเพิ่มเมื่อเทียบกัน โดยอยู่ที่ประมาณ 1.0 ถึง 1.5 เท่าเมื่อขยับจาก tree 3 ไป tree 6 โหมด orchestrated เป็นโหมดที่มีค่าใช้จ่ายสูงที่สุด เพราะทุก leaf จะใช้ context ใหม่ที่ต้องอ่านสัญญาและ gates ของมันก่อนเริ่มทำงาน ส่วน Stop hook ไม่เพิ่มค่าใช้จ่ายใดๆ เพราะทำหน้าที่เพียงสแกนไฟล์เท่านั้น ข้อมูลเหล่านี้เป็นตัวเลขของผู้เขียน ณ วันที่ 2026-08-10 ไม่ใช่การวัดผลที่เราทำซ้ำ

ควรใช้ unlazy หรือ ponytail?

เลือกใช้ทักษะให้ตรงกับปัญหาที่คุณพบ ponytail เหมาะสำหรับเอเจนต์ที่เขียนงานมากเกินไป เนื่องจากมันจำลองบทบาทนักพัฒนาอาวุโสที่คอยตั้งคำถามว่าโค้ดนั้นจำเป็นต้องมีอยู่จริงหรือไม่ และเลือกใช้ standard library ก่อนเสมอ ส่วน unlazy เหมาะสำหรับเอเจนต์ที่ทำงานที่คุณสั่งไม่เสร็จสมบูรณ์ เนื่องจากมันบังคับให้มีการย่อยงานและปฏิเสธที่จะปิด gate หากไม่มีหลักฐานยืนยัน หากคุณต้องการทั้งสองอย่าง ให้กำหนดขอบเขตงานด้วย ponytail ก่อน จากนั้นจึงส่งขอบเขตนั้นให้ unlazy เพื่อที่คุณจะไม่ต้องเสียค่า effort multiplier ให้กับงานที่ควรจะถูกลบออกไปตั้งแต่แรก

ทำไมเอเจนต์ของฉันยังหยุดทำงานก่อนกำหนดหลังจากติดตั้ง unlazy?

ให้ตรวจสอบ 4 ประการ ประการแรก ยืนยันว่าทักษะถูกจัดเก็บอยู่ในดิสก์ด้วย ls ~/.claude/skills/unlazy/SKILL.md เพราะการ clone ลงในไดเรกทอรีที่ไม่มีอยู่จริงเป็นข้อผิดพลาดที่พบบ่อย ประการที่สอง ยืนยันว่ามีการเขียนไฟล์ gates ก่อนเริ่มงาน เพราะ hook จะสแกนไฟล์ gates และการไม่มีไฟล์ GATES.md จะทำให้ไม่มีสิ่งที่ต้องบล็อก ประการที่สาม ยืนยันตำแหน่งที่ติดตั้ง hook: การรัน install-hooks.mjs แบบปกติจะเขียนลงใน settings.local.json ของโปรเจกต์นี้เท่านั้น ดังนั้นโปรเจกต์อื่นจำเป็นต้องใช้ --global ประการที่สี่ โปรดจำไว้ว่าวาล์วระบาย (release valve) ทำงานตามที่ออกแบบไว้ เนื่องจากหากมีการบล็อกการหยุดทำงานติดต่อกัน 6 ครั้งโดยไม่มีความคืบหน้าของ gate เอเจนต์จะได้รับอนุญาตให้ไปต่อพร้อมคำเตือน และบรรทัด ABANDON: <gate> <reason> จะยุติความพยายามนั้นโดยเจตนา