作者 | Nexus AI 團(tuán)隊(duì)

編輯 | Kitty

大型語(yǔ)言模型（LLMs）的迅速發(fā)展催生了新一代自主編碼智能體，它們能夠理解需求、瀏覽代碼庫(kù)，并在最少的人工干預(yù)下實(shí)現(xiàn)功能。以 Cursor、Claude Code 和 Codex 為代表的 AI 編程工具在現(xiàn)有基準(zhǔn)測(cè)試中已經(jīng)取得了令人矚目的成果。

然而，現(xiàn)有的評(píng)測(cè)基準(zhǔn)（如 SWE-Bench 等）大多局限于孤立的算法問題或簡(jiǎn)單的錯(cuò)誤修復(fù)。而真實(shí)的 App 開發(fā)并不是在一個(gè)真空環(huán)境中解數(shù)學(xué)題，它們的核心實(shí)現(xiàn)往往涉及以下幾個(gè)要點(diǎn)：

• 對(duì)多模態(tài)產(chǎn)品需求（PRD 文字說明 + 素材資源等）的真正理解；

• 對(duì)來自 Figma 等工具的視覺設(shè)計(jì)轉(zhuǎn)化為布局和交互的決策實(shí)現(xiàn)；

• 對(duì)龐大代碼庫(kù)的上下文理解，包括架構(gòu)模塊設(shè)計(jì)、功能實(shí)現(xiàn)以及私有庫(kù)等；

• 對(duì)移動(dòng)操作系統(tǒng)及其對(duì)應(yīng)技術(shù)棧的知識(shí)儲(chǔ)備。

針對(duì)這一行業(yè)空白，小紅書聯(lián)合多倫多大學(xué)、伊利諾伊大學(xué)香檳分校 U Lab、加州大學(xué)伯克利分校 Sky Computing Lab 等科研機(jī)構(gòu)，正式發(fā)布了 SWE-Bench Mobile。與模型廠商發(fā)布會(huì)上節(jié)節(jié)攀升的高分評(píng)測(cè)不同：在面對(duì)真實(shí)的企業(yè)級(jí)大型 App 開發(fā)任務(wù)時(shí)，目前能夠達(dá)到的任務(wù)成功率（Task Success Rate）也僅為 12%。

論文標(biāo)題：SWE-Bench Mobile: Can Large Language Model Agents Develop Industry-Level Mobile Applications?

論文地址：

https://arxiv.org/abs/2602.09540

Leaderboard：

https://swebenchmobile.com/

SWE-Bench Mobile 是首個(gè)真正還原“端到端”開發(fā)流程的基準(zhǔn)。它以 50 個(gè) (后續(xù)會(huì)擴(kuò)展到 100 個(gè)) 源自小紅書 App 實(shí)際迭代的任務(wù)為核心，每項(xiàng)任務(wù)都源于億級(jí)用戶場(chǎng)景下的真實(shí)產(chǎn)品需求。有以下三個(gè)核心創(chuàng)新：

（1）真實(shí)的工業(yè)級(jí)任務(wù)輸入與更精細(xì)化的多模態(tài)要求：無(wú)論是 450 詞左右的標(biāo)準(zhǔn) PRD（產(chǎn)品需求文檔），71% 任務(wù)中所包含的 Figma 視覺設(shè)計(jì)，以及所用的代碼庫(kù) Codebase，都是小紅書日常研發(fā)生產(chǎn)中用過的真實(shí)素材，其中一些產(chǎn)品特性依然跑在線上持續(xù)迭代。并且與傳統(tǒng)多模態(tài)評(píng)測(cè)中的平面截圖不同，F(xiàn)igma 作為輸入需要模型理解高精度的結(jié)構(gòu)化視覺信息，這也是實(shí)際工業(yè)生產(chǎn)中對(duì)真人程序員的基本要求。

圖 1 一個(gè)具體的 Task 例子：PRD 說“弱化關(guān)注內(nèi)容流的交互信息，強(qiáng)化時(shí)間序列”，F(xiàn)igma 展示詳細(xì)的視覺反饋，Agent 得同時(shí)輸出 Swift 邏輯代碼和布局邏輯。這考驗(yàn)的不僅是語(yǔ)言模型，更是視覺 - 代碼橋接能力。

（2）主流 benchmark 的盲點(diǎn)——移動(dòng)端編碼任務(wù)。和模型廠商或是 Coding Agent 發(fā)布會(huì)中經(jīng)常出現(xiàn)的演示 Demo 不同，目前市面上多數(shù)成熟的大型商業(yè)產(chǎn)品依然是 Mobile-First 的形態(tài)，如 Instagram、抖音、微信等。而移動(dòng)端的編碼任務(wù)又自帶很多 debuff：

