AlphaProof Code 對決 AesCode 32B：一個證明程式碼正確，另一個把它畫出來

把 AlphaProof Code 和 AesCode 32B 放在同一個句子裡，它們唯一共同的地方就是「code」這個詞。AlphaProof Code 是 Google DeepMind 於 2026 年 11 月 10 日發表的代理式框架，產出了約 650 萬行經機器檢查的 Lean 證明，證明編譯後的 libsignal 二進位檔行為符合規格。AesCode 32B 是一個 330 億參數的視覺語言檢查點，Microsoft 在 2026 年 10 月初未發布任何公告就上傳到 Hugging Face，它會把提示詞寫進單一自包含的 HTML 文件——一張投影片、一張海報、一個儀表板——再由人類查看。這兩者都不是你能呼叫的服務。其中一個甚至不是模型。如果你來到這裡是想找可直接替換的決策，誠實的答案是：不存在這樣的決策，而本文其餘部分會說明為什麼這個比較仍然值得做。

範疇錯誤，恰當地表述

AesCode 32B 是一個生成器。你給它一段描述，它會回傳一件成品，其品質以美學來評判，也取決於頁面上的數字是否恰好就是你要求的那些數字。模型卡本身的說法是：圖像生成器能組成漂亮的頁面，卻會把頁面上的數字畫錯；而程式碼模型能把數字弄對，卻看不出頁面好不好看——AesCode 會將你的提示詞與根據同一個提示詞生成的圖像配對，並以該圖像作為美學參考，同時依文字來決定內容。

AlphaProof Code 是一個驗證器。你給它一份規格——一項必須成立之陳述——它就會回傳一個由 Lean 核心檢查過的證明，證明某個特定編譯後的二進位檔滿足該規格。整個流程中沒有任何美學判斷。證明要麼被接受，要麼不被接受，而接受標準是幾千行的核心程式碼，而不是審查者的品味。

這個區別決定了兩者各自的用途。AesCode 32B 回答的是「幫我做個東西」；AlphaProof Code 回答的是「這東西是否真是它宣稱的樣子」。你會在某個週二下午用第一個來做一份簡報；而如果你是 Signal，則會用第二個，花上四週，動用五位研究員，以及多支由 40 到 80 個代理組成的團隊。

每一個實際上會出貨的內容

• 參數 — AesCode 32B：在 BF16 下約有 334 億個參數，分佈於十四個 safetensors 分片，總計 66,714,912,704 位元組。AlphaProof Code：無。它是一個框架，外加一個產物儲存庫，沒有可供下載的權重。

• 基礎 — AesCode 32B：這是 Qwen3-VL-32B-Instruct 的微調版本，架構宣告為 Qwen3VLForConditionalGeneration，因此可在 transformers 4.57 及更新版本中載入。AlphaProof Code：從設計上即與模型無關；DeepMind 論文指出，證明代理使用的是 G​emini 4 Carbon，並表示 Claude Opus 5.5 是起草與審查規格的模型之一。

• 授權條款 — AesCode 32B：Apache 2.0，今日已在 Hugging Face 上發布。AlphaProof Code：Lean 開發、AArch64 語意與 libsignal 綁定已發布於 github.com/google-deepmind/code-verification，而其著陸頁未標示授權條款，你應在以其為基礎建置任何內容之前先解決此事。

• 可用性 — AesCode 32B：僅限自行託管。權重約需 65 GB 加速器記憶體，需在四個 tensor-parallel rank 上執行 vLLM 指令；沒有託管端點，且儲存庫頁面背後沒有推論供應商對應。AlphaProof Code：研究產物，沒有端點、沒有候補名單、沒有定價。

• 輸出 — AesCode 32B：一份 HTML 文件，可透過開啟它來檢查。AlphaProof Code：一個 Lean 證明項，可由 Lean 檢查。

• 「正確」代表什麼——AesCode 32B：頁面看起來正確，且數字與提示相符，由人來判斷。AlphaProof Code：定理對模型中的所有輸入都成立，由核心來判斷。

唯一真正有趣的重疊是：兩者的輸出都是產物

這才是值得做的比較。兩個系統都會產出一個比生成它的模型更長壽的檔案。AesCode 32B 的 HTML 是一份完成的文件；你可以交付它、編輯它、對它做 diff，而且再也不需要那個模型。AlphaProof Code 的 Lean 證明是一份完成的推導；你可以在筆電上用幾分鐘的運算重新檢查它，而且如果規格沒有改變，這個結果五年後依然成立。

在充斥聊天端點的市場裡，這項特性比聽起來更罕見。大多數模型輸出都是用完即丟的文字，其價值取決於模型是否仍可用。這兩者都會產出你能保留的東西。差別在於「保留」為你換來什麼：使用 AesCode，你保留的是一套簡報；使用 AlphaProof Code，你保留的是一項保證。

