Anthropic 於二零二六年十月二十二日公布與 Theorem 合作的形式化驗證實驗結果，研究團隊以 Claude 為 123 個真實開源程式庫產生形式化證明，對象是編譯後的 RISC-V 機器碼，結論是這些程式在任何小於六十四 MB 的輸入下，於既定的 Linux 執行模型內不會觸發記憶體安全錯誤或斷言失敗。這是首次有團隊以大規模方式，把形式化驗證套用到生產級開源軟體的二進位層。

實驗規模寫得相當具體：239 個 OSS-Fuzz 進入點、合計約一億八千萬行 Rocq 證明碼，典型證明約六十萬行，所覆蓋的二進位檔中位數為一萬八千條 RISC-V 指令。

Claude 的形式化驗證實驗做了什麼？

研究團隊把開源專案既有的模糊測試轉換為形式化規格，再讓 Claude 對 RISC-V 編譯後的機器碼撰寫證明，並由 Rocq 證明檢查器逐項驗證，範圍涵蓋 123 個程式庫。

形式化驗證的傳統做法，是把程式碼翻譯成數學模型，再證明它永遠符合一組規則。這個過程在過去需要高度專業的人力，而且證明本身的長度往往是原始碼的許多倍。Anthropic 這次的實驗並沒有要求模型重寫程式，而是直接把編譯後的二進位檔當成證明對象，讓模型在機器碼層面推導行為。

選擇機器碼有兩個實際好處。第一，它繞過了「用另一種語言重寫整個專案」的前置成本，對於已經在生產環境運作的 C 與 C++ 程式庫尤其關鍵。第二，證明可以按套件為單位重複使用，同一個依賴只需要驗證一次，上層專案便能繼承結論。團隊在文章中把這一點與 Lean 生態的 Mathlib 相比：後者由七百多位貢獻者累積近三十萬條定理，每條新證明都建立在既有成果之上。

整體而言，這批工作的定位接近基礎建設，而非單一產品功能。Anthropic 公開了部分證明、RISC-V 與作業系統的形式語意，以及未能完成證明的規格清單，讓外部研究者可以自行檢查與延伸。

為什麼形式化驗證過去難以規模化？

證明長度可達程式碼數十倍，撰寫需要稀有專業技能。seL4 核心的實作耗費兩人年，形式化驗證卻用了二十人年，成本令多數專案無法負擔。

成本結構是主要障礙。文章引用 seL4 作業系統核心的例子：實作階段投入約兩個人年，形式化驗證階段則需要二十個人年。這種比例使得形式化方法長期只出現在航空電子、醫療器材與少數安全核心等領域，一般商業軟體難以採用。

第二個障礙是規格本身。要證明程式正確，首先必須定義「正確」是什麼。PNG 解碼器的行為可以依 RFC 2083 精確描述，但文字編輯器或瀏覽器的正確行為難以用單一形式規格涵蓋。規格不明確，後續所有證明都失去意義。

團隊處理規格問題的方式相當務實：把開發者已經寫好的模糊測試當成規格。OSS-Fuzz 的進入點本身就是一種宣告，任何導致崩潰的輸入都屬於缺陷。於是「這個進入點永遠不會崩潰」成為一條可證明的命题，而它同時覆蓋了壓縮解壓後還原、冪等性、差分測試等各種高階性質。

從測試到證明：這套流程如何運作？

流程先把程式與模糊測試編譯成 RISC-V 執行檔，結合作業系統語意產生規格，Claude 撰寫 Rocq 證明，檢查器若不通過便回頭修正，直到規格被滿足。

具體步驟可以分成四層。第一層是編譯，程式庫與它的模糊測試一併編譯為 RISC-V 執行檔，並以 AddressSanitizer 插樁，使不當記憶體存取直接觸發崩潰。第二層是建模，Theorem 提供 RISC-V 指令集與 Linux 行程的形式語意，把二進位檔轉換成可供推理的數學物件。

第三層是撰寫，Claude 在規格約束下產生 Rocq 證明。若證明失敗，失敗的性質本身會指向可能的缺陷位置，模型可以修改程式碼、重新產生規格、再繼續證明。第四層是檢查，Rocq 核心獨立驗證證明是否真的滿足規格，開發者不需要逐行閱讀那六十萬行證明碼。

需要信任的環節因此被壓縮到三項：RISC-V 與 Linux 行程的形式模型、被證明的定理敘述、以及 Rocq 檢查器本身。這個設計承認了信任基礎無法完全消除，但把它從「每一行業務程式碼」縮小到「少數共用元件」，而共用元件只需強化一次，就能服務任意數量的專案。

Claude 在這個過程中找到哪些錯誤？

模型在證明過程中發現數百個缺陷，包括需要約二十 MB 特定佈局輸入的越界寫入、需要六十四 MB 輸入的越界讀取，以及 libexpat 的 CVE-2026-56132。

這些缺陷的共同特徵是難以被模糊測試觸及。團隊指出，模糊測試的輸入通常上限為一百萬位元組，並依賴覆蓋率引導，因此對「需要極大輸入且佈局罕見」的路徑幾乎無效。其中一個案例發生在某個解壓縮器的副本中：計數器下溢導致越界寫入，只有在約二十 MB、具備特定結構的輸入下才會出現。

另一個案例出現在影像解碼器，越界讀取需要六十四 MB 輸入與超過 2 GB 記憶體才會觸發。還有程式庫需要對同一個檔案建立兩個控制代碼，並以特定順序呼叫才會出錯。團隊亦在 libexpat 重新發現 CVE-2026-56132，該缺陷需要深度嵌套的輸入。

