1. 项目概述：一个为AI智能体设计的“事实核查引擎”

在AI大模型（LLM）满天飞的今天，我们最头疼的问题是什么？是“幻觉”。你问它一个数据，它可能信誓旦旦地给你一个编造的数字；你让它验证一下刚才说的对不对，它可能又用同样的幻觉逻辑“证明”了一遍。这就像一个永远在自说自话的循环，你很难找到一个客观的锚点来判断信息的真伪。

Proof Engine 这个项目，就是为了打破这个循环而生的。它不是一个简单的提示词模板，而是一个遵循开放 Agent Skills 标准的“技能包”。你可以把它安装到 Claude Desktop、Claude Code、Cursor、ChatGPT 等各种支持该标准的AI工具里。一旦安装，当你向AI提出“证明一下”、“核实这个说法”这类请求时，Proof Engine 就会自动接管，用一种全新的、可验证的方式来处理你的问题。

它的核心思想非常直接： 不让LLM自己当裁判 。Proof Engine 将验证过程从LLM的“黑箱”中剥离出来，强制要求每一个事实断言都必须通过以下两种方式之一来“落地”：

  1. 可复现的Python代码计算 ：如果是数学或逻辑问题，AI必须生成一个完整的Python脚本。这个脚本不依赖LLM的内部知识，而是调用像 sympy 、 numpy 这样的标准库进行计算。任何人都可以重新运行这个脚本，得到确定性的结果。
  2. 可追溯的实时来源引用 ：如果是事实性陈述，AI必须提供具体的URL和精确的引文。Proof Engine 会真的去抓取那个网页，并在页面内容中搜索、匹配引用的文字。如果匹配不上，或者只匹配上一部分，验证结果就会相应降级或失败。

最终，它会生成一套完整的“证据链”文件，包括可执行的 proof.py 脚本、结构化的证明报告 proof.md 、详细的审计日志 proof_audit.md ，以及一个便于阅读的叙事总结 proof_narrative.md 。对于那些发布到其官网的证明，还会额外生成Jupyter Notebook、W3C PROV-JSON溯源文件和RO-Crate研究数据包，完全符合可重复研究的标准。

简单来说，Proof Engine 把AI从一个“全知但不可靠的讲述者”，变成了一个“负责搜集证据、撰写验证程序的助理”，而最终的裁决权，交给了客观的代码和公开的网络数据。这对于需要严谨事实核查的研究者、记者、学生，或者任何受困于AI“信口开河”的普通用户来说，都是一个强有力的工具。

2. 核心设计思路：如何构建一个“不信任LLM”的验证管道

Proof Engine 的设计哲学建立在一个清醒的认知之上：LLM本身不具备验证事实的能力，它只是一个基于概率生成文本的模型。因此，整个系统的设计目标，就是构建一条LLM无法“作弊”或“蒙混过关”的验证流水线。这不仅仅是技术实现，更是一种工程上的“不信任”原则的贯彻。

2.1 打破“自我验证”的循环

最常见的错误做法是：“AI，你说X是对的，请验证一下。” AI可能会回答：“根据我的知识库，X是正确的，因为A、B、C……” 这本质上是用同一套有缺陷的生成逻辑去检查自己，毫无意义。Proof Engine 的做法是，当AI生成一个初步的验证计划（比如“要证明这个，我们需要计算Y，并引用Z网站的数据”）后，系统会强制要求它将这个计划转化为 外部可检验的实体 。

例如，对于“美国自1913年以来美元购买力下降超过90%”这个说法，AI不能只是总结它读过的文章。它必须：

  1. 找到美国劳工统计局（BLS）关于消费者价格指数（CPI）的官方数据页面。
  2. 从页面中 精确引用 包含1913年和当前年份CPI数值的句子。
  3. 编写一个Python脚本，从引文中 解析 出这两个数字（而不是手动输入），然后计算通货膨胀率，最后判断下降比例是否大于90%。

这个过程中，LLM的角色被严格限定在“信息检索助理”和“代码生成器”。它负责找到可能相关的源和构思计算逻辑，但所有关键事实的“锚点”都必须来自外部。

2.2 九大强化规则：堵住每一个可能的漏洞

为了让这套机制足够健壮，Proof Engine 内置了九条强化规则。这些规则都是针对LLM在验证任务中常见的失败模式而设计的“补丁”。

规则1：永远不要手动输入值

问题：LLM可能会错误地转录引文中的日期或数字。比如引文写的是“increase of 1.2°C”，它可能在看的时候就看成了“1.5°C”，然后在代码里直接写 temperature_increase = 1.5 。 解决方案：强制要求从引文字符串中 程序化地解析 数值。代码必须是 temperature_increase = extract_number_from_quote(quote_text) 这样的形式。这样，如果引文本身是错的，或者解析逻辑写错了，错误是可见且可调试的。

