【2026 最新】Unlazy 教學：Acceptance Ledger＋Depth Tree 如何驗收 Agent 假完成？

Agent 很有自信地說「完成」，你打開 repo 卻發現文件沒更新、手機版跑版、測試只跑了一半——不能假設把提示詞改成「請更努力」，這種「假完成」就會消失。這篇 Unlazy 教學專為第一次替 Claude Code、Codex 或其他 coding agent 設計驗收流程的人而寫：我們會把需求改寫成 Acceptance Ledger、把大任務拆成 Depth Tree，再用一套可重現 A/B 方法判斷它究竟提高了品質，還是只增加 Token 與等待時間。

截至 2026 年 9 月 22 日，skills.sh 顯示 Unlazy 有 6.6K installs、3.5K GitHub stars；這是人氣快照，不是效果證明。更重要的是，官方重跑協議明說：早期六次比較缺少 prompt、逐步紀錄、輸出 repo、Token log 與計算程式，不能當成可稽核 benchmark。因此本文交付的是可直接執行的驗收與 A/B 設計，不會捏造一組「用了就進步幾倍」的結果。

先說結論：Unlazy 不能保證正確，但能改變「完成」的門檻

• 它做得到的：先列出可觀察的承諾，再讓可執行 gate 以 exit code、預期輸出與目前 evidence 判斷是否通過；工作回來後可以重跑。
• 它做不到的：自動知道規格是否完整、英文 gate 與 shell 指令是否真的在驗同一件事，也不能把錯誤測試變成正確測試。
• 建議起手式：先用 solo ledger，不要一開始就堆多層樹；當 coherent deliverables 需要 fresh contexts、獨立 ownership 或跨分支整合時，再考慮 Depth Tree。
• 效果怎麼判斷：用 Agent 看不到、改不到的 Hidden Oracle 驗收預先凍結的 acceptance outcomes，再以盲評補上 UX／安全等人工項目，並比較假完成、人工接手、時間與 Token。

Unlazy 教學先記住這句：Done 不是一句話，而是一組可重跑證據

完成 ≠ Agent 說 Done；完成＝每個必要承諾，都有能重新觀察結果的證據。

可以把它想成搬家點交。口頭說「都搬完了」是 final answer；逐房間清單是 Acceptance Ledger；開燈、開水、數鑰匙是 runnable gate；把客廳、廚房、倉庫分給不同人並在最後一起點交，就是 Depth Tree。清單的設計目的，是把已列出的遺漏顯示出來；但若你忘了把「冰箱裡的食物」寫進去，整張表全綠仍然可能漏東西。

這也是為什麼它與一般「多想一步」提示不同。Quantifying Laziness 在有限的 GPT-4 variant／DeepSeek 設定中，把 partial compliance 與提前截斷列為可觀察問題；Microsoft Research 的 Webwright 也在 Agent 輸出 done: true 前加入最終腳本、log、screenshot gate 與 Agent 自己的 self-reflection 判斷。這些材料說明外部 evidence gate 是一種實際設計選擇，卻沒有測 Unlazy 本身，也不能取代獨立 Hidden Oracle 或證明完成率改善。

Acceptance Ledger、Gate Checker、Depth Tree 各自做什麼？

1. Acceptance Ledger：先寫可驗收結果，再開始施工

Ledger 通常是 GATES.md。每一列只寫一個可觀察 outcome；能用程式判斷的項目，加上 CHECK: 與 EXPECT:，不能自動化的 UX 或風險判斷才留給 manual evidence。它像測驗的配分表：不是寫「完成前端」，而是拆成「360px 寬度沒有水平捲軸」「鍵盤可完成主流程」「既有桌機版測試沒有回歸」。

2. Gate Checker：只承認 exit 0、命中 EXPECT、而且證據仍屬於目前定義

在本文鎖定的原始碼中，runnable gate 要同時滿足三件事：命令 exit code 是 0、合併輸出符合 EXPECT:、ledger 裡的 evidence 仍綁定目前已解析的 CHECK、EXPECT 與原始 CWD 定義。這三項改變才會讓 automatic evidence 過期；resolved path、shell、timeout、platform 與 PATH 等執行身分由另一套 runtime approval 約束。父層能用 --reverify 嘗試重跑已核准的 runnable gates。但官方README 的 gate contract同時畫出界線：checker 只能證明你宣告的命令 oracle，不能理解 gate 標題與命令在語義上是否一致。

