用途：在编写新代码、提出 bugfix、审查 PR/diff，或讨论是否新增抽象层、配置层、插件系统时使用，帮助判断改动是降低还是增加复杂度。
主要能力与检查要点：
- Bugfix 质量：只加分支掩盖症状的修复是坏修复，即使“能用”；好修复应简化代码或修好根因，使该类 bug 不再复发。审查时看路径数量是减少还是增加。
- 抽象成本：新增抽象层（通用 helper、配置驱动、插件系统、“让它可配置”）的成本随未来读者与调用点呈指数增长，而非线性。默认遵循三次法则：同一具体需求独立出现至少三次再抽象；假想的未来需求不算真实需求。
- 复杂度上限由领域决定，但需双向检查：代码复杂时先质疑领域模型或需求；同时某些领域（税务、保险监管、合规逻辑）复杂度不可约，强行简化只是把复杂度移到更隐蔽处。
- 度量是信号而非判决：圈复杂度、认知复杂度可作客观参考，但只衡量机械分支难度，不衡量人类可读性，需与 affordance 测试（新同事能否快速正确理解）结合。
注意事项：不要把它当成“永远简化”的规则；三次法则是默认值而非教条；简化不等于最短代码；审查他人代码时先问可读性，用具体 diff 说话；不要用这些原则回溯论证已交付且未被质疑的设计决策。
适用场景：代码编写、bugfix 提案与评审、PR/diff 审查、抽象与配置化讨论。
限制：资料未提供安装命令、平台支持、收费与价格信息；基准测试数据来自特定场景与模型，仅供参考。