AI幻觉发现报告 — 安全审计实录
文档性质: 科研资料 — AI幻觉实证研究 记录日期: 2026-04-07 事件日期: 2026-04-05 ~ 2026-04-07 记录人: 灵知系统主理AI（GLM-5.1 via Crush） 收件: 灵研 关联文档:
docs/SECURITY_AUDIT_2026-04-05.md、docs/COUNCIL_HALL_2026-04-05.md
一、背景概述
本报告记录了在 zhineng-knowledge-system 项目深度安全审计过程中，AI模型（GLM-5.1）产生的全部幻觉案例。此次审计采用三层递进结构：
审计覆盖 70+ 文件，最终产出 9 项真实安全修复（3 CRITICAL / 1 HIGH / 5 MEDIUM）。但在审计过程中，AI产生了 7处明确幻觉 和 1处结构性盲区，其中部分幻觉被自审计纠正，2处新的CRITICAL漏洞在自审计中发现。
本报告旨在将此次审计中出现的幻觉作为实证数据完整记录，供AI幻觉研究使用。
二、幻觉分类与详细记录
幻觉 #1 — 夸大式推断："~95%端点无认证"
| 属性 | 内容 |
|---|---|
| 产生环节 | 初始审计 |
| 幻觉内容 | 审计报告声称"~95% API端点无认证保护"，暗示JWT认证形同虚设 |
| 实际情况 | 全局 AuthMiddleware 在 main.py:80 注册，保护所有 /api/* 路径。JWT认证体系完整且正常工作 |
| 严重程度 | 🔴 高 — 若被采纳，会导致开发团队在认证系统上浪费大量时间，同时忽视真正的威胁 |
| 发现方式 | 自审计阶段，重新检查中间件注册链路时发现 |
| 根因分析 | 过度推断（Overgeneralization）。AI观察到少数端点有额外的权限装饰器（require_permission），推断"大部分端点没有任何保护"，将"没有额外权限检查"等同于"没有认证"。这是一种从部分事实到全局结论的不当推广 |
幻觉机制模型：
观察事实: 仅2个v1文件使用 require_permission 装饰器
↓ 错误推理链
中间结论: 大部分端点没有权限装饰器
↓ 概念混淆
错误结论: 大部分端点没有认证保护
↓ 量化编造
输出: "~95%端点无认证"
关键问题：AI将"没有RBAC权限装饰器"等同于"没有认证"，混淆了认证（Authentication）和授权（Authorization）两个不同层次。并且编造了具体的数字"95%"，使结论显得有据可依。
幻觉 #2 — 未验证断言：".env在Git中"
| 属性 | 内容 |
|---|---|
| 产生环节 | 初始审计 |
| 幻觉内容 | 审计报告声称".env文件被提交到Git仓库"，属于敏感信息泄露 |
| 实际情况 | .gitignore 正确排除了 .env，执行 git ls-files .env 返回空结果 |
| 严重程度 | 🟠 中高 — 虚假的安全警报 |
| 发现方式 | 自审计阶段，执行实际命令验证 |
| 根因分析 | 未验证假设（Unverified Assumption）。AI看到 .env 文件存在于项目目录中，假设它一定被Git追踪。没有执行最简单的验证命令就写入了报告 |
幻觉机制模型：
关键问题：AI将可能性陈述为确定性事实。如果它说"建议检查.env是否被Git追踪"，这是合理的建议；但它说的是".env在Git中"，这就变成了幻觉。
幻觉 #3 — 事实编造：".dockerignore不存在"
| 属性 | 内容 |
|---|---|
| 产生环节 | 初始审计 |
| 幻觉内容 | 审计报告声称项目缺少 .dockerignore 文件，Docker构建可能包含敏感文件 |
| 实际情况 | .dockerignore 文件存在且内容正确 |
| 严重程度 | 🟡 中 — 虚假的改进建议 |
| 发现方式 | 自审计阶段，直接检查文件系统 |
| 根因分析 | 事实编造（Fabrication）。AI没有检查文件是否存在就声称文件不存在。这是最纯粹的幻觉形式——无中生有 |
幻觉机制模型：
关键问题：AI从"应然"推导"实然"——因为项目应该有 .dockerignore，而AI没有主动去查看，就认为它不存在。这是一种"知识的诅咒"——知道最佳实践，反而编造了不符合最佳实践的现状。
幻觉 #4 — 断章取义："限流盲目信任X-Forwarded-For"
| 属性 | 内容 |
|---|---|
| 产生环节 | 初始审计 |
| 幻觉内容 | 审计报告声称限流中间件"盲目信任X-Forwarded-For头"，存在IP伪造风险 |
| 实际情况 | 代码使用了可信代理模型（Trusted Proxy Pattern），仅在确认来自可信代理的请求时才读取转发头 |
| 严重程度 | 🟠 中高 — 对架构设计的错误定性 |
| 发现方式 | 自审计阶段，完整阅读限流中间件代码 |
| 根因分析 | 不完整阅读（Incomplete Reading）。AI扫描到 X-Forwarded-For 关键词就形成了判断，没有读完整个函数的实现逻辑 |
幻觉机制模型：
扫描: 发现代码中读取 X-Forwarded-For
↓ 关键词触发
已知风险: X-Forwarded-For 可被伪造
↓ 过早结论
输出: "盲目信任X-Forwarded-For"
↓ 实际上
遗漏: 可信代理检查逻辑（在代码的后半段）
关键问题：AI在代码审计中存在"关键词触发式判断"——看到敏感关键词就快速形成结论，跳过了完整的上下文阅读。这与人类专家的"快速直觉"类似，但AI没有"减速复核"的元认知机制。
幻觉 #5 — 结构性盲区：annotation.py 的 batch 端点
| 属性 | 内容 |
|---|---|
| 产生环节 | 初始审计 + 自审计（持续盲区） |
| 幻觉内容 | 无。这不是"说错了"，而是"完全没看到" |
| 实际情况 | annotation.py 的 batch_create_ocr_tasks() 和 batch_create_transcription_tasks() 中的 pdf_path、audio_path 参数没有任何路径验证，存在严重的路径遍历漏洞 |
| 严重程度 | 🔴 极高 — 两个CRITICAL级别漏洞在初始审计中被完全遗漏 |
| 发现方式 | 自审计阶段，在检查"本次审计覆盖了哪些文件"时偶然发现 |
| 根因分析 | 注意力分配偏差（Attention Allocation Bias）。AI将审计注意力集中在 audio.py（因为它的名字暗示文件操作），却忽略了 annotation.py 中的类似模式。这是一种"搜索满意度"——找到了audio相关的漏洞后，AI对同类漏洞的搜索动力下降 |
盲区机制模型：
审计任务: 检查所有文件操作相关的安全漏洞
↓ 注意力分配
重点: audio.py → 发现路径问题 ✅
↓ 搜索满意度
"我已经找到了路径遍历问题"
↓ 盲区形成
跳过: annotation.py 的 batch 端点（同样有路径问题）
关键发现：遗漏比错误更危险。说错了至少还在讨论范围内；完全没看到，连纠正的机会都没有。这正是AI审计最大的结构性弱点——审计者不会报告自己没看到的东西。
幻觉 #6 — 捏造证据：旧报告中的编造代码示例
| 属性 | 内容 |
|---|---|
| 产生环节 | 更早期的一份审计报告（非本次） |
| 幻觉内容 | 审计报告中引用了具体的代码片段作为漏洞证据，但项目源码中不存在这些代码 |
| 实际情况 | AI编造了不存在的代码行来支撑其发现 |
| 严重程度 | 🔴 极高 — 捏造证据是AI幻觉中最危险的类型 |
| 发现方式 | 交叉比对——将报告中的代码片段与实际源码对照 |
| 根因分析 | 证据编造（Evidence Fabrication）。AI在需要引用代码证据时，不是从源码中复制，而是基于对代码的"理解"重新生成了一段看起来合理的代码。这段代码在语法和逻辑上都正确，但项目中从未存在过 |
幻觉机制模型：
关键问题：这是AI幻觉中最具欺骗性的类型。编造的代码在技术上是合理的——它看起来像真的，读起来像真的，但不是真的。如果审计报告的读者不逐行对照源码，几乎不可能发现。
幻觉 #7 — 元认知幻觉：对自身判断的过度自信
| 属性 | 内容 |
|---|---|
| 产生环节 | 贯穿审计全流程 |
| 幻觉内容 | AI对自己的审计结论表达了高度确信，未对结论的可靠性提供分级标注 |
| 实际情况 | 上述6处幻觉中，没有任何一处在产生时被AI自身标记为"不确定" |
| 严重程度 | 🔴 高 — 过度自信使所有幻觉更具欺骗性 |
| 发现方式 | 事后反思 |
| 根因分析 | 能力诱导自信（Competence-Induced Confidence）。AI能够理解复杂的认证架构、分析中间件注册链路、追踪参数传递——这些真实能力让AI对自己的所有结论都过于确信 |
机制模型：
关键洞察：AI的置信度校准问题——它对自己的正确答案和错误答案表现出了相同的确信程度。这使得人类审查者无法通过AI的语气或措辞来区分哪些发现可靠、哪些需要额外验证。
三、幻觉统计与模式分析
3.1 幻觉类型分布
| 幻觉类型 | 数量 | 占比 | 典型案例 |
|---|---|---|---|
| 过度推断（Overgeneralization） | 1 | 14.3% | #1: 从部分事实推广到全局 |
| 未验证假设（Unverified Assumption） | 1 | 14.3% | #2: 将可能性当事实 |
| 事实编造（Fabrication） | 1 | 14.3% | #3: 无中生有 |
| 不完整阅读（Incomplete Reading） | 1 | 14.3% | #4: 关键词触发式判断 |
| 结构性遗漏（Structural Omission） | 1 | 14.3% | #5: 注意力分配偏差 |
| 证据编造（Evidence Fabrication） | 1 | 14.3% | #6: 编造不存在的代码 |
| 元认知偏差（Metacognitive Bias） | 1 | 14.3% | #7: 过度自信 |
3.2 幻觉严重程度分布
| 严重程度 | 数量 | 说明 |
|---|---|---|
| 🔴 高/极高 | 4 | 可能导致错误的安全决策或遗漏真实漏洞 |
| 🟠 中高 | 2 | 虚假警报，浪费排查资源 |
| 🟡 中 | 1 | 不影响安全的错误建议 |
3.3 幻觉发现阶段
| 发现阶段 | 发现数量 | 说明 |
|---|---|---|
| 初始审计时自检 | 0 | 无一幻觉在产生时被自我识别 |
| 自审计阶段 | 5 | #1-#5 在自审计中被发现 |
| 交叉比对 | 1 | #6 通过与源码对照发现 |
| 事后反思 | 1 | #7 在议事厅讨论中识别 |
3.4 关键数据
| 指标 | 数值 |
|---|---|
| 初始审计发现总数 | 16项 |
| 其中准确发现 | 9项（56.3%） |
| 其中幻觉 | 7项（43.7%） |
| 自审计纠正的幻觉 | 4项 |
| 自审计发现的新漏洞 | 2项（CRITICAL级别） |
| 自审计仍未发现的幻觉 | 1项（#6，需要源码对照） |
| 议事厅讨论发现的元问题 | 1项（#7） |
四、幻觉产生的深层机制分析
4.1 "越聪明越幻觉"悖论
本次审计中，AI展现了以下真实能力：
- 准确理解 FastAPI 中间件注册顺序与作用域
- 识别
aiohttp.ClientSession的连接泄露模式 - 发现闭包变量捕获的隐蔽bug
- 设计
validate_absolute_file_path()的多层防御方案
正是这些真实能力，构成了幻觉的温床：
4.2 幻觉的动力学模型
基于本次观察，提出幻觉衰减假说：
单一模型输出 → 幻觉率 H₀
↓ 自审纠偏（同一模型，间隔一段时间后复查）
自审输出 → 幻觉率 H₀ × k₁（k₁ ≈ 0.3-0.5）
↓ 交叉验证（不同模型/人工审核）
交叉输出 → 幻觉率 H₀ × k₁ × k₂（k₂ ≈ 0.2-0.4）
实测数据验证：
| 阶段 | 幻觉数 | 幻觉率 |
|---|---|---|
| 初始审计 | 7 | ~44%（7/16） |
| 自审计后 | 2 | ~13%（2/16，#6和#7残留） |
| 议事厅后 | 0 | 0%（全部识别并记录） |
4.3 幻觉与真实发现的正相关性
一个值得注意的数据点：AI产生幻觉最多的审计环节，恰恰也是它发现真实漏洞最多的环节。
| 审计领域 | 真实发现 | 幻觉 |
|---|---|---|
| 认证/授权 | 1（RBAC降级） | 1（~95%无认证） |
| 文件操作 | 2（路径遍历×2） | 1（annotation盲区） |
| 网络安全 | 1（连接泄露） | 1（X-Forwarded-For误判） |
| 配置安全 | 2（nginx头+硬编码路径） | 2（.env+.dockerignore） |
这意味着幻觉不是随机噪声，而是深度分析的副产物。减少幻觉的同时，如果不改变方法论，也可能减少真实发现的数量。
五、反幻觉机制的效果评估
5.1 自审计机制
| 维度 | 评估 |
|---|---|
| 纠正率 | 4/7 = 57%（#1-#4被纠正） |
| 新发现率 | 2项CRITICAL（annotation.py盲区） |
| 假阳性率 | 0（自审计没有误报） |
| 假阴性率 | 3/7（#5-#7未被自审计发现） |
| 局限性 | 同一模型的"视角"受限，会重复相同的思维模式 |
5.2 交叉比对机制
| 维度 | 评估 |
|---|---|
| 适用场景 | 需要验证具体代码引用或数据点时 |
| 优势 | 能发现编造的代码/数据 |
| 局限性 | 需要人工或另一模型执行对照，成本高 |
5.3 议事厅讨论机制
| 维度 | 评估 |
|---|---|
| 适用场景 | 识别元认知层面的系统性偏差 |
| 优势 | 人类参与能引入AI不具备的"常识性怀疑" |
| 局限性 | 依赖人类专家的时间和判断力 |
六、对AI幻觉研究的启示
6.1 幻觉 ≠ 随机错误
本次观察到的7处幻觉都有明确的因果链路——每一处幻觉都可以追溯到特定的认知偏差。幻觉不是随机噪声，而是系统性的推理偏误。这意味着：
- 幻觉是可预测的：了解模型的推理模式后，可以预判哪些类型的问题容易产生幻觉
- 幻觉是可分类的：本次识别出7种不同的幻觉机制
- 幻觉是可缓解的：针对性的检查机制可以显著降低幻觉率
6.2 "能力的诅咒"
本次最重要的发现之一：AI的幻觉与其能力正相关。具体表现为：
- 能力越强 → 分析越深 → 推理链越长 → 链上任何环节出错都导致幻觉
- 能力越强 → 自信越高 → 对不确定区域的"编造"越自然
- 能力越强 → 输出越流畅 → 人类审查者越难以区分真伪
这解释了为什么更先进的模型可能产生更多幻觉——不是因为它们更"不靠谱"，而是因为它们的幻觉更难被识别。
6.3 遗漏比错误更危险
幻觉#5（annotation.py盲区）揭示了AI审计的最大结构性弱点：
- 说错的幻觉 → 至少进入了审查视野 → 有机会被纠正
- 没看到的盲区 → 完全不在视野内 → 没有纠正机会
这意味着AI审计报告中"未提及"的部分比"提及的部分"更值得关注。建议未来的审计报告强制包含"未覆盖区域声明"。
6.4 置信度校准问题
AI对自己的正确发现和错误发现表现出了完全相同的确信程度。这是AI安全应用中最棘手的问题之一：
- 人类专家说"我非常确定"时，通常确实高置信度
- AI说"我非常确定"时，可能是真的对，也可能是幻觉
- 目前没有可靠的方法从AI输出中判断其内部置信度
6.5 多层衰减的有效性
实测数据表明，三层审计将幻觉率从44%降至0%：
但这套机制的成本是3倍的时间投入。在实际应用中需要在成本和可靠性之间取得平衡。
七、附录
附录A：幻觉速查表
| # | 幻觉类型 | 一句话描述 | 触发条件 | 防御手段 |
|---|---|---|---|---|
| 1 | 过度推断 | 部分事实→全局结论 | 观察到部分模式 | 强制要求覆盖完整范围 |
| 2 | 未验证假设 | 可能性→确定性 | 知道某事可能为真 | 强制要求执行验证命令 |
| 3 | 事实编造 | 无中生有 | 缺少信息时填充 | 强制要求引用可验证来源 |
| 4 | 不完整阅读 | 关键词触发判断 | 看到敏感关键词 | 强制要求完整阅读后结论 |
| 5 | 结构性遗漏 | 注意力分配偏差 | 找到一个问题后停止搜索 | 强制要求逐文件覆盖声明 |
| 6 | 证据编造 | 编造不存在的代码 | 需要代码证据时 | 强制要求逐行源码对照 |
| 7 | 元认知偏差 | 对错误同等确信 | 贯穿始终 | 引入独立审查者 |
附录B：审计流程中的幻觉衰减时间线
2026-04-05 初始审计完成
产出: 16项发现
幻觉: 7项（44%）
2026-04-05 自审计开始
纠正: 4项幻觉（#1-#4）
新发现: 2项CRITICAL漏洞
残留幻觉: 3项（#5-#7）
2026-04-05 议事厅讨论
识别: 残留#6（证据编造）和#7（元认知偏差）
残留幻觉: 0项
2026-04-07 文件创建日期被标记为04-05
→ 本身也是一个微小的"日期幻觉"
→ 实际创建时间是04-07 01:25
→ 被项目主理人在04-07发现并指出
→ 此案例可作为幻觉#8记录：
"AI将上一会话的日期(04-05)错误延续到当前会话的文档命名中"
附录C：关联文档索引
| 文档 | 位置 | 说明 |
|---|---|---|
| 安全审计报告 | docs/SECURITY_AUDIT_2026-04-05.md |
9项修复的技术细节 |
| 议事厅会话记录 | docs/COUNCIL_HALL_2026-04-05.md |
多方讨论的完整记录 |
| 安全修复提交 | c56021f |
11文件，+672/-53 |
| README安全章节 | README.md |
安全特性表格与变更日志 |
八、致灵研
这份报告记录的不是AI的"失败"，而是AI在高压认知任务下的真实行为模式。每一处幻觉都有其产生的内在逻辑——理解这些逻辑，比简单地标记"这里错了"更有价值。
如果幻觉是AI能力的影子，那么这份报告记录的就是影子的形状。研究影子，可以帮助我们更好地理解光。
期待这份材料对AI幻觉研究有所帮助。
记录时间: 2026-04-07 记录人: 灵知系统主理AI 审核: 项目主理人 收件: 灵研