3. Depth Tree：按真實邊界拆工，不是把努力乘上樹深

現行Depth Tree 方法明確要求不要把 depth 當成 effort／Token 的算術承諾。現在的 tree 用來暴露元件、所有權、依賴與整合點：小 bug 可以只用一張 ledger；當多個 coherent deliverables 值得交給 fresh contexts／獨立 ownership，或 API、前端、資料遷移需要 branch integration gates 時，再建立 leaves。更多層級若沒有新工作或驗收邊界，只會增加管理項目，是否值得仍要由 A/B 判斷。

4. Stop Hook：對已宣告 unmet 狀態回傳 block，不替你執行驗收

可選的 Claude Code Stop hook 會掃描 ledger 與 dispatch 中已宣告的狀態，在仍有 unmet gate 或未完成 dispatch wave 時回傳 block；它不執行 CHECK:，而且連續六次沒有語義進展後會放行，避免在完全無語義進展時持續 block。Codex 可使用同一套 Skill 與 gate checker，但這個 hook 不是跨 Agent 通用的強制層。把它理解成「門口提醒」，而不是保全替你重新驗屋。

版本先鎖死：本文使用的是原始碼，不是正式 2.1.0 Release

截至 2026 年 9 月 22 日，Unlazy main 的目標版本是 2.1.0，但官方仍標為 Unreleased，GitHub Releases 頁面也沒有 Release。本文把目前設計簡稱為「v2」，實際鎖定 commit 16671491f6679ad9378f52604d3bc2415b4120c7；不要把它寫成已發布穩定版。

git clone https://github.com/Leonxlnx/unlazy.git
git -C unlazy checkout 16671491f6679ad9378f52604d3bc2415b4120c7
npm --prefix unlazy test

AlphaLab 在同日以 Node.js 24.15.0、npm 11.14.0 執行上面官方測試，七組共 188/188 項測試通過。這只能說明該 commit 的 parser、checker、lease、hook、installer 與結構檢查在這個環境通過，不能推論它會讓任一模型提高多少 Hidden acceptance pass rate。

一般安裝可依官方指令執行 npx skills add Leonxlnx/unlazy，再在支援 slash skill 的工具輸入 /unlazy。Codex 的現行官方 Skill 文件則說明：Codex CLI／IDE 的 repo skill 放在 .agents/skills、個人 skill 放在 ~/.agents/skills，並用 $unlazy 明確呼叫；可先輸入 /skills 確認它真的被載入。做 A/B 時不要追著會變動的 main，兩組都要記錄確切 commit 與 Agent 版本。

Unlazy 教學實作：先做一張可被反證的 GATES.md

假設任務是「把舊設定格式遷移到新格式，同時保留向下相容」。一種可能出現的假完成，是新格式測試綠了，舊 fixture、文件範例或錯誤路徑沒被碰到。可先從這個最小模板改寫：

# Gates: settings migration

- [ ] G1: 舊版與新版設定都能載入，遷移後欄位值正確
  CHECK: node scripts/verify-settings-migration.mjs
  EXPECT: settings migration verification passed
  EVIDENCE: pending

- [ ] G2: 非法設定會失敗，且不會留下半套輸出
  CHECK: node scripts/verify-invalid-settings.mjs
  EXPECT: invalid settings rejection passed
  EVIDENCE: pending

- [ ] G3: 使用文件的兩個範例能由真實 parser 讀取
  CHECK: node scripts/verify-doc-examples.mjs
  EXPECT: documentation examples passed
  EVIDENCE: pending

三支 verifier 都應先執行所有 assertion，只有全部通過才印 success marker。尤其是「沒有多餘檔案」「沒有洩漏 secret」這類 absence check，要放一個已知會失敗的 positive control，證明路徑、glob 與 pattern 真的看得到違規案例。否則「搜尋不到」可能只是搜尋了錯誤目錄。

# 只解析狀態，保證不執行 CHECK
node <path-to-skill>/scripts/gate-check.mjs --status GATES.md

# 先讀懂每個命令與被呼叫的 script，再核准並立即執行待驗 gate
node <path-to-skill>/scripts/gate-check.mjs --approve GATES.md

# 交付前重驗全部 runnable gates；只有目前 runtime oracle 已核准者會執行
node <path-to-skill>/scripts/gate-check.mjs --reverify GATES.md

