代码精简重构

要解决什么问题

功能已经跑通、测试也绿，但实现比问题本身「重」：三层以上的 if 嵌套、五十行以上的单函数、到处出现的 data/result、合并分支后重复的五行逻辑。评审里常被标可读性或复杂度，可你并不想顺手改行为或埋新 bug。

本技能把目标钉在易懂而不是行数：新同事读简化版是否比读原版更快理解？若答案是否定的，就不算合格的精简。

如何工作

执行时遵循五原则：精确保行为（同输入同输出、同副作用与错误路径）；对齐项目约定（CLAUDE.md、邻近代码风格）；清晰优先于巧妙；避免过度内联或拆掉有意义的抽象；默认只动近期改动，不扩大 diff 噪声。

流程分四步：先懂再动（职责、调用链、测试与 git blame）；按具体信号识别机会（守卫子句、拆长函数、改命名、去死代码与重复块）；一次一条简化并跑测试，重构与功能修复分开提交；最后用可读性、一致性、可审 diff 做验证。

产出为自然语言说明 + SimplifyReport 工件（变更文件、每条 pattern/before/after、是否行为保持、移除的死代码），便于下游评审与单独提交重构。

适用边界

不适用：代码已干净；还没读懂（先懂再改）；性能关键且「更简」会明显变慢；即将整体重写。不确定行为是否一致时不要改——这是硬约束，不是风格建议。