当前位置：首页 > news >正文

我用AI把公司10万行代码屎山重构了，CTO看了代码后说：你提前转正

news 2026/5/24 8:38:46

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