为什么需要防幻觉工作流
AI 辅助调研越来越普遍，但大模型有一个根本问题：它会”编造”看起来合理但实际不存在的信息。
这不是模型”说谎”——而是它的训练方式决定的。模型的目标是生成”最可能的文本续写”，而非”最准确的事实陈述”。当训练数据中缺乏某方面信息时，模型会基于模式”合理推测”，产生幻觉。
防幻觉工作流的目标不是消除幻觉（这是模型训练层面的事），而是在使用层面系统性降低幻觉带来的损害。
核心原则
所有技术调研必须优先验证官方源，关键数字信息必须直接来自官方网站。
不满足于”看起来合理”——必须是”可追溯、可验证、有出处”。
信息源优先级体系
| 优先级 | 类型 | 示例 |
|---|---|---|
| L0（最高） | 官方网站、技术文档、学术论文 | 项目 GitHub、arXiv、官方 docs |
| L1（高） | 权威媒体、行业报告 | TechCrunch、Gartner 报告 |
| L2（中） | 用户反馈、社区讨论、第三方评测 | Reddit、V2EX、知乎专业回答 |
| L3（低） | 新闻聚合、二手转述、推测信息 | AI 生成的摘要、自媒体文章 |
核心规则：L3 信息不能作为决策依据。L2 信息需要交叉验证。L0-L1 信息可以直接引用。
执行检查清单
每次 AI 辅助调研必须完成以下步骤：
信息收集阶段
- 官方源验证：首先搜索并访问官方网站（
site:xxx.com） - 技术文档：查找官方技术文档、白皮书、API 文档
- 时间验证：检查发布日期、版本号、更新日志（技术信息时效性极强）
- 数字验证：技术参数、价格、性能指标必须官方验证
交叉验证阶段
- 官方源优先：官方信息与第三方冲突时，优先采用官方源
- 数字严格验证：所有数字信息必须有官方来源——见过太多”月活 100 万”实际是”注册用户 100 万”
- 时间敏感检查：技术领域的信息（如框架版本、API 端点）6 个月前的就可能过时
- 来源追溯：关键结论必须有可点击的 URL 来源
验证方法
- 浏览器直接访问：用 DevTools 访问官方网站获取第一手信息
- 快照取证：页面内容会变化，关键信息截图存证
- 多源对比：至少两个独立来源验证关键信息
- 实时验证：价格、API 价格等变化快的信息必须实时验证
不确定性管理
AI 输出中，不是所有信息都有同等置信度。需要明确标注验证状态：
| 标注 | 含义 | 使用场景 |
|---|---|---|
| ✅ 已验证 | 有官方源或权威第三方验证 | 官方文档明确记载的参数 |
| ⚠️ 待验证 | 需要进一步验证 | 社区中流传但官方未确认的信息 |
| ❓ 推测 | 基于有限信息的合理推测 | 从公开信息推断的技术架构 |
| ❌ 无法验证 | 当前无法找到可靠来源 | AI”编造”的时间、数字等 |
常见幻觉类型与对策
1. 数字幻觉
AI 经常编造具体的数字和百分比。
案例：“根据 Gartner 报告，该市场年增长率 23.7%“——实际报告可能根本没有这个数字，或者数字完全不同。
对策：所有数字必须追溯原始出处。如果找不到，标注为”无法验证”。
2. 引用幻觉
AI 会编造不存在的论文标题、作者和引用。
案例：AI 声称某论文提出了某种方法，但该论文根本不存在，或者存在但内容完全无关。
对策：在学术数据库（Google Scholar、arXiv）中验证论文是否真实存在。
3. 时间幻觉
AI 经常混淆事件的时间线。
案例：把 2024 年发布的功能说成是 2023 年发布的。
对策：技术调研中，所有时间信息必须查官方 changelog 或 release notes。
4. 名称/URL 幻觉
AI 会编造不存在的项目名称、GitHub 仓库、域名。
案例：AI 推荐使用某个”广受好评”的工具，但该工具在 GitHub 上根本不存在。
对策：点击链接验证，搜索 GitHub 确认仓库是否存在。
实战：一次典型的技术调研流程
假设你要调研一个新框架，流程如下：
- AI 初筛：让 AI 列出相关框架和基本特点（标记为 ⚠️ 待验证）
- 官方源验证：逐个访问框架的 GitHub 仓库和官方文档（升级为 ✅）
- 社区验证：在 V2EX、Reddit 查看实际使用者的评价（确认或修正）
- 数字核实：Star 数、版本号、最后更新时间直接从 GitHub 获取
- 输出标注：最终文档中明确标注每类信息的验证状态
一句话总结
AI 是调研的加速器，不是真相的担保人。
好的防幻觉工作流让 AI 从”嘴替”变成”检索助手”——它帮你找到方向，但最终的真相核实，还是要靠人类做那个”去官方看一眼”的动作。