AI生成代码的隐患：速度幻觉与验证缺失

ai 模型可以在十秒内写出一条复杂的查询或函数。这种速度令人惊叹，但它制造了一个危险的假象。生成时间已经降至接近零，但交付一个可正常工作、可靠的产品的时间几乎没有变化。

瓶颈只是简单地从「创作」转移到了「验证」。当你跳过或草率完成验证步骤时，你会为此付出两次代价：第一次是当一个隐蔽的 bug 进入生产环境，第二次是当你试图调试一段自己毫无记忆的代码时。

人类必须扮演守门人的角色，因为模型缺乏对微妙领域意图的理解。当 Agent 为你编辑代码时，review 步骤不是走过场。如果你不仔细审查每一行就接受修改，就会错过隐蔽的逻辑变更——比如把 UNION 改成 UNION ALL（两天前这事就让我摊上了）。

更重要的是，当你没有自己写代码时，你就无法在脑海中建立关于它如何运作的地图。当它日后出现问题时，你无法在记忆中搜索潜在的故障点。你被迫依赖 diff，或者让 AI 去修复一段你们双方都不真正理解的代码。

目标读者：

使用 Cursor 或 AI Agent 进行日常编码的开发者和数据工程师

注意到从 prompt 到代码的速度很快，但实际功能交付速度却感觉没变化的构建者

曾经花费数小时排查由已接受的 AI 修改引入的隐蔽 bug 的任何人

ai 辅助工程的承诺是速度。但草稿创建的速度与交付经验证产品的速度之间存在明显差异。

当你手工起草代码时，敲键盘很慢，但你的大脑在主动映射每一条分支、每一个子句和每一个边界情况。你在工作记忆中持有一份实现的「热缓存」。如果在测试期间出现 bug，你的大脑会立即知道哪些行是可疑的，因为你记得曾与那段特定逻辑「搏斗」过。

而 AI 生成则不存在那份热缓存。代码是完整呈现的。如果你不经过严格审查就接受它，就是用几分钟的仔细阅读，换来日后痛苦的逆向工程。

破坏系统的隐蔽变更

ai 模型训练于大量模式，但它们不理解你特定数据模型或领域规则的微妙约束。它们生成的代码语法上看起来很干净，执行时也没有语法错误，但会微妙地改变行为。

几天前，我漏掉了验证 Agent 建议修改中的某一行。Agent 把 UNION 改成了 UNION ALL。

从语法上讲，查询完全有效。dbt 编译它没有报错。Snowflake 执行它也很顺畅。但从功能上讲，它导致记录重复，改变了下游行数，并破坏了下游业务逻辑。

因为我接受修改时没有检查那一行，这个变更完全不存在于我的记忆中。当下游的 pipeline 失败时，我无法从自己对我所写代码的心智模型中提取信息。我只能一行一行地搜索、检查 git diff、反复查询代码库，只是为了定位一个人类在起草时本可立即识别出的缺陷。

失去作者记忆的代价

当你亲手写代码时，调试是一场内部搜索。你问自己：

「那个 join 中的空值我处理了吗？」

「我过滤掉非活跃状态记录了吗？」

「我把这个 group by 子句放在哪儿了？」

当 AI 写代码而你走马观花地 review 时，调试就变成了一场外部调查。你不记得那些决策，因为你没有做出那些决策。你突然变成了一个在压力下审计他人 pull request 的第三方审阅者。

这创造了一个令人沮丧的反馈循环：

ai 在几秒内生成代码。

你为了保持节奏而快速接受变更。

在测试或执行期间出现隐蔽的逻辑 bug。

你没有代码的心智模型，所以无法猜测问题出在哪里。

你被迫让 AI 去诊断正是它自己产生幻觉或错误构建的代码中的 bug。

这个循环摧毁了 AI 生成的速度优势。打字节省的时间完全被逆向工程那段不被记忆的代码所消耗。

人类守门人不是可选项

这就是为什么人类守门人是不可协商的。

ai Agent 可以总结文件、搭建结构、建议实现。但它无法为结果负责。它不知道你模型中的 UNION ALL 会导致下游 join 重复，或者一个微妙的类型转换会丢失快照所需的时间戳精度。

为了保持 AI 工作流的可持续性，把每一条生成的代码当作一个来自初级开发者的未经核实的 pull request 来对待——这个初级开发者以闪电般的速度工作，但缺乏上下文：

在接受之前阅读 diff 的每一行。如果你不理解为什么某一行发生了变化，就不要接受它。

把验证当作主要工作。打字从来不是软件工程的瓶颈；理解和正确性才是。

始终严格控制编写通道。让 Agent 读取、搜索、建议，但把最终决策和写入应用严格把控在你自己的判断之下。

目标不是停止使用 AI Agent。目标是认识到真正的速度来自于严格的验证、完整的所有权，以及绝不把你不完全理解的代码放入代码库。

能力不是行动的理由

• 低思考模式实际上更好
• 一个 Agent、一个代码库、一次只一个写作者