AI 写出来一堆重复代码，删之前先看这里

2026-09-11 AI编程,重复代码,代码重构

打开那个接口文件的时候，我数了一下：同一个「校验手机号」的逻辑，被写了三遍。三处实现长得几乎一样，但有一处多判断了一个前缀。AI 写出来一堆重复代码这件事很常见，难点从来不是删，是删哪一份。

AI 写出来一堆重复代码，最贵的一课是删错一份

我那次先删了「看起来最像冗余」的那一份。

结果那正是唯一做了前缀判断的地方。

问题在第二天才暴露：有用户提交了带前缀的号码，系统本该拦住，结果放了过去。

删代码的成本从来不在删这个动作，在你没看清三份之间的差别。

坑一：看着一样就当成一样

AI 生成重复代码的原因很直接：它每次只看你给的那部分上下文。

第二次生成的时候，它不记得第一次写过什么。

所以三份实现的差异，往往就是三次对话里需求表述的差异。

怎么避：把几份实现并排放在一起逐行比。不要看结构，看条件判断和默认值——差异几乎都藏在这两处。

坑二：先删后测

先删掉，再跑一遍，看着没问题就提交了。

问题在于，你跑的那一遍未必覆盖到被删分支。

怎么避：顺序倒过来。先给每份实现各写一个用例，确认都能跑到；删掉之后，用例必须全绿。用例先写，删除后写。

坑三：删重复的时候顺手重构

重复代码看着乱，很容易手一滑把命名、结构一起改了。

改动混在一起，出了事你分不清是删除导致的还是重构导致的。

怎么避：一次只做一件事。这一轮只做合并，命名和结构调整放到下一轮单独提交。

止损清单

发现删错了，按这个顺序处理：

1. 立刻回滚到删除前的状态，别在错误基础上补。

2. 把几份原始实现找出来，逐行比差异。

3. 补上删除前的用例，确认能覆盖被删的分支。

4. 重新合并，提交信息里写清「保留了哪一份的哪一个判断」。

5. 把这次的差异点记到项目笔记里，下次合并前先看。

回滚永远比在上面打补丁快。

合并时我用的判断口径

三句话，按这个顺序问：

哪一份被实际调用得最多？保留它，改动面最小。
差异的那个分支，业务上还需不需要？需要就保留，不需要就删。
合并之后，谁来验收？没人验收的就别合。

合并的目标是行为不变，不是代码变好看。 这一点想清楚，很多纠结就没了。

常见问题

Q：AI 写出来一堆重复代码，怎么判断该保留哪一份？

A：先逐行比对条件判断和默认值，找出真正的差异分支，再按调用量最小的改动面保留。不要凭「哪份看着规范」决定。

Q：删重复代码前必须先做什么？

A：先给每份实现各写一个能跑到的用例，删除后用例必须全部通过。顺序是先写用例再删。

Q：合并重复代码可以顺手重构吗？

A：不建议。删除和重构混在一次提交里，出问题时分不清原因，回滚也会连带丢掉落重构成果。