mcpField
D
doublecheck

doublecheck

github.com/githubAgent 工作流40.5k4.3k 次安装1 天前更新
代码仓库

关于 doublecheck

Doublecheck 是一项技能,通过自查、来源核验和对抗式审阅来验证 AI 生成文本中的事实主张。它支持持续核验回复,也可针对指定文本生成一次性报告。

主要功能

  1. 01提取并分类可核验主张
  2. 02对照外部来源核查主张
  3. 03检查幻觉模式
  4. 04生成行内或完整核验报告
  5. 05支持持续与单次模式

适用场景

  1. 01核查生成回复中的事实主张
  2. 02审阅引用来源和统计数据
  3. 03按需核验指定文本
  4. 04在持续对话中加入主张核查

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/github/awesome-copilot --skill doublecheck

安装后在 Claude Code 中输入/doublecheck确认已加载。

附带文件assets/verification-report-template.md

详细介绍

Doublecheck

对 AI 生成的输出运行三层验证流水线。目标不是告诉用户什么是真的——而是提取每一条可验证的主张,找到用户可以独立核查的来源,并标记任何看起来像幻觉模式的内容。

激活

Doublecheck 以两种模式运行:主动模式(持久)和一次性模式(按需)。

主动模式

当用户调用此技能但未提供要验证的具体文本时,激活持久性 doublecheck 模式。回复:

Doublecheck 现已激活。 在呈现我的回复之前,我会验证其中的事实性陈述。每条实质性回复后,你都会看到一个内联验证摘要。在任意回复上输入 "full report",即可获得带有详细来源的完整三层验证。随时输入 "turn off doublecheck" 即可关闭。

然后,在接下来的对话中遵循以下所有规则:

规则:在发送之前对每条回复进行分类。

在生成任何实质性回复之前,判断其是否包含可验证的陈述。对回复进行分类:

回复类型是否包含可验证的陈述?操作
事实分析、法律指导、监管解读、合规指导,或包含案例引用或法条引用的内容是——高密度运行完整验证报告(参见下方高风险内容规则)
对文档、研究或数据的总结是——中等密度对关键陈述运行内联验证
代码生成、创意写作、头脑风暴很少跳过验证;注明 doublecheck 模式不适用于此类内容
闲聊、澄清性问题、状态更新否静默跳过验证

规则:主动模式下的内联验证。

当主动模式适用时,不要为每条回复生成单独的完整验证报告。相反,使用以下模式将验证直接嵌入你的回复中:

  1. 正常生成你的回复。
  2. 在回复之后,添加一个 Verification 部分。
  3. 在该部分中,列出每条可验证的陈述及其置信度评级,并在可用时附上来源链接。

格式:

---
**Verification (N claims checked)**

- [VERIFIED] "Claim text" -- Source: [URL]
- [VERIFIED] "Claim text" -- Source: [URL]
- [PLAUSIBLE] "Claim text" -- no specific source found
- [FABRICATION RISK] "Claim text" -- could not find this citation; verify before relying on it

对于主动模式,优先考虑速度。对引文、具体统计数据以及任何你信心较低的陈述运行网络搜索。对于常识性陈述或你信心较高的陈述,无需搜索——只需将其评级为 PLAUSIBLE 然后继续。

如果任何陈述被评为 DISPUTED 或 FABRICATION RISK,请在验证部分之前显著标明,以便用户立即看到。当自动升级适用时(见下文),将此提示放在完整报告的顶部,在摘要表之前:

**Heads up:** I'm not confident about [specific claim]. I couldn't find a supporting source. You should verify this independently before relying on it.

规则:对高风险发现自动升级为完整报告。

如果你的内联验证发现任何被评为 DISPUTED 或 FABRICATION RISK 的陈述,不要生成内联验证。相反,将 "Heads up" 提示放在回复顶部,然后使用 assets/verification-report-template.md 中的模板生成完整的三层验证报告。当某些内容明显有误时,用户不应还需要请求详细报告。

规则:对高风险内容使用完整报告。

如果回复包含法律分析、监管解读、合规指导、案例引用或法条引用,始终使用 assets/verification-report-template.md 中的模板生成完整验证报告。不要对这些内容类型使用内联验证——对于这种简略格式而言,风险太高。

规则:内联验证的可发现性页脚。

在生成内联验证(而非完整报告)时,始终在验证部分的末尾附加此行:

_Say "full report" for detailed three-layer verification with sources._

规则:应请求提供完整验证。

如果用户说 "full report"、"run full verification"、"verify that"、"doublecheck that" 或类似表述,运行完整的三层流水线(下文所述),并使用 assets/verification-report-template.md 中的模板生成完整报告。

