【2026 最新】FlashProve 驗證教學：CPU 四次呼叫，分清接受、拒絕與輸入錯誤

你拿到一段 AI 回答，旁邊還附了「驗證通過」的字樣：這是在說模型沒有被換掉，還是在說答案一定正確？這篇 FlashProve 驗證教學要帶你看懂一份運算證明究竟驗了什麼，再把接受、拒絕與根本沒驗完的結果分開記。

Anthropic 於 2026 年 11 月 2 日公開 FlashProve。若你想先了解研究背景與效能數字，可以讀 FlashProve 可驗證推論解讀；這裡專注操作：在已有合適環境時，如何用隨附 CPU 範例建立一張驗收紀錄。完全不懂密碼學也能先讀原理；要複製指令的部分，則需要會開 Linux 終端機。

本文依截至 2026 年 11 月 5 日的官方文件與測試程式整理，固定公開提交 9e2bdd8。本次編輯環境為 macOS，未執行下列 Linux 驗證；文中的預期結果來自官方範例與測試斷言，並非 AlphaLab 實測。倉庫將它標為不維護的研究產物，適合用來學習如何界定證據。

先說結論：驗證通過＝指定材料＋指定範圍＋指定政策相符

把 FlashProve 想成「核對食譜的計算收據」：收據可以支持某份食譜和這些步驟的關係，食譜的名稱由誰背書、餐點是否符合你的需求，仍各有自己的檢查。這個比喻對應的是運算關係，不是對廚房歷史的錄影。

• CPU 範例通過：示範檔案能互相對上；它使用合成權重，沒有替線上 API 驗明身分。
• 正式查核前：先取得可信 commitment ID、配置、自己的輸入輸出 token 與接受政策。
• 結果判讀：一起看退出碼、最後一行與涵蓋欄位；看到途中出現 YES 或 STAGE PASSED 都不夠。

一、FlashProve 驗證教學：先認識五個零件

模型的權重是學習後留下的數字；推論是拿這些數字處理輸入、計算下一個 token。token 是模型使用的文字編碼單位，不必然等於一個中文字。這裡核對的，是整數化模型在特定輸入下的計算關係。

• ①「先封存食譜」：commitment ID 是 64 位十六進位識別碼，用來指定對權重與設定所作的承諾。公開檔案與設定仍要按文件保存。
• ②「交出計算收據」：proof 是證明檔，由提供者產生；驗證者拿到證明，不需要取得模型權重。
• ③「自己的工作單」：request 記錄 token IDs 與檢查範圍。正式情境要由自己送出、收到的 token 重建。
• ④「先訂驗收規則」：exact match 與 clipped gap 是兩種不同的接受政策，不能等看到結果才挑寬鬆的那一種。
• ⑤「自己的核對器」：cp_verify 是 C++ 驗證器；check_proof.py 再替操作者核對範圍、政策與結果欄位。兩者的退出碼與最後一行格式有差別。

這三步可在 官方整合說明 對照。零知識證明的目標是讓對方相信指定運算關係，同時限制權重資訊的揭露；這不表示整個實際服務的每一層軟體都已獲證明。官方也明列 Python 腳本與 C++ 驗證器不在相同的定理覆蓋內。

二、先備環境：這次只走 CPU 驗證路線

照 官方 CPU quick start 準備 Linux、bash、g++ 13 以上與 GNU 工具；下列 Python 整合腳本另需要 Python 3.10 以上。先在一般使用者帳號、自己能控制的目錄工作。若缺少工具，先完成環境準備，再開始；不要為了繞過錯誤而提權、改來源碼或改動共用目錄權限。

這條路線是在 CPU 檢查已存在的證明。官方的模型證明產生路線另要求 NVIDIA H100 與指定 CUDA 等環境；兩種工作不要混為一談。本篇不啟動 prover、不下載真實模型權重，也不把官方建置時間當成每台電腦的保證。

如果已安裝 Git，可在自己的練習目錄逐行執行以下準備命令；git checkout --detach 固定本篇引用的版本。每一步成功才進下一步。clone 若遇到儲存空間或網路限制，停在該步，先看文件也能完成結果判讀練習。

git clone https://github.com/anthropics/FlashProve.git
cd FlashProve
git checkout --detach 9e2bdd8ff5bf9c62f18263d7dac189b0400b260c
python3 --version
g++ --version
verifier/build.sh

建置成功的判準是退出碼 0，最後一行以 THE VERIFIER IS BUILT: 開頭。立刻用 echo $? 查看退出碼，之後其他命令會覆蓋它。若出現 build.sh: note:，把完整提示保留下來；尤其在共用機器上，要先排除別人能改動材料的路徑。

