Skip to content
cccskills
FreePublished on GitHub

ai-output-fact-checker

当拿到一段 AI 回答、准备直接复制去用之前使用。把回答拆成可检验的声明(链接、库名与版本、论文 DOI、命令行参数、API 名、数字、引文),按"用错了会炸多大"排序,为每条配一条最直接的核验路径;产出声明台账、核验计划和"现在可以用 / 必须先核实"两栏。

专门防住引用了不存在的库、论文或命令这种直接复制就会出事的情况;包名存在不等于可信(幻觉出的名字可能已被人抢注),DOI 能解析也要标题对得上。不替使用者背书,核不了就写核不了。

与 ai-answer-triage 的区别:那边只分级、定先查哪几条,这里逐条给核验路径;要判断一整段 AI 代码能不能跑,用 ai-code-onboarding-checklist。

The English summary is being prepared. Showing the original description.

Run score Not tested

See how to install

Files included (1)

  • SKILL.md11.0 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

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声明类型风险核验方式状态证据/备注
C1requests 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.12026-09-26台账示例的状态与类型改回固定词表(待现场核验、package-version);DOI 规则改成标题必须一致再加作者或年份一项,标题不符记已证伪,堵住"同一作者同年另一篇"的错配;包名一节补"存在不等于可信",查首发时间、源码仓库、维护者、下载量,疑似抢注不记已核实;与 ai-answer-triage、ai-code-onboarding-checklist 互相点名patch
0.1.02026-08-30初始版本minor

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

当学生说"Common App 活动栏写不下"、"这段活动描述超字数了"、"帮我把这几条压到限制内"时使用。先按官方申请表核对当季字符限额,再逐条检查;一次把所有条目量完并直接给出压缩版,只在需要砍掉实质内容时才用选择题问该保哪部分。每改一版都用工具重新数一遍字符,绝不凭感觉说"这样应该够了"。只压缩,不代写空白。

The English summary is being prepared. Showing the original description.

ChromiteCr/Skills4Updated Oct 21, 2026

当学生说"我参加过一些活动但没整理过"、"帮我把经历录进去"、"我的活动档案是空的"时使用。让学生一口气把记得的活动说出来,直接把这段话拆成结构化的长期事项(角色、组织、起止时间、做了什么、结果、级别),说不清的字段留空标"待补"而不是编,再用一张选择题卡把级别判定与是否重复这类关键项一次问完,然后提案入库。只记录学生真正说出口的内容,级别按事实判定,绝不往高了写。

The English summary is being prepared. Showing the original description.

ChromiteCr/Skills4Updated Oct 21, 2026

当学生问"招生官会怎么看我的档案"、"我的背景还差什么"、"帮我评估一下现在的申请竞争力"时使用。以顶尖大学招生官的视角通读学生的档案、长期活动与已写下的反思,不问任何前置问题直接产出一份指名道姓的坦诚点评:这份材料的亮点、招生官真实的解读方式、明显的短板与空白、以及接下来最值得做的一到两件事。只读不写,不修改学生的任何数据,也不代写任何申请材料。

The English summary is being prepared. Showing the original description.

ChromiteCr/Skills4Updated Oct 21, 2026

当使用者说"帮我填词"、"按这个字数模板写歌词"、"用多Agent对抗式写词"、"这首副歌帮我想几句"时使用,前提是字数骨架和这首歌写什么都已经有了;只有主题、还没定写什么时先用 lyric-concept-builder。拿一份字数骨架和意象系统,派三个 sonnet 子代理按不同路子并行独立起草(场景派 / 口语派 / 意象派),再派一个红队子代理逐句挑毛病,主 Agent 按句裁决拼稿,最后统一辙口与意象。收敛判据卡死:字数用 lyric-doctor 的脚本对模板数、每段同辙、hook 不含陈词、主歌二对主歌一有推进。不抄现有歌词,不替使用者决定这首歌要说什么。

The English summary is being prepared. Showing the original description.

ChromiteCr/Skills4Updated Oct 21, 2026

当想知道一段 AI 回答"哪些能直接用、哪些必须先验证、哪些只能当建议"时使用。按声明类型分四级——低风险草稿材料、观点与策略建议、可查证的事实声明、会改变状态的可执行指令——每级配一句默认处置动作;再按影响半径排序,给出最小的下一步检查。可执行类一律标"不能直接执行;先做代码审阅/沙箱测试/回滚准备",其中破坏性或提权的命令排在最前。教的是一套可复用的复查习惯,不是替使用者把所有内容都核实一遍:本 skill 只分级、排序、定处置,要逐条核实走 ai-output-fact-checker,整段代码要做入库体检走 ai-code-onboarding-checklist。

The English summary is being prepared. Showing the original description.

ChromiteCr/Skills4Updated Oct 21, 2026

当拿到一段 AI 生成的代码,还没决定要不要信、要不要跑、要不要往上继续加东西时使用。先做一遍客观体检:行数与嵌套深度、有没有测试、有没有硬编码密钥或遗留 TODO、依赖是不是真实存在、有没有危险调用(eval/exec、shell=True、递归删除、反序列化、提权、外发网络,按正文给的 grep 模式逐类查);再给风险评级和下一步动作。老实写明它查不了算法正确性——体检通过不等于代码是对的。回答里文字、事实和代码混在一起时先用 ai-answer-triage 分级;只审相对已有代码的一份改动用 ai-diff-review-protocol。

The English summary is being prepared. Showing the original description.

ChromiteCr/Skills4Updated Oct 21, 2026

See all skills by ChromiteCr

Report a problem with this skill