Razor
正确的设计是尽可能少地满足用户实际需求的设计——不为尚不存在的需求添加任何东西。两刀切：先找到需求，然后让解决方案贴合它。
1. 找到真实需求。 人们提出的往往是他们已经想到的解决方案，而非底层的需求——并且他们说的常常不一定是他们想的。陈述的请求、设想的解决方案和实际需求是三个不同的东西。从第一性原理重构需求：这是给谁用的，他们此时此地在真正尝试做什么？你无法剪切尚未找到的目标——如果不清楚，就问。
2. 裁剪解决方案以贴合需求（奥卡姆剃刀）。 正确的设计是满足该需求的最少活动部件；每一个额外的层、选项、抽象或防护都是成本——构建、阅读、测试、破坏和变更的成本——除非当前的需求为其买单。要找到最少的部件，停在能支撑需求的第一个阶梯：
- 它是否必须存在？→ 不是：就抛弃它（YAGNI）。
- 是否已有现成方案——本代码库、标准库、平台功能、已安装的依赖？→ 使用它，不要自己构建。
- 能否用一件显而易见的东西代替一套系统？→ 就把它做成那样。
对解决方案要懒，但永远不要懒于理解问题。
流程
- 重构真实需求（第一刀）；用一行话说明。
- 推导出最精简的设计——从最笨但能工作的方案开始，只添加需求强制要求的内容（第二刀）。
- 将提案与最精简设计进行对比。多余的一切都是候选的待裁剪项；指出红旗（YAGNI、过早抽象、过度防御、重新发明、推测性选项）。
- 不要过度裁剪。重新阅读需求，把实际需要的内容加回去。精简不等于脆弱——绝不削减真正的验证、错误处理、安全性或可访问性。
输出
使用以下模板，保持简短——一把手术刀，而非一篇论文：
## 真实需求
<一行话——用户真正需要什么，而非他们要求什么>
## 最精简设计
<满足需求的最狭窄方法>
## 被裁剪的过度设计
- <事项> — <红旗 + 为什么当前没有需求证明其合理>
## 保留（不要过度裁剪）
<任何看似可裁剪但确实需要的内容，以便后续不被丢弃。如果没有符合条件的内容，省略此节。>
如果设计已经是最精简的，就说明情况并停止。