unlazy

一个逼 agent 在动手之前先把「做完」写下来的技能。台账里的每个闸门是一条 shell 命令加上它必须产出的输出，只有进程退出码为 0 且期望值匹配合并输出才算通过——于是任何「完成了」的说法都得先扛过一次重跑。校验脚本只要 Node 16 以上、不带任何第三方运行时依赖：它可以只做检查而不执行任何命令，也可以在明确批准之后执行，或者把包括已标记完成在内的所有可执行闸门全部重跑；可选的 Stop 钩子在闸门未达成、或启动波次没收齐时，不让 Claude Code 的会话结束。单个闸门之上，是整套东西所依托的 Depth Tree 方法：把任务往下拆 N 层，并让每一片叶子拿到整件事的完整时间预算，于是投入随树的深度上升，而不是被层数除开；编排模式下，互相独立的叶子要在开工之前申明互不重叠的文件归属。

谁做的一位在慕尼黑的开发者，网名 Leonxlnx：账号 2025-07-03 注册，47 个公开仓库，2,167 个关注者，自我介绍只有一句「I build cool stuff」。这个仓库的 49 次提交里 24 次是他写的，其余 25 次分散在另外九个账号上，还有两次提交没有关联账号。他的其他仓库包括 91,596 星的 taste-skill 和 2,550 星的 agentic-ai-prompt-research。

1. 01

   一个反偷懒的技能，第一个月就拿到 3,782 颗星

   仓库建于 2026-08-09T23:39:12Z，而它最早的一次提交时间戳比创建时间还早十五秒——2026-08-09T23:38:57Z，标题是「unlazy: anti-laziness skill built on the Depth Tree method」。这正是把一段本地历史推进一个新建仓库的样子。公开历史共 49 次提交，集中在二十五天里：8 月 48 次，9 月 1 次，最新一次在 2026-09-03T09:31:08Z，标题是「fix: bind gate evidence and harden Windows identity」。到 2026-10-01，它有 3,782 颗星、281 个 fork、12 个 watcher、9 项未关事项——其中八个是 pull request，最新那个的日期是 2026-09-22。贡献者列表里有十个账号；作者本人写了 49 次提交里的 24 次，47 次提交带有关联账号，20 条共同作者尾注全部指向 Claude 模型——12 条 Opus 5、5 条 Fable 5、2 条带百万上下文窗口的 Opus 4.8，再加一条同样是百万上下文的 Opus 5。本记录把它定成 maintained 而不是 active：四周没有推送是一段停顿而不是终点，仓库没有归档，而且提交停下之后队列还在动——仍有八个 pull request 开着，日期从 2026-09-11 到 2026-09-22，全都比 main 上最后一次提交更新。

2. 02

   Depth Tree，以及一条被完整写出来的研究依据

   仓库用一句话说清了自己的核心：Depth Tree 方法把任务往下拆 N 层，并让每一片叶子拿到整件事的完整时间预算，于是投入随深度倍增；同一句话里还写着，它是「grounded in 2025-2026 research on model laziness, underthinking and premature completion」。README 没有把这句话留成姿态。研究依据那一节开篇就写：研究支持那些促使人们引入显式结构的失败模式，但并不能证明 unlazy 带来了确定的改进；随后用数字来论证——SlopCodeBench 里最好的被测 agent 通过了 14.8% 的检查点；METR 的 Time Horizon 1.1 报告全体 P50 倍增时间拟合为 196.5 天，而 2023 年之后的数据拟合是 130.8 天，并明确提醒不要把短的那个数字说成全时段估计；还有 s1 的 budget forcing，它在模型想停下时反复追加那个词，却同时否认多一个词总能改善结果。下面是来源列表，按最新在前排序，从 2025-02-18 排到 2026-08-06，外加一个没有日期的页面。每条都有标题、链接和日期，有两条带会议出处（COLM 2026 与 NeurIPS 2025），没有任何一条给出作者名——所以这些引用具体、可追溯，但不是完整文献条目。README 还撤回了自己更早版本的证据：旧版曾引用一次六轮内部对比，而重现那些比例与计数所需的原始产物并不在仓库里，因此那批结果只能当作历史设计输入，而不是基准保证。

3. 03

   在被允许停下之前，agent 必须写下什么

   安装是一条命令走 skills CLI（npx skills add Leonxlnx/unlazy），或者把仓库克隆到 ~/.claude/skills/unlazy 与 ~/.codex/skills/unlazy；支持斜杠技能的地方叫它 /unlazy，在 Codex 里是 $unlazy，也可以由自然语言触发。README 给的例子是 /unlazy tree 5 refactor the payment module and verify every migration path，那个数字就是深度。agent 欠下的是一份台账：每个闸门是一条勾选行，带标题、一条 CHECK: shell 命令、一个 EXPECT: 字符串、可选的 CWD:，以及一行 EVIDENCE:。校验器有三种状态：--status，唯一永远不执行命令的模式；普通运行，在还没有精确批准记录的 oracle 上只打印解析出来的命令、期望值、工作目录、shell 与继承来的 PATH，而不执行任何东西——README 特意提醒普通模式不是永久试运行；还有 --approve，用在用户读完每一条命令和每一个被调用的脚本之后。--reverify 会重跑所有可执行闸门，包括那些已经标记完成的。可执行闸门只有在进程退出码为 0 且期望值匹配合并输出时才算通过，两者都以 1 MiB 为上限，而且校验器绝不会把超长的匹配串截断成「成功」。解析器会拒绝：没有闸门的台账、重复的 id、写不完整的可执行闸门、非法的期望值，以及缺少理由或指向未知闸门的放弃声明。放弃是终止性的交接而不是通过：退出码 1，并打印 HANDOFF REQUIRED。

