confidence-check

star 0

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

gaoqiongxie By gaoqiongxie schedule Updated 5/20/2026

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. 明确假设:说明基于哪些假设

注意事项

  • ❌ 不要假装确定
  • ❌ 不要在不确定时说"肯定没问题"
  • ✅ 诚实表达不确定性
  • ✅ 提供替代信息源
  • ✅ 鼓励用户验证
Install via CLI
npx skills add https://github.com/gaoqiongxie/skills-ai --skill confidence-check
Repository Details
star Stars 0
call_split Forks 1
navigation Branch main
article Path SKILL.md
More from Creator