unlazy - AI Agent 深度任務防偷懶工具

解決什麼

大語言模型在執行復雜任務時存在"underthinking"(思考不足)和"premature completion"(提前完成)問題——AI Agent 可能在未完全理解需求時就返回看似完整但實際草率的結果。unlazy 通過"深度樹方法"(Depth Tree)將任務拆分 N 層,每個葉子節點獲得整個任務的完整時間預算,使工作量隨深度指數級增長,強制 AI 完成實質性驗證。核心機制是預先編寫驗收清單(GATES.md),用可執行的 Shell 檢查指令碼作為門控,只有通過所有檢查才算任務完成。

為何火

該專案針對 2025-2026 年 AI Agent 使用中的痛點:當要求 Claude Code 或 Codex 進行大規模重構時,模型常返回"已完成"但實際遺漏邊界情況或測試覆蓋。unlazy 提供可審計的驗收流程:每個門控包含 CHECK: 命令(如 node scripts/verify-pricing.mjs)和 EXPECT: 期望輸出,只有程序退出碼為 0 且輸出匹配才通過。2264 stars 反映開發者對"可驗證 AI 工作成果"的強需求,尤其在金融、醫療等需要嚴格驗收的領域。

核心功能

1. 門控合約系統:用 Markdown 清單定義驗收標準,每個門控包含檢查命令、期望輸出、工作目錄和證據記錄
2. 審批機制:首次執行前需 --approve 審查命令,批准記錄儲存在 ~/.unlazy/approved,繫結命令內容、PATH、shell 等環境指紋
3. 重驗證模式:--reverify 重新執行所有門控(包括已標記完成的),確保依賴變更後仍滿足驗收條件
4. 並行編排:通過 .unlazy/<scope>/ 目錄結構管理多上下文任務,支援葉子節點和中間節點的依賴宣告
5. 安全邊界:審批記錄必須在倉庫外的私有目錄,防止惡意修改;命令繼承啟動環境但不沙箱化

安裝

通過 skills CLI(推薦):

npx skills add Leonxlnx/unlazy      # 當前專案
npx skills add -g Leonxlnx/unlazy   # 全域性安裝

手動安裝:克隆到對應目錄

• Claude Code: ~/.claude/skills/unlazy
• Codex CLI: ~/.codex/skills/unlazy

需要 Node.js 16 或更高版本,無第三方執行時依賴。核心檔案是 SKILL.md(技能描述)和 scripts/gate-check.mjs(檢查器)。

適合誰

• 複雜重構場景:需要 AI 完成多模組改造且必須驗證所有遷移路徑的團隊
• 高可靠性要求:金融支付、資料遷移等容錯率低的專案,需要可審計的驗收證據
• CI/CD 整合:希望將 AI 生成程式碼納入自動化測試流程的開發者
• 多 Agent 協作:通過作用域隔離管理不同上下文的並行任務

中文使用者注意:Windows 下需注意 shell 差異(Git Bash vs PowerShell 的 PATH 不同),示例指令碼呼叫 Node.js 保證跨平臺,但自定義檢查若依賴 grep/tail 等 Unix 工具需額外配置。

社群評價

暫無足量社群公開討論,以下為基於專案本身的中立評估:該專案在 GitHub 上線 15 天即獲 2K+ stars,表明開發者對 AI Agent 質量控制的迫切需求。從設計看,其"先寫驗收再執行"的理念類似測試驅動開發(TDD),但應用於人機協作場景。技術實現較輕量(純 Node.js 指令碼 + Markdown),易於整合現有工具鏈。潛在爭議點可能在於:審批流程增加互動成本,不適合快速原型階段;依賴 Shell 檢查的可移植性在複雜環境下需額外維護。

選型對比

vs 直接使用 AI Agent:原生 Claude Code 缺少強制驗收機制,unlazy 通過門控合約將"AI 說完成"轉化為"可執行證明完成",適合高風險任務。

vs 傳統 CI/CD:Jenkins/GitHub Actions 驗證已提交程式碼,unlazy 前置到 AI 生成階段,在程式碼進入版本控制前就攔截不合格輸出。

vs Langchain Agents:Langchain 側重工具呼叫編排,unlazy 專注驗收紀律,兩者可互補——用 Langchain 驅動任務,用 unlazy 驗收結果。

取捨:unlazy 增加前期清單編寫成本,但減少返工和人工複查時間;不適合探索性程式設計,適合需求明確的工程任務。

已知坑

1. 審批記錄遷移:更換機器或 UNLAZY_APPROVAL_DIR 後需重新審批所有命令,因記錄繫結絕對路徑和環境指紋
2. 依賴變更盲區:審批僅雜湊 CHECK: 命令本身,不追蹤被呼叫指令碼或測試夾具的修改,需手動 --reverify
3. Windows shell 相容性:預設使用 /bin/sh(Unix)或 ComSpec(Windows),跨平臺專案需顯式指定 --shell 或統一用 Node.js 指令碼
4. 無沙箱隔離:檢查命令繼承完整檔案系統和網路許可權,惡意 CHECK: 可執行任意操作,審批前必須人工審查
5. 學習曲線:需理解門控合約語法、證據記錄機制和並行編排規則,文件雖詳盡但概念密度高

據 README,專案當前處於 2.1.0 未標記狀態,建議生產環境固定 commit SHA。gate-lint.mjs 可檢測弱模式(如空期望、重複 ID),加 --strict 可將警告升級為錯誤。