幻觉问题是大模型的原罪，也是 AI 应用落地的头号杀手。每隔一段时间就会有工程师满怀信心地向你展示他们的"防幻觉 Prompt"，然后在生产环境里被用户截图打脸。Prompt 不是没用，但它根本治不了幻觉——因为幻觉不是"说话方式"的问题，而是"生成机制"的问题。这篇文章讲清楚幻觉的根源，然后告诉你 Skills 能做什么、怎么做。

一、幻觉的根源与 Prompt 的无力

大模型幻觉的本质，是一个概率生成系统在没有足够约束的情况下，选择了"听起来合理"而非"实际正确"的输出。

语言模型被训练成"预测下一个 token"，它的目标函数是最大化序列的概率，而不是最大化输出的准确性。当你问它一个训练数据里没有明确答案的问题，它不会说"我不知道"——因为训练数据里很少出现这样的句子——它会生成一个"听起来像答案"的序列。这是架构决定的行为，不是 bug，是 feature。只不过是一个在需要准确性时完全帮倒忙的 feature。

1.1 为什么"让模型引用来源"的 Prompt 大概率失效

你当然可以在 Prompt 里写"你的每条陈述必须附上来源"。模型会照做——它会生成看起来像来源的文字。问题是，这些"来源"可能是模型凭借训练数据里的模式虚构出来的：URL 格式正确但页面不存在，论文标题真实但作者和结论是捏造的，新闻报道看起来完整但实际上发生在不同时间地点。Prompt 告诉模型"应该做什么"，但它管不了"模型能做到什么"。当模型不具备某条事实的真实来源时，它会用生成能力来填补这个空缺——而且填得天衣无缝，你不去真的点链接就发现不了。

1.2 Skills 能做什么：从"请求"变成"机制"

Skills 的防幻觉能力，来自于它把"请求"变成了"机制"。通过 SKILL.md 里的结构化约束，你可以强制 Agent 在回答前先执行事实核查步骤，强制它在没有可验证来源时输出"不确定"而非继续生成，强制它把来源的验证结果作为输出的前置条件。这不是在祈祷模型更诚实，而是在改变它的执行路径。

当然，Skills 也不是万能的。如果你的 Agent 根本没有访问外部知识库或搜索工具的能力，Skills 也无法凭空变出真实来源。Skills 的作用是"把你拥有的工具用得更严格、更结构化"，而不是创造你没有的能力。明确这一点，是避免对这个模板期望过高或过低的关键。

二、防幻觉 Skill 的设计原则

一个真正有效的防幻觉 Skill，需要在设计层面解决三个问题：如何强制事实核查、如何处理"无法核查"的情况、如何输出可验证的来源。这三个问题缺一不可，只解决其中一个或两个，都会留下被幻觉钻空子的漏洞。

2.1 原则一：核查前置，不允许跳过

事实核查必须是输出的前置条件，而不是可选步骤。在 SKILL.md 里，这意味着把核查逻辑写成独立的 Step，并在 Constraints 里明确声明"未完成核查的内容不得输出"。给模型留任何可以跳过核查的"快捷方式"，它就会在问题"看起来很简单"的时候走捷径——这是语言模型的本能，不是道德问题。

2.2 原则二：三种来源引用模式，按场景选择

来源引用有三种设计模式，各有适用场景，选错了不仅影响可读性，还会影响核查的严格程度。

内联引用模式适合实时搜索场景：每条关键陈述后面紧跟来源标注，格式为[陈述内容][来源]。读者一眼就能看到哪句话有来源支撑，核查成本最低。缺点是输出篇幅增大，读起来有点学术论文感，不适合需要流畅阅读的输出场景。

脚注引用模式适合长报告或分析类输出：正文里用编号标注 [1]，文末统一列出来源清单。输出更易读，但验证时需要来回跳转，适合用户愿意花时间核查的场景。

来源列表模式适合摘要类输出：正文不嵌入引用，结尾专门有一个"信息来源"区块。最简洁，但粒度最粗——读者无法知道哪条具体陈述对应哪个来源，容易被滥用成"摆设来源"而非真正的核查依据。

2.3 原则三：不确定性必须显式输出

这是最多工程师忽视的设计点。当 Agent 找不到可验证的来源，或者来源之间存在矛盾时，正确的做法不是"选一个说"，而是显式输出不确定性：标注 [无可验证来源]、描述矛盾的存在、建议用户自行核查。