並非所有發現都會造成崩潰。Claude 在證明某個程式庫的記憶體安全時注意到，一項限制應用程式可載入檔案的功能並沒有在所有路徑上生效。這類邏輯缺陷不會被記憶體檢查工具捕捉，卻直接影響安全邊界。團隊的結論是：即使最終證明未能完成，嘗試證明的過程本身就會產出真實可修的錯誤。

這項成果有什麼限制？

證明僅覆蓋單執行緒、靜態連結的 RISC-V 二進位檔，實際部署多用 x86 或 ARM 並動態連結 glibc；ASan 也無法偵測所有記憶體缺陷，並非每個進入點都已驗證。

最直接的落差在執行環境。證明假設程式是單執行緒、靜態連結的 RISC-V 二進位檔，配固定的記憶體預算；現實中多數使用者執行的是 x86 或 ARM 版本，並動態連結 glibc。要收窄這個差距，需要為更多架構與作業系統行程建立精確語意，這是可以逐步補上的工程，但目前尚未完成。

第二項限制關於覆蓋範圍。團隊證明了許多進入點在六十四 MB 以內輸入下不會崩潰，但沒有驗證每個程式庫的所有進入點，也無法涵蓋未被呼叫的死碼。AddressSanitizer 本身也無法偵測所有記憶體安全問題，因此「通過證明」並不等於「沒有缺陷」。

第三項限制涉及呼叫端。證明只描述程式庫自身的行為，若上層程式誤用介面，仍可能在呼叫端造成記憶體損壞。要處理這一點，必須為每個公開函式訂明呼叫者義務，並要求呼叫端嚴格遵守。

成本則是第四項限制。單一證明的生成可能消耗數億個 token。團隊量測了 36 個小型驗證任務，發現 Opus 5.5 在 token 用量比 Opus 5 少約四成的條件下，能完成其中一半的任務；多個代理共用同一份證明工作區時，整體 token 需求再降約一成七。趨勢指向成本下降，但現階段仍屬昂貴操作。

開發者可以如何開始？

Theorem 提供代跑流程的服務，並公開一個 Claude skill 協助開發者驗證自家程式碼。Anthropic 亦釋出部分證明與形式語意，供外部檢查與重用。

對於想嘗試的團隊，最實際的入口是從既有的模糊測試開始。若專案已經有 OSS-Fuzz 進入點，表示「什麼算錯誤」已被明確定義，這正是形式化驗證最需要的規格基礎。反之，若專案連模糊測試都沒有，先補上測試會比直接進入證明划算。

第二個建議是從依賴鏈下手。文章提到依賴呈冪律分佈，驗證少量共用程式庫就能覆蓋大量上層軟體。Theorem 的長期路線圖以 Nix 生態為對象，優先處理 glibc、OpenSSL、cURL 等關鍵基礎元件，這個順序值得其他團隊參考。

第三個建議關乎心態。團隊明確指出，「已形式化驗證」不等於「沒有缺陷」，它只表示程式在既定規格與機器模型下符合要求。若規格與現實脫節，缺陷仍會存在，只是位置轉移到模型假設裡。把驗證當成縮小搜尋範圍的工具，而不是終點，會更接近實際情況。

這對軟體供應鏈安全意味著什麼？

形式化證明可在二進位層為依賴項提供可檢查的安全保證，並容許按套件重用，令上游一次驗證、下游繼承結論，降低整體稽核成本。

軟體供應鏈的風險往往集中在少數被廣泛引用的底層程式庫。當這些程式庫能以套件為單位取得證明，下游專案就不需要重複稽核同一份程式碼，只需確認自己使用的版本與被證明的版本一致。這種模式在數學生態已運行多年，搬到系統軟體上是合理的延伸。

不過，證明的有效期取決於版本管理。任何原始碼變更都會使證明失效，因此需要把證明生成納入發布流程，而非一次性的專案。團隊在實驗中觀察到代理會複製彼此已完成的證明並改寫，這種重用行為正是把成本攤平的關鍵。

對企業而言，短期內較可行的做法，是針對最關鍵的依賴要求供應商提供驗證狀態，並把「是否具備形式化保證」納入採購評估。長期來看，若工具鏈成熟到能自動化整個流程，驗證狀態可能成為套件metadata的一部分，如同今日的簽章與雜湊值。

總結：形式化驗證會成為標準流程嗎？

短期內不會全面普及，成本與環境假設仍是門檻。但證明可重用、模型效率持續改善，關鍵基礎元件最可能先被納入驗證流程。

這次實驗的意義，在於把形式化驗證從「專家數年的人工投入」推進到「模型數週的自動產出」。一億八千萬行證明碼本身不是重點，重點是其中絕大多數不需要人手審閱，開發者只需信任少數共用元件。這種分工讓驗證的邊際成本隨著生態成熟而下降。

同時必須看清界限。證明覆蓋的是特定架構、特定執行模型與特定輸入上限，規格與現實之間的落差仍然是缺陷的來源。把形式化方法視為測試的補強，而非取代，才不會對安全保證產生錯誤期待。

對於關注供應鏈風險的團隊，現在值得做的是盤點依賴、確認既有測試的品質，並追蹤 Theorem 與 Anthropic 釋出的工具。等到流程穩定，先行者已經具備可重用的證明資產。

出處連結有哪些？

主要出處為 Anthropic 研究文章與 Theorem 官方網站，另引 Google OSS-Fuzz 與 Rocq 證明助理的專案頁面，可對照方法與工具鏈細節。