规则2：通过抓取来验证引用

问题：LLM可能会编造一个看起来合理的URL和一段对应的引文（即“幻觉引用”）。 解决方案：Proof Engine 会真的发起HTTP请求去获取该URL的页面内容，然后使用字符串匹配算法（考虑了一些空白字符和格式差异）在页面中搜索引文。如果完全找不到，该引用就被标记为“未验证”；如果只找到部分匹配，则验证强度会打折扣。

规则3：锚定到系统时间

问题：LLM对“今天”的日期认知可能是错的，或者它的训练数据截止日期并非当前日期。 解决方案：所有涉及当前日期的计算，必须使用 datetime.date.today() 或 datetime.datetime.now() 来获取，禁止硬编码如 current_year = 2023 。

规则4：明确的声明解释

问题：自然语言存在歧义。“超过50%”是指“大于50%”还是“大于等于50%”？“A比B老”是比较创建日期、成立日期还是其他？ 解决方案：在验证开始前，AI必须显式地声明它对原始声明所做的 可操作化解释 。例如：“本证明将‘以色列超过70岁’解释为：以色列的建国日期（1948年5月14日）至系统当前日期之间的时长，大于70年。” 这个解释会记录在案，让审查者清楚验证的前提。

规则5：独立的对抗性检查

问题：确认偏误。AI可能只寻找支持声明的证据。 解决方案：Proof Engine 会强制要求AI同时搜索 可能反驳 该声明的来源。例如，证明“咖啡降低糖尿病风险”时，也必须查找声称“咖啡无影响或增加风险”的研究。最终的结论需要综合正反两方面的证据强度。

规则6：独立的交叉检查

问题：共享变量错误。在复杂的证明中，一个中间计算结果被多个地方使用，如果这个结果算错了，会导致多个后续验证错误地“一致”。 解决方案：对于关键的计算步骤，鼓励从不同来源或使用不同方法进行交叉验证。例如，计算GDP增长率，既可以用今年和去年的数值直接算，也可以用第三方统计机构已经计算好的增长率数据进行比对。

规则7：永不硬编码常量

问题：LLM可能记错公式或物理常数。 解决方案：禁止在代码中直接写入如 pi = 3.14 或 gravitational_constant = 6.674e-11 。必须从公认的权威库中导入，例如 from scipy import constants 然后使用 constants.pi 。

规则8：拒绝证据的相关性

问题：为了反驳一个声明，AI可能找到一个勉强相关但说服力很弱的来源。 解决方案：用于反驳的证据，必须与声明的核心主张直接相关，并且其反驳的力度需要被评估。不能因为找到一个边缘的、无关的负面信息就草率判定“证伪”。

规则9：文本引用必须可机械解析

问题：在证明报告的叙述部分，AI手动输入的引用（如“据Smith (2020)的研究…”）可能与后面正式注册的源信息（如具体的URL和引文）对不上，造成混淆。 解决方案：所有在叙事中提到的引用，都必须通过一个唯一的标识符（如源ID）链接到后面“证据”部分的具体源条目。这通常通过模板或生成脚本来保证一致性。

这九条规则共同构成了一套严密的“防护网”，极大地提高了LLM生成欺诈性或错误证明的难度，将潜在的幻觉暴露在可审查的流程中。

3. 安装与配置：跨平台部署详解

Proof Engine 作为一个Agent Skill，其安装方式因你使用的AI工具有所不同。它的设计目标就是尽可能无缝地集成到你现有的工作流中。下面我将详细拆解在不同平台上的安装步骤，并分享一些配置心得。

3.1 主流平台安装指南

Claude Desktop (推荐) 这是体验最流畅的方式之一。你可以直接点击项目提供的 安装链接 ，这通常是一个 claude:// 协议链接，会自动唤醒Claude Desktop并触发安装流程。如果自动安装失败，可以手动操作：

  1. 在Claude Desktop侧边栏点击 Customize （自定义）。
  2. 点击 Browse Plugins （浏览插件）。
  3. 切换到 Personal （个人）标签页，点击 + 按钮。
  4. 选择 Add marketplace （添加市场）。
  5. 在弹出的输入框中，键入 yaniv-golan/proof-engine ，然后点击 Sync （同步）。 完成后，Proof Engine 就会出现在你的技能列表中。之后在任何对话中，只要触发“证明”、“核实”等关键词，它就会自动介入。

Claude Code (CLI / 插件模式) 对于喜欢在终端工作的开发者，Claude Code的命令行接口非常强大。

  • 从终端安装 ： 
    # 首先添加Proof Engine的市场源