4. 04

   那个钩子、那个 shell，以及什么都读不出来的那台机器

   可选的部件是一个 Claude Code Stop 钩子，只有用户同意才通过 install-hooks.mjs 安装。它扫描当前会话解析出来的台账与派发状态，只要还有闸门未达成、或启动波次没收齐，就返回 Claude Code 文档里那个顶层 decision: "block"。它自己不执行任何检查。它那条按会话记账的进度护栏在连续六次阻塞之后放行，而只改元数据的编辑不会让它重置——这个修正来自一条 pull request：此前的版本拿台账字节做哈希，于是任何编辑（包括校验器刚刚重写的那行证据）都会让计数器归零，把一个根本做不完的 agent 永久困住。校验器的 shell 依次取 --shell、UNLAZY_SHELL、平台默认值，而检查会继承启动环境（含 PATH），所以同一个校验器从 Git Bash 启动时能看到的工具，从 PowerShell 启动时看不到；--shell 换的是解释器，它不会替你装 grep 或 tail。而在 Windows 上，一位读者发现每一次文件读取都以失败告终：他那台机器上 fstat().dev 永远不等于 lstat().dev，于是校验器读不到任何台账，干净克隆下 32 个测试只过 5 个，在两个卷、Node 22.14.0 上都能复现。修法是用第二个不创建文件的句柄去比较大整数的描述符身份；作者保留了 SECURITY.md 里写明的「快照式」保证。更早一轮 Windows 修复清掉了孤儿进程：只杀 shell 会把检查的子进程留在后台，所以超时现在改调 taskkill /pid <PID> /f /t。

5. 05

   永远不会失败的闸门，和那条没人读的参数

   最有用的几轮来自真的拿这个技能干活的人。一条报告指出：某个闸门的 CHECK: 根本没观察它标题所称的东西，却照样返回 PASS、写出证据、退出码 0——因为叶子自检、--reverify 和 Stop 钩子问的是同一个 oracle。第二位报告者从另一个方向撞上同一类问题：他在一次十六周的课程就绪度审计里试用这个技能，闸门由另一个模型在另一套 harness 下写、也没装钩子，而让他不安的那个闸门守的正是任务里唯一一条硬约束——只读、不写。维护者修掉了那些机器可判定的假绿，合并了撰写规则，同时把话说白：校验器仍然无法证明「文字」与「命令」意思相同，这条边界现在是显式的。另一处 bug 值得记下来，因为它被报告过不止一次：indexOf("--timeout") 在选项不存在时返回 -1，于是下一个索引成了 0，过滤器把第一个位置参数丢掉——只点名一个台账文件时，运行要么偷偷扩到目录里所有台账，要么根本没读那个文件却报告成功。它最终以显式指定文件加回归测试的方式修掉；两次报告里有一次本身就是一个 pull request，其作者在看过后开放队列之后，把它作为更早一条报告的重复项自己关掉了。

6. 06

   十五条社区改动，和一个没有 release 可放的版本

   有三条报告针对的不是单个闸门而是整棵层级：被放弃的必需闸门仍能打印 ALL MET 并把完成度记到父节点头上；被调用脚本或其输入变化之后，批准仍可能保持「当前」；还有一份计划可以漏掉两个交付物里的一个，而所有已声明的闸门全都通过。第一条和第三条被修掉了——放弃再也不能把父节点提升为已完成，计划现在要清点可独立遗漏的需求，并在派发之前重读请求——第二条则作为有文档的安全边界关掉，因为批准绑定的是已声明的命令与环境，而不是被间接调用的脚本字节。这个仓库的发版节奏很不寻常：没有 release，也没有 tag。README 说当前源码目标是 2.1.0，但它不是一个打过 tag 的 GitHub release，需要不可变安装的人应当钉住某个具体提交；本该是 release notes 的东西放在一份 16,636 字节的 CHANGELOG.md 里，那里同时记录贡献者历史与 pull request 链接。社区成果就落在这个未发布的 2.1.0 中——列了十五条，把各条 pull request 里有用的部分整合进来、同时修掉它们的边界情况；测试数也跟着走：在 265fbd5d 这个提交上是七个套件共 137 个通过，后来变成 188 个、自检 15/15。持续集成跑 Ubuntu、Windows 与 macOS 乘以 Node 16、20、24：八月的一次是 9/9 个作业通过，九月的一次是 10/10，并钉住了 Node 22.14.0 与 libuv 1.49.2 的 Windows 作业。