当代码或架构可能过度设计时…

对代码库、架构、PR 或技术方案做一次「虚荣工程」诊断，识别为满足开发者自尊、简历或智力乐趣而非用户/业务价值而构建的复杂度，并给出简化与止损方案。

适用场景

解决思路

1. 先建立需求锚点：在查看任何代码前，明确系统真正需要做什么，回答五个问题——谁在使用（终端用户/内部团队/API 消费者/尚无人用）、必须做什么（核心用户故事或 jobs-to-be-done，最多 5 条）、实际运行规模（不是预测规模）、真实约束（合规、延迟 SLA、集成要求）、维护团队规模（单人/3 人初创/50 人组织）；若用户答不上来，这本身就是虚荣信号。
2. 阅读 references/detection-patterns.md，对照其中的检测模式扫描代码库或架构。
3. 对每个发现按虚荣严重度打分：V0 装饰性（无害，记录后略过）、V1 拖累（增加认知或维护成本但无用户价值，标记待简化）、V2 结构性（架构围绕虚荣而非需求，标记待重新设计）、V3 复利性（迫使其他代码变得更复杂，标记为紧急，会扩散）。
4. 产出结构化评估：Summary（一段话说明代码实际做什么 vs 被工程化成做什么，两者差距即虚荣面积）、Requirement-to-Complexity Ratio（RCR，1-10 分，1 为最小可行方案，10 为伪装成 CRUD 应用的博士论文，多数生产系统应在 2-4）、Top Findings（最多 7 条，每条含 What 具体模式、Where 文件/模块/组件、Severity V0-V3、Why it is vanity 如何未通过「用户需要吗」测试、What it should be instead 更简单的替代方案、Kill cost 移除或简化所需工时/天数）、Vanity Debt Estimate（虚荣模式而非真实需求导致的每月维护人时）、The Hard Question（一个直接且令人不适、团队必须诚实回答的问题）。
5. 为每个被审查的系统或功能生成 kill criteria 框架（最重要的交付物，防止虚荣工程复发）：先读 references/kill-criteria-template.md 的完整模板，再生成项目专属版本。
6. 设置 Tier 1 硬性终止条件（自动、不可协商、无需人工批准，满足即终止）：如组件导致安全泄露、导致 P1 及以上生产事故、成本连续 3 天超预算上限、30 天零使用（无 API 调用、无页面浏览）、唯一维护者离开且 2 周内无人接手。
7. 设置 Tier 2 审查触发条件（自动标记、人工决策、默认倾向终止，举证责任在「继续」一方）：如成功指标连续 14 天低于阈值、维护成本超过交付价值（每月工程人时 vs 用户影响）、连续 3 个 sprint 出现计划外工作、引入的依赖出现 CVSS >= 7.0 的 CVE、引入后团队速度可测量地下降。
8. 设置 Tier 3 软性继续条件（必须主动赢得继续资格，未在期限内达成则默认终止）：以 30 天评估窗口为例——主要成功指标连续 7 天达标、P95 延迟连续 7 天满足 SLA、零安全事件、运营成本连续 7 天低于预算上限、至少 2 名团队成员能独立修改并部署、存在文档且由非作者验证过。
9. 用七种反虚荣诊断透镜检查：删除测试（删掉它谁会注意到、何时注意到，若答案是「没人」或「只有作者」即虚荣）、替换测试（能否用更简单的东西完成 90% 的工作，剩余 10% 必须证明额外复杂度合理，但很少能证明）、新人测试（新加入的合格工程师能否在一小时内理解，否则抽象服务的是作者的心智模型而非团队）、规模测试（复杂度是由当前规模还是想象中的未来规模证明的）、简历测试（从技术栈移除它是否会让项目在面试中变得无趣，若是，这很可能就是它存在的原因）、依赖测试（每个依赖都是负债，节省 200 行却增加 50KB 包体积和升级负担的库不划算）、抽象测试（一个接口背后只有一个实现不是抽象而是间接层，两个可疑，三个才开始划算）。
10. 若 negentropy-lens 技能可用，交叉引用发现：虚荣模式按定义是熵增的（复杂度增加而无能力提升）；negentropy-lens 的「隐性知识缺口」常揭示虚荣（只有作者理解即复杂度服务于作者而非系统）；应用 negentropy 的「复利价值」测试（该工程决策让相邻决策更容易还是更难）。
11. 输出时保持直接、具体：点名模式、展示证据、提出更简单的替代方案；不要为保护自尊而软化发现，但区分虚荣与学习——初级开发者过度抽象是在学习抽象，高级开发者过度抽象是在放纵；以「这个复杂度未被当前需求证明，以下是合理的做法」为框架，目标是更好的系统而非被羞辱的工程师。

适用边界 · 注意事项

• 当团队确实处于早期学习阶段、正在通过实践掌握抽象或新技术时，不应按虚荣工程严厉评判，需区分学习与放纵。
• 当复杂度由真实且明确的约束（合规、延迟 SLA、集成要求）或当前实际规模所证明时，不适用。
• 当用户尚未提供任何代码、架构或技术方案，无法建立需求锚点与检测扫描时，无法执行本审查。