claude plugin marketplace add https://github.com/yaniv-golan/proof-engine
# 然后从该市场安装技能
claude plugin install proof-engine@proof-engine-marketplace
  • 在Claude Code会话中安装 ：你也可以直接在对话中输入命令： 
    /plugin marketplace add yaniv-golan/proof-engine
/plugin install proof-engine@proof-engine-marketplace

安装后，在代码编辑或技术讨论中，直接让Claude Code“证明这个算法复杂度”或“核实这个API的返回格式”，它就会调用Proof Engine技能。

Cursor / Windsurf / Manus 这类新一代的AI原生IDE，安装方式类似。通常是在设置（Settings）中找到“Skills”、“Plugins”或“Agents”相关选项，然后提供Proof Engine仓库的GitHub URL ( https://github.com/yaniv-golan/proof-engine ) 或直接上传下载的ZIP包。以Cursor为例：

  1. 打开 Cursor Settings 。
  2. 找到 AI Plugins 或类似区域。
  3. 将 https://github.com/yaniv-golan/proof-engine 粘贴到 Search or Paste Link 输入框。
  4. 确认添加即可。

ChatGPT 目前，ChatGPT的“技能”功能还处于测试阶段，通常面向企业版、教育版等用户开放。如果可用，安装步骤是：

  1. 从GitHub Releases页面下载 proof-engine.zip 。
  2. 访问 chatgpt.com/skills 。
  3. 点击上传按钮，选择下载的ZIP文件。 安装成功后，在ChatGPT的对话中，它也能调用Proof Engine进行事实核查。

3.2 通用安装与手动部署

对于其他支持Agent Skills标准但未在上述列表的工具，或者你想进行项目级部署，可以采用手动方式。

  1. 从发布页面下载最新的 proof-engine.zip 文件。
  2. 解压后，你会得到一个 proof-engine/ 文件夹。
  3. 将这个文件夹放置到对应的技能目录下：
    • 用户级目录 ： ~/.agents/skills/ (适用于所有项目)
    • 项目级目录 ：在你的项目根目录下创建 .agents/skills/ 文件夹，然后将 proof-engine/ 放进去。这种方式适合团队协作，确保每个成员在同一个项目中使用相同的验证技能。

实操心得 ：我强烈建议先从 Claude Desktop 或 Claude Code 开始尝试。它们的集成度最高，交互反馈也最直观。手动部署时，注意技能文件夹的命名和路径必须准确，否则工具可能无法识别。另外，由于Proof Engine需要执行Python代码和网络请求，请确保你的AI工具运行环境有相应的权限（尤其是网络访问权限）。

4. 使用流程与核心环节拆解

安装完成后，如何使用Proof Engine？整个过程是自动触发的，但理解其内部工作流，能帮助你提出更好的问题，并解读它产生的结果。整个流程可以分解为五个关键阶段。

4.1 阶段一：声明分析与分类

当你提出一个诸如“证明地球平均气温自1880年以来上升了超过1摄氏度”的请求时，Proof Engine 首先会引导AI对声明进行解构。

  1. 分类 ：判断声明属于 计算型 （如数学证明）、 实证型 （依赖事实数据）还是 混合型 。
  2. 消歧 ：识别并澄清模糊之处。例如，“地球平均气温”是指陆地表面温度、海表温度还是综合温度？数据来源是NASA、NOAA还是IPCC？Proof Engine 会要求AI给出一个明确的、可操作的解释（对应规则4）。
  3. 制定验证策略 ：基于分类，决定主要验证手段。计算型问题侧重于编写Python脚本；实证型问题则需要制定引用来源、数据提取和比较的逻辑。

这个阶段的输出是一个清晰的验证计划，它奠定了后续所有工作的基础。如果声明本身无法被形式化（如“Python是最好的语言”），Proof Engine 会直接拒绝或返回“UNDETERMINED”（无法判定）的结论。

4.2 阶段二：对抗性证据搜集

这是体现其严谨性的关键一步。Proof Engine 不会只让AI去找支持声明的证据。

  1. 支持性证据检索 ：AI会搜索支持声明的主要来源。例如，为了证明气温上升，它可能会去找NASA GISS的数据页面、IPCC的报告摘要。
  2. 对抗性证据检索 ： 同时 ，AI必须去搜索可能反驳或质疑该声明的来源。例如，查找认为全球变暖停滞或数据有误的文章（尽管可能是少数观点）。这强制打破了LLM可能存在的确认偏误（规则5）。
  3. 来源评估 ：AI需要对找到的来源进行初步评估，优先选择权威、一手、时间近的来源。但最终的“权威性”判断，更多是由后续的引用匹配和交叉检查来完成。

4.3 阶段三：验证代码生成与静态分析

这是将自然语言声明转化为机器可执行验证逻辑的核心。

  1. 代码生成 ：AI根据验证计划，编写一个完整的 proof.py 脚本。这个脚本必须遵守所有强化规则：
    • 使用 requests 或 urllib 库从提供的URL抓取内容。
    • 使用 BeautifulSoup 或正则表达式从抓取的内容中解析出所需的数值和文本。
    • 所有计算必须使用Python标准库或受信任的科学计算库（如 sympy 用于数学证明， datetime 用于日期计算）。
    • 关键常数必须从库中导入，禁止硬编码。
  2. 静态分析 ：在运行代码之前，Proof Engine 会调用一个 validate_proof.py 的模块对脚本进行静态检查。这个检查器会遍历代码的抽象语法树（AST），查找违反规则的模式，例如：
    • 是否存在直接赋值的数字或字符串字面量（违反规则1、7）？
    • 是否尝试使用 eval() 或 exec() 等危险函数？
    • 日期计算是否使用了 date.today() （符合规则3）？ 如果发现违规，生成过程会被中断，AI会被要求修正代码。

4.4 阶段四：动态执行与结果判定

代码通过静态检查后，便会在你的本地环境中执行。

  1. 代码执行 ：运行 proof.py 。这包括实际的网络请求、数据解析和逻辑计算。执行环境就是你当前AI工具（如Claude Code）的Python环境，因此需要具备相应的依赖库（如 requests , beautifulsoup4 ）。
  2. 引用验证 ：对于每一个引用，脚本会执行HTTP请求，下载网页内容，并尝试匹配AI提供的精确引文。匹配结果分为：完全匹配、部分匹配、未匹配。
  3. 生成裁决 ：综合所有计算结果的布尔值、引用匹配的程度、以及对抗性证据的强度，Proof Engine 会生成一个最终的裁决（Verdict）。裁决不是简单的“对/错”，而是一个更细致的分类：
    • PROVED ：所有核心计算通过，且关键引用得到完全验证。
    • SUPPORTED ：声明得到强力证据支持，但可能在某些边缘条件或次要引用上存在不确定性。
    • DISPROVED ：找到了确凿的反例或计算直接否定了声明。
    • PARTIALLY VERIFIED ：声明的一部分被证实，另一部分未被证实或证据不足。
    • UNDETERMINED ：证据矛盾、不足，或声明本身无法被形式化验证。

4.5 阶段五：生成完整证明报告

最后，Proof Engine 会打包生成一系列文件，形成一个完整的证明包：

  1. proof.py ：可重跑的验证脚本。这是整个证明的“源代码”，任何人都可以独立运行以复现结果。
  2. proof.md ：结构化的证明报告。包含声明、解释、裁决、证据摘要（每个证据的状态：已验证/部分验证/未验证）以及裁决的理由。
  3. proof_audit.md ：详细的审计日志。记录了整个验证过程的每一步：检索了哪些关键词、访问了哪些URL、HTTP状态码、引文匹配的详细输出、代码执行的完整日志（包括打印输出）。这是进行深度审查的“黑匣子”。
  4. proof_narrative.md ：面向读者的叙事总结。用连贯的段落叙述证明的过程和结论，适合直接阅读或分享。

如果这个证明被提交到 proofengine.info 网站，构建流程还会进一步生成：

  • .ipynb (Jupyter Notebook) ：将 proof.py 嵌入交互式笔记本，方便他人分步执行和探索。
  • PROV-JSON ：遵循W3C标准的溯源文件，用机器可读的形式记录“谁（AI）、在何时、用什么数据、产生了什么结论”的溯源链。
  • RO-Crate ：一个标准化的研究数据包，将上述所有文件、元数据（如作者、许可证）打包，便于长期保存和引用。

注意事项 ：整个执行过程依赖于你的本地网络环境和Python环境。如果某个引用网站无法访问（被墙、服务器错误），对应的引用验证就会失败。此外，网站内容可能动态变化，今天验证通过的引用，明天可能因为页面更新而匹配失败。Proof Engine 的审计日志会忠实记录这些情况，这也是其透明性的体现——它证明的是“在某个特定时刻，根据可获取的公开信息，该声明的状态”。

5. 适用场景与声明类型分析

不是所有问题都适合用 Proof Engine 来解决。它的强项在于处理那些 可形式化 的声明。理解什么样的声明是“好”的，能帮你更有效地使用这个工具。

5.1 理想匹配：清晰、可分解的声明

这类声明通常有明确的真值条件和客观的数据来源。

1. 纯计算型声明

  • 示例 ：“前1000个质数的和本身是质数。”
  • 为什么适合 ：验证完全依赖于数学逻辑和计算。Proof Engine 会生成调用 sympy 库计算质数和并进行素性测试的代码。不涉及外部引用，结果确定无疑。
  • 操作要点 ：确保声明中的数学对象定义清晰。“质数”是通常定义，没有歧义。对于更复杂的数学猜想，需要确保AI能将其转化为等价的、可计算的命题。

2. 基于公开数据的实证声明

  • 示例 ：“以色列建国超过70年。” “截至2023年，世界人口超过80亿。”
  • 为什么适合 ：存在公认的权威数据源（如政府官网、联合国报告）。声明可以分解为：a) 找到建国日期/历史人口数据；b) 找到当前日期/最新人口数据；c) 计算时间差/比较数值。每一步都可以通过引用和代码来锚定。
  • 操作要点 ：引导AI使用最权威、最直接的数据源。对于人口数据，应优先引用联合国《世界人口展望》报告页面，而非维基百科或新闻摘要。

