Build the Lever（构建杠杆）
当工作并非琐碎时，应构建能完成它的工具，而不是纯手工去做。
理由：两个收益。吞吐量——codemod、生成器或脚本每次都以相同方式完成工作，并且可以免费重跑。可信度——工具是一件产物，审查者可以阅读并重跑它来核验工作。手工修改只能通过重做来重新验证。确定性的脚本把"相信我"变成"运行这个"。
模式：默认构建杠杆。仅当任务琐碎、只是几处一眼可见的明显编辑时才跳过。
先手工完成第一个单元以摸清配方，然后构建工具。通过在第一个单元上重跑工具，并与手工版本做 diff 来证明它。让杠杆可安全重跑。
编辑用 codemod 或脚本，重复文件用生成器，分析用 dump-to-sqlite 查询，验证用可重跑的检查。
确定性的杠杆胜过扇出。如果工具能一次处理所有单元，就自己运行它。不要把委派者扇出去手工应用脚本本可完成的事。
当你把工作扇出给子智能体时，把杠杆写成它们都会读取的技能：配方、验证契约和禁止触碰的边界都放在同一件产物里。把它放在委派者的写入范围之外，以免它们悄悄修改契约。
应用这一原则会产生一个文件。如果你引用了它，而 diff 中没有 codemod、脚本、生成器或委派技能，说明你没有应用它。
当工作持续时间超过当前会话时，提交该杠杆。
平衡：门槛是琐碎性，不是重复性。即使是一次性任务，当杠杆正是让工作可核验的手段时，也值得构建。根据 Laziness Protocol，构建能完成或证明该工作的最小脚本，而绝不要构建框架。
与"Encode Lessons in Structure"不同，后者是把反复出现的指令变成持久护栏。本原则关注的是眼前工作的吞吐量与可审查性。若要为验证本身编写脚本，参见 Prove It Works。