語(yǔ)言（如 Kotlin、Objc）和框架可供訓(xùn)練的公開語(yǔ)料顯著少于 web 與 server 端一些系統(tǒng)（如 iOS）和語(yǔ)言本身也并不開源移動(dòng)端往往同時(shí)包含 UI 編碼（如 View 的展示、布局和動(dòng)畫等）以及數(shù)據(jù)編碼（如 kv、database 等），且由于機(jī)型的多樣性和用戶容忍度，移動(dòng)端往往需要考慮更多的性能優(yōu)化與兼容性。

這些原因都導(dǎo)致了很多 LLM 在移動(dòng)端編碼任務(wù)的能力不盡人意。且本次我們?cè)u(píng)測(cè)使用的小紅書移動(dòng)端 App 項(xiàng)目是一個(gè) 14GB 的大規(guī)模生產(chǎn)級(jí) iOS Mono Repo（60+ 萬(wàn)行 Swift 代碼，15+ 萬(wàn)行 Objc 代碼），這是現(xiàn)有基準(zhǔn)測(cè)試都沒有達(dá)到的。

（3）科學(xué)的任務(wù)設(shè)計(jì)與難度劃分：按工業(yè)開發(fā)的實(shí)際復(fù)雜度，從 “修改文件數(shù)、代碼行數(shù)、架構(gòu)復(fù)雜度” 三個(gè)維度，把任務(wù)分成易 / 中 / 難三級(jí)，還覆蓋了 UI 組件、數(shù)據(jù)管理、手勢(shì)交互等 6 大移動(dòng)端核心開發(fā)場(chǎng)景，能全面測(cè)試 AI Agent 的真實(shí)能力。

圖 2 任務(wù)難度和類別分類

（4）貼合工業(yè)流程的輸出與高效的評(píng)估方法：要求 Agent 輸出 Git 統(tǒng)一 diff 補(bǔ)?。ê凸I(yè)界 PR 提交流程一致），評(píng)估不用編譯運(yùn)行（避免移動(dòng)端環(huán)境的不確定性以及冗長(zhǎng)的編譯流程），而是用 449 個(gè)人工精細(xì)編寫并驗(yàn)證的 pytest 用例做補(bǔ)丁級(jí)靜態(tài) + 意圖驗(yàn)證，既考驗(yàn)代碼正確性，也考驗(yàn)代碼是否符合產(chǎn)品需求和架構(gòu)規(guī)范，比傳統(tǒng)的單元測(cè)試（unit test）效率更高的同時(shí)達(dá)到同等的評(píng)測(cè)效果。

圖 3 SWE-Bench Mobile 評(píng)測(cè)流程概覽：從接收 PRD 和 Figma 設(shè)計(jì)稿，到基于大規(guī)模代碼庫(kù)進(jìn)行檢索與生成，最終提交 Git Patch 進(jìn)行意圖驗(yàn)證。

論文中評(píng)估了 3 類主流編碼代理（Cursor/Codex/Claude Code）+7 種主流模型，搭了 14 種配置做了全面評(píng)估。這里展示一些對(duì)評(píng)測(cè)結(jié)果的觀察及簡(jiǎn)單的分析：

第一，目前 AI Agent 在移動(dòng)端開發(fā)上的能力上限依然很低。即使是表現(xiàn)最好的組合（Cursor + Opus 4.5），成功率也僅 12%。

圖 3 各種 Agent 配置在 SWE-Bench Mobile 上的任務(wù)成功率任務(wù)成功率（Task Success Rate）

并且，隨著任務(wù)復(fù)雜度的提升，Agent 的表現(xiàn)呈現(xiàn)出斷崖式下跌：在需要修改 7 個(gè)以上文件的復(fù)雜任務(wù)中，成功率暴跌至 2%。而部分配置（如 Codex + GPT-5.1）的成功率甚至直接歸零（0%）。這表明，目前的 Agent 距離成為可以獨(dú)立完成任務(wù)的“開發(fā)者”還有很長(zhǎng)的路要走，現(xiàn)階段它們更適合的角色依然是人類的“Copilot”工具。

圖 4 隨著文件修改數(shù)量（復(fù)雜度）的增加，任務(wù)成功率從 18% 急劇下降至 2%

第二，Agent 的架構(gòu)設(shè)計(jì)比模型本身更重要。 這是一個(gè)非常有趣的發(fā)現(xiàn)。實(shí)驗(yàn)數(shù)據(jù)顯示，同樣的 Claude Opus 4.5 模型，在 Cursor 框架下能達(dá)到 12% 的成功率，而在 Codex 框架下僅為 4%。這 3 倍的性能差距有力地證明：Agent 的工程化框架（Scaffolding），如工具調(diào)用、上下文管理、迭代策略等與底層模型能力同樣重要。

