Anthropic 的 Frontier Red Team 與形式化方法合作夥伴 Theorem 表示，Claude 為 123 個開源程式庫中的 239 個模糊測試入口，產生了經機器檢查的證明。這些證明針對特定編譯後的 RISC-V 程式，以及明確界定的當機與記憶體安全性質；不能據此推論相關程式庫在所有情況下都沒有 bug。95

這項工作的規模引人注目：團隊表示，整個過程歷時數週，產生約 1.8 億行 Rocq 證明程式碼。更值得關注的，是 AI 協助能否讓形式化驗證應用到更多實際軟體；但每項結論仍須以實際寫下並檢查的規格與條件為準。313

這些證明究竟證明了什麼？

Anthropic 表示，在特定假設下，對於所有小於 64 MB 的輸入，以及模型所涵蓋的 Linux 作業系統回應與記憶體配置，受驗證程式都會正常結束，不會觸發記憶體安全錯誤或未通過的斷言。證明的對象是編譯後的 RISC-V 執行檔，不是對每個程式庫版本或實際部署環境的概括保證。912

團隊將既有的 Google OSS-Fuzz 測試入口轉用為形式化規格。模糊測試會嘗試大量輸入；這套流程則讓 Claude 為指定的二進位程式產生證明，涵蓋定理所列範圍內的所有輸入。313

Anthropic 將這項工作描述為首次大規模運用 AI，在組合語言層級形式化驗證生產軟體。這是團隊對計畫創新性的說法，並非已獲獨立確立的歷史共識。713

為什麼 Rocq 檢查器很重要？

Claude 負責產生證明，Rocq 的證明核心則負責檢查。開發者因此不必單靠相信 Claude 的推理，也不必逐行人工審閱，才能確認證明是否通過機器檢查。不過，機器檢查並不會消除所有前提：定理必須描述開發者真正關心的性質，而形式化模型與檢查器也仍屬於可信賴基礎的一部分。95

Anthropic 與其他報導提到，證明產物約有 1.8 億行 Rocq 程式碼，平均每個二進位程式約 60 萬行。龐大的程式碼量反映了工作的規模，但光看行數，無法判斷某項性質適用範圍有多廣，也無法說明它是否符合實際產品需求。312

測試可能漏掉什麼？這次報告了哪些發現？

模糊測試會執行大量輸入，但本身無法證明在特定範圍內的每一種可能輸入都會得到安全結果。相關報導指出，Claude 在這項工作中找出並修補數百個 bug，其中包括經過數兆次模糊測試仍未被發現的問題。這些是本次計畫的報告數據，不能直接視為形式化驗證在其他專案中勝過測試的普遍衡量結果。211

實際上的啟示不是要取代測試，而是形式化證明可以提供另一種證據：針對明確寫出的性質與範圍，它能證明符合規格的所有輸入都具有指定行為，而不只是測試中實際跑過的案例。92

「已驗證」不等於「完全沒有 bug」

保證僅適用於選定的測試入口與特定編譯產物，不會自動涵蓋程式庫的每個函式、建置設定、處理器架構或使用方式。95

執行條件同樣重要。相關報導指出，證明適用於單執行緒、靜態連結的 RISC-V 二進位程式，在經模型化的 Linux 環境與固定記憶體預算下執行。許多軟體使用者實際執行的建置版本採用不同架構或設定，因此不應把這項結果當成那些部署版本也已獲保證。122734

此外，證明成立代表寫下的定理成立，並不代表開發者可能在意的所有性質都已涵蓋。規格範圍以外仍可能有 bug；形式化模型與證明檢查基礎本身，也仍是結果所依賴的環節。531

開發者可以怎麼看待這項成果？

這項工作的核心意義，是顯示 AI 協助或許能讓組合語言層級的形式化驗證，擴展到比過去更多的實際軟體，而不必完全仰賴大量專家投入。它並未提供適用於所有專案的成本估算，也不保證這套方法一定能在任何程式碼庫上奏效。713

目前公開的證明產物只是部分成果；一則報導指出，公開內容涵蓋 25 個程式庫與 60 個測試入口，並非整個計畫的完整結果。Theorem 也宣布推出 OSS Verify，提供一項面向開源維護者的計畫。321638

對開發者而言，較穩妥的做法是把證明視為有範圍的保障：先確認它涵蓋哪個測試入口、哪個編譯產物、採用了哪些假設，以及證明的具體性質。這項成果值得讓 LLM 輔助的形式化驗證成為測試之外的評估選項，但不代表可以停止測試，更不代表軟體已經沒有 bug。95