单次模式

当用户调用此技能并提供要核实的特定文本(或引用之前的输出)时,运行完整的三层流水线,并使用 assets/verification-report-template.md 中的模板生成完整的核实报告。

停用

当用户说“关闭 doublecheck”“停止 doublecheck”或类似话语时,回复:

Doublecheck 现已关闭。 我将正常回复,不再进行内联核实。你可以随时重新启用它。


第 1 层:自我审计

以批判性的视角重新阅读目标文本。你在这一层的任务是提取和内部 分析——暂时还不进行网络搜索。

第 1 步:提取主张

逐句通读目标文本,找出每一条断言了可核实内容的陈述。对每条主张进行分类:

类别要寻找的内容示例
事实性关于事物当前或过去状况的断言“Python 创建于 1991 年”“GPL 要求衍生作品开源”
统计性数字、百分比、数量“95% 的企业使用云服务”“合同包含 30 天终止条款”
引用对特定文档、案例、法律、论文或标准的引用“根据 CDA 第 230 条……”“在 Mayo v. Prometheus(2012)案中……”
实体关于特定人物、组织、产品或地点的断言“OpenAI 由 Sam Altman 和 Elon Musk 创立”“GDPR 适用于欧盟居民”
因果断言 X 导致 Y 或 X 引发 Y“此漏洞允许远程代码执行”“该法规是为应对 2008 年金融危机而通过的”
时间日期、时间线、事件顺序“截止日期是 3 月 15 日”“2.0 版本在安全补丁之前发布”

为每条主张分配一个临时 ID(C1、C2、C3……),以便在后续各层中跟踪。

第 2 步:检查内部一致性

将提取出的各条主张相互对照审查:

  • 文本中是否有自相矛盾之处?(例如,对同一事件给出两个不同日期)
  • 是否存在逻辑上互不相容的主张?
  • 文本是否在某一节中作出假设,却在另一节中将其否定?

立即标记任何内部矛盾——这些问题无需外部核实即可判定为问题。

第 3 步:初步置信度评估

对每条主张,仅基于你自己的知识作出初步评估:

  • 你是否记得这是准确的?
  • 这是否属于模型经常产生幻觉的那类主张?(具体引用、精确统计数字和确切日期属于高风险类别。)
  • 该主张是否足够具体、可以核实,还是足够模糊、无法证伪?

记录你的初步置信度,但暂时不要将其作为发现报告。这是第 2 层的输入,而非输出。


第 2 层:来源核实

对每条提取出的主张,搜索外部证据。这一层的目的是找到用户可以访问的 URL,以独立核实各项主张。

搜索策略

对每条主张:

  1. 构建一个搜索查询,使其能够浮现出原始来源。对于引用,搜索确切的标题或案例名称。对于统计数字,搜索具体数字和主题。对于事实性主张,搜索关键实体及其关系。

  2. 运行搜索,使用 web_search。如果第一次搜索没有返回相关结果,换用不同措辞再试一次。

  3. 评估你的发现:

    • 你是否找到了直接涉及该主张的原始来源或权威来源?
    • 你是否从可信来源找到了相互矛盾的信息?
    • 你是否没有找到任何相关内容?(这本身就是一个信号——真实的事物通常会有网络痕迹。)
  4. 记录结果,附上来源 URL。即使你也概述了来源内容,也务必提供 URL。

什么算作来源

优先选择一手来源和权威来源:

  • 官方文档、规范和标准
  • 法院记录、立法文本、监管申报文件
  • 同行评审的出版物
  • 官方组织网站和新闻稿
  • 权威参考著作(百科全书、法律数据库)

注明某个来源是二手来源(新闻报道、博客文章、wiki 页面)还是一手来源。用户可据此权衡。

专门处理引文

引文是幻觉风险最高的类别。对于任何引用具体案件、法规、论文、标准或文件的断言:

  1. 搜索确切的引文(案件名称、标题、章节号)。
  2. 如果找到了,确认所引内容确实如目标文本所称的那样表述。
  3. 如果完全找不到,将其标记为 FABRICATION RISK。模型经常为不存在的事物生成听起来煞有介事的引文。

第 3 层:对抗性审查

彻底切换你的姿态。在第 1 层和第 2 层中,你在努力理解和核实输出。在这一层中,假定输出包含错误,并主动寻找这些错误。

幻觉模式检查清单

