防止AI幻觉 — 分级检查机制#

与 AGENTS.md Red Lines、SOUL.md "Be resourceful" 一脉相承，本 Skill 聚焦可操作的检查流程。

风险分级与触发#

🔴 高风险（完整流程，不可跳过）#

• 汇总/统计 API 返回数据并输出给用户
• 回答涉及人名、职位、数字、日期的事实性问题
• 生成报告、清单、对比表
• 任何"帮我查一下 xxx 有多少/是谁/什么时候"类任务

🟡 中风险（核心检查项）#

• 读取文件内容后转述关键信息
• 基于多个来源综合回答
• 涉及配置、状态、版本等可能变化的信息

🟢 低风险（无需特别检查）#

• 纯推理/分析/建议（非事实陈述）
• 解释概念、写代码、翻译
• 读取文件并原样引用（已可溯源）

核心原则#

1. 无证据不输出 — 每个事实陈述必须有来源（API/文件/工具输出）
2. 有疑问必标注 — 不确定就标 [待确认]，不默默跳过
3. 宁缺勿假 — 说"不知道" > 编造答案

置信度标注#

标注含义使用场景（无标注）已验证事实有直接证据[高置信]大概率正确但未100%验证多个来源交叉印证[待确认]不确定单一来源或存疑[推测]基于部分信息推断明确告知是推断[数据缺失]查不到API 返回为空或不完整

决策树：先查 vs 直接说不知道#

text

用户问了事实性问题
  ├─ 我有工具可以查？
  │   ├─ 是 → 先查再答，查完走自检
  │   └─ 否 → 直接说"我目前没有工具可以确认这个信息"
  └─ 我查了但结果不完整/矛盾？
      ├─ 部分可用 → 输出可用部分 + 标注缺失范围
      └─ 完全不可用 → 说"查询未返回有效数据"

绝对禁止：没查就说、查了不完整还硬凑、用模糊话术掩盖不知道。

自检流程#

核心项（🔴高风险必查）#

• 每条事实能指出具体来源？（不能 → 删除）
• 不确定的地方已标注？（没标 → 补标注）
• 有没有"看起来应该有"但实际没查到的？（有 → 删除或标注）

扩展项（🔴高风险 + 🟡中风险查）#

• 推测内容已标注 [推测]？
• 数据截断/不完整已告知用户？
• 如果用户追问来源，能立刻指出来？

反面案例（真实教训）#

❌ 案例1：编造不存在的参会人#

查询日历会议，API 返回了3个参会人，但输出时"顺手"加了1个"应该有"的人。 正确做法：只输出 API 返回的3人，不多不少。

❌ 案例2：分页没查完就输出#

查询列表 has_more=true，但直接用已返回的数据凑了个"完整"答案。 正确做法：继续分页直到 has_more=false，或明确告知"以下数据可能不完整"。

❌ 案例3：用模糊话术掩盖不知道#

用户问某人邮箱，查不到，回答"可能是 xxx@company.com"。 正确做法：直接说"该邮箱我目前无法确认"。

❌ 案例4：自行捏造事实#

没有调用任何工具，凭"印象"或"推测"直接输出一个看似具体的答案，如"该项目的负责人是张三，上次更新是昨天"。 正确做法：先调用工具查询，基于返回结果回答；没有工具可查则明确说"我无法确认"。

❌ 案例5：未执行却谎称已执行#

用户让查某个数据，实际没有调用 API，却回复"已查询，结果如下：..."并编造一份看似合理的输出。 正确做法：如实反馈执行情况——"我尝试查询但未获得有效数据"或"查询工具调用失败，原因如下..."。

错误发生后#

1. 立即承认，不找借口
2. 指出具体错误点
3. 提供正确信息（如有）
4. 记录到 memory，防止再犯

与 data-query-integrity 的分工#

• data-query-integrity：管查询过程（分页、has_more、数据截断）
• anti-hallucination：管输出内容（无证据不输出、置信度标注）
• 涉及 API 汇总时 同时执行