在 Skill 里强制定义"不确定时的输出格式"，是防幻觉设计里最有效的单一措施。模型有了明确的"不确定"输出模板，就不再需要用幻觉来填补空白——它知道"我可以说我不知道"，而且有一个标准的方式来说。

三、完整模板：强制事实核查 + 来源引用

下面是完整的防幻觉 Skill 模板，设计目标是：不核查，不输出；有疑问，显式标注。

---
name: fact-checked-response
version: "1.0.0"
description: "对用户查询执行强制事实核查，所有关键陈述必须附有可验证来源，无法核查时显式标注不确定性而非继续生成"
author: "Research Automation Team"
triggers:
  - "帮我查一下"
  - "这个说法准确吗"
  - "事实核查"
  - "请核实"
  - "来源是什么"
tools_required:
  - web_search
  - knowledge_base_query
input_schema:
  query:
    type: string
    required: true
    description: "需要核查的问题或陈述"
  citation_style:
    type: enum
    values: ["inline", "footnote", "source_list"]
    default: "inline"
    description: "来源引用格式"
  confidence_threshold:
    type: number
    default: 0.8
    description: "可信度阈值（0-1），低于此值的陈述必须标注不确定性"
output_schema:
  verified_content:
    type: string
    description: "经过事实核查的回答正文，包含来源标注"
  sources:
    type: array
    description: "所有引用来源的结构化列表"
    items:
      source_id: string
      title: string
      url: string
      accessed_at: date
      credibility_score: number
  unverified_claims:
    type: array
    description: "无法验证的陈述列表及原因"
    items:
      claim: string
      reason: string
  overall_confidence:
    type: number
    description: "整体回答的可信度评分（0-1）"
---

## Overview

本 Skill 对所有输出执行强制事实核查流程。核心原则：先核查，再输出；无来源，不断言；有矛盾，显式说明。适用于需要高准确性的信息查询、内容核实、研究辅助等场景。

本 Skill 不适用于：纯创意写作、头脑风暴类任务、用户明确表示不需要核查的场景。在这些场景下请使用不含强制核查约束的通用对话 Skill。

## Steps

### Step 1: 问题分解与核查计划制定

接收用户查询后，首先将其分解为若干需要独立核查的事实性子命题，并区分以下三种类型：可核查事实（Checkable Fact，有客观真值的陈述，如时间、数量、事件、人物）；分析性判断（Analytical Claim，基于事实的推断，在输出中标注"分析性观点"）；不可核查内容（Unverifiable，预测、假设、主观评价，直接标注无需核查）。

生成核查计划，列出每个可核查子命题对应的核查工具和预期来源类型。不可核查和分析性内容跳过 Step 2-3，直接进入 Step 4 输出，但必须在输出中显式标注其类型。

on_error:
  strategy: continue
  note: "问题分解失败时，整体作为单一命题处理，不中断流程"

### Step 2: 多源并行核查

对所有可核查子命题，并行执行以下核查动作。

动作一，Web 搜索核查：使用 web_search 工具搜索每个命题，收集至少2个独立来源。来源须满足：可公开访问、发布时间在查询相关时间窗口内、来自非用户输入的第三方。

动作二，知识库核查（如可用）：调用 knowledge_base_query 工具在内部知识库中检索相关内容，记录匹配程度和最近更新时间。

动作三，来源交叉验证：对收集到的多个来源进行交叉验证。多个独立来源陈述一致，置信度标记为高；来源之间存在矛盾，标记为"存在争议"；只有一个来源，标记为"单一来源，待验证"。

on_error:
  strategy: mark_unverifiable
  message: "核查工具调用失败，该命题标记为[无法核查]，不得在正文中以肯定语气输出"

### Step 3: 可信度评分

对每条子命题，根据以下维度计算可信度评分（0-1）：来源数量（至少2个独立来源获得满分的50%）；来源权威性（官方机构、学术期刊、主流媒体优先）；来源时效性（信息是否在有效时间窗口内）；来源一致性（多源一致加分，存在矛盾扣分）。

低于 confidence_threshold（默认0.8）的命题，在 Step 4 的输出中必须附带不确定性标注，不允许通过任何方式绕过这个约束。

### Step 4: 结构化输出生成

根据 citation_style 参数，用对应格式组装最终输出。

**inline 格式示例：**

大语言模型的参数量在2023年后快速增长¹，GPT-4 的参数量据估计超过万亿²，但 OpenAI 从未官方确认具体数字。⚠️ [无可验证来源]

