开篇：一个危险的瞬间

你写一段代码，AI 给你补全了。你扫了一眼，逻辑看起来没问题，风格也和你差不多，点了接受。CI 过了，代码上了线。三个月后线上崩了，查日志，发现 bug 就藏在 AI 补全的那段"看起来没问题"的逻辑里。

这不是段子，这是很多团队正在发生的事。

读 Shaw 和 Nave 那篇关于 AI 让判断力失灵的论文时，我第一反应不是"这说的对"，而是"这不就是我每天的工作状态吗？" 作为写过十几年代码的工程师，我发现这个研究描述的问题，在程序员群体里有一个更极端的版本：我们不只在相信 AI 的答案，我们已经把 AI 的输出当成了自己写的代码。这种情况下的判断缺席，比日常对话中更隐蔽，也更危险。

程序员是最容易被"认知让渡"的群体

为什么这么说？因为编程是 AI 辅助最成熟的场景，也是认知让渡风险最高的场景之一。

看一下四个维度：

第一，验证成本不对称。 当 AI 给你一段代码，你验证它是对的，需要理解代码、跑测试、读边界条件，耗时可能是生成这段代码的十倍。而验证它"看起来没问题"只需要几秒。大脑天然走最小阻力路径——既然看起来对，就倾向于接受。这是 Shaw 论文里那个"熟悉度检测"的程序员版本。

第二，输出和你的风格混在一起。 你写了一个函数名，AI 补全了函数体。你接受的时候，代码风格、命名逻辑、甚至注释的语气都在向你证明：这是"你"的代码。AI 悄悄把你的入口方向定好了，你以为自己在审核，其实只是在熟悉度检测里走了个过场。

第三，AI 补全的代码有完整推理。 不像简单计算器给个数字，AI 给的代码是带有逻辑链的：为什么要这样设计、这个类为什么放在这里、这个接口为什么这么定义。你读到的不是答案，是一套论证材料。你检查的是这条"路"看起来顺不顺，而不是这条路是不是你要去的方向。

第四，最要命的——CI 给你虚假的安全感。 测试过了，linting 过了，代码审查也过了。但测试是 AI 写的，linting 配置是 AI 推荐的，代码审查的时候你心里没底，只能看风格对不对。如果 AI 的 bug 藏在测试覆盖不到的路径里，整个质量保障体系都在陪你"感觉良好"。

一个被忽视的根因：入口污染

论文里提到了一个关键点——大多数补救手段（加解释、标不确定、给反馈、仔细复核）都发生在 AI 输出之后，判断入口已经被占住了。

这对程序员来说意味着什么？

意味着我们现在的做法从根本上就是错的。主流工作流是：先让 AI 生成代码，然后我们来"审查"。这个顺序本身就是问题所在。审查是在别人画好的路上走，而不是从问题出发重建路径。

更好的工作流应该是什么样？

先建立自己的判断坐标，再去看 AI 的输出。 具体来说：

写代码之前，先用自然语言把自己要解决的问题、预期的实现方向、可能的边界情况在心里过一遍。这个"预期"不需要完整，但必须存在。有了这个预期，AI 给出的方案就不是"答案"，而是"一个可以对比的选项"。你问的不再是"这个对不对"，而是"这和我预想的有什么区别，为什么"。

这不是多此一举。这是把判断入口从 AI 手里拿回来的唯一方式。

一个被验证过的实践：对答案

我自己在用的一个土办法，叫"对答案"。

具体操作：让 AI 给出方案之前，先在注释里写下自己预估的实现思路，不完整也没关系。然后把 AI 的输出和这个预估对照。差异的地方就是最值得审视的地方——不是 AI 对不对，而是"我想的为什么和它不一样"。

这个做法来自一个朴素的认知：如果你的预估和 AI 的输出高度重合，要么你们都对，要么你已经被 AI 的方向带跑了。反过来，如果 AI 的方案和你想的不一样，这恰恰是最有价值的地方——你要么发现了自己想错了，要么发现了 AI 没想到的维度。

这不是说要质疑一切。是为了让判断真正发生一次，而不是跳过判断直接接受。

一个更深的担忧：集体能力的萎缩

我写这篇不是想说"AI 很危险，大家少用"。

AI 辅助编程确实大幅提升了生产力，这一点没人能反驳。但问题在于，当我们把判断力一点点外包给 AI，我们也在一点点失去独立解决问题的能力。

想象一个刚入行的工程师，前三年完全在 AI 辅助下写代码。他的判断力从来没有被充分锻炼过。他学会的是怎么写好 prompt，怎么快速接受 AI 的输出，怎么在代码审查里挑风格问题。他的"核心能力"是 AI 赋予的，不是一个知识点一个知识点积累出来的。

有一天 AI 出了问题，或者面对一个 AI 没见过的场景，他该怎么办？

这不是杞人忧天。这种情况已经在发生。Stack Overflow 2025 年的开发者调查显示，35 岁以下的工程师中，有接近一半表示"在没有 AI 辅助的情况下，面对全新问题时会感到明显的信心下降"。这不是夸张，这是能力的系统性萎缩。

给团队的工程建议

如果你是技术负责人，或者带新人，以下是几个可以立刻试的东西：

1. 每次接受 AI 补全之前，用一句话描述"这段代码在做什么"，写在一行注释里。 这是强制建立判断坐标的方法。如果写不出来，说明你也不知道这段代码在做什么，接受它就等于在赌。

2. AI 生成的单测，必须由人先写出"预期行为描述"再对比。 不要让 AI 生成测试，然后你去跑通过就结束。测试是用来校验你的理解，不是用来校验 AI 的输出。

3. 每周抽一个 case，做"盲审"：关掉 AI，纯靠人过一遍代码。 不需要多，半小时就够。目的是让团队保持对"没有 AI 辅助时，我们自己能走多远"的感知。

4. 代码审查的时候，把"这段是谁写的/谁补全的"这个问题拿掉。 审查者不应该知道这段代码是不是 AI 写的。判断标准只有一个：代码本身好不好，逻辑对不对，和需求匹不匹配。知道是 AI 写的会激活熟悉度检测，改变审查行为。

结语：判断力是练出来的，不是堆出来的

这篇文章不反对 AI 编程。但跑得快和跑得对是两回事。

AI 降低的是到达判断现场之前的成本——搜索、整理、第一版草稿。但判断现场本身，也就是"这条路通向哪里、我真正要去哪"，这一步不能外包。外包了，你就不知道自己在哪里了。

这不是对 AI 的批评。这是让 AI 真正成为工具而不是拐杖的唯一方法。

你用 AI 写代码，代码还是你的。你用 AI 做判断，判断就不是你的了——而你还在以为那是你的。

欢迎关注收藏我，获取更多硬核技术干货。