3. 多源交叉验证的共识性声明

  • 示例 ：“地球平均气温自1880年以来上升了超过1°C。”
  • 为什么适合 ：尽管涉及复杂科学，但有多家独立科研机构（NASA, NOAA, 英国气象局等）发布长期数据集。Proof Engine 可以要求AI从至少三个独立来源提取变暖趋势数据，并检查它们是否一致支持“>1°C”的结论。
  • 操作要点 ：这类证明的关键在于“独立来源”的数量和质量。Proof Engine 默认可能需要3个独立源才能达成“PROVED”。你需要评估声明的争议性来调整这个期望。

5.2 边界情况：需要谨慎处理的声明

这类声明可能部分可验证，但包含模糊或主观成分，容易导致“部分验证”的结果。

1. 基于科学文献的因果声明

  • 示例 ：“喝咖啡降低2型糖尿病风险。”
  • 挑战 ：科学共识往往建立在大量研究、元分析之上。单个研究可能结论不一。Proof Engine 可以要求AI找到一篇支持该结论的权威医学期刊论文，并精确引用其中的风险比（HR）或比值比（OR）数据。这可以证明“有研究支持此说法”，但不足以证明该说法是绝对真理。裁决很可能是 SUPPORTED 或 PARTIALLY VERIFIED ，并附注“结论基于单一研究，未综合反驳性证据”。
  • 处理建议 ：可以尝试将声明具体化为“根据《XX》期刊2020年的一项研究，喝咖啡与2型糖尿病风险降低X%相关”。这样就从验证一个普遍结论，变成了验证一个具体的引用事实。

