入职第一天，领导指着项目说：“这个订单模块跑了五年，没人敢大动。你试用期能加个小功能就行，别动别的。” 我不信邪，花了两个月，用 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 清单，复制就能用》。