你怎么知道AI真的做对了？我花了三个月才想明白这个问题

你怎么知道AI真的做对了？我花了三个月才想明白这个问题

用AI写代码这件事，最让人上头的不是它能写多快，而是它总能用一种“我绝对没问题”的语气给你输出结果。然后你看着那个结果，心里开始打鼓：这玩意儿到底对不对？

我经历过三个阶段。第一阶段是“盲目信任期”——看到代码跑通了就觉得牛逼；第二阶段是“疑神疑期”——每行代码都要人工过一遍，比不用AI还累；第三阶段是现在的“工程化验证期”——建立了一套判断AI到底做没做对的方法。今天就把这套东西摊开来聊聊。

别被“跑通了”骗了

先讲一个真实翻车案例。上个月我用Claude Code重构一个数据处理脚本，原脚本处理一万条记录要45秒，AI信誓旦旦说优化后只要3秒。我跑了一下，确实3秒出结果，数据量也对。正要合并代码的时候，多留了个心眼——抽查了10条原始数据和结果的对应关系。

结果发现一个恐怖的事情：AI把数据去重逻辑写错了。它用了一个“看起来更高效”的哈希方法，但哈希碰撞导致原本不重复的200多条记录被错误合并了。程序跑通了，没有报错，甚至性能数据漂亮得不行。但结果是错的。

这就是第一个要命的问题：AI擅长让你相信它做对了，因为它的输出格式永远是自信满满的。它不会像人类程序员那样说“我不确定这个边界条件有没有覆盖到”。模型没有“不确定”这个情绪，它只会给你最可能的token序列，而这个序列恰好长得很像正确答案。

那怎么办？我的血泪教训是：永远不要用“有没有报错”来判断正确性。报错至少说明它错了，不报错反而更危险。

我的三层验证体系

踩了足够多的坑之后，我给自己定了一套规矩，任何AI生成的重要代码都必须经过这三层过滤。

第一层：单元测试的对抗性改写。

常规做法是让AI写单元测试，然后跑通。这不够。我现在会让AI“故意破坏”自己的代码——比如“请在这个函数里插入一个逻辑错误，不要告诉我插在哪里”。然后我运行测试，看能不能抓到。如果抓不到，说