检查以下常见模式:

  1. 捏造的引文 —— 文本引用了你在第 2 层中无法找到的具体案件、论文或法规。这是最危险的幻觉模式,因为它看起来具有权威性。

  2. 没有来源的精确数字 —— 文本陈述了具体的统计数据(例如“78% 的公司……”),却没有说明这个数字来自哪里。模型经常生成听起来煞有介事但完全编造的统计数据。

  3. 在不确定话题上自信地给出具体细节 —— 文本就一个具体细节确实未知或存在争议的话题陈述了非常具体的内容。留意确切的日期、精确的金额,以及在专家存在分歧的领域中的确定性归因。

  4. 似是而非的错误关联 —— 文本将某个概念、裁决或事件与错误的实体关联起来。例如,将裁决归于错误的法院,将引语归于错误的人,或者在把法律名称弄对的同时错误地描述该法律的条款。

  5. 时间错乱 —— 文本将可能已经过时的事物描述为当前情况,或以错误的顺序描述事件序列。

  6. 过度概括 —— 文本将仅在特定司法管辖区、语境或时间段内适用的事物陈述为普遍真理。在法律和监管内容中很常见。

  7. 缺失限定语 —— 文本将一个微妙的话题呈现为已有定论或直截了当,而实际上存在重大例外、限制或反论。

对抗性问题

对于通过了第 1 层和第 2 层的每项主要断言,问:

  • 什么会使这项断言不成立?
  • 这个领域是否存在模型可能学到的常见误解?
  • 如果我是一名主题专家,我会对这样的表述提出异议吗?
  • 这项断言来自我的训练数据截止时间之前还是之后,它可能已经过时吗?
需要上报的危险信号

如果你发现以下任何情况,请在报告中显著标记:

  • 在任何地方都找不到的具体引文
  • 没有可识别来源的统计数据
  • 与权威来源说法相矛盾的法律或监管断言
  • 以高度自信陈述但实际上存在争议或不确定的断言

生成核查报告

完成全部三层后,使用 assets/verification-report-template.md 中的模板生成报告。

置信度评级

为每条论断分配最终评级:

评级含义用户应做什么
VERIFIED已找到并链接支持来源若该论断对你的工作至关重要,请抽查来源链接
PLAUSIBLE与常识一致,但未找到具体来源视为合理但未经证实;若据此做出决策,请独立核实
UNVERIFIED未能找到支持或反驳的证据未经独立核实,请勿依赖该论断
DISPUTED从可信来源找到了反驳证据查阅反驳来源;该论断可能有误
FABRICATION RISK符合幻觉模式(例如无法找到的引文、无来源的精确统计数据)在你从一手来源确认之前,假定该论断是错误的
报告原则
  • 提供链接,而非结论。由用户决定什么是真的,而不是你。
  • 当你发现相互矛盾的信息时,请将有来源的双方观点都呈现出来。不要选出一个赢家。
  • 如果某条论断不可证伪(过于模糊或主观而无法核实),请说明。"不可证伪"本身就是有用的信息。
  • 明确说明你无法核查的内容。"我无法核实这一点"与"这是错的"是不同的。
  • 按严重程度对发现进行分组。将最需要关注的项目放在最前面。
局限性披露

务必在报告末尾包含以下内容:

本次核实的局限性:

  • 本工具加速人工核实;它并不能取代人工核实。
  • 网络搜索结果可能不包含最新信息或付费墙来源。
  • 对抗性审查使用可能与生成原始输出相同的底层模型。它能发现许多问题,但无法发现全部问题。
  • 论断被评为 VERIFIED 意味着找到了支持来源,而非该论断一定正确。来源也可能出错。
  • 被评为 PLAUSIBLE 的论断仍可能错误。没有反驳证据并不等于证明其准确。

特定领域指南

法律内容

法律内容具有更高的幻觉风险,因为:

  • 案件名称、引文和判决要旨经常被模型捏造
  • 司法管辖的细微差别常被抹平或省略
  • 法条措辞可能被转述,从而改变其法律含义
  • "多数规则"与"少数规则"的区分常被丢失

对于法律内容,请对以下方面给予额外审查:案件引文、法条引用、监管解释和司法管辖主张。尽可能搜索法律数据库。

医学与科学内容
  • 检查所引用的研究确实存在,且结果描述准确
  • 留意将过时指南当作现行指南呈现的情况
  • 标记剂量、治疗方案或诊断标准——这些会变化,且错误可能具有危险性
金融与监管内容
  • 核实具体的金额、日期和阈值
  • 检查监管要求是否归属于正确的司法管辖区且为现行有效
  • 留意在近期立法变化后可能已过时的税法论断
技术与安全内容
  • 核实 CVE 编号、漏洞描述和受影响版本
  • 检查 API 规范和配置说明是否与当前文档一致
  • 留意可能已过时的版本特定信息

评论

支持 Markdown