跳到主要内容

如何处理 AI 幻觉

AI 幻觉（hallucination）不是“偶尔答错一次”那么简单。在 Vibe Coding 场景里，它常常表现为：捏造文件、捏造 API、误解需求、假设环境存在、把没跑过的代码说成已验证。 所以真正要处理的，不只是结果错误，而是降低错误进入代码库的概率。

0. 面试速答（30 秒版 TL;DR）​

  • AI 幻觉的本质是：模型在信息不完整时，仍然生成了看起来很像真的答案。
  • 在编码场景里，最危险的 4 类幻觉：
    • 事实幻觉：API、版本、框架行为说错
    • 代码幻觉：引用不存在的函数、文件、参数
    • 环境幻觉：假设某个命令、依赖、服务一定存在
    • 需求幻觉：把用户没说的话当成要求
  • 治理顺序应该是：先缩小任务 -> 再给证据源 -> 再强制验证 -> 最后才接受产出。
  • 原则不是“让 AI 永不出错”，而是 让每次错误更早暴露、更容易拦截。

1. 先建立心智模型：幻觉不是“撒谎”，而是“概率补全”​

模型不会先停下来确认“我真的知道吗”，它更像是在做：

  • 根据已有上下文预测最像答案的内容
  • 尽量保持语气连贯
  • 优先生成“像样”的结构

这就导致一个典型问题：

  • 形式越完整，越容易让人误以为它已经验证过。

所以在工程场景里，判断标准不该是“它讲得像不像真的”，而该是：

  • 它有没有证据？
  • 证据是不是当前仓库里的？
  • 能不能跑出来？

2. 编码场景最常见的 4 类幻觉​

2.1 事实幻觉​

例如：

  • 某框架 API 名称说错
  • 某版本默认行为说反
  • 把旧版本配置当成新版本配置

这类问题常见于：

  • 新框架
  • 快速演进的 AI 工具链
  • 版本差异大的生态

应对方法：

  • 让 AI 说明版本前提
  • 要求引用官方文档或仓库内配置
  • 不允许“默认按最新版本处理”这种模糊前提

2.2 代码幻觉​

例如：

  • 引用了仓库里不存在的文件
  • 说某个 hook / util 已存在，但其实没有
  • 输出一段 API 风格看起来很对的代码，但参数是编的

这类最危险，因为它很像“差一点就能跑”。

应对方法：

  • 要求所有关键引用附带 path:line
  • 修改前先搜代码，不允许凭印象补实现
  • 重要改动必须跑测试或最小验证命令

2.3 环境幻觉​

例如：

  • 默认假设仓库有某个脚本
  • 默认假设你有 Docker、某个数据库、某个二进制工具
  • 默认假设某个端口、服务、环境变量已经就绪

应对方法：

  • 让 AI 在开始前列环境前提
  • 缺前提时先做探测，而不是直接执行方案
  • 把“需要用户提供的外部条件”单独列出来

2.4 需求幻觉​

例如：

  • 用户只想改文档，AI 开始改代码
  • 用户只想修 bug，AI 顺手做重构
  • 用户只要求最小改动，AI 扩大到全局抽象

这是团队里最常见、也最隐蔽的一类。

应对方法：

  • 明确写出：
    • 目标
    • 非目标
    • 可修改范围
    • 禁止改动范围

一句话：需求边界不清，AI 会自动脑补。

3. 一套更稳的处理流程​

3.1 缩小任务​

不要一上来就说：

  • “帮我把整个项目优化一下”
  • “把架构重构得更合理”

更好的说法是：

  • 只改哪个目录
  • 解决什么现象
  • 以什么命令验证
  • 不允许碰哪些文件

任务越大，幻觉空间越大。

3.2 提供权威上下文​

最有效的做法不是“多说一点”，而是“给对的证据源”：

  • 仓库里的真实文件
  • 配置文件
  • 错误日志
  • 测试失败输出
  • 官方文档链接

如果上下文源是假的、旧的或不完整，AI 的答案再流畅也没有意义。

3.3 强制它给证据​

例如可以要求：

  • 涉及现有代码时，必须给 path:line
  • 涉及命令时，必须说明预期输出
  • 涉及框架行为时，必须写清版本前提

你要把“拍脑袋输出”改造成“带证据输出”。

3.4 强制验证​

这是最关键的一步。

最小验证方式包括：

  • 打开对应文件确认是否存在
  • 运行 typecheck
  • 运行最小测试
  • 本地启动并手动点一遍关键路径

没有验证的 AI 产出，最多只能算候选方案，不能算完成结果。

4. 典型题 & 标准答法​

Q1：AI 幻觉能不能彻底消灭？​

答：

不能。因为模型是概率生成系统，只能通过更好的上下文、约束和验证来降低风险，不能保证零幻觉。

Q2：处理幻觉最有效的一招是什么？​

答：

不是“换个更强的模型”，而是 把输出改成必须可验证。一旦要求文件证据、命令验证、测试结果，很多幻觉会在进入代码库前就暴露。

Q3：为什么 AI 越能说，反而越危险？​

答：

因为人会把“表达完整”误判成“已经正确”。工程里必须把“说服力”降级，把“可验证性”升级。

5. 团队里最值得落地的 5 条规则​

  1. 没有 path:line 的代码结论，不直接采纳。
  2. 没有验证命令的修改，不算完成。
  3. 未声明版本前提的框架结论，默认高风险。
  4. 涉及大范围改动，先拆成小任务再让 AI 做。
  5. 人类 reviewer 只对“已验证结果”评审，不替 AI 补做事实校验。

6. 常见误区​

  • 误区 1：把所有错误都叫幻觉
    • 有些是提示词不清，不是模型乱编。
  • 误区 2：只靠“请仔细思考”
    • 这能改善表达，但不能替代证据和验证。
  • 误区 3：以为强模型就不会编
    • 强模型只是在很多场景里更少编，不是不会编。
  • 误区 4：让 AI 自己给自己验收
    • 它可以辅助验证，但不能替代真实执行结果。

7. 速记要点（可背诵）​

  • AI 幻觉 = 信息不完整时的高可信补全。
  • 编码里最危险的不是答错，而是 错得像对的一样。
  • 最稳的治理链路：缩小任务 -> 给证据源 -> 要求证据 -> 强制验证。