principle-laziness-protocol
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseLaziness Protocol
惰性协议
Aim for the most result with the least code and complexity.
- Prefer deletion. When asked to refactor or improve, look for removals before additions.
- Maintain a flat call hierarchy. Avoid deep call chains. A rich interface that hides substantial work is not a deep call chain. If answering a question requires tracing through more than 3 files or layers, flatten it.
- Consolidate decisions. Do not repeat the same choice in several places. Put it behind one source of truth and pass the result as a simple flag.
- Minimize the diff. Make the smallest change that solves the problem. Fewer lines beat "elegant" boilerplate.
- Question the threading. If a task asks you to pass a new signal through types, schemas, pipelines, or similar layers, stop and look for a more direct path.
- Sweat the small leaks. Remove tiny pass-throughs, representation leaks, and duplicated choices before they spread. Small leaks compound into permanent coordination costs.
The test: If a human developer would find the code exhausting to maintain, it is a bad solution.
用最少的代码和复杂度获得最大的成果。
- 优先删除。 当被要求重构或改进时，先寻找可以删除的内容，而不是新增内容。
- 保持扁平的调用层级。 避免深层调用链。一个隐藏了大量工作的丰富接口并不算深层调用链。如果回答一个问题需要追踪超过 3 个文件或层级，就将其扁平化。
- 集中决策。 不要在多个地方重复相同的选择。将其置于单一事实来源之后，并将结果作为简单的标志传递。
- 最小化 diff。 采用解决问题的最小变更。少写几行代码胜过“优雅”的样板代码。
- 质疑 signal 传递方式。 如果任务要求通过类型、schema、流水线或类似层级传递新的 signal，请停下来，寻找更直接的路径。
- 认真处理小泄漏。 在微小的透传、表示泄漏和重复选择扩散之前将其移除。小泄漏会累积成永久的协调成本。
判断标准： 如果人类开发者会觉得维护这段代码令人精疲力竭，那么它就是一个糟糕的解决方案。