類比失效之處在於可審計性。任何人都能打開 HTML，查看標題是否錯誤。幾乎沒有人能打開 650 萬行 Lean，看出該定理是否真的如新聞稿所言——這正是為什麼 DeepMind 的論文花了好幾頁，列舉其可信基底、37 個受契約約束的原語，以及它不證明的性質。此產物可被檢查；但對它的解讀並非沒有代價。

兩邊的數字各值多少

AesCode 32B 的標題亮點是整體分數 85.89，對比 GPT-5.5 的 81.28——這是 Microsoft 對競爭對手模型的測量，使用 Microsoft 撰寫的評分量表，以及 Microsoft 建置的評測框架。Boundary 為 97.27，且有 4.3% 的樣本出現嚴重溢出；style 為 55.99，而表中沒有任何模型在該列突破 60。根據該儲存庫自身的計數器，Microsoft 以外尚無人發表該模型的數字。上述每一項數字皆為廠商回報，且未經重現。

AlphaProof Code 完全沒有基準測試表，而這並不是報告上的缺口——而是另一種主張。結果是：某個特定二進位檔滿足十條符號定理，以及一條帶有具體界限的計算軌。你可以不同意規格，但你不能質疑核心對該證明的裁決。可比的注意事項是結構性的，而非統計性的：SPQR 修復沒有後量子保證、沒有載荷隱私、未升級的首次訊息沒有回應者驗證、每次升級只有一個工作階段、訊息長度固定、沒有多裝置狀態。還有一個 MAC 偽造界限，在單一工作階段中約 25,000 則訊息時會變得空洞。

有一個數字確實能有效地跨領域套用。AlphaProof Code 的驗證花了四週，而同等級的工作在歷史上往往要專家團隊花上數年；相較之下，論文自己引用的基準是 seL4 約 20 人年、CompCert 約 6 人年。那個比例才是應該牢牢抓住的主張，而且它關乎工作流程，不關乎模型品質。

這週你實際上能執行哪一個？

AesCode 32B：可以，前提是你有相應的硬體。下載各個分片，在四個 rank 上以 vLLM 提供服務，讓提示詞維持在該顯示卡 24,576 個 token 的上限之內，並接受你的審查步驟就是由人瞇著眼盯著渲染後的 HTML。它不會告訴你頁面是否正確；它會告訴你頁面看起來是否正確。

AlphaProof Code：沒有。已發布的成果是一套 Lean 開發內容，而不是讓你直接呼叫的管線。甚至其中的模型也不是交付項目——該框架是一項研究建構，而 DeepMind 自己的說法是，擴展它「需要持續研究」。CodeMender 是自動修復的姊妹專案；驗證與補救在該實驗室的路線圖中是兩個不同的產品。

如果你想要的是一個能起草規格的模型——也就是人類專家把 Signal 的安全目標轉譯成 Lean、再逐一審閱的那個步驟——那屬於一般的模型工作，而Claude Opus 5.5 已列於 OrcaRouter 的目錄，價格為每百萬輸入 token 4 美元、每百萬輸出 token 20 美元，並以 0% 加價原樣轉嫁供應商定價。讓規格起草迴圈在兩、三個模型之間路由，並比較它們的 Lean 輸出，是一次路由 DSL 呼叫，而不是一項研究專案。以上這些都無法給你證明；證明步驟才是那六百萬行的來源。

為什麼這組配對無論如何都值得發布

因為「程式碼模型」已經變成一個沒有下限的類別。一個會寫投影片的模型，和一個能證明訊息傳遞協定的框架，都被歸到這個類別底下，而買家在排行榜上比較它們時，什麼也學不到。有用的問題不是哪一個比較好——而是你能為輸出取得什麼證據。AesCode 32B 給你一個渲染後的頁面和一份廠商評分規準。AlphaProof Code 給你一個經核心檢查的推導，以及一份異常明確的假設清單。這兩者之中，有一種能擴展到你寧可不願出錯的程式碼，而那不是參數量較大的那一個。

如果你是在為設計流程評估 AesCode 32B，要測試的不是它的整體分數，而是它的邊界行為——4.3% 的嚴重溢出率，正是簡報會悄悄變得錯誤、而不是單純變難看的所在。如果你是在評估 AlphaProof Code，要讀的是產物儲存庫中的規格偏差目錄：超過 200 筆計算條目與約 35 筆符號條目，其中十五筆是 Double Ratchet 分析中的缺口或錯誤。那份目錄是此次發布中最誠實的文件，因為它列出了證明未能補上的所有事項。