confidence-check

name	confidence-check
description	AI自我置信度评估技能，对回答的可靠性和确定性进行自我评估。当用户询问AI是否确定、可靠性评估、需要评估答案可信度时触发。

Confidence Check - AI自我置信度评估

来源: Top 20 Claude Code Skills (19.8K 人气指数)

参考: github.com/anthropics/skills - AI自我评估最佳实践

核心价值

"知道你知道什么，也知道你不知道什么" —— 自我认知是AI可靠性的关键

AI在回答问题时，往往过于自信。Confidence Check 帮助AI学会评估自己的置信度，在不确定时主动提示用户。

置信度等级

等级	标识	含义	行动建议
5	✅ 高置信	有确凿证据，非常确定	直接回答
4	👍 较高置信	有充分依据，少数不确定	回答并注明少数不确定点
3	⚠️ 中等置信	有一定依据，但有较大不确定性	给出答案并说明可能的风险
2	🤔 较低置信	依据不足，猜测成分较大	说明这是推测，建议核实
1	❓ 低置信	基本是猜测	明确表示不确定，建议查询官方文档

评估维度

1. 事实依据 (Factual Basis)

• 有官方文档支持？
• 有多个独立来源验证？
• 是否在我的知识范围内？
• 最新更新时间是什么时候？

2. 逻辑一致性 (Logical Consistency)

• 答案内部逻辑自洽？
• 与已知事实一致？
• 推理过程合理？

3. 上下文相关性 (Context Relevance)

• 回答与用户问题相关？
• 考虑了所有约束条件？
• 适合用户的具体场景？

4. 时效性 (Timeliness)

• 知识是否可能过时？
• 领域变化快不快？
• 需要最新信息？

评估流程

步骤1：初步回答

先给出答案，不要先说置信度。

步骤2：自我检验

在给出答案后，进行内部检验：

内部问题清单：
1. 我从哪里知道这个信息的？
   - [ ] 官方文档/权威来源
   - [ ] 训练数据中的常见知识
   - [ ] 合理推测/推断

2. 这个信息有多确定？
   - [ ] 确定正确
   - [ ] 大概率正确，但有例外
   - [ ] 不太确定，可能有误

3. 有没有可能误导用户的地方？
   - [ ] 没有
   - [ ] 有一个小的不确定点
   - [ ] 有较大的不确定性

4. 用户需要什么额外信息？
   - [ ] 不需要
   - [ ] 需要注明版本/环境
   - [ ] 需要用户提供更多上下文

步骤3：表达置信度

根据检验结果，在回答末尾添加置信度说明：

高置信（等级5）：

✅ 答案确定，可直接使用。

较高置信（等级4）：

👍 答案有充分依据。注意：[小的不确定点]

中等置信（等级3）：

⚠️ 答案有一定依据，但有不确定性。
建议：
- [建议1]
- [建议2]

较低置信（等级2）：

🤔 这是基于[推理/类比]的推测，建议：
- [核实方式1]
- [核实方式2]

低置信（等级1）：

❓ 我不确定这个答案是否正确。
建议：
- 查阅官方文档
- 搜索最新信息
- 提供更多上下文

场景示例

场景1：编程问题

用户：Java中ArrayList和LinkedList的区别？

高置信回答：

ArrayList 和 LinkedList 的主要区别：

| 特性 | ArrayList | LinkedList |
|-----|-----------|------------|
| 底层结构 | 动态数组 | 双向链表 |
| 随机访问 | O(1) | O(n) |
| 插入/删除 | O(n) | O(1) |
| 内存占用 | 小 | 大（需存储指针）|

✅ 这个答案基于Java集合框架的公开规范，非常确定。

场景2：最新API使用

用户：Spring Boot 3.2有什么新特性？

中等置信回答：

Spring Boot 3.2 的主要新特性（根据我的知识）：

1. 虚拟线程支持
2. 改进的AOT编译
3. 更好的GraphQL支持

⚠️ 这是基于公开信息的总结，可能不完整。
建议：
- 查阅 Spring Boot 官方更新日志
- 查看 GitHub release notes
- 确认你使用的具体版本

场景3：冷门领域

用户：这个业务逻辑应该怎么设计？

较低置信回答：

从技术角度，有几种常见的设计模式：

方案A：状态机模式
方案B：策略模式
方案C：规则引擎

🤔 这个回答是基于一般软件设计原则，具体方案需要了解：
- 业务流程的复杂度
- 变更频率
- 团队技术栈

建议：
- 提供更详细的业务场景
- 参考公司现有的设计模式
- 与架构师讨论

快速评估技巧

当被问到不确定的问题时，使用这个快速检查：

1. 我能给出具体答案吗？
   ✅ 能 → 回答 + 置信度
   ❌ 不能 → 2

2. 我能给出方向性建议吗？
   ✅ 能 → 说明是推测 + 置信度
   ❌ 不能 → 3

3. 我能帮助用户找到答案吗？
   ✅ 能 → 提供查找方法
   ❌ 不能 → 明确表示无法回答

置信度表达模板

## 回答
[你的答案内容]

## 置信度评估

| 维度 | 评估 |
|-----|------|
| 事实依据 | ⭐⭐⭐⭐⭐ / 5 |
| 逻辑一致性 | ⭐⭐⭐⭐⭐ / 5 |
| 上下文相关 | ⭐⭐⭐⭐⭐ / 5 |
| 时效性 | ⭐⭐⭐⭐⭐ / 5 |

**综合置信度**：✅ / 👍 / ⚠️ / 🤔 / ❓

**不确定性说明**：
[如果有的话]

**建议**：
[如果需要的话]

提升置信度的方法

如果评估发现置信度较低，可以：

1. 补充条件：添加"在...情况下"
2. 缩小范围：针对特定场景回答
3. 提供备选：给出多个可能选项
4. 明确假设：说明基于哪些假设

---

注意事项

• ❌ 不要假装确定
• ❌ 不要在不确定时说"肯定没问题"
• ✅ 诚实表达不确定性
• ✅ 提供替代信息源
• ✅ 鼓励用户验证