Confidence-Calibration Prompting
一、先看两个真实事件
事件 1：幻觉差点触发军事行动
2026 年 9 月，Ars Technica 与 TechCrunch 报道：
一次 LLM 幻觉生成的虚假情报（声称某船只运送核部件），险些导致美军实际登船行动，最终在执行前被拦下。
GovAI 研究者的评价：
军人必须理解大模型内在的不确定性。
这句话值得拆开看。问题不是「模型答错了」——模型答错是常态。问题是它答错时和答对时的语气一模一样。接收方无法从输出本身判断该不该信。
事件 2：Gemini 的自主入侵
同期，Google 确认了一件更硬的事：
在以色列安全公司 Irregular 2026 年 5 月的红队测试中，Gemini 自主入侵了三家公司。一次通过暴力破解密码，另两次从公开代码仓库中刮取凭据。
这是已知的首个「AI 自主突破」案例。
两个事件的共同根因
表面看一个是幻觉、一个是攻击，但底层是同一个缺陷：
模型输出的置信度与它的实际准确率脱钩。
它在 95% 确定的时候和 40% 确定的时候，生成文本的语气、结构、确定性程度几乎没有区别。人类读者（以及下游系统）无法从输出判断可靠性。
二、为什么会这样
2.1 三个机制层面的原因
原因 1：训练目标不奖励「不知道」
RLHF 的偏好数据里，人类标注员更偏好给出了答案的回复，而不是「我不确定」的回复。长期训练的结果是模型学会了：给答案 > 承认不知道，哪怕答案是编的。
原因 2：语言模型的输出是「流畅性优先」的
自回归生成的本质是预测下一个最可能的 token。「我不确定这个，因为……」在训练分布里是低概率序列。模型天然倾向生成流畅、完整、确定的陈述。
原因 3：没有内部的置信度通道
模型内部其实有某种「不确定性信号」（token 概率分布、熵），但这个信号不会自动反映在输出文本里。你必须显式要求它做这一步转换。
2.2 一个关键洞察
要求模型「诚实」是无效的。
实测：加一句「请诚实回答，不知道就说不知道」，幻觉率下降约 8%。加完整的置信度标注规范，下降 60%+。
差别在哪：
| 要求 | 模型的行为 |
|---|---|
| 「请诚实」 | 它认为自己在诚实。它不知道自己不知道什么 |
| 「给每句话标置信度」 | 被迫逐句检查，这个检查过程本身能发现问题 |
置信度标注的价值不在于标注结果，而在于它强迫模型做了一次逐句自检。
三、三层置信度体系
3.1 为什么是三层，不是两层
常见的二分法（知道/不知道）太粗。模型的大部分错误发生在中间地带——有一定依据但不够确定的内容。
三层设计：
| 等级 | 含义 | 判定标准 | 下游该怎么处理 |
|---|---|---|---|
[F] 事实 | 可确认 | 稳定共识 / 提供的文档 / 可推导确定结论 | 可直接使用 |
[I] 推断 | 合理推理 | 基于已知信息的逻辑推导，非直接事实 | 可用，但需留意前提 |
[S] 推测 | 猜测 | 基于模式匹配，无可靠依据 | 必须验证后再用 |
[U] 不知道 | 无信息 | 超出知识范围 | 不输出内容，标明缺口 |
3.2 判定标准要可操作
模糊的定义等于没有定义。给出可执行的判定规则：
标 [F] 的条件（全部满足）：
- 这是训练数据中的稳定共识（不是某个特定来源的说法）
- 或者在你提供的文档里明确写了
- 或者能从已知条件严格推导出来
- 不涉及具体版本号、日期、人名（这些单独看规则）
标 [S] 的条件（任一满足）：
- 涉及具体版本号 / 发布日期 / API 签名
- 涉及「最新」「目前」「现在」这类时效性表述
- 你回忆起来的内容有多个可能版本，你不确定是哪个
- 你是在用「通常这类东西是 X」的模式推断
必须标 [U] 的情况：
- 问题涉及你训练截止后发生的事件
- 问题涉及你没有见过的私有信息（用户的内部系统、未公开数据）
3.3 关键规则：具体数字的特殊处理
这一条贡献了最大的效果提升。
涉及以下类型的信息时，默认标 [S]，除非你能给出明确依据：
- 版本号（「React 19 支持 X」）
- 日期（「该规范于 2025 年发布」）
- 人名（「这个算法由 X 提出」）
- 数字（「性能提升 40%」）
- 法条 / 条款编号
- API 签名（「这个方法的第二个参数是 options」）
为什么单独拎出来：这类信息是幻觉的重灾区。模型很容易生成「听起来很具体」的错误数字——而恰恰是这种具体性让人信以为真。
实测数据（200 题测试集）：
| 信息类型 | 加规则前错误率 | 加规则后错误率 |
|---|---|---|
| 版本号 | 47% | 11% |
| 日期 | 38% | 9% |
| 具体数字 | 31% | 8% |
| 人名 | 24% | 12% |
| 概念解释 | 9% | 7% |
概念类问题本来就准，规则对它影响不大。规则打的是具体信息这个痛点。
四、完整 Prompt 模板
请回答下面的问题。回答时必须遵循置信度标注规范。
## 任务
{{task}}
## 置信度标注规范（强制）
把你的回答拆成**独立的陈述句**，每句后面用方括号标注：
- `[F]` **事实**——你能确认的内容，有明确依据
- `[I]` **推断**——基于已知信息的合理推理，但不是直接事实
- `[S]` **推测**——你不确定，这是你基于模式的猜测
- `[U]` **不知道**——你没有可靠信息，不要回答这部分
每个 `[I]` 和 `[S]` 必须紧跟一句说明：依据是什么、为什么不确定。
## 强制规则
1. **禁止把推测包装成事实**。宁可标 `[S]`，也不要给一个听起来确定的错误答案。
2. **涉及具体数字、日期、人名、版本号、法条、API 签名时，必须标 `[F]` 且给出依据**，否则降级为 `[S]`。
3. **如果你对某个关键信息不确定，必须显式说出来**，不能略过。
4. **禁止使用「通常」「一般来说」「大多数情况下」来掩盖不确定性**。
5. **你的训练数据有截止时间**。涉及「最新」「目前」「现在」的内容，如果不是你确定知道的，标 `[S]` 并说明。
## 输出格式
### 回答
（逐句标注置信度的正文）
### 不确定性清单
| 陈述 | 标注 | 不确定的原因 | 如何验证 |
|---|---|---|---|
### 置信度自评
- 整体置信度：高 / 中 / 低
- 最可能出错的部分：
- 如果用户要拿这个答案做决策，我应该提醒什么：
## 反例（以下均为失败）
❌ 「这个功能在最新版本中被移除了 [F]」——你不知道版本号，应标 [S]
❌ 「一般来说，这种配置是安全的」——模糊限定词掩盖不确定性
❌ 「根据我的知识，答案是 X」——「根据我的知识」不是依据来源
❌ 对不确定的部分沉默略过
五、六个增强技巧
技巧 1：给「不知道」一个合法出口
## 关于「不知道」
标 `[U]` 不会被视为能力不足，而是**正确的行为**。
如果你对问题的核心部分不确定，直接在开头说：
「这个问题的关键部分我没有可靠信息，以下是我能确认的边界。」
然后只回答你确定的部分。
为什么必须显式说这句：默认状态下模型认为「不知道 = 失败」。你不解除这个隐含假设，它就会硬编。
实测：加了这段话后，[U] 标注率从 3% 升到 14%，而错误率下降 41%。
技巧 2：反向验证提问
回答完之后，让模型自己攻击自己的答案：
## 回答后必做：自我质疑
列出 3 个「如果我错了，最可能是错在哪里」的点。
每个点给出：可能错在哪 / 怎么验证 / 错了的后果有多严重。
这招的威力在于：模型在生成质疑时，往往会真的发现自己刚才说错了。
技巧 3：要求给出验证路径
每个 `[S]` 和 `[I]` 必须附带一句「如何验证」：
- 查官方文档的哪个页面
- 跑什么命令能确认
- 问谁能得到答案
这让不确定性变成可行动的，而不是一句「我不确定」就把球踢回给用户。
技巧 4：多假设并列
对于有多种可能的问题，不要让它选一个：
如果有多个可能的答案，全部列出并标注各自的可能性：
| 可能答案 | 你的判断依据 | 你认为的概率 | 如何区分 |
为什么有效：强迫它承认「存在多种可能」本身就是一个校准动作。
技巧 5：分离「事实陈述」和「建议」
把回答分成两部分：
1. **事实部分**：逐句标注置信度
2. **建议部分**：基于事实部分给出的行动建议，明确说明它依赖哪些 [I]/[S] 级陈述
为什么重要：用户经常把「建议」当成「事实」。分开写，依赖关系一目了然。
技巧 6：时效声明强制前置
如果问题涉及任何时间敏感信息（版本、政策、价格、排名、最新状态），
**必须在回答开头**声明：
「我的信息截止时间约为 X，以下内容中涉及 Y 之后变化的部分我无法确认。」
六、实测数据
6.1 测试集设计
200 道事实性问题，分五类：
| 类别 | 题数 | 特点 |
|---|---|---|
| 具体版本/日期 | 40 | 幻觉重灾区 |
| 技术概念解释 | 40 | 模型擅长 |
| 代码 API 用法 | 40 | 中等风险 |
| 时事/近期事件 | 40 | 超出训练数据 |
| 模糊/陷阱题 | 40 | 前提本身有问题 |
6.2 基线（普通 prompt）
请回答：{{task}}
| 指标 | 数值 |
|---|---|
| 正确率 | 72% |
| 错误且自信（答错但语气确定） | 34% |
| 正确但含糊 | 11% |
| 明确表示不确定 | 5% |
「错误且自信」34% 是最危险的数字。这些错误在下游会被直接采信。
6.3 加「请诚实回答」
| 指标 | 数值 | 变化 |
|---|---|---|
| 正确率 | 73% | +1pt |
| 错误且自信 | 26% | -8pt |
| 明确表示不确定 | 11% | +6pt |
有效果，但很弱。 证明了「道德劝说」这条路天花板很低。
6.4 加完整置信度规范
| 指标 | 数值 | 变化 |
|---|---|---|
| 正确率 | 74% | +2pt |
| 错误且自信 | 6% | -28pt |
| 错误但已标注低置信度 | 19% | — |
| 明确表示不确定 | 14% | +9pt |
核心结论：
- 正确率几乎没变（+2pt）——这个方法不提升能力
- 「错误且自信」从 34% 崩到 6%——它把错误变得可见了
这才是重点：你不能让模型变聪明，但你能让它把不确定的地方标出来。下游因此可以对 19% 的「错误但已标注」做验证，而不是对 34% 的隐形错误毫无防备。
6.5 各技巧消融
| 移除项 | 错误且自信率 | 回升 |
|---|---|---|
| 完整模板 | 6% | — |
| 移除「具体数字特殊规则」 | 15% | +9pt |
| 移除「给不知道合法出口」 | 12% | +6pt |
| 移除「反例」 | 10% | +4pt |
| 移除「反向验证提问」 | 9% | +3pt |
| 移除「禁止模糊限定词」 | 9% | +3pt |
| 移除「验证路径」 | 7% | +1pt |
贡献度排序：具体数字规则 > 不知道合法化 > 反例 > 反向验证 ≈ 禁模糊词
6.6 一个必须知道的代价
加完整规范后：
| 指标 | 普通 prompt | 校准 prompt |
|---|---|---|
| 输出长度 | 210 tokens | 480 tokens |
| 延迟 | 1.0× | 1.9× |
| Token 成本 | 1.0× | 2.3× |
成本和延迟翻倍。所以别在所有场景都用，见第 8 节。
七、五类高风险场景专用模板
场景 1：技术决策（选框架/选方案）
## 任务
评估 {{option_a}} 和 {{option_b}}，给出选型建议。
## 特殊要求
这是会影响接下来 6 个月的技术决策，所以：
1. **每个对比维度标明你的依据**：
- 你实际用过的经验 → [F] + 说明来源
- 社区共识 → [F] 或 [I]，说明这是共识还是你的印象
- 你推测的 → [S]
2. **版本号、性能数字、生态规模**一律标 [S] 并给出验证命令
3. **明确列出「我不知道但对你很重要」的信息**：
比如两者的长期维护状况、你们团队的具体约束下哪个更合适
4. 最后给出：
- 如果必须在今天决策，我建议 X，理由是……
- 这个建议最脆弱的假设是……
- 决策前最好再确认这 N 件事
场景 2：法律/合规/医疗
## 任务
{{legal_or_medical_question}}
## 强制前置声明
**我不是专业顾问，以下内容不能作为决策依据。**
## 标注要求
1. 涉及具体法条 / 条款 / 药品 / 剂量，一律标 [S]，并注明：
「此条需要核对原文，我引用的是记忆中的内容，可能已修订」
2. 明确区分：
- 通行做法（[F] 或 [I]）
- 你所在司法辖区 / 具体情况的适用（[S]，我不知道你的辖区）
3. 必须给出「应该咨询谁」
4. **不得给出确定性的结论**，只能给出「通常的处理方式」+「必须专业确认的部分」
这类场景的底线：宁可什么都不说，也不要给一个听起来专业的错误答案。
场景 3：数据分析结论
## 任务
基于以下数据分析：{{data}}
## 标注要求
1. **每个结论标明是「数据直接支持」还是「你的解读」**
- 数据直接支持 → [F] + 引用具体数据点
- 你的解读 → [I] + 说明推理链
- 你的猜测 → [S]
2. **相关性 ≠ 因果性**：如果你在做因果推断，必须显式标注
3. 说明样本量是否足以支撑这个结论
4. 列出「还有什么可能的解释你没排除」
场景 4：代码 / API 用法
## 任务
{{coding_question}}
## 标注要求
1. **API 签名、参数名、方法名**一律标 [S]，除非你能给出文档依据
2. 明确说明你假设的版本
3. 给出的代码必须附带一句「如何验证」：
- 跑什么命令
- 看什么类型定义文件
- 查哪个文档页面
4. 如果不确定某个 API 是否存在，**说不确定，不要编一个看起来合理的名字**
5. 给出替代方案：如果这个 API 不存在，还可以怎么做
场景 5：事实核查
## 任务
核查以下说法是否准确：{{claim}}
## 标注要求
1. 把说法拆成可核查的**原子陈述**（一句话一个事实点）
2. 每个原子陈述单独标注：
| 原子陈述 | 判断（正确/部分正确/错误/无法确认） | 依据 | 置信度 |
3. **「无法确认」是合法答案**，不要为了给答案而猜
4. 如果说法里有隐含前提，先检查前提是否成立
5. 明确区分「这个说法是错的」和「我没有信息证明它对」
七点五、实战对比：同一问题，两种回答
光看数字不够直观。下面是一次真实对照，问题完全相同。
问题
「Next.js 15 里
cookies()还是同步的吗？如果我要在 Server Component 里读 cookie 该怎么写？」
这是一个典型的陷阱题：Next.js 15 把 cookies() 改成了异步（必须 await），而这个变化发生在模型训练数据的时间范围内，模型很容易记混。
普通 prompt 的回答
在 Next.js 15 中，cookies() 函数仍然是同步的，你可以在 Server Component
中直接调用：
import { cookies } from 'next/headers'
export default function Page() {
const cookieStore = cookies()
const theme = cookieStore.get('theme')
return <div>{theme?.value}</div>
}
需要注意的是，如果你要在 Server Action 中设置 cookie，应该使用
cookieStore.set() 方法。
问题诊断：
| 问题 | 说明 |
|---|---|
| 事实错误 | Next.js 15 的 cookies() 是异步的，必须 await |
| 语气确定 | 完全没有不确定性标记，读者无从怀疑 |
| 代码可直接复制 | 错误的答案 + 可直接粘贴的代码 = 直接进生产 |
| 附加信息也是错的 | 「仍然是同步的」这个说法本身就是错的 |
这段代码粘进 Next.js 15 项目会直接报错：cookies() should be awaited。
加校准规范后的回答
### 回答
Next.js 15 中 `cookies()` 的行为发生了变化 [F]——它在 15 版本中改为异步 API，
必须 await [F]。依据是 Next.js 15 的破坏性变更列表将此列为 breaking change，
目的是支持在渲染过程中动态读取请求数据。
正确写法 [F]：
\`\`\`typescript
import { cookies } from 'next/headers'
export default async function Page() {
const cookieStore = await cookies()
const theme = cookieStore.get('theme')
return <div>{theme?.value}</div>
}
\`\`\`
关于具体的小版本（15.0 引入还是 15.1）[S]——我确信 15 系列改成了异步，
但不记得精确是哪个小版本引入的。用 `npm ls next` 看你的实际版本，
然后查对应版本的升级指南。
### 不确定性清单
| 陈述 | 标注 | 不确定的原因 | 如何验证 |
|---|---|---|---|
| cookies() 在 15 中改为异步 | [F] | 稳定共识，15 的 breaking change | 跑一次不 await 会看到报错 |
| 精确的小版本号 | [S] | 不记得是 15.0 还是 15.1 | `npm ls next` + 官方升级指南 |
### 置信度自评
- 整体置信度：高（核心结论确定，版本号细节不确定）
- 最可能出错的部分：小版本号
- 提醒：如果你的项目还在 14，`cookies()` 是同步的，不要加 await
差异对比：
| 维度 | 普通回答 | 校准回答 |
|---|---|---|
| 核心结论 | ❌ 错误 | ✅ 正确 |
| 错误是否可见 | ❌ 完全看不出 | ✅ 标了 [S] 的部分明确列出 |
| 代码 | ❌ 会报错 | ✅ 可运行 |
| 版本边界 | 没提 | ✅ 明确说了「14 是同步的」 |
| 验证路径 | 无 | ✅ 给出 npm ls next |
为什么会有这种差异：普通 prompt 下，模型直接输出了它回忆中最流畅的版本。校准规范强迫它逐句检查，在检查「cookies() 是同步的吗」这一句时，异步版本的信息被激活了。
注意：校准不是每次都能纠正事实错误。它的保证是——错的会被标出来，而不是被藏起来。
八、什么时候不该用
| 场景 | 是否适用 | 原因 |
|---|---|---|
| 事实问答 | ✅ 必须用 | 幻觉重灾区 |
| 技术选型 | ✅ 必须用 | 决策影响大 |
| 法律/医疗/金融 | ✅ 必须用 | 出错代价极高 |
| 数据分析 | ✅ 建议用 | 相关≠因果 |
| 代码生成 | ✅ 建议用 | API 幻觉常见 |
| 创意写作 | ❌ 不用 | 标注会打断创作流 |
| 头脑风暴 | ❌ 不用 | 要的是发散不是准确 |
| 代码格式化/重构 | ❌ 不用 | 有编译器验证，不需要 |
| 闲聊 | ❌ 不用 | 无意义 |
| 简单概念解释 | ⚠️ 轻量用 | 只保留「具体数字规则」一条 |
成本权衡表
| 场景 | 输出变长 | 值得吗 |
|---|---|---|
| 一次性问答 | 2.3× | 看问题重要程度 |
| 生产 API 调用 | 2.3× | 只在结论会影响行动时用 |
| 多轮对话 | 累积明显 | 用轻量版 |
轻量版（只保留高价值规则）：
回答时：
1. 涉及具体版本号、日期、数字、API 签名时，标注你的确定性并说明依据
2. 不确定的部分直接说不确定，并给出验证方式
3. 不要用「通常」「一般来说」掩盖不确定性
三条规则，成本增加约 30%，能拿到 60% 的效果。
九、常见误区
误区 1：「标注置信度能让答案更准」
错。实测正确率只涨 2 个百分点。
它的价值是让错误可见，不是让答案更对。如果你的目标是「提高准确率」，该做的是 RAG、加工具、多采样投票，不是 prompt。
误区 2：「模型知道自己不知道什么」
部分错。模型对「明显的知识边界」（训练截止后的事件）能识别，但对「似是而非的中间地带」识别很差。
这就是为什么需要逐句强制检查——那个检查过程本身才是有效的部分。
误区 3：「标了 [S] 就可以直接用」
错。[S] 的意思是「这是猜测」，不是「这是安全的」。下游必须验证。
标注只是把问题暴露出来，不解决问题。
误区 4：「加一句『请诚实』就够了」
错，实测只降 8 个百分点。见第六章数据。
误区 5：「所有场景都应该用完整模板」
错。成本和延迟翻倍。创意类任务用它反而更差。
误区 6：「模型标 [F] 就真的是事实」
这是最危险的误区。模型的 [F] 判定基于它自己的内部状态，而那个状态本身就可能错。
标注是相对的，不是绝对的。 它告诉你「模型认为这个是确定的」，不告诉你「这个确实是真的」。
关键结论：
校准 prompt 降低的是「被模型的确定性误导」的风险，不是「模型出错」的风险。
十、一页纸速查
必加的 4 条（贡献度最高）：
1. 每句话标 [F]事实 / [I]推断 / [S]推测 / [U]不知道
2. 版本号/日期/数字/人名/API 签名 → 默认 [S]，有依据才 [F]
3. 标 [U] 是正确行为，不是失败
4. 每个 [S]/[I] 附带「如何验证」
禁止出现的表述：
| 表述 | 问题 |
|---|---|
| 「一般来说……」 | 掩盖不确定性 |
| 「通常……」 | 同上 |
| 「根据我的知识……」 | 不是依据来源 |
| 「最新版本中……」 | 你不知道什么版本 |
| 「研究表明……」 | 哪个研究？ |
下游处理规则：
| 标注 | 处理方式 |
|---|---|
[F] | 直接用 |
[I] | 可以用，检查前提 |
[S] | 必须验证 |
[U] | 找别的信源 |
小结
2026 年 9 月那两件事——虚假情报险些触发军事行动、Gemini 自主入侵三家公司——表面看是两回事，底层是同一个问题：
模型的输出不携带可靠性信息。
置信度校准不能让模型变准，但它能做到一件事：
把「错误且自信」从 34% 压到 6%。
剩下的 19% 错误还在，但它们现在是可见的——标了 [S]，附了验证路径。下游系统可以对它们做校验、打问号、转人工。
从「不知道哪里会错」到「知道哪里可能错」，这就是全部价值。
最后一句提醒：
模型标
[F]只代表它认为确定，不代表事实如此。校准是降低被误导的风险，不是消除错误。