重构或评估改动大小时，用「懒惰协议」以删除和最小改动换最大结…

在重构、评估 diff 大小，或忍不住想加抽象、分层、穿透传参时，用最少的代码与复杂度拿到最大结果。

适用场景

解决思路

1. 优先删除：被要求重构或改进时，先找可以移除的东西，再考虑新增。
2. 保持扁平的调用层级：避免深层调用链；但一个隐藏了大量工作的丰富接口不算深层调用链。如果回答一个问题需要追溯超过 3 个文件或层级，就把它拍平。
3. 合并决策：不要在多个地方重复同一个选择；把它放到单一事实来源（source of truth）后面，只把结果当作一个简单标志（flag）传出去。
4. 最小化 diff：做解决问题所需的最小改动。更少的行数胜过「优雅」的样板代码。
5. 质疑传参穿透：如果任务要求你把一个新信号穿透类型、schema、pipeline 之类的层，先停下来，寻找更直接的路径。
6. 处理小的泄漏：在微小的透传（pass-through）、表示泄漏和重复选择扩散之前就移除它们。小泄漏会累积成永久的协调成本。
7. 用维护者测试验收：如果一个人类开发者会觉得这段代码维护起来令人疲惫，那它就是个糟糕的方案。

适用边界 · 注意事项

• 当丰富接口本身隐藏了大量工作时，不要为了追求扁平而拆掉它——这不属于需要扁平化的深调用链。
• 当任务目标是引入真正的新能力或对外契约时，只盯着删除和最小 diff 可能不够，需先满足功能正确性。