2. 历史解释性声明

  • 示例 ：“罗马帝国衰亡源于铅中毒。”
  • 挑战 ：这是历史解释，而非单纯事实。Proof Engine 可以验证一些子事实：“古罗马水管中使用铅”、“在罗马贵族骨骼中检测到高铅含量”、“铅对神经系统有害”。但它无法验证“衰亡源于”这个因果关系，因为涉及复杂的多因解释和历史学辩论。
  • 处理建议 ：将其拆解为一系列可验证的子声明进行分别验证。最终的证明报告会展示每个子事实的验证状态，让读者自行判断整体论点的说服力。

3. 依赖于度量和范围的比较声明

  • 示例 ：“Transformer模型比RNN更高效。”
  • 挑战 ：“高效”指什么？训练速度？推理速度？参数效率？内存占用？需要在特定任务（如机器翻译）、特定数据集（如WMT）、特定度量（如BLEU分数 per GPU hour）下才有比较意义。
  • 处理建议 ：必须首先要求AI对声明进行极度精确的“可操作化解释”。例如：“本证明将‘更高效’解释为：在WMT14英德翻译任务上，达到相同BLEU分数时，Transformer-base模型的训练时间少于LSTM-seq2seq模型。” 之后，验证就变成了查找对应论文中的具体实验数据。

5.3 不适用场景：应避免的声明类型

试图用Proof Engine验证以下类型的声明，通常会得到“UNDETERMINED”或直接被拒绝。

1. 价值判断与主观意见

  • 示例 ：“Python是最好的编程语言。” “这幅画很美。”
  • 原因 ：缺乏客观的真值条件。“好”和“美”的标准因人而异，无法通过代码或单一引用来证实或证伪。

2. 未来预测

  • 示例 ：“AI将在2030年前实现通用人工智能（AGI）。”
  • 原因 ：关于未来的断言没有当前可验证的经验证据。Proof Engine 只能验证基于当前或历史数据的事实。

3. 法律或道德判定

  • 示例 ：“被告有罪。”
  • 原因 ：这需要法律程序、证据链和法官/陪审团的心证，远非事实核查所能涵盖。Proof Engine 或许能验证庭审中的某个具体事实（如“监控显示被告在案发时间出现在现场”），但无法对最终的“有罪”做出裁决。

4. 过于模糊或宏大的声明

  • 示例 ：“资本主义终将灭亡。” “生命的意义在于奉献。”
  • 原因 ：声明本身难以分解为有限个可检验的子命题，或者其定义极其模糊。

