principle-build-the-lever

构建杠杆

当工作并非微不足道时，就构建一个能完成它的工具，而不是手动操作。

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

模式： 默认构建杠杆。只有任务微不足道、只需几处一眼就能看明白的显而易见的编辑时，才跳过。

• 先手动完成第一个单元，摸清方法，再构建工具。通过在该单元上重新运行工具，并与手动完成的版本比较差异来验证。确保杠杆可以安全地重复运行。
• 用代码转换工具或脚本进行编辑，用生成器创建重复性文件，用转储到 SQLite 的查询进行分析，用可重复运行的检查进行验证。
• 确定性的杠杆胜过分散任务。如果工具能一次处理所有单元，就自己运行。不要把脚本能完成的工作分散给委派人员手动处理。
• 将工作分配给子 Agent 时，把杠杆写成所有人都要阅读的技能：将方法、验证约定和禁止触碰的范围写在同一个产物中。把它放在委派人员的写入范围之外，避免他们悄悄修改约定。
• 应用这一原则会产出一个文件。如果你引用了这一原则，但差异中没有代码转换工具、脚本、生成器或委派技能，那就说明你并未应用它。
• 如果工作会持续到本次会话结束之后，就提交这个杠杆。

平衡： 判断标准是任务是否微不足道，而不是是否重复。即使是一次性的工作，只要杠杆能让工作变得可检查，就值得构建。根据 Laziness Protocol，构建能完成或证明任务的最小脚本，绝不构建框架。

这与 Encode Lessons in Structure 不同，后者是将反复出现的指令变成持久的防护措施。本原则关注的是当前工作的效率和可评审性。如需了解如何编写验证脚本本身，请参阅 Prove It Works。