Back to Details

principle-build-the-lever

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Build the Lever

构建杠杆

When the work isn't trivial, build the tool that does it instead of doing it by hand.
Why: Two payoffs. Throughput: a codemod, generator, or script does the work the same way every time and reruns for free. Confidence: the tool is one artifact a reviewer can read and rerun to check the work. Hand-done changes can only be re-verified by redoing them. A deterministic script turns "trust me" into "run this".
Pattern: Default to building the lever. Skip it only when the task is trivial, a couple of obvious edits you can see at a glance.
  • Do the first unit by hand to learn the recipe, then build the tool. Prove it by rerunning it on that unit and diffing against your hand-done version. Make the lever safe to rerun.
  • Codemod or script for edits, generator for repetitive files, a dump-to-sqlite query for analysis, a rerunnable check for verification.
  • A deterministic lever beats fan-out. If the tool can process every unit in one pass, run it yourself. Don't fan out delegates to hand-apply what a script can do.
  • When you fan work out to subagents, write the lever as a skill they all read: the recipe, the verification contract, and the do-not-touch fences in one artifact. Keep it outside the delegates' write scope so they can't quietly edit the contract.
  • Applying this principle produces a file. If you cited it and there is no codemod, script, generator, or delegate skill in the diff, you didn't apply it.
  • Commit the lever when the work outlives the session.
Balance: The bar is triviality, not repetition. A one-off still earns a lever when the lever is what makes the work checkable. Per the Laziness Protocol, build the smallest script that does or proves the job, never a framework.
Distinct from Encode Lessons in Structure, which makes a recurring instruction a durable guardrail. This is throughput and reviewability on the work in front of you. For scripting the verification itself, see Prove It Works.
当工作并不琐碎时，构建工具来完成它，而不是手动完成。
原因： 这能带来两项收益。吞吐量： codemod、generator 或 script 每次都以相同方式完成工作，并且可以免费重复运行。可信度： 工具是一个产物，reviewer 可以阅读并重新运行它来检查工作。手动完成的变更只能通过重做来再次验证。确定性的 script 将“相信我”变成“运行这个”。
模式： 默认构建杠杆。只有当任务琐碎、只需一眼就能看出的几处明显编辑时，才可以跳过。
  • 先手动完成第一个单元以了解做法，然后构建工具。在该单元上重新运行工具，并与手动完成的版本进行 diff，以此证明工具有效。确保杠杆可以安全重跑。
  • 编辑使用 codemod 或 script，重复性文件使用 generator，分析使用 dump-to-sqlite query，验证使用可重跑的 check。
  • 确定性的杠杆胜过 fan-out。如果工具能够一次处理所有单元，就自己运行它。不要 fan out delegates，去手动完成 script 可以完成的工作。
  • 将工作 fan out 给 subagents 时，把杠杆写成一个它们都会读取的 skill：把做法、验证 contract 和禁止修改的边界放在同一个产物中。将它放在 delegates 的写入范围之外，防止它们悄悄修改 contract。
  • 应用这一原则应产出一个文件。如果你在 diff 中引用了这一原则，却没有 codemod、script、generator 或 delegate skill，就说明你并没有真正应用它。
  • 当工作持续时间超过当前 session 时，提交这个杠杆。
平衡： 判断标准是琐碎程度，而不是重复次数。即使是一次性工作，只要杠杆能让工作变得可检查，也值得构建。根据 Laziness Protocol，构建能完成或证明任务的最小型 script，绝不要构建 framework。
这不同于 Encode Lessons in Structure，后者会将反复出现的指令转化为持久的防护栏。本原则关注当前工作的吞吐量与可审查性。若要为验证本身编写 script，请参阅 Prove It Works。