代码减法助手

问题：代码库为什么越来越复杂

真实项目中，复杂度往往不是一行代码写错，而是大量代码“看起来有用，但实际上没人用”。常见来源包括：

• 无当前价值的抽象：单实现接口、只生产一种对象的工厂、只为测试暴露的生产接口
• 重复路径：同一逻辑的多份副本，或仅有转发、改名的胶水层
• 预留配置：无人改变的配置键、永不到达的分支、未启用的平台选项
• 过早优化：无调用者的缓存、未使用的依赖、重复的数据模型

当这些问题叠加，仓库会逐渐变成“改不动”的状态。

工作方式：审计优先的减法流程

代码减法助手默认采用“先审计，后修改”的模式，不把删行数当作唯一目标。

核心步骤

1. 固定真实需求：用一句话写出当前必须实现的用户结果，明确不做的事项
2. 建立行为基线：运行测试、构建、静态检查，记录命令和结果
3. 画最短调用路径：从外部入口走到核心结果，标出每层的输入、输出、副作用和权限边界
4. 识别复杂度来源：逐项检查无调用代码、重复实现、单一实现抽象、无人改变的配置等
5. 建立变更价值账本：每项记录当前用途、消费者、删除收益、行为风险、验证成本和回滚难度
6. 设计最小补丁：一次只改变一个复杂度来源，优先内联合并、删除无用选项或收窄接口
7. 分层验证：先跑针对性测试，再跑模块测试、全量测试、构建和关键冒烟

输出规范

默认输出包含需求与不可变行为、审查范围和基线状态、最短调用路径、变更价值账本、候选项分级与证据、推荐的最小补丁顺序、验证矩阵与结果，以及净影响、回滚点和延后项。

候选状态使用 KEEP、MERGE、REMOVE、DEFER 或 UNKNOWN。每个 REMOVE 必须同时给出消费者检查、替代方案、验证方法和回滚方式。

边界：什么情况不适用

• 不把代码少、文件少或依赖少视为唯一优化目标
• 不删除未核对动态加载、反射、插件和外部消费者的代码
• 不把正确性、安全漏洞或性能故障伪装成简化建议
• 不在无测试或无可观察验证时宣称行为等价
• 不擅自移除公共 API、数据库字段、配置键或兼容路径

如果仓库本身没有可运行的基线测试，或涉及高度动态的运行时发现机制，建议先补齐验证手段，再启动减法流程。