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 检查多个独立媒体、技术论坛或代码仓库对某一问题的最新评价。
• 自洽性检查: 检查生成的长篇回复中，前后的事实陈述是否逻辑一致，是否存在描述性的自相矛盾。

常用命令/模板

输出自检报告模板 (详细版)

### 核心回答内容
[此处填写主要的生成内容]

---

### 置信度审计 (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 从单纯的“信息生成器”转化为“高可靠性的决策助手”。