用途
“Build the Lever”是一条适用于任何非琐碎工作的原则，不限于批量工作：编辑、迁移、分析、检查等。其核心主张是：当工作并非琐碎时，应构建能完成该工作的工具，而不是手工去做。
主要能力与理由
- codemod、生成器或脚本每次都以相同方式完成工作，并且可以免费重跑。
- 工具是一件产物，审查者可以阅读并重跑它来核查工作。手工完成的改动只能通过重做来重新验证。
- 确定性脚本把“相信我”变成“运行这个”。
使用方式
默认构建杠杆。仅当任务确实琐碎——一眼可见的少量明显编辑——时才跳过。
先手工完成第一个单元以摸清配方，然后构建工具。通过在该单元上重跑工具并与手工版本做 diff 来验证。让杠杆可安全重跑。
具体形式包括：编辑用 codemod 或脚本，重复文件用生成器，分析用 dump-to-sqlite 查询，验证用可重跑的检查。
确定性杠杆优于扇出。如果工具能一次处理每个单元，就自己运行它。不要把脚本能做的事扇出给委派者手工应用。
当把工作扇出给子代理时，把杠杆写成一个它们都读取的技能：配方、验证契约和“禁止触碰”的围栏放在同一件产物中。把它放在委派者的写入范围之外，这样它们就无法悄悄修改契约。
应用这条原则会产生一个文件。如果你引用了它，而 diff 中没有 codemod、脚本、生成器或委派技能，那你就没有应用它。
当工作比会话更长久时，提交这个杠杆。
适用场景
适用于编辑、迁移、分析、检查等任何非琐碎工作。门槛是琐碎性，而非重复性。一次性工作仍然值得一个杠杆，当杠杆正是让工作可核查的原因时。按照 Laziness Protocol，构建能完成或证明该工作的最小脚本，绝不要构建框架。
限制与边界
- 仅当任务确实琐碎（一眼可见的少量明显编辑）时才跳过构建杠杆。
- 与“Encode Lessons in Structure”不同，后者把重复出现的指令变成持久护栏；本原则关注的是眼前工作的吞吐量和可审查性。
- 关于把验证本身脚本化，参见“Prove It Works”。
暂未提供
该技能的安装命令、平台支持、收费与价格信息在给定资料中暂未提供。