AesCode 32B vs Muse Code：海報引擎與終端機代理並非競爭對手

AesCode 32B 與 Muse Code 會被拿來比較，是因為兩個名稱都含有「code」這個字，而這幾乎是它們唯一的共同點。AesCode 32B 是 Microsoft 用於產生可編輯 HTML 與 CSS 的研究檢查點——簡報、海報、儀表板、報告——以 Apache 2.0 授權發布於 Hugging Face，該儲存庫建立於 2026 年 9 月 29 日，而帶有「Release AesCode-32B」名稱的提交則標註日期為 2026 年 10 月 7 日。Microsoft 並未對外發布任何相關消息：沒有發布貼文、沒有新聞稿，模型卡本身也未載明發布日期。Muse Code 根本不是模型。它是 Meta 的終端機程式碼代理，自 2026 年 8 月初起進入 beta 階段，時間都花在對儲存庫執行 shell 命令上。前者產出的是你在瀏覽器中開啟的檔案。後者則持續執行命令，直到測試通過為止。在兩者之間做選擇，並不是一項模型層面的決定，而這個頁面能發揮的用處，就是阻止你把它當成那樣的決定來做。

每個實際上是用來做什麼的

AesCode 32B 以 Qwen3-VL-32B-Instruct 為起點，根據其模型卡所述，其訓練方式是先以 3,000 個示範進行冷啟動監督式微調，接著進行涵蓋七個獎勵通道的 GDPO 強化學習——執行、文字、邊界、表格／圖表、版面配置、空白與設計。其中六個通道是確定性驗證器；第七個則是視覺語言評審，依據與目標頁面的「設計圖」相繫的逐樣本評分規準運作。每個候選輸出都會在阻擋外部請求的沙箱化 Playwright 瀏覽器中渲染，然後依據 DOM、計算樣式、邊界框與螢幕截圖進行評分。預期的輸出在模型卡上有明確列出：可編輯的簡報、海報、儀表板與報告，以及多模態程式碼生成的研究。該模型會輸出完整的 HTML 文件，並經過訓練以使用真正的 HTML 表格結構與 ECharts 規格，使其輸出保持可檢查性。

Muse 在結構上做了不一樣的事。它是 macOS 和 Linux 的原生二進位檔，具備主要代理迴圈、會在工作階段中持續蒐集脈絡的非同步背景代理、隔離的 Git 工作樹讓子代理不會互相衝突，以及本機事件日誌，讓當機的工作階段能夠重新執行或恢復。Meta 自家的報告指出，它會在長達數小時的時間內寫下數千次工具呼叫。真正被販售的是那個迴圈，而不是產出物。

把兩者並列來看，動詞並不相符。AesCode 32B 負責渲染。Muse Code 負責執行。如果你的問題是「我們的季度簡報要讓設計師花上三天」，Muse Code 派不上用場，而 AesCode 32B 正是針對這個問題而來。如果你的問題是「沒有人想在週末升級這棵依賴樹」，AesCode 32B 沒什麼可說，Muse Code 才是對的工具。

雙方各自的證據並不是同一種類型的證據

這是每個比較頁面都會弄錯的部分，所以值得慢慢細究。

AesCode 32B 的數據來自一項 300 個樣本的資訊圖表評估，每個提示詞生成三次且不做挑選，而這些數據本身就相當亮眼：整體得分 85.89，對比 GPT-5.5 的 81.28 與 Claude Opus 4.8 的 80.39，這兩者都是透過 Microsoft 自家測試框架、以相同的參考圖設定測得。該卡片也指出，嚴重的畫布邊界失敗在 4.3% 的樣本中反覆出現，而 GPT-5.5 為 34.7%；此外，AesCode 32B 在其自身的 Qwen3-VL-32B 骨幹模型之上，於視覺維度高出 22.4 分、整體高出 24.8 分。

請把這一切都視為廠商自行回報且未經重現。該基準測試、訓練該模型的獎勵通道，以及為其評分的指標，都出自同一間實驗室之手，而那 300 個樣本則是微軟的。這並不是否定該結果的理由——這項評估異常透明，驗證器堆疊是公開的，而且模型卡公布了一個沒有任何模型能突破 60 分的維度（「style」，其中沒有任何項目得分高於 55.99），這一點所展現的誠實勝過大多數廠商的表格。但這正是不要將 85.89 與另一間實驗室在不同任務上產生的數字並列、並假裝進行了比較的理由。

Muse Code 的數字又是另一種意義上的「由 Meta 回報」：它們量測的是模型加上測試框架（harness）的整體表現。Meta 回報 Muse Code 在 Terminal-Bench 2.1 上拿下 82.9%，僅次於 Claude 5 搭配 Claude Code 的 86.7%，另外在 DeepSWE 1.1 上為 59.6%，在內部程式編寫評測上則為 70.6%。由於那張表中不同的模型搭配了不同的測試框架，你無法從系統的總分中讀出模型本身的貢獻。而且 Muse Code 的評測項目與 AesCode 32B 的評測項目之間完全沒有重疊——前者評的是終端機任務與軟體工程，後者評的是資訊圖表的文字是否清晰可讀、版面是否不會溢出。

「一個 32B 檢查點」隱藏了什麼？

