Ai Output Fact Checker

---
name: ai-output-fact-checker
description: 当拿到一段 AI 回答、准备直接复制去用之前使用。把回答拆成可检验的声明（链接、库名与版本、论文 DOI、命令行参数、API 名、数字、引文），按"用错了会炸多大"排序，为每条配一条最直接的核验路径；产出声明台账、核验计划和"现在可以用 / 必须先核实"两栏。专门防住引用了不存在的库、论文或命令这种直接复制就会出事的情况；包名存在不等于可信（幻觉出的名字可能已被人抢注），DOI 能解析也要标题对得上。不替使用者背书，核不了就写核不了。与 ai-answer-triage 的区别：那边只分级、定先查哪几条，这里逐条给核验路径；要判断一整段 AI 代码能不能跑，用 ai-code-onboarding-checklist。
category: ai-usage/verification
version: 0.1.1
status: draft
priority: P0
compatible_agents:
  - claude-code
  - codex
  - cursor
  - codebuddy
  - nestudy
  - generic-llm-agent
display_name: AI 回答事实核验
outputs:
  - chat
max_rounds: 20
suggest_hint: 复制这段 AI 回答之前，先用「AI 回答事实核验」把里面的链接、库名、版本和引文过一遍
---

# 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

```markdown
## 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 |