铁律「不要轻信，必须验证」：怎么检验 AI 的产出

为什么需要验证

在前面的章节里，我们提到 AI 有"幻觉"的倾向——它可能在不确定时编造看似合理的回答，而且语气和给出正确答案时一模一样。

如果你只是在闲聊中问 AI 一个趣味问题，幻觉的影响微乎其微。但当你把 AI 的输出直接用到正在构建的项目中——用它给的配置、它推荐的函数、它建议的架构——一个错误的回答就可能变成一个真实的隐患。

验证不是因为你不信任 AI，而是因为你要为项目的结果负责。一个好的项目经理不会因为团队成员看起来很自信就跳过审核，对 AI 也是一样。

三个实用的验证方法

自己跑一遍

最直接的验证方式：把 AI 给你的代码或方案实际运行一遍，看看结果是否和它描述的一致。

不要只看"是否能运行"，还要观察：

• 输出的结果是不是你期望的？
• 在边缘情况下——比如输入为空、数字为零、网络断开时——它的表现如何？
• 刷新页面或重启程序之后，之前的数据还在吗？

"能跑"是最低标准，"跑对了"才是真正的通过。

交叉提问

当 AI 给出一个方案后，你可以换一种方式再问一次。比如：

• 开一个新的对话，用不同的措辞描述同样的需求，看看它给出的方案是否一致。
• 直接质疑它："这个方案有没有什么缺点或风险？"
• 请它对比不同的解决思路："除了这种做法，还有没有其他常见的方式？各自的优缺点是什么？"

如果同一个问题在不同提问方式下得到了差异很大的回答，那至少说明这个问题值得更深入的考察。

要求可验证的依据

当 AI 告诉你"应该用某个函数"或"这个配置参数的作用是某某"时，你可以要求它给出依据来源——"这个函数在官方文档的哪个页面可以找到？"

如果 AI 给出了具体的链接或文档位置，你可以去亲自确认一下。如果它给出的链接打不开或内容对不上，那很可能就是一次幻觉。

这不需要每个输出都去核实，但对于关键决策——涉及安全配置、数据存储方式、计费模式、权限设置的内容——花一分钟查一下官方文档，往往能省下几天的排错时间。

验证的分寸

你可能会担心：如果事事都要验证，那用 AI 的效率优势不就没了？

好消息是，你不需要验证所有的东西。一个合理的原则是：按后果的严重程度来决定验证的力度。

• AI 帮你写了一段样式代码，让按钮换了个颜色——这类变更影响小，肉眼看一下效果就行。
• AI 建议了一种数据库的表结构设计——这关系到后续的扩展性，值得多问几句为什么。
• AI 给出了一段涉及用户认证、密钥管理或支付逻辑的代码——这类输出必须仔细验证，因为出错的代价极高。

建立起这样的判断力之后，验证就不再是一种负担，而是一种高效的风险过滤器。