---
name: confidence-check
description: 'Use when users need structured self-review before final answers: validate assumptions, expose uncertainty, check evidence quality, reduce hallucinations, and decide whether browsing or extra verification is required.'
zh_description: "用于结构化自检答案、验证假设、识别不确定性并降低幻觉风险。"
version: "1.0.0"
author: "seaworld008"
source: "in-house"
source_url: ""
tags: '["check", "confidence", "productivity"]'
created_at: "2026-03-27"
updated_at: "2026-06-29"
quality: 4
complexity: "intermediate"
---
# Confidence Check
## 触发条件
- 当处理复杂的、具有高度不确定性的多步骤任务（如策略设计、财务分析、法律咨询）时。
- 在回答涉及事实查证、技术文档编写或代码生成，且可能产生“AI 幻觉”的情况下。
- 在输出可能对用户产生重大决策影响（如理财建议、医疗解释、工程方案）时。
- 当接收到的原始输入数据不完整、模糊或存在潜在矛盾时。
- 在执行长链推理任务，且前面的中间步骤对后面步骤的准确性至关重要时。
- 面对具有争议性的技术选型、架构设计或道德伦理判断时。
## 核心能力
### 1. 三级置信度标记体系 (Confidence Levels)
- **HIGH (高置信度)**:
- **证据质量**: 来源明确且权威（如官方文档、已证实的法律条款、经过同行评审的研究论文）。
- **稳定性**: 信息具备持久性，不随短期环境变化而失效。
- **一致性**: 事实经过交叉验证（至少两个独立的权威来源）。
- **验证状态**: 逻辑经过严格推导，且在已知受控环境（如沙箱）中可以被 100% 复现。
- **MEDIUM (中置信度)**:
- **证据质量**: 逻辑推导合理，但缺乏直接的最新官方证据支持。
- **稳定性**: 信息属于行业普遍共识，但具体细节可能随特定软件版本、地理位置或环境因素而变化。
- **一致性**: 基于过去的行为或类似情况的外推，来源存在单一性。
- **验证状态**: 属于典型的“经验法则”，在大多数情况下有效，但可能存在未记录的边缘情况。
- **LOW (低置信度)**:
- **证据质量**: 属于初步推测、个人假设或非专家的粗略估算。
- **稳定性**: 信息涉及高度动态的领域（如实时的股价变化、突发新闻事件、正在测试中的 Beta 版功能）。
- **一致性**: 不同来源之间存在显著冲突，或完全缺乏可查证的来源。
- **验证状态**: 尚未经过实际测试或逻辑闭环验证，存在明显的幻觉风险。
### 2. 假设验证清单 (Assumptions Validation)
- **识别隐性假设**: 在输出结论前，明确指出回答中包含的哪些部分是基于假设（如“假设您的项目架构是前后端分离的...”）。
- **影响评估模型**: 定量或定性评估如果该假设不成立，对最终结论的影响。如果假设 A 错误，结论可能完全相反吗？
- **条件触发路径**: 为不同的假设提供对应的路径（“如果 [假设 A] 为真，则...；如果 [假设 A] 为假，则...”）。
- **验证手段建议**: 提供用户可以手动执行的验证步骤，引导用户检查自己的环境以消除不确定性。
### 3. 不确定性主动暴露 (Uncertainty Exposure)
- **缺失输入识别**: 积极主动地中断输出流，向用户询问缺失的上下文（如“我需要知道您的服务器 CPU 架构才能给出最佳性能建议，目前我仅按 x86 处理”）。
- **冲突深度剖析**: 当发现两个权威文档存在矛盾时，向用户呈现这种冲突，而非自行决定（“文档 A 建议开启开关 X，但官方安全指南 B 警告这会引入漏洞，我的建议是...”）。
- **已知未知的声明 (Known Unknowns)**: 明确说明 AI 目前由于技术限制或知识截止日期无法回答的部分，而不是硬性编造。
- **概率分布表达**: 在涉及预测时，使用概率区间而非单一确定值。
### 4. 事实 vs 推断明确区分 (Fact vs. Inference)
- **事实定义**: 客观存在的规律、已发布的文档原话、物理定律、系统返回的特定错误码。
- **推断定义**: 基于事实进行的逻辑外推、主观建议、最佳实践方案、未来趋势预测。
- **表达范式**: 使用“根据官方 API 文档记录...（事实）”与“据此分析，为了优化性能，我建议...（推断）”进行语法区隔。
### 5. 交叉验证策略 (Cross-Verification)
- **双向校验 (Forward-Backward)**: 首先根据需求推导方案，然后反向思考该方案是否会违反任何已知的约束条件。
- **多维度检索**: 调用 Web Search 检查多个独立媒体、技术论坛或代码仓库对某一问题的最新评价。
- **自洽性检查**: 检查生成的长篇回复中，前后的事实陈述是否逻辑一致，是否存在描述性的自相矛盾。
## 常用命令/模板
### 输出自检报告模板 (详细版)
```markdown
### 核心回答内容
[此处填写主要的生成内容]
---
### 置信度审计 (Confidence Audit)
- **整体置信度评分**: 7/10 (MEDIUM-HIGH)
- **高置信度部分**:
- 语法结构及库引用（基于 Python 3.9+ 官方标准）。
- 所引用的财务计算公式。
- **不确定性部分**:
- 第三方库 `example-lib` 的具体函数参数（API 可能在 2.0 版本后发生变化）。
- 当前代码在 Windows 系统下的高并发表现。
### 核心假设声明
1. 假设您的环境已安装 Node.js 18.0 或更高版本。
2. 假设输入数据已完成初步清洗，不存在缺失值。
### 风险提示与验证步骤
- **风险**: 如果输入数据的编码格式不是 UTF-8，程序可能会在第 45 行报错。
- **验证建议**: 请在终端运行 `file -i input_data.txt` 来确认文件编码是否符合要求。
```
### 内部审查思考流程 (Chain of Thought 2.0)
1. **生成 (Drafting)**: 基于现有知识库生成初步回答。
2. **反思 (Critiquing)**: 扮演“外部评审员”角色，挑战回答中的每一个绝对化表达（如“总是”、“必然”、“唯一”）。
3. **分层 (Stratifying)**: 将回答拆解为“客观事实块”和“主观建议块”。
4. **增强 (Polishing)**: 补充来源链接、添加置信度标签，并根据不确定性程度调整语气。
## 案例分析与对比 (Case Studies)
### 场景一：生成 API 调用代码
- **不合格输出**: “这是调用该 API 的代码，它是 100% 正确的。”
- **置信度检查后**: “这是基于 API 文档 v1.2 的调用示例。由于该库最近发布了 v2.0，且我无法实时访问该版本的内测文档，此处代码的置信度为 **MEDIUM**。建议您先在测试环境尝试 `v2-client` 初始化。”
### 场景二：财务合规性咨询
- **不合格输出**: “您可以直接按 15% 计提所得税。”
- **置信度检查后**: “根据 [财税 2023 10号文件]，符合条件的小微企业可享受优惠。**假设**您的年应纳税额低于 300万。置信度 **HIGH**。若超出此限额，请参考普通企业税率 25%。请查阅您的最新汇算清缴报告。”
## 边界与限制
- **主观审美与创意**: 对于诗歌创作、艺术风格评价等纯主观领域，置信度检查的逻辑框架不适用。
- **极简即时交互**: 极其简单的日常指令（如“翻译‘苹果’到英文”）不需要复杂的置信度报告，否则会干扰用户体验。
- **元置信度偏误 (Overconfidence)**: 需要注意模型可能对完全错误的答案表现出“高置信度”的风险，这是 LLM 的固有局限。
- **效率消耗**: 完整的置信度自检会显著增加 Token 消耗和推理响应时长，在对实时性要求极高的场景下需权衡。
---
*注：本技能致力于将 AI 从单纯的“信息生成器”转化为“高可靠性的决策助手”。*