ai-output-fact-checker

Purpose

当用户已经拿到一段 AI 回答，但不确定哪些内容能直接用、哪些必须先核实时，使用这个 skill。

它解决的是事实核验与风险分流，不是内容润色，也不是替用户背书。

Use when

适用于：

• 回答里包含链接、论文、库名、版本号、命令、配置名、政策说法、数字、日期、兼容性声明。
• 用户准备复制命令、安装依赖、引用资料、据此做决策。
• 用户明确要求“帮我检查这段 AI 回答靠不靠谱”。

不适用于：

• 纯主观审美或价值判断。
• 需要访问私有系统、内网、付费数据库，而当前拿不到权限。
• 用户真正需要的是“把需求补全后再去问 AI”——那更接近 prompt-brief-builder。
• 用户只想知道先查哪几条、每类怎么处置，不需要逐条核验路径——用 ai-answer-triage，它分完级会把要核的几条交回这里。
• 要判断的是一整段 AI 写的代码能不能信、能不能跑——用 ai-code-onboarding-checklist；代码里引用的包名、API、版本号这些声明仍可以拿回这里逐条核。

Inputs

尽量收齐以下输入；缺项时要明确标注不确定性，而不是擅自补全：

1. AI 原回答（必需）
2. 原始问题或任务目标（强烈建议）
3. 执行环境（可选）
   • 操作系统 / shell
   • 编程语言与版本
   • 包管理器（pip / npm / cargo / etc.）
   • 目标地区或政策适用范围
4. 核验边界（可选）
   • 只做离线审阅
   • 可以联网查公开资料
   • 可以运行只读/无副作用的本地检查

Deliverable

输出由三部分组成：

1) Claim Ledger

用统一表格列出可检验声明：

ID	声明	类型	风险	核验方式	状态	证据/备注
C1	requests 2.32 支持某接口	package-version	高	查官方文档或 registry	待现场核验	需要联网

状态只用以下集合，避免自造话术：

• 已核实：找到直接证据且与声明一致
• 已证伪：找到直接证据且与声明冲突
• 待现场核验：理论上可验证，但当前缺工具/权限/联网
• 不可直接核验：表述过泛、无明确对象、或本质上是观点
• 非事实声明：建议、偏好、措辞，不做真假裁定

2) Verification Plan

按风险和行动顺序给出 3 档处置：

• 先拦住：复制就可能出事故的项（命令、删除/迁移、依赖安装、政策/合规断言）
• 尽快核实：会影响方案选型或引用可信度的项（版本兼容、论文/DOI、发布日期、性能数字）
• 可后核实：背景解释、延伸阅读、低风险补充信息

3) Safe-to-use Summary

最后只回答三件事：

1. 哪些部分现在可以继续用
2. 哪些部分必须先核实再用
3. 如果用户赶时间，最小核验路径是什么

Procedure

Step 1. 先拆声明，不先下结论

把原回答拆成最小可检验单元。优先抓这些：

• URL / 域名 / 文档页面
• 包名 + 版本号
• 论文标题 / DOI / arXiv 编号
• CLI 命令、参数、环境变量、配置键
• API 名、函数名、类名、返回字段
• 日期、数字、价格、配额、限制
• “支持 / 不支持 / 默认 / 已废弃 / 推荐”这类兼容性与政策断言

不要把一大段混成一条；也不要把纯建议硬拆成事实。

Step 2. 给每条声明分型

优先使用下面这套类型，方便不同 Agent 复用：

• url：链接、页面是否存在、是否指向对应内容
• package-version：包/版本是否存在，发布时间与兼容说明是否匹配
• paper-id：DOI、arXiv、ISBN、标准号
• command-line：命令、flag、子命令、退出条件
• api-surface：函数、类、参数、字段、HTTP 端点
• policy-or-limit：配额、价格、字符限制、速率限制、地区政策
• numeric-claim：性能、耗时、容量、阈值、默认值
• quote-or-summary：是否准确转述原文
• opinion：主观看法，不做真假裁定

Step 3. 风险排序

按“用户复制后会不会直接翻车”排序，而不是按学术洁癖排序：

高风险

• 会执行的命令
• 会安装或升级的依赖
• 会迁移、删除、覆盖配置的建议
• 合规/政策/价格/额度断言
• 引用不存在的论文、库、接口

中风险

• 性能数字、发布日期、默认配置
• 兼容性矩阵
• 文档总结是否准确

低风险

• 历史背景、概念类补充、非关键延伸阅读

Step 4. 选最直接的核验路径

遵循“优先原始来源，优先确定性检查，优先低副作用”的顺序：

1. 官方文档 / 官方 registry / 官方论文页
2. 命令 --help、-h、--version、只读查询
3. 包管理器公开元数据
4. 标准文献索引与 DOI 解析
5. 次级资料（博客、问答、第三方教程）

