近日，OpenAI 早期核心成員之一，Vibe Coding 概念提出者 Andrej Karpathy 在社交媒體 X 上(原 Twitter）提出了關(guān)于 LLM 正在改變軟件開發(fā)的“約束結(jié)構(gòu)”（constraints landscape）的看法，他指出，大模型在“代碼翻譯”上遠(yuǎn)強(qiáng)于從零生成——已有代碼本身就是高度結(jié)構(gòu)化的 Prompt，同時還能作為測試參照。

如果真是這樣，軟件的穩(wěn)定形態(tài)可能就會被打破——重寫變得便宜，遷移成為常態(tài)。那么問題是，當(dāng)代碼會被 AI 反復(fù)理解、翻譯、重組時，什么樣的語言，才更適合這樣的過程？（What kind of language is optimal？）

這個問題并不是停留在討論層面。最近出現(xiàn)的一個新基準(zhǔn)測試 SWE-AGI，正在嘗試給出某種實驗性的回答——它要求 AI 從零開始，僅依據(jù) RFC 和標(biāo)準(zhǔn)文檔，真正構(gòu)建一個完整系統(tǒng)

更有意思的是，研究者刻意沒有用 Python 或 Java，而是選擇了一門全新的編程語言 MoonBit 作為構(gòu)建環(huán)境。

原因很簡單——他們希望排除“模型見過太多訓(xùn)練數(shù)據(jù)”的干擾，看看 AI 在一個相對干凈的語言環(huán)境里，能不能真正理解規(guī)則、推理結(jié)構(gòu)、完成工程。

前言

在 AI 編程從“輔助寫函數(shù)”邁向“自主構(gòu)建系統(tǒng)”的關(guān)鍵節(jié)點(diǎn)，一個新的基準(zhǔn)測試SWE-AGI為我們揭示了當(dāng)前 AI 編程代理（Agent）的真實水位。

這項來自粵港澳大灣區(qū)數(shù)字經(jīng)濟(jì)研究院和香港科技大學(xué)今年 2 月的實證研究，摒棄了傳統(tǒng)的代碼補(bǔ)全測試，轉(zhuǎn)而要求 AI 從零開始，僅根據(jù)權(quán)威規(guī)范（RFCs/標(biāo)準(zhǔn)文檔）和固定的 API 腳手架，端到端地構(gòu)建生產(chǎn)級軟件系統(tǒng)。

• 論文鏈接：https://arxiv.org/abs/2602.09447

值得注意的是，研究中使用了國產(chǎn)新編程語言 MoonBit。

在評測 AI 編程能力時，最大的干擾項莫過于“數(shù)據(jù)污染”（Data Contamination）。如果評測的代碼恰好出現(xiàn)在模型的訓(xùn)練數(shù)據(jù)中，那么 AI 的“編寫”實際上只是一場“背誦”表演。為了打破這一魔咒，SWE-AGI 基準(zhǔn)測試做出了一個大膽且關(guān)鍵的決定：放棄 Python、Java 等傳統(tǒng)大語言，轉(zhuǎn)而采用新興的編程語言 MoonBit 作為唯一的構(gòu)建環(huán)境。

基于“反作弊”的工程考量：

1. 切斷“開卷考試”的后路：MoonBit 作為一個相對年輕的語言，其開源生態(tài)尚在建設(shè)中，這意味著它在大模型的預(yù)訓(xùn)練語料庫中幾乎不存在。這直接封殺了 AI 通過“記憶復(fù)現(xiàn)”來蒙混過關(guān)的可能性。

2. 強(qiáng)制“邏輯推理”：由于沒有現(xiàn)成的代碼片段可供抄襲，AI 必須真正理解 RFC 規(guī)范和 API 腳手架，從零開始進(jìn)行邏輯推演。

3. 工具鏈的完美閉環(huán)：MoonBit 原生支持“聲明先行”（Declare-first）的工作流，配合其統(tǒng)一的工具鏈（moon），為 AI 提供了極低延遲的編譯-測試反饋循環(huán)。

結(jié)論是在這場針對“自主軟件工程”的大考中，GPT-5.3-codex與Claude Opus 4.6展現(xiàn)了斷層領(lǐng)先的統(tǒng)治力，而其他模型則被遠(yuǎn)遠(yuǎn)甩在身后。

MoonBit 大型軟件合成挑戰(zhàn)賽

點(diǎn)擊下圖了解更多賽事詳情

論文解析

1、模型戰(zhàn)局：第一梯隊已拉開代差

SWE-AGI 基準(zhǔn)測試包含 22 個任務(wù)，涵蓋模板語言、數(shù)據(jù)序列化、編程語言前端、二進(jìn)制格式解析等多個領(lǐng)域，代碼規(guī)模在 103 到 104 行之間。

在這一高難度的“系統(tǒng)構(gòu)建”場景下，模型表現(xiàn)呈現(xiàn)出了明顯的兩極分化。GPT-5.3-codex 憑借 86.4% 的通過率（19/22）穩(wěn)居榜首，Claude Opus 4.6 以 68.2%（15/22）緊隨其后。相比之下，其他參評模型（包括開源模型及部分閉源模型）在簡單任務(wù)上的表現(xiàn)尚可，但一旦進(jìn)入中高難度領(lǐng)域，成功率便跌至個位數(shù)甚至為零。

模型名稱

總?cè)蝿?wù)通過率 (22選)

