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 genuinely 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. A reviewer will.
  • 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, so every delegate inherits the same hardened version instead of re-explaining it per prompt and watching each one drift. 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, so the next run reruns it instead of redoing it.
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、生成器或脚本每次都会以相同方式完成工作，且可免费重新运行。可信度：工具是审核人员可阅读并重新运行以检查工作成果的单一工件。手动完成的变更只能通过重新操作来再次验证。确定性脚本将“相信我”转变为“运行这个”。
模式： 默认构建杠杆工具。仅当任务确实琐碎——比如几个一眼就能看明白的简单编辑时——才跳过构建工具。
  • 先手动完成第一个单元以掌握方法，然后构建工具。通过在该单元上重新运行工具并与手动完成的版本对比差异来验证工具。确保杠杆工具可安全重新运行，审核人员会这么做。
  • 使用codemod或脚本进行编辑，使用生成器创建重复文件，使用导出到sqlite的查询进行分析，使用可重新运行的检查进行验证。
  • 确定性杠杆工具优于分散工作。如果工具可一次性处理所有单元，那就自己运行它；不要将工作分散给subagents，让他们手动执行脚本就能完成的任务。
  • 当你将工作分配给subagents时，把杠杆工具写成他们都遵循的skill：将方法、验证规则和不可修改的限制整合到一个工件中，这样每个subagent都能遵循同一个严谨版本，而非每次提示都重新解释，避免出现偏差。将该文件放在subagents的编辑范围之外，防止他们悄悄修改规则。
  • 应用此原则会生成一个文件。如果你引用了该原则，但差异中没有codemod、脚本、生成器或subagent skill，说明你并未应用它。
  • 当工作持续时间超过当前会话时，提交杠杆工具，这样下次执行时可直接重新运行，而非重新构建。
平衡： 判断标准是琐碎性，而非重复性。即使是一次性任务，只要杠杆工具能让工作可检查，就值得构建。根据懒惰协议，构建完成任务或验证任务的最小脚本即可，绝不要构建框架。
这与将经验融入结构不同，后者是将重复指令转化为持久的防护措施。本原则关注的是眼前工作的吞吐量和可审查性。关于编写验证脚本本身，可参考验证工作成果。