为一条 AI 回复验明正身，过去只有两个坏选择：要么信服务商的口径，要么花大价钱跑本地部署自己盯着显存。FlashProve 给了第三个选项：服务商发布一个 commitment ID 绑定一组权重，每条回复附带密码学证明，任何人拿普通 CPU 跑 cp_verify，几秒钟就能确认这条回答确实出自被承诺的那个模型，全程接触不到权重本身。仓库 anthropics/FlashProve 当前版本 0.16.0，Apache-2.0 许可，README 自述定位是研究工件：not maintained，不接受贡献。
先划边界。本批开源栏文章《FlashProve：不交权重也能自证清白》讲它是什么、为什么可信：Lean 4 写下的可靠性定理、承诺-证明-验证三段式协议、它对 API 诚信问题的意义，那是原理层。本篇是实战 SOP，只解决一个问题：怎么把验证器在你的机器上跑起来，从环境准备、克隆仓库、构建 cp_verify，到验证一条存储证明、读懂退出码，最后给出真实场景的验证五件套；日常接 API 的工作流是另一件事，见《Hy4 API 接入 SOP》。热点栏与本主题无直接关联，不重复展开。全文命令与流程以仓库 README 原文为依据，口径抓取于 2026 年 11 月 5 日，文中日期一律写绝对日期。
开跑之前：四条路线与一盆冷水
README 按硬件门槛把能做的事分成四条路由，先把全景摆出来，再决定你走到哪一站。路由 1 是构建 cp_verify 并验证一条存储证明，需要 Linux、bash、g++ 13 及以上版本、内存小于 2GB，构建耗时 1 到 2 分钟，单次检查小于 2 秒，这是本篇的主干。路由 2 是 toy proofs，在 CPU 上自测证明库，在路由 1 基础上多要 make 和 python3、内存小于 1.5GB，约 1 分钟跑完。路由 3 是在 GPU 上构建出证端并跑一个 8 层合成模型，需要 H100 加完整 GPU 栈，构建约 29 分钟；同一套构建跑全尺寸合成权重则要 280GB 内存、约 42 分钟。路由 4 下载 232GB 的公开 4-bit 权重转换，对真 Llama 4 Maverick 出证，要 330GB 内存和数小时。普通读者的合理终点是路由 2；路由 3 与 4 的技术细节在开源栏里展开，本篇只把门槛写清。
一个官方口径值得记下：完整验证一条真实证明，24 线程 CPU 上约 17 秒；而第四步那条存储示例的检查小于 2 秒。差距在于真实证明覆盖 1024 token 上下文的整段推理，示例只是最小载荷。这个数字也解释了"普通人验货"为什么现实：不需要显卡、不需要大内存，一台老笔记本就能当验证机。
冷水现在泼：截至本篇写作的 2026 年 11 月 5 日，没有任何主流服务商在生产环境附带 FlashProve 证明。所以不要拿着本篇去"验证 OpenAI 或 Anthropic 的生产 API"，那条路现在不存在，本篇也不会编出这种步骤。本篇的价值是三件事就绪：验证器能跑、原理吃得透、退出码读得懂，未来哪家服务商实装，你当天就能验货。
第一步：环境准备，门槛比想象中低
硬性门槛只有四条：x86-64 Linux、bash、g++ 13 及以上、内存小于 2GB。最后一条常让人怀疑看错——多数推理框架的部署文档张口就是几十 GB 显存或内存，而 FlashProve 把验证端压到了 2GB 以内，这正是"证明在服务商侧生成、在验证侧廉价"的设计结果。查内存用 free -h，查编译器版本用 g++ --version，低于 13 就先升编译器再继续。
权限规则要当成铁律：README 要求一切命令以普通（非 root）用户身份在仓库根目录执行，绝不使用 root 或 sudo；只有安装系统包这一步需要 root。仓库给编码代理的规则写得更狠：绝不用 sudo、chmod、chown、rm 或修改源文件的方式"绕过一个报错"，遇到错误停下来报告。人操作同样受益于这条纪律——用权限硬怼过去的构建，问题只会延后爆发。
Windows 用户注意：原生环境不可用，通用做法是安装 WSL2 后在 WSL2 的 Linux 发行版里完成下述步骤。这是社区通行常识，不是 README 原文，README 的支持列表只有 x86-64 Linux；macOS 同样不在其中。Ubuntu 24.04 最小安装补齐路由 1 与路由 2 依赖的命令如下，需要 root 执行：
apt-get update && apt-get install -y --no-install-recommends g++ make python3 unzip其中 make 与 python3 是路由 2 才用的，只想跑通本篇主干的话，g++ 与 unzip 就够。g++ 13 这条版本线卡得比较死：Ubuntu 24.04 默认仓库直接满足；Ubuntu 22.04 默认是 g++ 11，需要从更高版本的工具链源安装，属于发行版通用操作，README 未展开，按你的发行版文档处理即可。
第二步：克隆仓库，认清三个位置
之后所有命令都假设你在仓库根目录执行：
git clone https://github.com/anthropics/FlashProve
cd FlashProveclone 下来先认三个位置。verifier/ 是本篇主角，验证器源码与 build.sh 都在里面；examples/accepted-proof/ 是仓库自带的一条已接受存储证明，包含 config、ivk、example.req、example.y、example.proof，以及记录承诺 ID 的 ID.txt，第四步的验证对象就是它；guide/ 与 docs/ 是文档，真实场景那一节的 request 文件构造方法在 guide/verify-a-proof.md。当前版本 0.16.0，README 顶部写明这是研究工件：not maintained、不接受贡献、Apache-2.0 许可。研究工件意味着它不会像活跃开源项目那样跟进 issue、修兼容性，遇到的问题大概率要自己对着文档解决；好处是协议与文档高度自洽，照着 README 走几乎不会遇到版本漂移。
第三步：构建验证器，1 到 2 分钟的安静
构建只有一行：
verifier/build.sh它的行为很特别：先静默 1 到 2 分钟，期间没有任何进度输出，然后打印一行以 THE VERIFIER IS BUILT: 开头的信息，并以退出码 0 结束。静默不是卡死，是正常现象；以 build.sh: note: 开头的行是警告而非错误，按 README 要求，报告时要原样引用。如果你的终端工具调用会超时，README 给了后台构建的写法：
echo "build started" >> verifier-build.log; nohup bash -c 'verifier/build.sh; echo "exit code $?"' >> verifier-build.log 2>&1 &之后轮询日志：
tail -n 2 verifier-build.log直到最后一行以 exit code 开头。README 特别强调：期间不要启动第二个构建。构建失败最常见的原因是 g++ 版本低于 13 与权限混乱——后者多半来自有人习惯性加了 sudo，构建产物属主变成 root，后续步骤全链报错；回到第一步的非 root 纪律重新来过，比修补更省时间。
第四步：验证存储示例，看到 YES
构建成功后，bin/ 下多出 cp_verify。用它验证仓库附带的存储示例，命令原样来自 README：
bin/cp_verify examples/accepted-proof/config examples/accepted-proof/ivk examples/accepted-proof/example.req examples/accepted-proof/example.y examples/accepted-proof/example.proof -id "$(cat examples/accepted-proof/ID.txt)"期望结果有两项，缺一不可：最后一行是 YES，退出码是 0。跑出 YES 的那一刻，值得说清楚它到底证明了什么。README 原话是：这个示例是小模型合成权重，只证明验证器本身工作正常，不涉及任何真实服务商。换句话说，YES 证明的是你的机器上协议实现可用、验证器安装无误，而不是"验证了哪家 API"；把它理解成体温计自检，而不是体检报告。
顺手记下 README 给编码代理的报告规范，人做验证同样适用：报告确切命令、退出码与完整的最后一行；当证明被接受时，还要报告你传入的 commitment ID，以及输出里的 covered: 与 result-v1: 两行。养成这个习惯，将来验证真实证明时，手里的记录才经得起复盘。
第五步：读懂退出码，接入真实场景五件套
存储示例只是热身，真实场景的调用形状是五件套：
bin/cp_verify CONFIG_DIR PUBLIC_KEY_DIR REQUEST_FILE TOKEN_FILE PROOF_FILE -id COMMITMENT_ID五个文件加一个 ID，各就各位：CONFIG_DIR 与 PUBLIC_KEY_DIR 来自服务商发布的配置与公钥，REQUEST_FILE 是你自己构造的请求文件，构造方法在 guide/verify-a-proof.md，TOKEN_FILE 是被验证的那条回复，PROOF_FILE 是随附证明，COMMITMENT_ID 是服务商公布的承诺 ID。判读结果看两样东西的组合：退出码加最后一行。verifier 文档的退出码表如下，数值原样照抄，不要凭记忆变形：
| 退出码 | 最后一行 | 含义 |
|---|---|---|
| 0 | YES / WITHIN LIMITS: ... | 接受：精确匹配，或落在裁剪容差内 |
| 1 | NO: <名称> | 拒绝，或本地故障 |
| 5 | NOT CHECKED: <名称> | 无结论；仅 internal-stage 或 internal-exception-parFor 可重试一次 |
| 14 | NOT-A-VERIFICATION | 调用本身无效，看 ---- the call ---- 之后的行 |
| 2, 3, 4, 15 | （不固定） | 命令行或文件有误，或调用不完整，无结论 |
三条判读纪律值得写进验证脚本的注释里。第一，退出码 5 的重试窗口极窄：只有最后一行名称是 internal-stage 或 internal-exception-parFor 时可以重试一次，其他任何 NOT CHECKED 都直接上报，不要反复跑。第二，退出码 1 有歧义：可能是证明真的被拒，也可能是你本地缺文件之类的故障，先排查自身环境，再宣布"对方造假"。第三，退出码 14 说明调用参数有问题，不是对方的问题，去看 ---- the call ---- 之后的行，那里会指出调用哪里不合法。
真实场景里最容易踩的坑是 commitment ID 的来源。安全模型的核心是一条不对称规则：承诺 ID 必须从你信任的第三方获取，绝不能从被验证的服务器或随证明附带的文件里拿。原因不难想：如果 ID 由被验证方自己递过来，它随时可以换一组权重、换一个 ID 重发证明，你的验证就没有锚点。README 写明唯一例外是仓库里的存储示例。另外，官方在 integrations/ 里提供了封装脚本 check_proof.py，把调用与结果比对打包好，适合把验证嵌进自动化流程。
边界清单：YES 不等于答案正确
最后把协议边界一次说清，免得拿到 YES 就过度信任。第一，FlashProve 只证来源不证正确性：证明说的是这条回答出自被承诺的那组权重，不保证内容正确、有用或不带偏见，模型本身的水平与验证无关。第二，证明覆盖的上下文窗口是 1024 token，超出部分不在承诺范围内。第三，协议对推理过程做了确定性约定，整数化与贪心 MoE 路由是其覆盖的前提，细节在仓库的 limits 系列文档。第四，仓库自述 not maintained、不接受贡献，代码以研究工件状态存在，许可为 Apache-2.0，许可与第三方材料清单以 LICENSE、NOTICE 与 THIRD_PARTY.md 为准。第五，也是最重要的：现阶段没有主流服务商在生产环境附带证明。本篇的目标从来不是让你今天就去验某家 API，而是验证器就绪、退出码吃透、五件套熟练，等哪家服务商实装的那天，你的验证流程当天可用。
想再往前走一步的读者：路由 2 的 toy proofs 在 CPU 上约 1 分钟，期望倒数第三行以 AS EXPECTED: the honest copy was accepted 开头，能让你看到诚实副本被接受、作弊副本被拒绝的对照；路由 3 与 4 需要 H100 与完整 GPU 栈（CUDA 13.2 Update 2，nvcc 13.2.86），分别面向 8 层合成模型与真 Maverick 权重，内存与时长门槛见开头的路线表。原理层的承诺-证明-验证三段式、Lean 4 定理与它对 API 诚信问题的意义，见开源栏的《FlashProve：不交权重也能自证清白》；本地部署要盯显存的那条路，见《大模型本地部署显存 SOP》。
常见问题
Q1：Windows 能直接跑 cp_verify 吗？ A1：不能。README 的支持平台只有 x86-64 Linux，需要 bash 与 g++ 13 及以上。通用做法是安装 WSL2，在 WSL2 的 Linux 发行版里按本篇步骤执行，这是社区通行常识而非 README 原文；macOS 同样不在支持列表。
Q2：build.sh 一直没输出，是不是卡死了？ A2：不是。README 明确它会先静默 1 到 2 分钟，然后打印以 THE VERIFIER IS BUILT: 开头的一行并以退出码 0 结束。以 build.sh: note: 开头的行是警告不是错误。终端会超时的话改用后台构建命令，轮询 tail -n 2 verifier-build.log 等到 exit code 行，期间不要启动第二个构建。
Q3：cp_verify 输出 YES 说明什么，不说明什么？ A3：说明验证器工作正常、这条存储证明通过协议校验。但示例是小模型合成权重，与任何真实服务商无关，它不构成对任何线上 API 的验证。判断真实证明要用退出码加最后一行组合判读，退出码 1 还要先排除本地故障。
Q4：commitment ID 为什么不能从被验证的服务器拿？ A4：这是安全模型的核心。承诺 ID 把证明锚定到一组权重，如果由被验证方自己提供，它可以换权重、换 ID 重发证明，验证失去锚点。必须从你信任的第三方获取，随证明附带的文件也不算数；仓库存储示例是唯一例外。
Q5：现在能用它验证我正在付费的 API 吗？ A5：不能。截至 2026 年 11 月 5 日没有主流服务商在生产环境附带 FlashProve 证明，仓库本身也标注 not maintained。当前能做的是把验证器跑通、吃透退出码表与五件套，服务商实装后即可直接验货。