如果只能看到二手说法，状态最多写“待现场核验”，不要装作“已核实”。

Step 5. 诚实输出剩余不确定性

遇到以下情况必须直说：

• 没联网
• 没权限访问目标系统
• 缺少执行环境
• 声明本身太含糊，无法唯一核验
• 回答把多个断言揉在一起，证据无法一一对应

Deterministic checks by claim type

下面给主流 Agent 一个通用核验框架；能自动查的查，查不了就明确降级。

url

• 检查 URL 结构是否合法
• 如可联网，检查是否可访问、是否重定向到无关页面
• 核对页面标题/关键段落是否支持声明

package-version

• 核对包名是否存在
• 存在不等于可信：AI 幻觉出的包名可能已被别人抢先注册。在 registry 的页面或元数据里再看四样：首次发布时间、源码仓库链接（且仓库确实对应这个包）、维护者、下载量或被依赖数。首发只有几周、没有仓库或仓库对不上、下载量与"常用库"的说法明显不相称时，不记已核实：元数据与声明冲突（回答把它当成熟的常用库）记已证伪，备注"疑似抢注"；看不出冲突但也找不到仓库和维护者，记待现场核验。两种都放进"先拦住"，下一步是去该领域的官方文档确认正确的包名
• 核对指定版本是否真实发布
• 核对发布日期是否与声明一致
• 如声明兼容性，优先查 changelog / release notes / docs

paper-id

• DOI 是否可解析
• arXiv 编号是否存在且标题匹配
• DOI 解析出的标题必须与引文标题一致（大小写、标点、副标题分隔符的差异可以放宽），另外作者或年份至少再对上一项，才记已核实；标题对不上时，哪怕作者和年份都对（同一作者同年的另一篇），也记已证伪，备注"DOI 指向另一篇"

command-line

• 先拆出程序名、子命令、flag、位置参数
• 如可本地只读验证，检查 help 文本是否存在对应 flag
• 明确区分“语法存在”与“执行结果正确”

api-surface

• 查官方 API 文档、类型定义、示例响应
• 区分“有这个字段”与“默认一定返回这个字段”
• 版本相关 API 必须带版本上下文

policy-or-limit

• 查官方政策页、价格页、产品限制文档
• 这类信息易变，输出中要带核对日期
• 找不到官方来源时，最多写“待现场核验”

numeric-claim

• 要求数字带对象、单位、条件
• 缺单位或前提时，先降级为不可直接核验
• 若数字来自基准测试，记录测试环境与样本范围

quote-or-summary

• 找原文
• 用“原句/原段 → AI 转述 → 是否偏移”的形式对照
• 如 AI 把限定条件吞掉，要标成高风险误导

Output template

## Claim Ledger
| ID | 声明 | 类型 | 风险 | 核验方式 | 状态 | 证据/备注 |
|---|---|---|---|---|---|---|
| C1 |  |  |  |  |  |  |

## 先拦住
- 

## 尽快核实
- 

## 可后核实
- 

## 现在可以继续用的部分
- 

## 必须先核实的部分
- 

## 最小核验路径
1. 
2. 
3. 

Quality bar

完成稿至少满足：

• 没把观点冒充成事实核验结论
• 没把“没查”写成“没问题”
• 每条高风险声明都有明确下一步核验动作
• 所有“已核实/已证伪”都能指向具体证据
• 如果引用易变事实，写明核对日期

Boundaries

• 不编造不存在的官方来源。
• 不凭语气判断“像真的”就放行。
• 不把“命令能解析”误写成“命令安全可执行”。
• 不替用户执行高风险操作；如需运行有副作用命令，先让用户确认。
• 不因为一个点是真的，就给整段回答盖“整体可靠”章。

Example triggers

• “帮我核查这段 AI 回答里哪些能直接信。”
• “这份 AI 给的安装步骤有没有瞎编命令或版本？”
• “把这段回答拆成要验证的声明，按风险排序。”
• “它引用了论文和文档，帮我列一个核验清单。”

Handoff note for other agents

如果当前 Agent 没有联网或执行能力，也能先完成：

1. 声明抽取
2. 风险排序
3. 核验路径设计
4. 明确标出哪些项必须交给有工具/权限的后续 Agent 或人来完成

这能保证 skill 在不同 Agent 环境下都可用，只是“已核实”的覆盖率会不同。

变更记录 / Changelog

版本	日期	变更	类型
0.1.1	2026-09-26	台账示例的状态与类型改回固定词表（待现场核验、package-version）；DOI 规则改成标题必须一致再加作者或年份一项，标题不符记已证伪，堵住"同一作者同年另一篇"的错配；包名一节补"存在不等于可信"，查首发时间、源码仓库、维护者、下载量，疑似抢注不记已核实；与 ai-answer-triage、ai-code-onboarding-checklist 互相点名	patch
0.1.0	2026-08-30	初始版本	minor