实操心得 ：在使用Proof Engine前，花点时间自己先打磨一下你的问题陈述。尽量让它具体、可测量、有时限、有明确的比较基准。一个好的声明是成功验证的一半。如果你不确定某个声明是否合适，可以先让AI（不启用技能）帮你将其“翻译”成一个更可验证的形式。

6. 结果解读与常见问题排查

Proof Engine 生成的证明包包含丰富的信息，正确解读这些结果是发挥其价值的关键。同时，在实际使用中你可能会遇到一些典型问题。

6.1 深度解读证明报告

拿到 proof.md 和 proof_audit.md 后，不要只看最后的 PROVED 或 DISPROVED 标签。作为一个严谨的审查者，你应该深入细节。

1. 审查“声明解释” 这是验证的基石。检查AI对原始声明的解释是否合理、有无偷换概念。例如，将“AI模型很大”解释为“参数数量超过10亿”，这个阈值设定是否公允？如果解释本身有偏差，整个证明就建立在错误的前提上。

2. 逐一检查证据源状态 在 proof.md 的“证据”部分，每个来源都会有一个状态标记：

  • ✅ VERIFIED ：引文在目标URL中被完整找到。
  • ⚠️ PARTIALLY VERIFIED ：只找到部分匹配（例如，找到了数据但单位不同，或找到了句子但缺少一个关键数字）。审计日志会显示具体匹配了哪些部分。
  • ❌ UNVERIFIED ：完全未找到引文，或URL无法访问（HTTP错误）。
  • SKIPPED ：该来源被跳过（例如，用于对抗性检查但未找到有力反证）。

你需要点开 proof_audit.md ，查看每个源的详细日志：

  • HTTP请求详情 ：返回的状态码是什么？200 OK 还是 404 Not Found？如果是403或429，可能是临时访问限制。
  • 引文匹配详情 ：显示了在页面内容中搜索引文的实际结果。是精确匹配，还是经过了空白字符标准化后的匹配？匹配到的上下文是什么？
  • 数据提取日志 ：代码是如何从匹配的文本中解析出数字或日期的？解析逻辑是否可能出错？（例如，误把页码当成年份）。

3. 分析计算逻辑与代码 仔细阅读 proof.py 。检查：

  • 数据流 ：从原始引文文本到最终用于计算的变量，数据转换是否正确？有没有不当的类型转换？
  • 计算过程 ：数学公式或逻辑判断是否正确？边界条件处理是否得当？（例如，比较“超过90%”时，用的是 > 还是 >= ？）
  • 错误处理 ：代码是否考虑了网络请求失败、数据解析失败的情况？还是直接崩溃？

4. 理解裁决理由 最终裁决旁边会附上简要理由。例如，“PROVED：所有三个独立数据源均显示升温超过1.0°C，且引用均获验证。” 或 “PARTIALLY VERIFIED：主要计算成立，但其中一个支持性引用（来源#2）仅部分匹配，且一条对抗性引用指出数据存在争议。” 这个理由将证据状态与最终结论联系了起来。

6.2 典型问题与解决方案

在实际操作中，你可能会遇到以下问题：

问题1：验证失败，状态多为“UNVERIFIED”或“PARTIALLY VERIFIED”。

  • 可能原因A：网站防爬虫 。许多新闻网站或学术平台有反爬措施，简单的 requests.get 可能被屏蔽。
    • 排查 ：查看 proof_audit.md 中对应URL的HTTP响应状态码和返回的HTML内容。如果返回的是验证码页面或403错误，即是此问题。
    • 解决 ：Proof Engine 目前可能未配置复杂的请求头（如User-Agent）或会话管理。对于关键证明，你可能需要手动指导AI在 proof.py 中添加更模拟浏览器的请求头，或使用 requests.Session 。但注意，这增加了代码复杂性。
  • 可能原因B：动态加载内容 。所需数据由JavaScript在客户端动态生成，初始HTML中不存在。
    • 排查 ：审计日志中显示的页面HTML内容非常简短，不包含引文。
    • 解决 ：这通常是此类工具的硬伤。可以尝试让AI寻找该网站的“纯文本”版本、API接口，或使用 requests-html 、 Selenium 等能执行JS的库（但这会大幅增加环境依赖和复杂度）。更务实的做法是更换数据源。
  • 可能原因C：引文过于精确或格式有变 。AI提供的引文是它“记忆”或“生成”的，与网页上的实际措辞有细微差别（如标点、空格、换行）。
    • 排查 ：审计日志显示匹配算法找到了相似但不完全相同的文本。
    • 解决 ：指导AI在编写验证脚本时，使用更灵活的匹配方式（如正则表达式提取关键数字模式），或者只引用最核心的数据短语，而非整个长句。

