入职第一天，领导指着项目说："这个订单模块跑了五年，没人敢大动。你试用期能加个小功能就行，别动别的。" 我不信邪，花了两个月，用AI把这堆屎山一点一点铲平了。代码行数砍了40%，圈复杂度从45降到8，上线一个月零bug。CTO在技术会上说："这个模块过去是雷区，现在是示范区。" 他提前两个月让我转正，还加了薪。
前言
每个程序员职业生涯中都会遇到一座"屎山"。可能是前任留下的，可能是一群实习生堆的，也可能是三年前的自己写的（别不承认）。
我遇到的这座山，是一个老牌电商的后台订单模块。文件平均1500行，函数平均200行，缩进有的用空格有的用Tab，注释全是"// fix" "// todo" "// 别动"。最经典的一个函数叫doSomething()，里面switch-case写了12层，处理12种订单状态，每种状态里还有嵌套if-else。
我想加一个新状态，加了三天，改一处崩三处。第四天我崩溃了：这代码不是人写的，是人挖的坑。
然后我决定：用AI，把这堆屎山一点一点铲平。
一、屎山有多毒？我列了张清单
开始之前，我先给这座山做了"体检"：
| 指标 | 重构前 | 行业参考 | 严重程度 |
|---|---|---|---|
| 平均函数行数 | 187行 | <30行 | 🔴 严重 |
| 最大圈复杂度 | 45 | <10 | 🔴 严重 |
| 重复代码率 | 23% | <5% | 🟡 中等 |
| 注释覆盖率 | 3% | >20% | 🔴 严重 |
| 单元测试覆盖率 | 0% | >70% | 🔴 致命 |
没有人敢动它，因为没有人完全理解它。一个订单状态的修改，可能在12个case分支里产生蝴蝶效应。
金句：屎山的可怕不在于它烂，而在于没人敢承认它烂，更没人敢碰它。
二、我的AI重构三步法
我没有一次性推倒重来------那会死得很惨。我用AI分三步，每一步都确保功能不变，只改结构。
第一步：用AI补注释 + 生成文档
我选了一个最复杂的文件orderHandler.js（2200行），整个丢给Cursor的Composer，提示词：
分析这个文件，为每个函数生成JSDoc注释（包括参数、返回值、副作用说明），然后生成一个README，画出主要函数的调用关系图。
AI十几秒后输出：
- 每个函数前加了
@param、@returns、@throws - 识别出三个没有被任何地方调用的"僵尸函数"
- 画了一张Mermaid流程图，清晰显示了订单状态的流转路径
我拿着这张图，第一次看懂了这座山的"地图"。
第二步：用AI拆分长函数
最长的那个processOrder函数，400行。我用Cursor选中它，输入：
将这个函数按单一职责拆分成多个小函数，每个函数不超过30行。保持原有逻辑完全不变，不要改变外部接口。
AI生成了8个小函数：validateOrder、calculateDiscount、checkInventory、createPaymentRecord......每个都带清晰命名和注释。
我手动跑了回归测试，全过。这一步，函数平均行数从187降到了42。
第三步：用AI消除重复代码 + 抽象公共逻辑
AI发现三处完全一样的"价格计算"逻辑散落在不同文件里。我用重构工具提取成一个共享函数，AI帮我自动改了所有调用处。
重复代码率从23%降到了4%。
金句：AI帮你写代码不稀奇，AI帮你删代码才是真本事。
三、真实案例：一个隐藏了三年的bug被AI揪出来了
重构过程中，AI注意到一段代码：
js
if (order.status === 'paid') {
sendEmail(user);
updateInventory(product);
}但上面几行还有一个if (order.paid === true)的判断，两个条件不完全等价。AI在注释里标注：
⚠️ 可疑：
order.status和order.paid似乎表示同一件事，但有两个不同字段。建议确认是否数据不一致导致bug。
我查了历史记录，果然三年前有人加了paid字段，但老代码还在用status。偶尔因为异步更新不同步，会出现"已支付但未发货"的投诉。这个bug一直没定位到，被AI一眼看出来了。
四、重构成果：数据不会骗人
| 指标 | 重构前 | 重构后 | 变化 |
|---|---|---|---|
| 总代码行数 | 10.2w | 6.1w | ↓ 40% |
| 平均函数行数 | 187 | 32 | ↓ 83% |
| 圈复杂度（最高） | 45 | 8 | ↓ 82% |
| 重复代码率 | 23% | 4% | ↓ 83% |
| 单元测试覆盖率 | 0% | 68% | - |
| 线上故障数（月均） | 4.2 | 0.3 | ↓ 93% |
CTO看到报告，在技术会上说："这个模块过去三年是公司的'雷区'，现在变成了'示范区'。" 他提前两个月给我转了正，还额外给了项目奖金。
五、注意事项：AI重构的坑
- 一定要有测试覆盖：没有测试的重构是自杀。我先补了关键路径的集成测试，才敢让AI动手。
- 分步骤提交：不要一次性提交AI生成的大几百行改动。按函数拆、按文件拆，每个PR只改一个点。
- AI也会翻车 ：有一次AI把
i++改成了i+1，导致死循环。所以每次AI生成后，必须人工review核心逻辑。 - 业务敏感代码不要全信AI：涉及金额、库存、权限的判断，手动写测试断言，再跑一遍。
六、写在最后
重构屎山不是技术活，是心理活。AI给了我们一把铲子，但挖哪里、怎么挖、挖多深，还是人决定。
如果你也接手过屎山，或者正在屎山里挣扎，点个赞让我看到不是一个人。赞多的话，我下一篇写《AI重构屎山的完整Prompt清单，复制就能用》。