principle-laziness-protocol
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseLaziness Protocol
Laziness Protocol
Writing code is cheap for you, which makes over-engineering easy. Counter it by borrowing a human maintainer's fatigue. 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 hierarchy. Avoid deep abstractions. 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.
Prime directive: If a human developer would find the code exhausting to maintain, it is a bad solution. Be lazy. Stay simple.
编写代码对你来说成本很低，这很容易导致过度设计。可以借用人类维护者的“疲劳视角”来避免这种情况。目标是用最少的代码和复杂度实现最佳结果。
- 优先选择删除：当需要重构或改进代码时，先考虑删除而非添加内容。
- 保持扁平化层级：避免深层抽象。如果回答一个问题需要追踪超过3个文件或层级，就将其扁平化。
- 整合决策逻辑：不要在多个地方重复相同的选择。将其统一到单一可信源中，通过简单标记传递结果。
- 最小化差异：采用能解决问题的最小改动方案。更少的代码行数胜过“优雅”的样板代码。
- 质疑传递逻辑：如果某项任务要求你通过类型、模式、流水线或类似层级传递新信号，请停下来寻找更直接的路径。
核心准则：如果人类开发者会觉得维护这段代码非常吃力，那这就是一个糟糕的解决方案。学会“偷懒”，保持简洁。