问题2：Python脚本执行出错。

  • 可能原因A：缺少依赖库 。脚本中使用了 sympy , numpy , pandas , beautifulsoup4 等，但你的环境未安装。
    • 解决 ：在运行证明前，根据 proof.py 顶部的 import 语句，手动安装缺失的包（ pip install sympy beautifulsoup4 ）。一个成熟的Proof Engine 部署应能提示或自动处理依赖，但目前可能需要手动干预。
  • 可能原因B：网络超时或错误 。 requests.get 因网络问题抛出异常。
    • 解决 ：代码中应包含基本的错误处理（ try...except ），并将网络错误记录为验证失败的一部分。你可以检查AI生成的代码是否包含了此类健壮性处理。
  • 可能原因C：网页结构变化，解析逻辑失效 。用于提取数据的CSS选择器或XPath路径失效了。
    • 解决 ：这是基于网页抓取的验证的固有风险。证明的有效性具有“时间戳”。审计日志记录了抓取时的原始HTML，可以作为快照。如果后续需要复现，可能需要调整解析逻辑。

问题3：AI生成的验证逻辑存在根本性缺陷。

  • 可能原因 ：LLM误解了问题，或设计了一个错误的实验来“证明”某事。
  • 示例 ：证明“狗比猫聪明”。AI可能设计了一个“比较平均神经元数量”的验证，并找到了相关论文数据。但这并不能等价于“聪明”。
  • 解决 ：这就是为什么“声明解释”环节至关重要。你必须在验证开始前，就质疑和确认AI对声明的操作化定义是否合理。Proof Engine 不能保证逻辑正确，它只保证验证过程的执行是透明和可复现的。逻辑的正确性需要人来判断。

问题4：证明过程非常缓慢。

  • 可能原因 ：证明涉及从多个网站抓取数据，每个请求都有网络延迟。
  • 解决 ：这是为了可靠性付出的性能代价。对于复杂的证明，可以预期需要数十秒甚至更长时间。审计日志会记录每个步骤的耗时。

避坑技巧 ：

  1. 从简单证明开始 ：先用“前10个质数的和是129”或“月球直径约为3474公里”这类简单、明确的声明来测试你的安装和环境，熟悉整个流程和输出格式。
  2. 优先使用API数据源 ：对于需要频繁验证的数据（如股价、天气、汇率），指导AI优先寻找提供公开API的源（如金融数据API、政府开放数据平台），这比解析HTML页面更稳定、更快速。
  3. 善用审计日志 ： proof_audit.md 是你的最佳调试伙伴。任何意外结果，首先查看这里。它比最终的裁决标签包含更多的真相。
  4. 理解“PARTIALLY VERIFIED”的价值 ：不要把它简单看作失败。它精确地指出了证据链中的薄弱环节，这本身就是一个有价值的信息——它告诉你这个声明在何处、因何原因存在不确定性。

7. 高级应用：引用、DOI与集成

对于研究者或希望将证明正式化、可引用的用户，Proof Engine 提供了一套完整的学术引用和持久化标识符工作流。

7.1 引用已发布的证明

Proof Engine 官网 proofengine.info 不仅是一个展示平台，更是一个可引用的证明数据库。每个发布的证明都包含标准的引用信息。

1. 引用格式 每个证明页面都提供多种引用格式：

  • APA / Chicago ：纯文本的引用字符串，可直接复制到论文参考文献中。
  • BibTeX / RIS ：可下载的文件，可一键导入到Zotero、Mendeley、EndNote等文献管理软件中。
  • 核心元数据 ：引用中包含了证明标题、作者（通常是证明的创建者或提交者）、发布日期、证明的永久URL以及最重要的—— DOI （数字对象标识符）。

2. DOI（数字对象标识符） 对于重要的证明，项目会通过Zenodo为其注册一个DOI。DOI是一个永久链接，即使证明的托管URL发生变化，通过DOI也能定位到该证明。这为学术引用提供了稳定性和权威性。在证明页面上，你可以看到类似 https://doi.org/10.5281/zenodo.1234567 的链接。

3. 机器可读的引用数据 除了人类可读的格式，证明还提供：

  • JSON-LD ：嵌入网页中的结构化数据，遵循 ClaimReview 模式。这是谷歌等搜索引擎用于标记事实核查内容的标准格式，有助于提升证明的可见度。
  • Proof JSON API ：网站提供一个统一的 index.json 文件，列出所有证明的元数据。每个证明也有独立的 proof.json 文件，其中包含完整的 citation 字段，方便其他工具或AI智能体以编程方式获取和引用证明。

7.2 为你的证明申请DOI

如果你运行了一个有价值的证明，并希望将其发布到Proof Engine网站并获得DOI，你需要遵循以下流程：