第三，Prompt 工程存在“反直覺”現(xiàn)象。 我們通常認(rèn)為，給 Agent 越詳細(xì)的設(shè)定、越復(fù)雜的思維鏈，效果會(huì)越好。但在代碼生成任務(wù)中，復(fù)雜的 Prompt 并未帶來預(yù)期提升，反而可能導(dǎo)致模型“想太多”而跑偏。相反，簡(jiǎn)單的“防御性編程（Defensive Programming）”策略效果最佳。通過強(qiáng)調(diào)邊緣情況處理，測(cè)試通過率（Test Pass Rate）提升了 7.4%。因此在工程實(shí)踐中，側(cè)重于代碼質(zhì)量的提示比強(qiáng)調(diào)工作流程的提示更有效。

第四，大多數(shù)失敗源于“顧頭不顧腚”。 在對(duì)失敗案例的歸因分析中，我們發(fā)現(xiàn) 45% 的失敗源于“實(shí)現(xiàn)不完整（Incomplete Implementation）”。Agent 修改了部分但并非所有必需的文件。這說明主流 Coding Agent 在面對(duì)大型代碼庫(kù)時(shí)，對(duì)“全局觀”和跨文件推理能力仍存在關(guān)鍵挑戰(zhàn)。

總的來說，SWE-Bench Mobile 填補(bǔ)了工業(yè)級(jí)移動(dòng)端 Coding Agent 評(píng)估的空白，也為后續(xù)的學(xué)術(shù)研究工作者提供了一個(gè)嚴(yán)格、真實(shí)、更貼近移動(dòng)端開發(fā)的測(cè)試平臺(tái)，明確了 LLM Coding Agent 的研究方向（比如跨文件推理、多模態(tài)需求理解，從簡(jiǎn)單的腳本生成，邁向真正復(fù)雜的、工業(yè)級(jí)的軟件工程開發(fā)）。

同時(shí)，SWE-Bench Mobile 也為工業(yè)界 Agent 使用者提供了明確的參考：目前的 Agent 只能做“copilots“，且必須有人工監(jiān)督才能可靠落地。但好消息是，像 GLM-4.6 這種成本可控的模型，配合靠譜的 Agent 框架，性能已經(jīng)可以和昂貴的前沿模型相媲美。研究給出了未來大規(guī)模落地的可行路線：通過更好的框架設(shè)計(jì) + 更經(jīng)濟(jì)的模型組合，在工業(yè)級(jí)移動(dòng)開發(fā)場(chǎng)景中實(shí)現(xiàn)高性價(jià)比的規(guī)模化應(yīng)用。

號(hào)外：將于 4 月 16 - 18 召開的 QCon 北京站設(shè)計(jì)了「Coding Agent 驅(qū)動(dòng)的研發(fā)新范式」專題，本專題聚焦 Coding Agent 驅(qū)動(dòng)的研發(fā)新范式，探討其在需求理解、代碼生成、測(cè)試修復(fù)與協(xié)作流程中的工程實(shí)踐，以及對(duì)研發(fā)工作流、工程效率與研發(fā)組織方式帶來的變化。如果你有相關(guān)技術(shù)案例，歡迎加入這場(chǎng)技術(shù)共創(chuàng)：

https://jinshuju.com/f/Cu32l5

作者團(tuán)隊(duì)介紹

Nexus AI 是小紅書社區(qū)工程孵化的實(shí)驗(yàn)室，專注于 Agentic 系統(tǒng)的構(gòu)建、評(píng)估與應(yīng)用優(yōu)化，探索其在真實(shí)業(yè)務(wù)場(chǎng)景中的落地與規(guī)?；瘜?shí)踐。

會(huì)議推薦

2026，AI 正在以更工程化的方式深度融入軟件生產(chǎn)，Agentic AI 的探索也將從局部試點(diǎn)邁向體系化工程建設(shè)！

QCon 北京 2026 已正式啟動(dòng)，本屆大會(huì)以“Agentic AI 時(shí)代的軟件工程重塑”為核心主線，推動(dòng)技術(shù)探索從「AI For What」真正落地到可持續(xù)的「Value From AI」。從前沿技術(shù)雷達(dá)、架構(gòu)設(shè)計(jì)與數(shù)據(jù)底座、效能與成本、產(chǎn)品與交互、可信落地、研發(fā)組織進(jìn)化六大維度，系統(tǒng)性展開深度探索。QCon 北京 2026，邀你一起，站在拐點(diǎn)之上。