AI 代码的坏味道：7 个该停下来重写的信号

能跑和写得好，是两回事

AI 生成的代码有个特点：第一次看都挺顺眼，三个月后全是坑。因为 AI 优化的是“当下通过”，而不是“长期可维护”。下面 7 种坏味道是 AI 代码里最高发的，闻到任何一个，都值得停下来处理——越早越便宜。

1. 过度防御：try/catch 包治百病

AI 特别爱在每个函数里加 try/catch，还 catch 了之后只打个 log。结果：错误被吞掉，线上出问题时你连堆栈都找不到。处理：删掉那些“以防万一”的 catch，只在边界处（API 入口、任务队列消费端）集中处理异常。

2. 注释式道歉：代码在解释自己为什么烂

“这里用了一个 trick，暂时这样”“TODO：以后优化”——AI 写这种注释时，它其实知道这段代码有问题，但选择了糊弄过去。看到这类注释别放过：要么当时就修，要么转成真正的 issue 跟踪。注释里的 TODO 存活超过一周，基本等于永久。

3. 幽灵抽象：只被用了一次的“通用”设计

AI 喜欢提前抽象：一个只有一种实现的 Interface、一个只有一处调用的工厂函数、配置里为“未来”预留的十个字段。YAGNI（你不会需要它）在这里特别适用：删掉所有当前没有第二个用例的抽象，等真需要时再加——那时候你对需求的理解也更深。

4. 复制粘贴式变体：三个函数长得 90% 像

让 AI “再写一个类似的”，它最省事的做法是复制一份改两行。三个月后你要改逻辑，得改三个地方，还总漏一个。处理：抽成带参数的同一个函数，或者至少让 AI 自己做一次“重复度检查”。

5. 类型体操：TypeScript 里的 any 大逃亡

AI 遇到复杂类型时，第一反应是 as any、“先跑起来再说”。any 一旦进去，类型系统在这块就瞎了，后面的重构全靠肉眼。处理：把 any 当编译错误对待——每个 any 旁边必须有一行注释说明为什么暂时绕过，以及什么时候补上真正的类型。

6. 配置爆炸：env 文件比代码还长

AI 倾向于把一切做成可配置的：阈值、开关、策略全塞进环境变量。结果是部署时没人知道哪些必须设、默认值是什么。处理：区分“部署时才知道的”（密钥、URL）和“写死也行的”（重试次数、超时），后者直接写常量。

7. 测试在演戏：断言 assertTrue(true)

最危险的一种。AI 写的测试经常只测 happy path，断言写得模棱两可，甚至 mock 掉了被测对象本身——测试全绿，代码全错。处理：每个 PR 让 AI 回答三个问题——这个测试在测什么？如果把实现改错，测试会红吗？边界条件覆盖了吗？答不上来就重写测试。

一句话总结

AI 写代码的速度是你的 10 倍，制造技术债的速度也是。养成习惯：每次让 AI 交代码时，顺手扫一遍这 7 条——花 5 分钟，能省下三个月后的一个周末。