1. 前提条件

  • 你有一个GitHub账号，并且已经Fork了Proof Engine仓库。
  • 你的证明已经本地生成，并且你确信其正确性和价值。
  • 你拥有一个 Zenodo账户 ，并创建了一个具有 deposit:write 和 deposit:actions 权限的 个人访问令牌 。Zenodo是一个由CERN运营的开放科学数据存储库。

2. 提交证明到网站 Proof Engine网站通过GitHub仓库进行协作。通常，你需要：

  1. 将你的证明文件（ proof.md , proof.py , proof_audit.md , proof_narrative.md ）按照规定的目录结构放置。
  2. 创建一个Pull Request (PR) 到主仓库。
  3. 项目维护者会审核你的证明。审核通过后，证明会被合并并出现在网站上。

3. 申请DOI（通常由维护者执行） 一旦证明被合并到主分支，网站构建流程可以自动或手动为其申请DOI。这需要使用Zenodo API。

# 设置你的Zenodo访问令牌（用于生产环境）或沙箱令牌（用于测试）
export ZENODO_TOKEN=your_actual_token_here
# 或者用于沙箱测试
export ZENODO_SANDBOX_TOKEN=your_sandbox_token_here

# 在网站构建目录中，为某个证明（通过slug标识）申请DOI
python tools/proof-site.py mint-doi your-proof-slug --site-dir path/to/site
# 使用 --sandbox 参数先在测试环境尝试
python tools/proof-site.py mint-doi your-proof-slug --site-dir path/to/site --sandbox

这个过程会：

  • 将你的证明包（包括所有文件）上传到Zenodo。
  • 从Zenodo获取一个永久的DOI。
  • 在证明的元数据文件（如 doi.json ）中记录这个DOI。
  • 后续构建网站时，引用信息中就会自动包含这个DOI。

4. 更新已有DOI的证明 如果你需要修正一个已有DOI的证明，Zenodo支持创建新版本。使用 --force 参数可以上传新内容并更新DOI记录，同时保持DOI不变（指向最新版本）。

注意事项 ：申请DOI是一个正式的数字出版行为。请确保你提交的证明内容准确、来源可查，并且你拥有提交这些内容的权利（或内容符合开源许可）。滥用DOI系统是不被鼓励的。

7.3 与其他工具集成

Proof Engine 的本质是一个遵循开放标准的Agent Skill，这为它与其他工具链集成提供了可能。

1. 作为可信信息源供其他AI调用 你可以将Proof Engine网站上的 llms.txt 文件URL（ https://proofengine.info/llms.txt ）提供给其他LLM。这个文件包含了所有已发布证明的简明摘要。LLM在回答相关问题时，可以优先引用这些已经过严格验证的事实，从而提高其回答的可靠性。

2. 嵌入自动化工作流 由于每个证明最终生成一个包含代码和数据的标准化包（RO-Crate），它可以被集成到更广泛的自动化研究或新闻核查流水线中。

  • 学术研究 ：在论文写作中，对于关键的数据陈述，可以运行Proof Engine生成一个可复现的证明包，作为论文的“补充材料”或“可复现性附件”提交。
  • 新闻编辑室 ：记者在撰写涉及数据的报道前，可以用Proof Engine快速核查关键数据点，并将生成的审计日志作为内部审核依据。
  • 教育领域 ：用于教授学生批判性思维和如何验证信息。学生可以提交自己对某个说法的证明，老师则可以审查其证据链和代码逻辑。

3. 扩展与定制 Proof Engine 是开源的。如果你有特定领域的需求（例如，专门验证生物医学文献中的统计结果，或验证区块链交易数据），你可以基于其框架进行扩展：

  • 添加新的验证模块 ：为特定类型的数据源（如特定数据库API）编写专用的数据获取和解析函数。
  • 定制强化规则 ：针对你所在领域的常见错误模式，设计额外的静态分析或运行时检查规则。
  • 适配其他输出格式 ：除了现有的Markdown和JSON，你可以定制生成PDF报告、可视化图表等。

Proof Engine 不仅仅是一个“防AI幻觉”的工具，它更代表了一种工作范式：将模糊的声称，转化为可执行、可审查、可重复的验证程序。在这个信息过载且真假难辨的时代，这样的范式或许能为我们提供一丝宝贵的确定性。

Logo
亚马逊云科技技术品牌专区

更多推荐

cover

别再只聊大模型！AI的下一场革命，藏在“身体”里

avatar 亚马逊云科技技术品牌专区
cover

别再只聊大模型！人工智能的下一场革命，藏在“身体”里

avatar 亚马逊云科技技术品牌专区
cover

别再只聊大模型！AI的下一场革命，藏在“身体”里

avatar 亚马逊云科技技术品牌专区