AI 生成的代码，我不读就直接用，直到出事

我有阵子用 AI 写代码用得很飘。

AI 生成的代码，扫一眼结构对，跑一下测试绿，我就提了。读？太慢了，AI 写的代码看着都挺像样，读它干嘛，反正跑通了。

这个习惯持续了挺久，直到一次事故把我打醒。

一个我读了就会发现的 bug

那次是段处理数据的代码，AI 生成的，跑着也没��题。上线后某天，一个边界条件下，它把不该删的数据删了。

事后我回头读那段代码——那个 bug 就明明白白写在那里：一个判断条件里，它用了个错误符号，本意是「保留这些」，实际成了「删掉这些」。这个 bug 我写代码时会犯，但我会读自己代码；AI 写的，我没读，于是它就溜过去了。

最讽刺的是，这段代码我如果读了，十秒就能看出来。但它「看起来太对了」——结构清晰、命名规范、注释齐全，看着就像「肯定没问题」的代码。我正是被这种「看着对」麻痹了，跳过了那十秒的阅读。

这次事故让我想明白一件事：AI 生成的代码，「看着对」的概率比人写的高得多，但这恰恰是它更危险的地方。

人写的烂代码，一眼能看出来乱、绕、有味道，你会警惕。AI 写的代码，即便逻辑有错，外表也整整齐齐、规规矩矩，骗过你的第一眼扫描。你会基于它的「外表可信」跳过审查，而真正的 bug，恰恰藏在被跳过的细节里。

代码的质量和代码的「看着像不像对」是两回事。AI 把这俩的相关性打没了——它能写出外表极整洁的错代码。于是我那种「扫一眼结构对就提」的捷径，彻底失效了。

出事后我立了条规矩，硬性的：AI 生成的每段代码，至少完整过一遍 diff 再提交。不是扫结构，是逐行读，重点看逻辑判断和边界条件。

这个规矩执行起来有点痛苦——AI 生成快，读慢，节奏被拖下来了。但那次事故告诉我，这十分钟的阅读，��挡住「删库级 bug」的最后一道防线，省不得。

我还加了个小动作降低阅读成本：让 AI 生成时同时解释「每段改动的意图」，我读代码时对照它的解释看。这样我能更快定位「它想做啥」和「它实际做了啥」的偏差——大部分 bug 就在这偏差里。

那次之后，我对 AI 代码的态度从「默认信任」变成了「默认怀疑」。

不是说 AI 代码质量不行，相反它质量经常很高。但「经常高」不等于「这段高」，而「这段」才是要上线的。我跳不过那段逐行阅读，因为我不读，就没人替我读了——测试覆盖不到的地方，靠的就是人的那双眼睛。

AI 让写代码变快了，但没让读代码变多余。恰恰相反，因为代码来得快、来得多、来得「看着对」，读这一步比以前更重要了。

快的是生成，慢的是把关。AI 帮你跳过了前者，但后者这关，��远得你自己过。跳过它的代价，是哪天在线上炸雷，然后你回头发现那个 bug，就明明白白躺在你没读的那十秒里。