Anthropic 的 Frontier Red Team 與形式化方法合作夥伴 Theorem 表示，Claude 為 123 個開源程式庫中的 239 個模糊測試入口，產生了經機器檢查的證明。這些證明針對特定編譯後的 RISC-V 程式，以及明確界定的當機與記憶體安全性質；不能據此推論相關程式庫在所有情況下都沒有 bug。95

這項工作的規模引人注目：團隊表示，整個過程歷時數週，產生約 1.8 億行 Rocq 證明程式碼。更值得關注的，是 AI 協助能否讓形式化驗證應用到更多實際軟體；但每項結論仍須以實際寫下並檢查的規格與條件為準。313

這些證明究竟證明了什麼？

Anthropic 表示，在特定假設下，對於所有小於 64 MB 的輸入，以及模型所涵蓋的 Linux 作業系統回應與記憶體配置，受驗證程式都會正常結束，不會觸發記憶體安全錯誤或未通過的斷言。證明的對象是編譯後的 RISC-V 執行檔，不是對每個程式庫版本或實際部署環境的概括保證。912

團隊將既有的 Google OSS-Fuzz 測試入口轉用為形式化規格。模糊測試會嘗試大量輸入；這套流程則讓 Claude 為指定的二進位程式產生證明，涵蓋定理所列範圍內的所有輸入。313

Anthropic 將這項工作描述為首次大規模運用 AI，在組合語言層級形式化驗證生產軟體。這是團隊對計畫創新性的說法，並非已獲獨立確立的歷史共識。713

為什麼 Rocq 檢查器很重要？

Claude 負責產生證明，Rocq 的證明核心則負責檢查。開發者因此不必單靠相信 Claude 的推理，也不必逐行人工審閱，才能確認證明是否通過機器檢查。不過，機器檢查並不會消除所有前提：定理必須描述開發者真正關心的性質，而形式化模型與檢查器也仍屬於可信賴基礎的一部分。95

Anthropic 與其他報導提到，證明產物約有 1.8 億行 Rocq 程式碼，平均每個二進位程式約 60 萬行。龐大的程式碼量反映了工作的規模，但光看行數，無法判斷某項性質適用範圍有多廣，也無法說明它是否符合實際產品需求。312

測試可能漏掉什麼？這次報告了哪些發現？

模糊測試會執行大量輸入，但本身無法證明在特定範圍內的每一種可能輸入都會得到安全結果。相關報導指出，Claude 在這項工作中找出並修補數百個 bug，其中包括經過數兆次模糊測試仍未被發現的問題。這些是本次計畫的報告數據，不能直接視為形式化驗證在其他專案中勝過測試的普遍衡量結果。211

實際上的啟示不是要取代測試，而是形式化證明可以提供另一種證據：針對明確寫出的性質與範圍，它能證明符合規格的所有輸入都具有指定行為，而不只是測試中實際跑過的案例。92

「已驗證」不等於「完全沒有 bug」

保證僅適用於選定的測試入口與特定編譯產物，不會自動涵蓋程式庫的每個函式、建置設定、處理器架構或使用方式。95

執行條件同樣重要。相關報導指出，證明適用於單執行緒、靜態連結的 RISC-V 二進位程式，在經模型化的 Linux 環境與固定記憶體預算下執行。許多軟體使用者實際執行的建置版本採用不同架構或設定，因此不應把這項結果當成那些部署版本也已獲保證。122734

此外，證明成立代表寫下的定理成立，並不代表開發者可能在意的所有性質都已涵蓋。規格範圍以外仍可能有 bug；形式化模型與證明檢查基礎本身，也仍是結果所依賴的環節。531

開發者可以怎麼看待這項成果？

這項工作的核心意義，是顯示 AI 協助或許能讓組合語言層級的形式化驗證，擴展到比過去更多的實際軟體，而不必完全仰賴大量專家投入。它並未提供適用於所有專案的成本估算，也不保證這套方法一定能在任何程式碼庫上奏效。713

目前公開的證明產物只是部分成果；一則報導指出，公開內容涵蓋 25 個程式庫與 60 個測試入口，並非整個計畫的完整結果。Theorem 也宣布推出 OSS Verify，提供一項面向開源維護者的計畫。321638

對開發者而言，較穩妥的做法是把證明視為有範圍的保障：先確認它涵蓋哪個測試入口、哪個編譯產物、採用了哪些假設，以及證明的具體性質。這項成果值得讓 LLM 輔助的形式化驗證成為測試之外的評估選項，但不代表可以停止測試，更不代表軟體已經沒有 bug。95