¹ 来源：MIT Technology Review, 2023-11-15
² 来源：SemiAnalysis, 2023-07-10（单一来源，待验证）

**footnote 格式示例：**

大语言模型的参数量在2023年后快速增长[1]，GPT-4 的参数量据估计超过万亿[2]，但 OpenAI 从未官方确认具体数字。

[1] MIT Technology Review, "The race to build bigger AI models", 2023-11-15
[2] SemiAnalysis, "GPT-4 Architecture", 2023-07-10（单一来源）

**source_list 格式示例：**

[正文不含内联引用标注，仅在结尾列出]

信息来源：
- MIT Technology Review (2023-11): 模型规模增长趋势
- SemiAnalysis (2023-07): GPT-4 参数量估算（单一来源）

对于每条无法验证的命题，统一使用以下格式，不得自行发挥：

> ⚠️ [无可验证来源] {原始陈述}
> 原因：{无来源 / 来源存在矛盾 / 来源过期 / 核查工具不可用}
> 建议：用户可通过 {具体方式} 自行核查

on_error:
  strategy: fail_safe
  message: "输出生成失败，返回已完成核查部分的摘要，注明[部分内容未完成核查]"

### Step 5: 输出质量自检

在最终输出之前，执行自检清单：每条关键事实陈述是否有来源标注？是否存在未标注的低可信度命题？unverified_claims 列表是否完整？overall_confidence 评分是否反映实际核查质量？

如果自检发现遗漏，返回 Step 4 补充。最多循环2次；超过后输出当前最优版本，并在开头附注"[部分内容待补充核查，已完成核查内容可信]"。

## Constraints

- 绝对禁止：在没有来源支撑的情况下，以肯定语气输出事实性陈述
- 所有来源必须在输出时同步填充 sources 数组，不得正文里有引用但 sources 为空
- 置信度低于0.5的命题，无论如何都必须标注 ⚠️，不允许通过调高 confidence_threshold 参数绕过
- 来源不得包含：用户在本次对话中提供的内容（自引用）、无法公开访问的 URL、发布时间不可确认的内容
- overall_confidence < 0.7 时，必须在输出开头注明整体可信度评分，不得隐藏

## Uncertainty Handling

当遇到以下情况，使用对应的标准输出格式，不得自行发挥措辞：

无来源可用：
> ⚠️ [无可验证来源] 该陈述无法通过可访问的公开来源进行核查。

来源之间存在矛盾：
> ⚠️ [来源存在争议] 不同来源对此存在矛盾陈述：{来源A} 认为……，{来源B} 认为……，当前无法确定哪个更准确。

信息可能已过期：
> ⚠️ [来源时效性存疑] 该信息的最新可验证来源发布于 {日期}，建议核查是否有更新版本。

核查工具不可用：
> ⚠️ [核查工具不可用] 本次无法执行完整事实核查，以下内容基于模型训练数据，请自行验证。

3.1 模板使用说明与常见误区

这个模板有两个参数值得特别关注。confidence_threshold 默认值 0.8 在大多数场景下是合适的，但在医疗、法律等高风险领域应该提高到 0.9 以上，甚至直接把低可信度陈述从输出中删除而不是标注。反过来，在一些探索性研究场景里，0.6 就够了，更严格的阈值会让 Agent 有一半内容都打上警告标，输出变得无法使用。阈值不是越高越好，而是要匹配你的应用场景的风险容忍度。

citation_style 的选择经常被当成"样式偏好"处理，但实际上它影响的是整个核查流程的粒度。inline 模式要求每条陈述独立有来源，核查粒度最细，生成成本也最高。source_list 模式只需要整体有来源，速度最快，但来源和陈述的对应关系模糊，有被滥用的风险——实践中有些工程师把它用成了"在结尾加一个来源列表就算核查了"。这是模板被用坏了，不是模板设计有问题，但作为模板设计者你需要在文档里写清楚这个坑。

四、总结

防幻觉不是让模型"更诚实"的问题，而是让执行路径"更受控"的工程问题。Skills 通过强制核查步骤、显式不确定性输出和来源验证机制，把"祈祷模型不胡说"变成了"系统不给模型胡说的机会"。

当然，这个模板需要 Agent 具备实际的搜索和检索工具。如果你的 Agent 只能依赖训练数据，防幻觉 Skill 能做的也只是"更优雅地承认不确定性"——但即使只是这一点，也比满口自信地胡说强得多。承认不知道，是比知道更难教给模型的能力，而 Skills 机制让这件事变得可操作。