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