“跑通的那一刻是最幸福的。之后的每一天都是恐惧。”

三个月前，组里来了个新同事，小林。

小林干活极快。一个需求，别人要两天，他半天搞定。用的什么？Cursor + Claude，全程 AI 生成。

代码跑通了。测试过了。PR 合并了。

然后噩梦开始了。

第一个来改这段代码的人，看了十分钟后问我：”这谁写的？”

“小林。”

“小林写的？小林不会写这种代码。”

我翻了一下 git blame。每一行的作者都是小林，但提交注释全是”AI-generated”。

800 行代码，没有一个注释。变量名叫 result1、data2、temp3。一个函数里有七层嵌套。异常处理全是 except: pass。

最恐怖的是——它能跑。

测试全绿，线上零报错。

但它就像一座用纸牌搭的城堡。你知道它现在站着，但你不知道碰哪一张牌它会塌。

烦死了。每次 code review 看到这种代码，我都想把小林的键盘摔了。

The New Stack 2025 年有一份报告，里面的数据颇为扎心：

67% 的开发者在调试 AI 生成的代码上，花费的时间比以前更多了。

68% 的开发者在解决 AI 代码的安全问题上，花的时间也更多了。

你想想这个画面。公司买 AI 编程工具的初衷是”提效”。结果开发者把省下来的编码时间，全花在了理解 AI 到底写了什么上。

这不叫提效。这叫转移。 把编码的时间转移到了调试上。总工时没变，甚至更多了。

Hacker News 上有人总结得更直白：

“如果 AI 工具让团队快 76%，但多出 100% 的 bug，你其实并没有提高生产力，你只是在转移技术债务。”

技术债务不会消失。它只会延期，并且附带利息。

我用了三个月观察团队里的 AI 代码，总结出了”赛博屎山”的三个典型特征。对号入座，看看你的项目有没有。

特征一：函数像俄罗斯套娃

AI 写代码有个习惯——它不喜欢拆函数。

你让它写一个”用户注册”功能。它不会拆成”参数校验”“密码加密”“写入数据库”“发送验证邮件”四个函数。它会写一个 200 行的 register_user()，里面套着七层 if-else。

为什么？因为 AI 的上下文窗口是有限的。它在生成代码的时候，倾向于在一个连续的上下文中完成所有逻辑，而不是拆成多个独立的函数去分别处理。

拆函数需要”设计思维”——思考职责边界、思考复用性、思考未来的扩展。这些恰恰是 AI 最弱的地方。

AI 写的是”能运行的代码”，不是”好维护的代码”。

特征二：异常处理全面摆烂

AI 代码里的异常处理，大抵只有三种模式：

# 模式一：假装没发生
try:
    do_something()
except:
    pass

# 模式二：打个日志就算完
try:
    do_something()
except Exception as e:
    logger.info(e)

# 模式三：抛给调用方
try:
    do_something()
except:
    raise

没有重试逻辑。没有降级策略。没有具体的异常类型捕获。没有错误码规范。

你问 AI”加上完善的异常处理”，它会给你加。但它加的还是这三种模式的变体。

因为它不知道你的业务里，哪些异常是可恢复的，哪些是致命的。 这个判断只有人能做。

特征三：魔法数字和硬编码满天飞

AI 代码里到处都是 if status == 3、if role_id == 7、timeout = 30。

这些数字是什么意思？不知道。为什么是 3 不是 4？不知道。为什么要 30 秒而不是 60 秒？不知道。

AI 不知道你的业务常量应该叫什么名字。 它只知道”这里需要一个数字”，然后从训练数据里随便挑了一个看起来合理的。

三个月后，当产品经理说”把超时时间从 30 秒改成 60 秒”，你面对的不是一个配置项的修改，而是全文搜索 30，然后一个个判断哪个 30 是超时时间。

这便是 AI 代码的隐蔽成本。

AI 生成的代码，不能跳过 Code Review 直接合并。

很多团队用了 AI 之后，PR 数量暴增，review 质量暴跌。一天合并 20 个 PR，每个 PR 看 30 秒就 approve。

这不叫 review。这叫签字。

每天签 20 个字。累死了。

review AI 代码时，重点看三件事：

  • 函数拆分：超过 50 行的函数，要求拆
  • 异常处理：except: pass 零容忍
  • 魔法数字：所有硬编码数字必须提取为常量

不要让 AI 自由发挥。给它约束：

  • “每个函数不超过 30 行”
  • “必须写 docstring”
  • “异常处理必须指定具体异常类型”
  • “禁止 except: pass”

这些约束听起来像是基本要求。但你如果不说，AI 就真的不做。

AI 不会主动遵循你公司的编码规范。 你得把规范喂给它。

说错了——不是”喂”就行。应该说，是每次生成都要塞给它。AI 没有记忆。你以为上次告诉过它了，这次它又忘了。

这种感觉很恶心。就像你教了一个实习生三遍，他第四遍还犯同样的错。

每个月抽一天，让团队一起 review 最近的 AI 生成代码。不是为了追责，是为了还债。

把那些嵌套太深的函数拆了。把那些 pass 掉的异常处理补了。把那些魔法数字提出来。

技术债就像信用卡账单。你可以这个月不还，但下个月的利息会让你更疼。

——虽然我这么说，但我自己上个月也没还。有一堆 AI 生成的代码就放在那儿，每次经过都想假装看不见。人就是这样，知道该做的事和实际做的事之间，永远有一道缝。

AI 写的代码跑通了。

这不可怕。

——不对，应该说，跑通这件事本身不可怕。可怕的是接下来的每一天。

代码跑通只是最低标准。可维护、可理解、可扩展——这些才是软件工程真正在意的东西。而 AI 在这些维度上的表现，大抵还停留在”能跑就行”的阶段。

——等等，这样说也不完全公平。我上个月用 AI 写一个 CLI 工具，代码质量确实比我手写的干净。但这恰恰说明问题：AI 在简单场景下表现很好，让你误以为它在复杂场景下也行。这种错觉才是最危险的。

工具没毛病。有毛病的是你降低了标准。

这，便是赛博屎山的由来。

关于码孖AI

码孖AI，专注 AI 工程化落地。我们相信：AI 不是来替代程序员的，是来帮程序员省时间的——前提是，你得会用。

关注我，持续更新实战踩坑指南。

:::callout tip 觉得有用？ 点个「在看」，分享给同样在 AI 落地路上挣扎的朋友。 :::