principle-build-the-lever

构建撬杆

当工作并非微不足道时，就构建能完成这项工作的工具，而不是手动处理。

原因： 有两大收益。效率：codemod、生成器或脚本每次都以相同方式完成工作，而且可以免费重复运行。信心：工具是一个审阅者可以阅读并重新运行、以检查工作成果的产物。手动完成的改动只能通过重做来重新验证。确定性脚本能把“相信我”变成“运行这个”。

模式： 默认构建撬杆。只有当任务确实微不足道、只需做几处一眼就能看明白的改动时，才跳过。

• 先手动完成第一个单元，摸清方法，然后构建工具。通过在该单元上重新运行工具，并与手动完成的版本进行差异对比，证明工具有效。确保撬杆可以安全地重复运行。审阅者会这么做。
• 编辑用 codemod 或脚本，重复文件用生成器，分析用从转储数据到 sqlite 的查询，验证用可重复运行的检查。
• 确定性撬杆胜过分散任务。如果工具可以一次处理所有单元，就亲自运行它；不要把脚本能做的事分散给其他人手动处理。
• 将工作分派给子 Agent 时，把撬杆写成所有子 Agent 都会阅读的一项技能：将方法、验证约定和禁止触碰的范围写在同一份产物中，这样每位受派者都能继承同一份经过完善的版本，而不必在每个提示词中反复解释，任由各自逐渐偏离。将它放在受派者的写入范围之外，避免他们悄悄修改约定。
• 应用这一原则会产出一个文件。如果你引用了这一原则，但差异中没有 codemod、脚本、生成器或子 Agent 技能，就说明你没有应用它。
• 如果工作会超出本次会话，就提交撬杆，让下次运行时重新运行它，而不是重新做一遍。

权衡： 衡量标准是任务是否微不足道，而非是否重复。即使是一次性任务，只要撬杆能让工作可检查，也值得构建。按照 Laziness Protocol，构建能完成或证明这项工作的最小脚本，绝不构建框架。

这与 Encode Lessons in Structure 不同；后者是把重复出现的指令固化为持久的护栏。这里关注的是眼前工作的效率和可审阅性。若要编写用于验证的脚本，请参阅 Prove It Works。