# 若 resolved CWD、shell 或 PATH 等 approval identity 可能改變
node <path-to-skill>/scripts/gate-check.mjs --approve --reverify GATES.md

--status 才是永遠不執行命令的模式；普通模式在同一 oracle 已核准後可能直接執行。CHECK: 是任意 shell code，會繼承目前檔案、環境變數、網路與憑證權限。Approval 代表你同意執行，不是 sandbox；被呼叫的 script、fixture 或 dependency 內容也不會因命令字串沒變就自動重新取得核准。想把 coding agent 的測試與驗收底層補起來，可先讀 Coding Agent 測試驗收方法。

另有一個本文鎖定 commit 的時效性陷阱：截至 2026 年 9 月 22 日，公開 issue #36 重現了「gate 已 met 後，若 resolved CWD、shell 或 PATH 改變，單獨執行 --approve 可能略過新的 runtime approval」；相關 PR #37 當時仍未合併。遇到這個特定情境，先確認上游狀態；在該 commit 可合併使用 --approve --reverify，並逐項閱讀將執行的 oracle。

A/B 怎麼跑：三種任務、兩個條件、每格至少多次重跑

入門 pilot 可選三種容易「看起來好了」的 repo 任務：跨檔案設定遷移、響應式／無障礙前端修改、帶負向案例的 parser 或權限 bug。每題都跑 baseline（不載入 Unlazy）與 treatment（載入固定 commit、使用 Acceptance Ledger；有真實整合邊界才用 Depth Tree），每格先做 3 次，共 18 次。三次只可能暴露流程錯誤與初步變異，不能證明普遍效果；若結果要影響團隊流程，應先用 pilot 估變異，再以預先登錄的 power／simulation 增加不同 repo 與 repetitions。

第一步：在執行前凍結實驗卡

先寫下 Agent 產品、完整模型 ID／snapshot、reasoning、權限、工具、system rules、base commit、lockfile、OS、runtime、網路政策、context／Token／時間上限、retry 與 timeout 規則。Hosted model 若不能鎖 snapshot，就記錄執行時間，並讓 A、B 在同一時間區塊交錯。這些欄位任何一項不同，都可能把「Unlazy 效果」變成模型、快取或依賴差異。

{
  "base_commit": "REPO_COMMIT",
  "unlazy_commit": "16671491f6679ad9378f52604d3bc2415b4120c7",
  "agent_product": "PRODUCT_AND_VERSION",
  "model_snapshot": "EXACT_MODEL_OR_DATED_UNKNOWN",
  "reasoning": "FIXED_SETTING",
  "permissions": "FIXED_POLICY",
  "wall_time_limit": "FIXED_BEFORE_RUNS",
  "retries": 0,
  "primary_outcome": "all_hidden_acceptance_outcomes_pass"
}

第二步：每次 run 都用全新 session 與 worktree

前一次的 transcript、review、.unlazy 狀態或修正結果都不能流進下一次；可控制的本機 cache 要清除或用 run id 隔離，無法控制的 provider cache 則記錄為限制。兩組收到完全相同的需求與 acceptance bullets；差別只能是是否載入 Unlazy 工作流。可用 detached worktree 建立每個起點：

git worktree add --detach ../runs/T1-A-1 REPO_COMMIT
git worktree add --detach ../runs/T1-B-1 REPO_COMMIT

# A = baseline；B = pinned Unlazy
# T1、T2、T3 各自把 A/B 的順序隨機化，再建立第 2、3 次 run

如果 baseline 額外少看到需求內容，效果就混入「有沒有寫清楚規格」的差異，不能歸因於 ledger 形式。兩組必須看到同一份可見需求；B 組只是把那些要求映射到 ledger、執行 gate、必要時用 tree 管理分工。

第三步：用 Hidden Oracle 當裁判，不拿可見 gate 自我評分

Hidden Oracle 應在實驗前由另一個人凍結並計算 checksum，再放進 Agent 工具無法存取、由 ACL／容器／網路邊界隔離的 evaluator，Agent session 結束後才執行；checksum 只能證明內容身分，不能代替存取隔離。Oracle 只能驗證使用者已明說的需求，不能偷偷加入新需求。前端題要測不同 viewport、鍵盤路徑與 console；設定題要測舊 fixture、新格式、rollback 與禁改範圍；負向斷言要有一個已知違規 fixture，證明 verifier 有能力失敗。

