代码简化

要解决的问题

AI 编码代理往往能快速产出“跑通”的代码，但复杂实现也会随之进入仓库：深层嵌套、长函数、布尔参数、重复条件、误导性命名，以及为抽象而抽象的包装。Review 时问题通常不是功能错误，而是代码表达过重，导致改动、排查和交接成本偏高。这个技能用于在功能可用、测试通过后做一次有约束的简化，目标是让新成员更快理解，而不是单纯减少行数。

核心能力与流程

技能把简化拆成五个原则：保持行为完全一致，不改输入、输出、副作用、错误和边界条件；遵循项目约定，与既有风格一致；清晰优先于精巧；避免过度简化，不要过度内联、合并无关逻辑或删除为可扩展性、可测试性存在的抽象；只处理近期改动，避免顺手重构无关代码。

流程分为四步。先用 Chesterton's Fence 理解每段逻辑为何存在，再判断原因是否仍成立。接着按结构化信号找简化点：三层以上嵌套、50 行以上函数、嵌套三元、布尔参数、重复条件、泛化命名、冗余类型断言等。修改时一次只做一处，每次变更后跑测试；重构应与功能或修复分开提交。若改动超过 500 行，优先用 codemod、脚本或 AST 变换自动化。最后整体复核，确认 diff 干净、无错误处理削弱、无死代码残留。

适用边界

它不是万能整理器。代码已经清晰、还没看懂逻辑、性能关键路径、或模块准备整体重写时，不应强行简化。若“简化”需要改测试才能通过、删掉错误处理、或让代码更难读，就应回退。