三、FlashProve 驗證教學：先跑原樣，再做三個負例

以下只處理官方 accepted-proof 小型合成範例。先在同一個 bash 工作階段設定路徑、ID 與紀錄目錄。這裡可使用隨附 ID 是因為它是示範；正式服務的可信 ID 取得流程在下一節。

FP_CASE=$(mktemp -d)
FP_EXAMPLE=examples/accepted-proof
FP_ID=79a5a2bc7a469b40df73dedf40abeb740671e8ae8077738bd3743897aeb22183
printf '紀錄目錄：%s\n' "$FP_CASE"
fp_check() {
  fp_label=$1; fp_request=$2; fp_id=$3
  if python3 integrations/check_proof.py     "$FP_EXAMPLE/example.proof" "$fp_request"     --public-key-dir "$FP_EXAMPLE/ivk"     --parameter-file "$FP_EXAMPLE/config/policy.txt"     --scales-file "$FP_EXAMPLE/config/KL.bin"     --commitment-id "$fp_id"     --range 60:64 --next-token 199 --end-token none     >"$FP_CASE/$fp_label.stdout" 2>"$FP_CASE/$fp_label.stderr"; then
    fp_rc=0
  else
    fp_rc=$?
  fi
  printf '%s\n' "$fp_rc" >"$FP_CASE/$fp_label.exit"
  printf '%s exit=%s\n' "$fp_label" "$fp_rc"
  tail -n 2 "$FP_CASE/$fp_label.stdout"
}
fp_check baseline "$FP_EXAMPLE/example.req" "$FP_ID"

這個函式只包裝官方命令、分開保存 stdout／stderr 與退出碼；它不會自動判定可以採用回答。官方原樣範例的預期是退出碼 0、倒數第二行含 result: outcome=verified，最後一行以 check_proof: verified: exact match: 開頭。若不一致，先保留紀錄並停下，別直接進入後續案例。

負例 1：「工作單換了」——只改請求副本的第一個 token

以下把第一個 32-bit token 改成相鄰數值，保留檔案長度與範圍；原始 request、proof 與權重不變。它測的是「原證明能否套到另一份輸入」，不是模型會不會答對題目。新檔用排他建立模式，遇到既有同名檔會停止。

python3 -I - "$FP_EXAMPLE/example.req" "$FP_CASE/changed.req" <<'PYREQ'
import struct, sys
from pathlib import Path
data = bytearray(Path(sys.argv[1]).read_bytes())
token = struct.unpack_from("<I", data, 0)[0]
struct.pack_into("<I", data, 0, token ^ 1)
with open(sys.argv[2], "xb") as out:
    out.write(data)
PYREQ
fp_check changed_request "$FP_CASE/changed.req" "$FP_ID"

官方 真實驗證器負例測試 明列更改 prompt token、checked token 與範圍等案例，預期拒絕。上述案例應按拒絕來驗收，實際退出碼與文字要以你保存的本次紀錄填寫；本篇沒有預填一份假想終端機輸出。

負例 2：「認錯收據對象」——換成錯誤 ID

fp_check wrong_id "$FP_EXAMPLE/example.req"   abababababababababababababababababababababababababababababababab

這仍是格式合法的 64 位十六進位字串，但不同於此範例的 ID。官方測試將這種情況列為 rejected；要保留「材料與你指定的 ID 不符」這個原因。不能看到拒絕就推論供應商蓄意作假，也可能是自己的版本或變數傳錯。

負例 3：「材料根本沒到」——指向不存在的請求檔

fp_check missing_request "$FP_CASE/not-created.req" "$FP_ID"

官方 整合腳本退出碼 將缺檔等環境問題歸為 2、error：這是沒有形成判決，並非證明已被數學駁倒。先確認該路徑確實不存在；如果它意外存在，這個案例就沒有測到「缺檔」。

若直接用 cp_verify，還會遇到 5 / NOT CHECKED，表示檢查未完成；官方只對 internal-stage 或 internal-exception-parFor 建議重試一次。14 / NOT-A-VERIFICATION 則表示呼叫不構成有效驗證。不要把它們塞進「模型錯誤」那一欄；完整原因可查 驗證器輸出規格。

四、從練習接到真實服務：你要自己帶來什麼？

CPU 小考最容易誤讀的一步，是把「整包檔案互相吻合」當成「品牌身分成立」。正式查核前，請按 官方接受規則 把責任分開：