部署正是兩款產品分野最明顯之處，而簡短版本用項目符號清單就能交代清楚。

• 這是什麼 — AesCode 32B：一個可供下載的 33B 參數模型檢查點。Muse Code：一款可安裝的終端機代理產品。

• 授權 — AesCode 32B：Apache 2.0，包含權重。Muse Code：專有；其背後的模型是封閉的。

• 你需要提供什麼——AesCode 32B：一張 GPU 與一套服務堆疊。Muse Code：一組 API 金鑰或一份訂閱。

• 硬體門檻 — AesCode 32B：該卡建議光是 bf16 參數就需規劃約 65 GB 的加速器記憶體，而它自身的 serving 範例採用四路張量平行。Muse Code：一台筆電。

• 背景 — AesCode 32B：在回報的配置中為 24,576 個 token，在 RL 訓練期間提示與回應則上限為 8,192。Muse Code：透過其底層的 Muse Spark 模型提供 1M token 的視窗。

• 價格 — AesCode 32B：權重免費；成本在於硬體。Muse Code：按 token 計費，或透過月費方案。

• 證據 — AesCode 32B：廠商自行在其自家 300 個樣本上執行的評估，並公開測試框架。Muse Code：Meta 報告的系統層級基準測試，針對代理與模型耦合的堆疊。

「硬體門檻」那一列，正是大家會直接跳過的那一列。在 bf16 下，32B 的檢查點並非筆電能跑得動的模型，而 AesCode 32B 更是在此之上的視覺語言模型，因此推論服務路徑還得承載影像輸入。Muse Code 則是一個花個下午就能裝好的執行檔。

在它們真正重疊的地方

真正的重疊只有一個，而且範圍很窄：兩者都可以被指向某個與設計相鄰的成品，並被要求產出人類會再進一步精修的東西。如果你的團隊正以程式碼形式產生內部儀表板，同時又想要一個能對儀表板儲存庫發出 pull request 的代理，那麼這兩款產品都會觸及那個工作流程。

即使在那裡，分工也很清楚。AesCode 32B 產出成品。Muse Code 產生變更。一條兩者兼具的管線，會呼叫 AesCode 32B 來渲染，再把產生的檔案交給代理程式去放置、接線並測試——而這兩個產品都不會阻礙這樣做，因為它們從來不曾競爭同一個位置。

這場對戰中你今天能預測的那一半

這裡有一個值得直說的實際不對稱。AesCode 32B 並未由任何推論服務供應商部署。Hugging Face 卡片上沒有列出任何託管端點、沒有合作夥伴，也沒有 API；如果你想使用它，就得下載 65 GB 的權重，並自行建置服務路徑。對研究發布而言，這是常態，而這也是橫亙在該模型與任何沒有八張 GPU 的人之間最大的單一障礙。

Muse Code 的底層模型並沒有那個問題。Muse Spark 系列是以單純的 API 模型形式提供，而Muse Spark 1.2 已在 OrcaRouter 目錄上，並依 Meta 的定價表計費：每百萬輸入 token 1.25 美元、每百萬輸出 token 4.25 美元——供應商定價原樣傳遞，我們這邊不加價，因此 Meta 的價格變動在同一天就會反映到這裡。一組金鑰就能連同 200 多個其他模型一起使用，若供應商出狀況還會自動容錯移轉，這正是「我們可以試試看」和「我們可以把它放上正式環境路徑」之間的差別。如果你真正想從這個頁面得到的，是不採用 Muse Code 產品、也能使用 Muse Code 內部智慧的方式，那就是這條路，而且它確實存在。如果你想要的是 AesCode 32B，那條路就是下載。

該選哪個

如果成品本身才是重點，就選 AesCode 32B。你正在大量製作簡報、報告、海報或儀表板，你擁有硬體，或願意租用硬體，而且一個能輸出結構化、可編輯 HTML 的模型——表格就是表格、圖表是 ECharts 規格、所有內容都能在 Git 中進行差異比對——其吸引力值得一套研究級的服務設定。接受你是這款未發表、下載次數少的模型的早期採用者，沒有獨立實驗室重現其分數，而且其 24K 上下文對長文件而言是一項真實限制。

如果過程才是重點，就選 Muse Code。你想要一個能在終端機裡執行的代理，能在工作階段中途當機後存活下來，還能同時在各自隔離的工作樹中hold多個工作流程，而且你願意為此按 token 計費或按月付費。

兩者都別選，直接路由到 Muse Spark 1.2；如果你要的是一個位於 API 金鑰背後、能力強大的推理模型，而終端機框架從來就不是你想要的那一部分。

什麼會改變這個頁面

有三件事。如果有推論服務供應商採用 AesCode 32B——或 Microsoft 發布託管端點——部署欄就會崩解，這個模型也會變成你一個下午就能評估完的東西，而這會讓設計密集型團隊面對的問題接近許多。如果有獨立評估重現 85.89 的整體分數與 4.3% 的邊界失敗率，證據不對稱的情況就會大幅縮小。而如果 Meta 開源 Muse Spark 的權重，「你可以下載其中一個，卻不能下載另一個」這種說法就會徹底消失。在上述任一情況發生之前，最誠實的總結是：這兩個產品共用的是一個詞，而不是一項工作。