Appearance
Code Simplification 解决的是 AI 把代码写得过度复杂的问题。它不是追求更少行数，而是在行为不变的前提下减少嵌套、命名不清、重复逻辑和没必要的抽象。
AI 写复杂了怎么收回来：Code Simplification 怎么用
下载 code-simplification 中文版 Skill ZIP
一个保存按钮，AI 写出了 manager、adapter 和 strategy。
为了一个简单按钮，它可能写 hooks、manager、adapter、config、fallback、strategy。
代码能跑，但你一看就知道：太重了。
code-simplification 这个技能的目标是把复杂度收回来。不是把代码压短，而是让后面的人更容易理解。
简化前先确认行为
能跑的代码，不要急着改。
简化前要先知道它现在做什么：输入是什么，输出是什么，副作用是什么，错误路径是什么，谁在调用它。
如果你还没理解代码，就让 AI 删除分支、合并函数，很容易把隐藏约束删掉。
给 AI 的要求可以写成：
md
先解释这段代码的职责、调用方、边界条件和测试覆盖。
在确认行为前，不要开始简化。简化不是减少行数
有些短代码更难读。
嵌套三层的三元表达式、复杂的 reduce、过度链式调用，看起来短，但读起来累。
好的简化通常是：
- 用早返回减少嵌套。
- 把复杂条件命名成函数。
- 删除没有价值的包装层。
- 合并重复逻辑。
- 改清楚命名。
- 去掉解释“代码在做什么”的注释。
如果更短但更绕，那不是简化。
只简化当前范围
AI 一旦开始重构，很容易一路扫全项目。
这很危险。
简化应该优先限定在刚改过的代码，或者 review 明确指出的问题。不要顺手整理无关模块，不要因为“看着不舒服”就动旧代码。
你可以这样限制：
md
只简化这次 diff 里新增或修改的代码。
不要重构无关文件。
每个改动都要保持行为不变。常见的 AI 复杂度
AI 生成代码里，常见复杂度有这些：
- 为一个分支写一套策略模式。
- 单次使用的 helper 抽到单独文件。
- 为不会发生的错误写 fallback。
- 参数对象层层传递，实际只有一个调用方。
- 命名很泛：data、result、item、handler。
- 注释解释一眼就能看懂的代码。
这些都可以收回来。
简化后要验证
简化是重构，不应该改变行为。
所以验证很关键：
- 原有测试必须通过。
- 如果没有测试，至少走一遍关键路径。
- 如果是纯函数，补几个输入输出用例。
- 如果删了分支，要确认分支真的没有必要。
不要让 AI 用“逻辑等价”来替代验证。
你可能还需要
同类技能：
当 AI 写出一堆“以后可能有用”的东西时，先问一句：现在真的需要吗？