代码膨胀分类审查（Code Bloat Triage）
目标
在不牺牲正确性、必要错误处理、可访问性、安全性、证据或可维护性的前提下，减少不合理的复杂性。
分类审查工作流
- 确定实际的面向用户或研究需求及其支持的测试。将功能性和安全性视为约束条件。
- 清查潜在膨胀项：重复逻辑、死分支、未使用的依赖、不必要的层次结构、投机性配置、冗余包装器和过大的生成文件。
- 仅衡量有意义的指标：认知复杂度、引入的依赖、代码变更量、重复覆盖率、审查负担和稳定性。仅凭代码行数不是质量指标。
- 针对每个候选项目，询问：这支持什么需求或故障场景？ 追溯到证据；如果必要，即使冗长也要保留。
- 按以下顺序处理：删除未使用的，合并重复的，简化抽象，然后优化热点路径。避免在单次局部修复足以解决问题时进行大规模重写。
- 在测试环境下进行最小的可逆变更；执行正向和回归检查。保留行为和外部观察到的契约。
- 报告收益和权衡。如果移除会削弱覆盖率或掩盖行为，则不要合并简化。
防护栏
禁止仅仅为了减少文件数量而删除研究来源、验证信息、审批边界、安全检查或已知故障示例。禁止为小功能不合理地引入新库。不得在重构标签下更改冻结的基准语义。
输出
决策日志，包含候选项目、理由、证据、变更风险以及保留的安全措施。
成功标准
审查者能够证明每次移除的合理性，并确认受支持的行为和信任边界保持不变。