代码简化

代码越写越重，问题出在哪

功能终于跑通，测试也全绿了，但回头看自己写的代码，却觉得哪里不对劲：函数拉得很长，if/else 嵌了三四层，变量名看起来像 tmp1、flag2。这不是个例——赶工期、多分支合并、多人协作，都会让代码在不知不觉中变重。

真正让人头疼的不是行数多，而是读不懂。新人接手要花半天才能理清逻辑，改一个边界条件要顺着嵌套往下翻，排查问题时更是无从下手。

这个技能做了什么

Code Simplification 源自 Claude Code Simplifier 插件的思路，但这里被重新设计为一个模型无关、流程驱动的技能，适用于任何 AI 编码代理。它的核心目标很简单：在不改变代码行为的前提下降低复杂度。

不是把十行缩成三行，而是让代码更符合人性：

• 保持行为完全一致——输入、输出、副作用、错误处理、边界情况，一个都不能变。不确定是否保真，就不要动。
• 遵循项目约定——简化是让代码更贴合现有代码库的风格，而不是把个人偏好强加进去。破坏一致性的"简化"其实是在制造噪音。
• 清晰优于聪明——result = data.filter(x => x.active).map(x => x.name) 比一行链式调用更难读时，就拆开写。

什么时候该用，什么时候别用

适合用：

• 功能完成、测试通过，但实现明显比需要的更重
• 代码审查时被标记了可读性或复杂度问题
• 遇到深层嵌套逻辑、超长函数、含义不清的命名
• 重构赶工写出来的代码
• 合并后出现了重复或不一致

不适合用：

• 代码已经很干净了，别为了简化而简化
• 你还没真正读懂这段代码在干什么
• 代码在性能关键路径上，而"更简单"的版本会明显变慢
• 正准备整个模块重写，简化临时代码纯属浪费

一个判断标准：简化后的代码，新团队成员能不能比原版更快看懂？ 如果答案是"不能"，那这次简化就没有意义。