原因是「可見測試通過」不等於「長任務完成」。SlopCodeBench v2 的最新 arXiv metadata涵蓋 36 題、196 checkpoints、15 個 coding agents；沒有任何 agent 端到端解完一題，最佳 checkpoint pass rate 為 14.8%。這不是 Unlazy 評測，但提醒我們要把 checkpoint pass 與全任務完成分開記。

第四步：先看 Hidden acceptance，再算成本

• Hidden acceptance pass rate：預先凍結的 Hidden Oracle outcomes 是否全部通過；另外保留 UX／安全盲評，不把 hidden tests 假裝成完整正確性。
• 完成聲明分類：執行前定義 success、partial、handoff 的判讀規則，讓不知道 treatment 的 reviewer 依 final answer 分類並處理分歧。
• 假完成：同時報「成功聲明且 hidden outcome 失敗 ÷ 全部 runs」、「成功聲明且 hidden outcome 失敗 ÷ 所有成功聲明」與「（成功聲明且 hidden outcome 失敗）÷ 所有 hidden outcome 失敗」；避免 treatment 只因少說成功就顯得更可靠。
• 誠實 handoff：未完成時是否清楚交代阻塞與證據；它不是成功，必須依預先凍結的 blind-review rubric 另列。
• 規格覆蓋：先凍結可見 requirements 的分母，再算多少進入 ledger；另記 vacuous gate、manual gate 與錯誤 path。
• 代價：輸入、cached input、輸出 Token、wall time、API 成本、重試、人工審查與接手分鐘。
• 每次 hidden pass 成本：該組所有 runs 的總成本 ÷ Hidden Oracle 完整通過次數；不能刪掉失敗 run，零成功要預先規定為不可估，並同時顯示總成本與 raw passes。

建議同時報 raw counts、中位數與範圍。三次得到 2/3 與 3/3 並不代表 B 已被「統計證明」較好；run 是觀測／隨機分派單位，task 是 block、cluster 與一般化單位，同一 run 裡的 100 個 tests 不是 100 個獨立樣本。若要估 tree 的增量，可改成三臂 staged ablation：baseline、ledger／checker、ledger／checker＋tree；「tree only」不是現行 Unlazy tree，Claude Code 專用 Stop hook 也應另作 factor。不要從兩臂結果反推是哪個元件有用。這和 Agent Skill Routing A/B Test 的核心相同：一次只回答你真的操弄過的因果問題。

6 個關鍵坑：Gate 全綠，成品仍可能錯

1. CHECK 根本沒觀察 gate 標題

官方 repo 的公開 issue #13 曾用「八顆行星都能點」搭配 CHECK: echo ok 重現綠燈。這不是 parser bug，而是 oracle 語義缺口。解法是讓 verifier 讀取真正 artifact／service，並讓 success marker 只出現在所有 assertion 之後。

2. Ledger 漏掉原始需求

若任務要求 A＋B，PLAN 只收 A，所有已宣告 gate 都可能完美通過。現行 contract inventory 會要求把每項必要 outcome 映射到 owner 與 observation，但仍需要人或獨立 reviewer 重讀原始需求。可搭配 Agent Skill／SKILL.md 教學，先把觸發條件、輸入與成功定義寫清楚。

3. Absence check 搜錯地方也會通過

「沒有 secret」「沒有 staging URL」這類 negative gate 可能假綠：錯誤 path、空 glob、壞 regex 都可能回報找不到。官方合併的 PR #15 因真實課程稽核案例加入三條 gate authoring 規則，其中第一條就是 negative gate 要有 positive control。

4. Approval、evidence 與 ledger 都不是防竄改證明

自動 evidence 用未加金鑰（unkeyed）的 SHA-256 摘要綁定 gate 定義，能偵測結構漂移，卻不是身份驗證；能編輯 ledger 的人也能偽造外觀。成功輸出的原文只留下 fingerprint／byte count，Approval 也不會雜湊被呼叫的 transitive scripts。高風險任務要保存外部 CI log、artifact checksum 與 reviewer 記錄，不能只留一張打勾的 Markdown。

5. Gate 過嚴、規格寫錯或反覆修同一點

