AI 写的代码，你敢签你的名字吗？
AI 写的代码，你敢签你的名字吗？
上周有人在我一个工具的 GitHub 上开了个 issue。
说某个导出功能在数据量大的时候会卡死，怀疑是没做流式处理。我去翻代码，找到了那段逻辑——三个月前让 Claude Code 写的，当时测试跑过了，我扫了一遍 diff 就合并了。
现在盯着这段代码，我说不清它为什么把整个数据集先加载到内存里再写文件，而不是边读边写。我甚至想不起来当时让 AI 写这段的时候，自己有没有提过”流式处理”这个选项。commit 上是我的名字，但如果你问我”为什么选了这个方案”，我答不上来。
那个提 issue 的人还在等我回复。我对着自己名下的代码，给不出一个”为什么”。
所有问题，同一张脸
后来我回头复盘这段代码，发现了一个更深的问题：不是 AI 写得潦草，恰恰相反，它写得太”好”了。
格式整齐，命名规范，注释到位，该有的分支处理都有。看上去不像是偷懒的产物，也不像在某个地方犹豫过。它就是自信地选了一个在当前测试条件下能跑通的方案，然后交差了。
这就是 AI 最让人后背发凉的特点：它对待每一个问题的态度是一样的——自信。
你让它用 Python 写一个 HTTP 服务器，它给你一个好答案。你让它设计一个高并发场景下的锁方案，它也给你一个看起来一样好的答案。两个答案的语气、格式、完整度几乎一模一样。
真假混在一起，外表一模一样。
后来跟几个做后端的朋友聊起这件事，反应出奇一致：“我也有过。“有人让 AI 写认证中间件，用了半年才发现 token 刷新逻辑有竞态条件。同一个模式：AI 的输出在审查时没有破绽，问题藏在它没告诉你的假设里。
人类独有的那一秒
你有没有遇到过这样的时刻——有人问你一个你其实不太确定的问题，你停顿了一下，然后说：“这个我不太确定，可能需要再查一下。”
这个停顿很重要。有经验的医生遇到不典型症状不会直接下诊断，有经验的工程师听到模糊需求不会直接给方案。不是能力不够，是他们知道自己的判断在哪些边界上会变不可靠。
有个词叫元认知，叫什么不重要，意思就是你对自己的判断边界有感知——知道自己在哪些地方可能会犯糊涂。
AI 没有这个东西。
它不会在给你方案的时候说”这个场景我其实不太确定”，也不会标注”以下假设可能不成立”。输出里找不到任何”犹豫”的痕迹。它就是均匀地、自信地，把所有答案用同一种语气交给你。
而这种均匀的自信，恰恰是风险最大的地方：你失去了判断的抓手。
以前你自己写代码，不确定的地方会犹豫，会去查文档，会问同事。这些”犹豫”本身就是一道质量过滤——虽然慢，但帮你挡掉了不少问题。现在这道过滤被跳过了。AI 不犹豫，直接给你答案。如果你也不犹豫，因为它给的答案看着确实没问题，那风险就从两头同时被放大：生成端没有自我质疑，接收端也没有。
之前有人在评论区留过一句话，我觉得说得准：“那种看 AI 代码时’感觉不对但说不出为什么’的直觉，其实不是代码审查能力，是身体在替你的元认知报警。“
从”我写的”到”我放行的”
AI 缺少元认知，这件事本身不可怕，它就是一个工具的特性，你知道了就好。
真正可怕的是，用着用着，你自己的元认知也在退化。
以前提交一个 commit 有一种隐含的重量——你的名字挂在那，意味着如果出了问题，你能站起来说：我选的，因为 X。哪怕这个决定只花了三秒钟，它也是你的。
现在呢？commit 上签的是你的名字，但那个”决定”是谁做的？
决定是”我考虑了 A 和 B，选了 A”。放行是”AI 选了 A，我没看出明显问题”。两件事在 git log 里长得一模一样，但责任的含义完全不同。
你的名字还在 commit 上，但你跟这段代码之间的关系变了——从”我写的”变成了”我放行的”。直到有一天你发现，你名下有几千行代码，你对其中大部分只剩下一个模糊的印象：“当时好像没问题。”
这种”每一行都是我的”的本能，是长期手写代码训练出来的——自己敲的每一行、踩的每一个坑，都在强化一个认知：出了事你得兜着。现在这个训练过程正在被跳过，那种本能就在慢慢变淡。就像一块肌肉，不用就萎缩。
“没有否决”和”做了决定”之间的距离
当有人来问”这段代码为什么这么写”，不管是 GitHub issue、用户私信，还是你半夜被告警吵醒去查日志，以前这个问题总有答案：我评估了 A 和 B，A 更快但 B 更稳，考虑到场景选了 B。不管对错，至少有一条可以追溯的判断链。
现在呢？我问了一圈身边的开发者，最常见的回答是：“AI 生成的就这样。”
这句话说出来很轻松。但你仔细品一下它的意思：答案变成了”没人选，它就这么出来了”。整个决策过程被跳过了。你甚至没有权衡过，AI 输出了什么，你就用了什么——这连一个”不够好的判断”都算不上，至少判断还能复盘、还能改进。
“没有否决”和”做了决定”之间的距离，就是整个责任真空的宽度。
更让人不安的是安全场景。你让 AI 写一个接受用户输入的接口。AI 给了你一个能跑的版本，测试过了，你合并了。三个月后有人发现这个接口没做输入校验，往里塞一段精心构造的请求就能拿到不该拿的数据。
出了事之后，“怎么没测到”至少还有技术答案。更尴尬的问题是”谁决定这样设计的”。你去翻 commit 记录，上面是你的名字。但你知道，你没有”决定”过任何事。你只是没有否决 AI 的输出。
这种真空现在藏在无数个代码库里，没人注意到它。测试报告上看不到它，code review 标不出来，任何指标上都不留痕迹。它只在出事之后才会被看见，以最尴尬的方式。
在模糊地带保持警觉
这事没有方法论可以兜底。
元认知来自经验，经验来自时间和试错。你不可能通过读一篇文章就获得”知道自己不知道什么”的能力。同样，好的工程师在某个时刻做出的那个”不够完美但更对”的决定——为了可读性牺牲一点性能，为了简单砍掉一个华丽的抽象——也不是规则手册教的，是长期实践磨出来的直觉。
这两种能力说到底是同一件事：在模糊地带保持警觉。
回到那个 GitHub issue。
我最后给那个用户回了一个诚实的答复：确认了问题，解释了当初的实现思路是基于小数据量场景，承诺会改成流式处理。
但写完那条回复之后，我给自己加了一个习惯。每次合并 AI 生成的代码之前，问自己一句：
“如果这段代码明天出了问题，有人来问我为什么这么写，我能不能给出一个答案？”
就一个问题。
答得上来，就合并。答不上来，就退回去再看一遍。
至于这个习惯我能坚持多久——说实话，我不确定。赶着上线的时候，“先合了再说”几乎是本能反应。
但至少现在，每次我点合并之前，脑子里会闪过那个 issue 页面——一个陌生人在等我解释一段我自己都说不清的代码。
那种感觉，我不想再有第二次。
至少，下次点”合并”之前，慢两秒。