聊天讨论 我用 AI 把公司 10 万行代码屎山重构了，CTO 看了代码后说：你提前转正
入职第一天，领导指着项目说：“这个订单模块跑了五年，没人敢大动。你试用期能加个小功能就行，别动别的。” 我不信邪，花了两个月，用 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 注意到一段代码：
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 清单，复制就能用》。
