Qwen3.8-Max 與十二天自主編程宣言

10 月 2 日，阿里巴巴的 Qwen 團隊發布 Qwen3.8-Max，這是一個 2.4 兆參數的混合專家模型；該公司形容它在法律、金融與設計等數百種任務類型上都具備足夠能力。最受關注的說法，其實比參數數量更狹窄。根據發布內容，這個模型可以自主進行程式開發超過十二天，交付一個完整專案。

參數數量早就不再是新聞了。「十二天」才是值得檢視的數字，因為它描述的能力類型，不同於多數模型出廠時附帶的示範。

一項任務與一個專案

多數程式模型的基準測試衡量的是單一工作單位：寫一個函式、修一個錯誤、回答一個關於程式碼庫的問題。時間跨度只有幾分鐘。能在這些測試中成功的模型，證明的是當問題被完整指定、結果可以一步檢查時，它能產出正確的輸出。

耗時十二天的專案，並不是更長的函式。它是一連串決策，每個決策都會限制下一個決策，而模型必須在數千次編輯中持續記住一個設計。失效模式也隨之改變。每一步正確率 95% 的模型，在五分鐘的任務裡是絕佳助手，在兩週的任務裡卻是負擔，因為錯誤會複合累積，而且沒有人盯著每一次編輯。

這就是為什麼時間跨度的說法比參數數量更重要。它把問題從能力轉移到可靠性。

有三件事必須奏效，而且它們都不是純粹的模型屬性。

記憶與狀態管理排第一。十二天的工作不可能塞進上下文視窗，無論視窗多大。系統必須把任務狀態外部化、把中間結果寫到磁碟，並在中斷後從檢查點恢復。這是模型周邊的基礎設施，其正確性決定長時間執行能否撐過重新啟動。

自我修正排第二。在長時程中，模型會走錯路。少了人類逐步審查，它需要一種方式察覺某個做法正在失敗，並在失敗擴散前修正。這意味著模型必須拿自己的中間輸出對照原始目標進行評估，而這比一開始生成輸出更困難。

工具穩定性排第三。一個多日專案會碰觸程式碼庫、測試執行器、文件，還可能有套件管理器。每一次工具呼叫，都是模型預期與環境回傳之間出現落差的機會。在數千次呼叫中，正是這個分布的尾部會終結整個執行。

綜合來看，十二天的說法是在陳述一個完整系統：模型加上執行框架再加上環境。這是解讀它的實用方式，因為它告訴你當它失敗時該去哪裡找問題。

發布時機並非偶然。代理研究者之間正有一場爭論：強大的模型還需要多少鷹架。問題在於，更好的模型是否會讓精心設計的代理框架過時，還是可靠性正是來自框架。

自主工作十二天的說法，站在這場爭論的一邊。它暗示模型能承擔負載，而框架只是配角。但上述三項需求指向相反結論：框架才是讓長時程得以成立的要素，模型只是其中的一個元件。

兩種解讀可以同時成立，而這大概也是最公允的說法。更強的模型會減少任務需要多少手把手引導，同時也提高一個打造精良的執行框架所能達成的上限。一個能在長時程上規劃的模型，在好的框架裡價值更高，而不是更低。

發布內容把程式開發與辦公室工作配成一對，而這個組合並非偶然。兩者都是輸出可檢查的類別，而這正是自主性可行的原因。試算表裡有公式錯誤可以被測試。合約少了條款可以對照檢查清單審閱。模型不必對世界大體正確，只要對一個有可驗證答案的任務正確即可。

這也是為什麼這個說法比乍聽之下更狹窄。一個能在程式碼庫上自主運行兩週的模型，不同於一個能在開放式研究問題上自主運行兩週的模型；後者的工作是否正確，要很久以後才有人能判斷。發布時的框架把承諾留在有回饋存在的領域內。

這樣讀，十二天這個數字既是關於能力的說法，也同樣是關於驗證的說法。時程越長，系統就越依賴能否檢查自己的工作。

選擇這兩個領域有商業邏輯。程式開發與辦公室工作，是企業已經有預算、而且輸出不需要專家也能評估的地方。一個能自動化兩週開發任務的模型，有可衡量的報酬。一個會寫詩的模型沒有。

忽略參數數量，去看三個具體細節。

問「自主」在實務上是什麼意思。十二天的執行若偶爾有人類檢查點，會是不同於完全無人看管的產品。公司很少說明檢查點在哪裡，而這個細節對實用性的決定程度超過總時長。

問這次執行產出了什麼。完成的專案是可測試的成品。一個儲存庫、一套通過的測試、一個可運作的部署，都可以驗證。截圖和旁白示範不行。

問它出錯時發生了什麼。長時間執行會失敗，而有趣的資訊在於如何失敗。一個能偵測到死路並回頭的模型，遠比一個硬著頭皮前進、產出看似合理卻跑不起來的結果的模型有用。

阿里巴巴推出旗艦模型，瞄準程式開發與辦公室工作，而非一般聊天，這是在表態價值所在。消費者聊天機器人市場擁擠且難以變現。企業願意付錢的工作，是能取代或擴增工時的工作，而這類工作有很長的時程。

如果十二天的說法即使只部分成立，實際效果就是小團隊可以嘗試過去需要更大團隊才能做的專案。如果不成立，這個模型仍然是一個具備大型上下文視窗的強大程式助手，而十二天這條說法會自己從行銷中淡出。無論如何，論述框架才是有用的部分。如今衡量能力，除了看模型一次能做什麼，也看它能不受監督地持續工作多久。