thinking-via-negativa

Via Negativa

先做减法，再做加法。优先消除危害、浪费和非必要的复杂性；只有在穷尽可移除项后，仍有明确需求时才添加。

适用场景

• 准备添加功能、抽象、依赖、流程或控制措施来解决问题时。
• 简化系统或工作流时，复杂性正是需要付出的代价。
• 通过决定不保留、不构建或不维护什么来确定优先级。
• 开展性能或可靠性工作时，消除有问题的路径胜过添加缓解措施。

不适用场景

• 承载关键职责的控制措施：身份验证、校验、测试、速率限制、重试、安全检查——在证明其已无用前，默认认为它们必不可少。
• 无法通过移除或简化来满足的明确需求。
• 没有证据表明某项内容未被使用或造成净危害，却仅出于审美追求极简。
• 影响未知且没有回滚方案的不可逆删除。

流程

1. 暂停添加的冲动。 用一行说明目标和拟添加的内容。
2. 先问减法问题。 列出可以移除或停止哪些内容，以更少的表面积实现同一目标。
3. 以证据整理候选项。 优先考虑未使用、冗余、成本高而价值低或有害的内容。要求提供使用情况、调用图、指标或实验方面的证据，而不是个人喜好。
4. 应用不可逆性防护。 将内容分类为可逆或难以恢复；识别依赖项；拒绝删除未经证实、用途不明的防护措施。规划分阶段移除，或在风险不可忽略时标明风险。
5. 先移除最安全且价值最高的候选项。 执行减法、监控并验证所需行为确实不受影响，再处理下一项。
6. 只有目标仍未达成时才添加。 如果减法无法满足需求，则添加最小改动，并记录移除措施为何不足。
7. 在通过移除达到目标时停止； 或者，当剩余候选项不符合不可逆性或证据门槛，且有充分理由进行最小添加时停止。

停止条件： 通过移除达成目标；或在有证据支持的减法未能奏效后，记录剩余需求。

输出

Goal: <desired outcome>
Proposed add (if any): <thing>
Removal candidates: <element — evidence — risk — reversible?>
Action: remove <X> | staged remove <X> | add minimal <Y> because <why removal failed>
Verification plan: <how absence/success is checked>
Do-not-touch: <load-bearing items preserved>

验证

• 如果没有未使用或有害的证据就删除了内容，或将安全控制措施作为“复杂性”移除，则判定失败。
• 如果添加内容上线前，未针对同一目标先进行减法审查，则判定失败。
• 防止过度应用：如果某项内容承担关键职责，或其必要性已有明确证明，不要仅为减少行数或追求纯粹而将其删除。