当 AI 替我写代码,谁来替我背锅?
- 作者:Bougie
- 创建于:2026-06-14

昨天看到一个数字,愣了半天:Stack Overflow 2026 年的调研说 84% 的开发者已经在用 AI 写代码了,但真正信任 AI 生成结果的只有 3%。
84% 用,3% 信。
这比例让我想起我妈。她每天刷手机看短视频,但你跟她说网上说的她一律不信。她属于那 97% 的人——手在用,脑子不认。
我们正在集体干一件特别拧巴的事:一边把 AI 当拐棍杵着走路,一边死攥着缰绳不撒手。
# 那个「回不去了」实验
METR 做过一个有意思的实验。他们找了一批资深开发者,让他们不用 AI 写两周代码。这些人集体拒绝了,理由是「已经回不去了」。
但是——让他们自己评估生产力,人人说翻倍了。实际测评一看,没翻倍。
这个 gap 我琢磨了好几天。
我自己也有这感觉。去年开始重度用 AI 辅助编程,写代码的时候感觉巨顺,一个功能半小时搞定,一天能干以前三天的活。但回头复盘月度产出,好像也没多到哪去。
那种「效率飞升」的幻觉是从哪来的?我觉得是因为 AI 帮我省掉了最烦的部分——查文档、试错、被简单语法问题卡住。那些挫败感消失了,记忆里留下的全是「我真行」的时刻。但真正花时间的活——设计架构、调试边界条件、跟产品经理扯皮——AI 并没帮我省多少。
METR 那帮人测的是实际产出,不是主观爽感。结论就是:AI 让你爽了,但没让你快。
这大概就是 tokenmaxxing 的温床吧。
# tokenmaxxing 是个病
「tokenmaxxing」这个词我第一次看到以为是钓鱼的,后来发现还真有人正经在聊。就是把消耗的 token 数量当成生产力指标,像极了当年互联网公司把 DAU 当命根子。
你一天烧多少 token?多就是牛。
这种逻辑的危害在于,它把手段和目的彻底搞反了。代码写出来是要跑在服务器上给用户用的,不是往某个对话框里填字的。token 消耗量只能说明你跟 AI 聊得欢,不能说明你在产出有用的东西。
更讽刺的是,这跟 KPI 治下的形式主义是一回事。以前是日报周报写满就是好员工,现在是 token 打满就是高产能。换了层皮,骨子里的东西没变。
我见过团队开始考核「AI 使用率」,要求每个人每天必须有多少比例的代码是由 AI 生成的。这不是荒唐吗?就像要求你每天必须用锤子钉多少钉子,至于钉子钉哪、钉没钉歪、钉完墙倒不倒,不管。

# 那些阴险的 bug
让我真正睡不着觉的,不是 AI 写代码慢或者啰嗦,而是它写的 bug 太难抓。
有个数据说 AI 生成代码的缺陷密度是人工代码的 1.8 倍。1.8 倍听起来好像还好?但魔鬼在细节:这些 bug 特别阴险——本地跑、单元测试都过,只在生产环境的边界条件、并发、长跑之后才炸。
你知道这意味着什么吗?
意味着 code review 看不出来。自动化测试看不出来。甚至你自己手动测也测不出来。你得真的把它扔到生产环境里,让它跑足够长的时间,遇到足够刁钻的输入,才可能触发。
而一旦触发,就是线上事故。
我上个月刚踩过一个类似的坑。AI 帮我写了个缓存逻辑,本地测试完美,压测也没问题。结果跑了三天之后,内存开始缓慢泄漏。一查,是 AI 在处理并发清理的时候有个 race condition,低并发根本测不出来。
我花了整整两天定位,最后把那段代码全删了,自己重写了一遍。
这种事会越来越多。随着 AI 生成代码的比例上升,这种「看起来没问题,跑起来炸」的 bug 会成为分布式系统的家常便饭。
# 老人们不敢信,新人瞎信
还有个数据有意思:10 年以上经验的开发者里,只有 2.5% 高度信任 AI;反而新手更敢信。
我猜原因是这样的:老家伙们踩过的坑太多了,知道代码里埋了多少雷,所以对任何「自动生成的」东西都有本能的警惕。而新手没挨过打,觉得 AI 写的代码跟我写的代码都是代码,能用就行。
但讽刺的是,真正能识别出 AI 代码里那 1.8 倍缺陷密度的,恰恰是老人。新手敢信,但新手也看不出来问题。
这就形成了一个怪圈:最谨慎的人不敢信 AI,但最需要被 AI 辅助的新人反而最敢信 AI。结果就是,代码质量最差的那帮人,最可能大面积使用 AI 而不自知。

# 那个能拍板的人
我最近越来越觉得,「谁能拍板说这段代码可以上线」这件事,正在变得极其值钱。
不是那种形式上的「code owner」,是真正能看一段代码,判断它能不能扛住生产环境的压力,知道它哪里可能炸,出事了能第一时间定位到根因的人。
这种能力以前也有,但不太被当回事。大家觉得代码能跑就行,出问题再修呗。但 AI 加入之后,事情变了:代码能跑不等于代码能跑好,能跑好不等于能跑稳,能跑稳不等于出了问题你能修。
你自己生成的代码,你都看不懂,你怎么敢上线?
我现在的状态是:用 AI 写代码的时候,脑子里始终有根弦绷着。「这段它是怎么想的」「如果这个参数是 nil 会怎样」「如果有并发请求进来这个锁够不够」。以前这些是我自己脑子里的东西,现在 AI 替我写了,我得重新过一遍,甚至比自己写还累。
但累归累,该过的还得过。因为最后签这个字的人,还是我。

# 没人写的代码,没人负责
回到那个调研数字:42% 的企业代码已经来自 AI,但 96% 的开发者不肯给它签字背书。
96%。
这比例已经不是在说「不信任」了,这是在说「谁来负责这件事」根本没有答案。
代码是人写的,出了问题人背锅,这是过去五十年软件行业的基本逻辑。Git blame、code review、责任链、晋升答辩,都是建立在这个逻辑上的。
但 AI 写的代码,它没有作者。它不归任何人所有。出问题了,你 blame 谁?blame AI?AI 又不能开除。
我知道现在有些公司在搞「AI 签名」,要求标注哪段是 AI 写的,谁 review 的,谁 approve 的。说实话我觉得这是把简单问题复杂化。因为本质上不是「标注」的问题,是「能力」的问题——你得先能看懂这段代码,你才有资格说它行不行。
一个看不懂代码的人,review 完了跟没 review 一样。
# 尾巴
写到这里我发现我没有结论。
我的感觉是:AI 写代码这件事,正在把整个行业拖进一个巨大的责任真空。我们都在用,但没人愿意负责。我们都变快了,但没人敢说真的变好了。我们都在吹 tokenmaxxing,但没人在乎代码最后能不能跑稳。
最后谁承担这个后果?
用户。
线上炸了,用户第一个感知到。代码回滚、用户补偿、舆论危机,最后还是要有人出面收拾残局。而那个「出面收拾残局」的人,就是我在上文说的那种「能拍板」的人。
这种人会越来越贵。不是因为他们写代码快,而是因为他们能兜底。
但这种人有多少?
我不知道。我只知道我身边,10 年经验以上还愿意死磕代码质量的人,越来越少。大家都在忙着追新框架、学新工具、刷 token 消耗量,没人在乎代码里那个可能在第 72 小时才触发的 race condition。
也许这就是这个行业现在的样子。也许再过几年会好起来。也许不会。
我不知道。
先写到这吧。