核心評價

gpt-5.3-codex

19 / 22 (86.4%)

不僅勝率最高，且在困難任務(wù)中展現(xiàn)了極強(qiáng)的魯棒性與效率。

claude-opus-4.6

15 / 22 (68.2%)

相比前代大幅提升，在復(fù)雜狀態(tài)機(jī)任務(wù)中表現(xiàn)出色。

gpt-5.2-codex

17 / 22 (77.3%)

實力強(qiáng)但效率較低，處理復(fù)雜任務(wù)時耗時顯著長于 5.3 版本。

claude-opus-4.5

10 / 22 (45.5%)

在中高難度任務(wù)中力不從心，被最新版本拉開巨大差距。

其他模型 (Kimi/Gemini等)

極低 (<30%)

僅在極簡單的 Easy 任務(wù)中有零星表現(xiàn)，無法勝任系統(tǒng)級構(gòu)建。

主流模型 SWE-AGI 實測成績對比

數(shù)據(jù)洞察：只有 GPT-5.3 和 Claude Opus 4.6 證明了具備端到端構(gòu)建基礎(chǔ)軟件（如 CSV 解析器、URI 處理器、甚至簡單的 SAT 求解器）的能力。對于其他模型而言，從“寫代碼”跨越到“做系統(tǒng)”，依然是一個難以逾越的鴻溝。

2、GPT-5.3 的“降維打擊”：少讀多試的工程智慧

雖然 GPT-5.3-codex 和 GPT-5.2-codex 都能完成大部分任務(wù)，但它們的工作流（Workflow）有著本質(zhì)的區(qū)別。這種區(qū)別揭示了頂尖 AI 工程師的進(jìn)化方向。

• 效率的飛躍：GPT-5.3 在處理困難任務(wù)時，平均耗時僅為 1.7 小時，而 GPT-5.2 需要 7.8 小時。GPT-5.3 的代碼實現(xiàn)量（Core LOC）也更精簡，說明它不再通過堆砌代碼來解決問題。

• 策略的轉(zhuǎn)變：行為日志分析顯示，GPT-5.2 有 64.6% 的時間在“讀”代碼（理解上下文、維護(hù)架構(gòu)），陷入了一種“維護(hù)模式”。而 GPT-5.3 將更多精力投入到了“調(diào)試（Debug）”和“測試”中。