• 先取得 ID 與配置：在送出 prompt 前，透過待驗伺服器無法控制的管道，向替模型背書的一方取得 ID。公開且有人監看的供應商發布頁可以是管道；它不是「必須與供應商毫無關係」的同義詞。
• 自己重建 token 工作單：使用模型公布的 tokenizer、chat template 與實際收送的 token IDs。驗證器不知道你原本送了什麼；拿對方附的 request 原封不動去驗，只證明那份 request。
• 先固定終止與覆蓋範圍：真實回答的 end-token IDs 來自公布的 generation_config.json。範例的 --end-token none 會略過結束檢查；不要直接搬去宣稱完整回答已驗。
• 先訂政策與假設：是否接受計入 proof of work、哪些定理與實作假設被採用，都要在驗之前決定。結果中的 bits 是程式逐輪計算值，不能直接寫成整體安全等級。

範例 60:64 也不是 Python 的切片。以 0 起算，它在 64-token request 裡檢查位置 61～63，另加 request 後面的 next token；不是「第 60 到第 64 個字」。因此要同時記下 range、next-token、claim、end_token 與自己的預期。

官方接受規則還要求核對 commitment 與 proof-of-work 行、配置及範圍等條件。範例預設會計入工作量，--no-proof-of-work 可以拒絕這類接受，但不能因為它擋住範例就事後移除選項「湊出通過」。綠燈代表你原先的條件成立，條件本身仍須說清楚。

五、exact match 與 clipped gap：同樣通過，承諾不同

exact match：指定範圍內，被檢查的 token 符合所承諾整數模型的貪婪選擇，也就是每一步選最高分 token。它不把現實世界的真相變成檢查項；模型算出錯年份，與那組權重計算相符這件事仍可能成立。

clipped gap：檢查的是分數差距經截斷後的平均成本與超限數量等政策條件。它容許與最高分選擇有落差，官方明說這比 exact match 弱。結果 within limits 要連同先訂的限制一起保存，不能改標為「逐字相同」。定義詳見 What is proved。

因此，一份合格運算證明不是任意 API 的隨插即用身分辨識器：要有相符模型與配置、可信 ID、自己的 token 紀錄和對應證明。若服務只回傳模型名字與自然語言，請先使用 模型供應商身分查核 的方法整理證據；不要宣稱已完成密碼學驗證。

要把它接入 Agent 系統，也應把「證明是否符合條件」和「產物是否做對」設成不同檢查。你可在 Agent Harness 實作 的驗收環節加入這兩道判斷；一個通過紀錄，不能順帶替後續工具權限與檔案結果打勾。

如果還不熟悉模型與執行層的分工，先讀 Agent Harness 入門，再把驗證器想成其中一道明確的檢查。更多概念與操作練習，可從 AlphaLab AI 教學入口挑選下一個問題。

常見問題：八個先講答案的判讀

1. CPU 範例通過，就證明我用到正版 Claude 嗎？

不能。這是合成權重範例，結論限於該組材料；品牌與 commitment 的對應還要有可信來源。

2. 我需要 H100 才能驗證嗎？

這條 CPU 範例路線不用。H100 是官方模型證明產生路線的條件，別把產生與檢查混在一起。

3. 退出碼 0，就能自動放行嗎？

不夠。以整合腳本為例，還要核對倒數第二行 outcome、ID、range、claim 及其他先訂條件；連 –help 都可能以 0 正常退出。

4. NO 就表示供應商造假嗎？

不一定。檔案、版本、呼叫或本機錯誤都可能造成拒絕；先追原因，再判斷責任。

5. NOT CHECKED 和 NO 一樣嗎？

不同。前者是未完成檢查，後者是拒絕或本機故障的判決類別；都不能當成已證明的回答。

6. clipped gap 是「差一點也算同一個答案」嗎？

不是這樣讀。它限制的是指定數學成本，不是語意相似度，也不是內容正確率。

7. 通過能表示整段回答已完整結束嗎？

不一定。要驗覆蓋範圍和 end token；本篇範例刻意使用 none，沒有檢查自然回答的結束。

8. 今天只有 Mac，可以先完成什麼？

可以先完成驗收表：寫下預期 ID、範圍、政策、來源與待填結果。等具備官方 Linux 條件再執行，未執行欄保持空白。

給新手的三個重點

• 先固定你要驗的材料與接受條件，再看結果；不要從輸出抄一個 ID 回去當信任依據。
• 先跑原樣，再一次改一項；把拒絕、輸入錯誤與未完成檢查分開。
• 運算相符、模型身分與答案品質是三個問題，每個問題都要有自己的證據。