principle-build-the-lever

构建杠杆

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

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

默认选择构建杠杆。只有当任务微不足道、只是几处一眼就能看清的明显改动时，才跳过。

• 先手动完成第一个单元，摸清方法，然后构建工具。在这个单元上重新运行工具，并与手动完成的版本进行差异比较，以此验证工具。确保杠杆可以安全地重复运行。
• 对于比较工具，为它声称能比较的每种输出分别植入一个已知错误的改动，并确认工具会报告每处不匹配。例如，先改动总数，再单独调换项目分配，同时保持总数不变。如果缺少必需的输入，工具必须拒绝执行或报告结果无法确定，绝不能判定为匹配。将这些控制保留在实验中，并在信任结果前重新运行。
• 用 codemod 或脚本进行编辑，用生成器创建重复文件，用可重复运行的转储到 sqlite 查询进行分析，用可重复运行的检查进行验证。
• 确定性杠杆胜过分派。如果工具能一次处理每个单元，就亲自运行它。不要把脚本能做的工作分派给代理手动处理。
• 将工作分派给子 Agent 时，把杠杆写成所有人都要阅读的技能：将方法、验证约定和禁止触碰的边界放在同一份产物中。将它放在代理无法写入的范围之外，避免他们悄悄修改约定。
• 应用这一原则会产出一个文件。如果你引用了它，但差异中没有 codemod、脚本、生成器或代理技能，那你就没有应用这一原则。
• 如果这项工作会超出当前会话，就提交杠杆。

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

这与 Encode Lessons in Structure 不同，后者是将反复出现的指示固化为持久的防护措施。本原则关注的是眼前工作的吞吐量和可审阅性。若要编写验证工作本身的脚本，请参阅 Prove It Works。