• 結(jié)論：GPT-5.3 展現(xiàn)出了更接近人類高級工程師的特質(zhì)——它不再糾結(jié)于每一行代碼的完美，而是通過高頻的試錯和反饋循環(huán)來快速收斂。

3、警惕“幻覺”：Claude Opus 的深思熟慮

Claude Opus 4.6 的表現(xiàn)則代表了另一種路徑。它比 GPT-5.3 花費(fèi)了更多的時間在“規(guī)劃（Plan）”和“閱讀規(guī)范（Spec）”上。

• 優(yōu)勢：這種“三思而后行”的策略，使得 Claude Opus 4.6 在處理強(qiáng)規(guī)范、復(fù)雜狀態(tài)機(jī)的任務(wù)（如 HTML5 解析）時，能保持較好的架構(gòu)一致性，避免了 GPT-5.2 那樣的無效修補(bǔ)。

• 劣勢：這種深思熟慮也帶來了高昂的時間成本。Claude Opus 4.6 的平均運(yùn)行時間普遍高于 GPT-5.3，顯示出其在“思考”與“行動”之間的權(quán)衡。

4、核心瓶頸：AI 90% 的時間都在“讀”代碼

這篇論文最顛覆性的發(fā)現(xiàn)，并非 AI 能寫多少代碼，而是揭示了“讀”比“寫”難。

通過對 Agent 行為日志的分析，研究者發(fā)現(xiàn)：隨著代碼庫規(guī)模的擴(kuò)大，代碼閱讀（Code Reading）成為了 AI 開發(fā)的主要瓶頸。

• 數(shù)據(jù)說話：在處理困難任務(wù)時，GPT-5.2-codex 有64.6%的行為是讀代碼；即便是 GPT-5.3，也有 41.4% 的時間在閱讀。

• 本質(zhì)原因：AI 的瓶頸不再是生成代碼的“手速”，而是維護(hù)長視野（Long-horizon）架構(gòu)一致性的“記憶力”和“理解力”。AI 花費(fèi)大量精力去理解自己剛剛寫過的代碼，以確保新增功能不會破壞現(xiàn)有邏輯。

結(jié)語：自主軟件工程的現(xiàn)狀與未來

SWE-AGI 的測試結(jié)果告訴我們：在許多實際部署中，瓶頸并非代碼生成，而是代碼審查、調(diào)試、集成和需求澄清。

雖然 GPT-5.3-codex 已經(jīng)證明了它能像人類一樣，從零構(gòu)建一個標(biāo)準(zhǔn)的二進(jìn)制解碼器或模板引擎，但當(dāng)面對極其復(fù)雜的系統(tǒng)（如完整的 C99 解析器或 Python 子集）時，所有模型的通過率都出現(xiàn)了斷崖式下跌。

未來的 AI 編程代理，勝負(fù)手將不再是誰的“代碼庫背得更熟”，而是那些能夠通過強(qiáng)靜態(tài)保障、確定性構(gòu)建和豐富的自動化檢查，將反饋負(fù)擔(dān)從人工轉(zhuǎn)移至機(jī)器的編程語言和平臺更具優(yōu)勢。

根據(jù) MoonBit 官網(wǎng)數(shù)據(jù) https://mooncakes.io/ 顯示，MoonBit 在小數(shù)據(jù)集的語料環(huán)境中已積累了近 5,000+ 生態(tài)庫和千萬行級別的代碼規(guī)模。在這樣的數(shù)據(jù)規(guī)模下，模型并非依賴海量歷史包袱，而是在一個結(jié)構(gòu)更可控、語義更一致的環(huán)境中學(xué)習(xí)與推理。

如果正如 Karpathy 所說，LLM 正在改變軟件的“約束結(jié)構(gòu)”，那么語言本身的結(jié)構(gòu)是否更有利于機(jī)器理解，可能就不再是邊緣問題。

在這個意義上，MoonBit 的存在，并不是偶然插入的變量，而是一個正在被驗證的方向。