執行前就定義每個 run 的時間／Token／retry cap。超過上限、同一失敗沒有新證據，或 spec 與需求矛盾時，停止並保留 transcript。若錯誤 gate 是 Agent 在 treatment 中自己寫出的，它就是 treatment 行為，必須照預先規則計分，不能排除；只有與 treatment 無關、事先定義的 infrastructure／evaluator 故障才可標成 invalid。若研究者提供的共同規格或 oracle 本身有錯，建立新 protocol version，對所有組別從乾淨起點對稱重跑，並保留舊結果。無法完成則用明確 handoff，而不是刪 gate。

6. 把更多樹、更多 Agent 誤當成更多品質

一個單檔 bug 通常可先從 solo ledger 開始；branch integration、lease、dispatch wave 與 parent reverify 都會增加管理項目。先用 AI Agent Harness 的觀念判斷哪些驗收該由模型外部執行，再參考 AI Agent Harness 實作指南把 checker 放進真正的 CI／browser runner。當 fresh contexts、獨立 ownership 或跨分支整合可能帶來新證據時，再把 Depth Tree 納入 A/B。

什麼任務值得用 Unlazy？

• 值得：需求可拆成多個獨立 outcomes、常漏文件／回歸／跨端驗收、修改風險高，或會由多個 Agent／人員交接。
• 先用 solo ledger：單一 bug、單一 feature、文件或小型 refactor；先保留少量、真正能失敗的強 gate，不為了數量加入弱 gate。
• 再升級 Depth Tree：API、資料、前端與 deployment 有明確所有權，而且 branch 能執行跨子任務 integration test。
• 不值得：幾分鐘能人工確認的低風險改字、沒有可觀察 artifact 的腦力激盪，或 verifier 成本比錯誤本身更高。

一個務實的採用方式，是先挑你團隊經常返工的一類任務跑小型 pilot，而不是把所有 repo 一夜之間改成深樹。與站內的 OMP Plan／Advisor／Reviewer A/B 教學相比，OMP 那篇設計比較的是額外角色；本文提出要比較的 treatment 是「驗收帳本＋可重跑 oracle＋必要時分解」這一整套 completion discipline，兩者回答的問題不同。

常見問題

1. Unlazy 真的能阻止 Agent 假完成嗎？

不能保證。它會把已寫入 ledger、且 oracle 判定為 unmet 的狀態顯示出來；漏規格、弱測試、錯路徑與 manual judgment 仍可能假綠，是否改善完成率要由 A/B 判斷。

2. Acceptance Ledger 就是另一份 todo list 嗎？

不只。普通 todo 記活動；ledger 應記 outcome，並把可判定結果連到可重跑 command 與 evidence。

3. Depth Tree 越深，Agent 會越努力嗎？

不一定，而且現行官方方法明確反對這種算術承諾。深度只應對應真實工作與整合邊界。

4. 每個 gate 都通過，就能交付嗎？

還要重讀原始需求與執行獨立整合驗收。Gate 只證明它觀察的 oracle；使用者意圖、UX、安全與未列出的 requirement 可能仍在外面。

5. 可以直接執行別人 repo 裡的 GATES.md 嗎？

不可以盲跑。先用 --status 檢查，再閱讀每個 command 與被呼叫 script；CHECK: 會用你的環境權限執行。

6. Stop hook 會不會讓 Agent 永遠卡住？

官方設計有六次無語義進展的 release guard。但過嚴 gate 仍可能增加數輪重試，所以必須另外設定整體預算、停止與 handoff 規則。

7. 三次 A/B 重跑夠嗎？

只夠 pilot。它可能暴露流程錯誤與初步變異；要做一般化結論，必須增加 task diversity、重跑數與預先定義的不確定性分析。

8. 應該先開 ledger、tree，還是 Stop hook？

先 ledger。先證明 gate 能觀察真正 outcome，再視跨元件需求加 tree；Stop hook 最後才作為 Claude Code 的可選提醒層。

給新手的 5 個重點

• 先寫 outcome，後寫 command；不要用「完成實作」這種活動名稱。
• 每個 success marker 都只能在全部 assertion 後出現，negative gate 一定要有 positive control。
• 先跑 --status、讀懂指令，再 --approve；交付前用 --reverify。
• 效益要由獨立 Hidden Oracle 判斷，不能用 Unlazy 自己的綠燈證明 Unlazy 有效。
• 記住本文錨點：Done 不是一句話，而是一組可重跑證據。

想持續追蹤 Agent、模型與工作流，可瀏覽 AlphaLab AI 專區；若想把這類方法整理成自己的工作系統，也可查看 AlphaLab 課程。