🔧 阿川の電商水電行
移動端開發穩了？AI 目前還無法取代客戶端開發，小紅書的論文告訴你數據
近期，由小紅書聯合多倫多大學等高校的研究人員發布了 《SWE-Bench Mobile》（2602.09540） 論文，內容主要是評估 LLM 智能體在處理真實生產級移動端應用開發任務時的能力，並提出了首個針對該領域的基準測試——SWE-Bench Mobile。
這個論文對比之前那些簡單的需求場景，明顯更具備說服力，最重要的是，用真實的數據給目前的 AI 狂熱澆一澆冷水。
目前的程式設計基準測試大多集中在孤立的演算法問題，而 SWE-Bench 則是關注 GitHub 上的 Bug 修復，然而真實的工業級移動端開發更為複雜：
- 多模態輸入：開發者需要根據產品需求文檔（PRD）和 Figma 設計稿等來寫程式
- 複雜的工程環境：中大廠的移動端代碼庫通常規模巨大（ 5GB 以上），且涉及 Swift 與 Objective-C 混編、特定系統 API 及複雜的 UI 互動，還有編譯環境影響
- 任務類型多樣化：不限於 Bug 修復，更多是功能開發和 UI 增強
所以研究團隊從目前小紅書自己的真實產品流水線中提取了 50 個具有代表性的開發任務，構建了該基準測試：
- 數據集組成 ：
- 50 個真實任務：源自實際的產品需求
- 449 个人工验证的測試用例：平均每個任務 9.1 個測試點，用於評估功能正確性
- 多模態支持：70% 的任務附帶 Figma 設計連結，92% 附帶參考圖
- 代碼庫規模：基於約 5GB 大小的真實 iOS 生產代碼庫（Swift/Objective-C）
- 任務複雜度：平均每個任務涉及修改 4.2 個文件，遠超之前的基準測試
整個基準的規則是：
- 70% 任務包含 Figma
- 92% 包含參考圖片
- 平均 PRD 長度 450 字
每個任務包含：
- 一個統一 diff 補丁（patch）輸出
- 綜合測試套件（平均 9.1 個測試案例）
- 任務難度分級：從簡單 UI 調整到複雜跨模組改造
對於任務的兩個關鍵指標：
- 任務成功率：所有測試通過的任務比例
- 測試通過率：所有測試案例通過的比率
而對於 LLM，論文評估了 22 種 不同的“智能體-模型”配置，涵蓋了四個主流框架：
- 商業智能體：Cursor、Codex (由 DeepSeek/OpenAI 等模型驅動)、Claude Code
- 開源智能體：OpenCode
評估維度包括：任務完成率、任務複雜度影響、成本效果比較、多次運行穩定性、Prompt 設計影響等。
而根據論文可以得出結論：當前 AI 在生產級的軟體工程力存在巨大局限性：
- 成功率極低 ：表現最好配置的成功率僅為 12% ，大多數任務以“實現不完整”告終，但測試通過率最高可到 28%，說明部分任務可以部分正確生成，但沒能完全部署成功
- 智能體架構十分重要 ：同一個底層模型，在 Cursor 框架下的成功率為 12%，但在 OpenCode 下僅為 2%，智能體的工具調用、上下文管理等設計與模型本身同等重要
- 商業模型佔優：商業閉源智能體在處理大型代碼庫時的穩定性和正確性顯著優於開源方案
- 複雜度陷阱：任務涉及 1-2 個文件時成功率為 18%，但當涉及 7 個以上文件時，成功率驟降至 2% ，顯示出模型在跨文件長程推理方面的短板
- “防禦性編程”提示詞更有效：研究發現，使用基於“防禦性編程”（原則的簡潔提示詞，比複雜的提示詞能讓成功率提升 7.4%）
對於失敗，論文還針對失敗類型歸類：
- 缺失關鍵功能標誌位或 Feature Flag 是主要的失敗原因
- 其次是 數據模型缺失；
- 再者是 incomplete patch（文件覆蓋不足）等問題
這些失敗的類似，在一定程度上反映了智能體對真實工程流程、跨文件依賴、與視覺設計的理解嚴重不足，也就是這些問題是“工程級問題”，而不是“語言問題”：
所以哪怕換成 Android / Flutter，這類跨文件工程理解問題仍然存在。
基於這些數據，論文認為當前 LLM Agent 儘管在單一代碼生成上有突破，但在端到端工程上下文（包含設計、代碼庫理解、工程流程）仍遠未達到企業生產標準。
另外，論文也有一個有趣的結論數據，主要統計了各 Agent + Model 的每任務成本（美元）和平均耗時（分鐘），例如：
- Cursor + Opus 4.5 ： $3.50 / 15 min
- Codex + GLM 4.6 ： $1.30 / 13.3 min
- OpenCode + GLM 4.6 ： $0.13 / 32.5 min
- OpenCode + Opus 4.5 ： $9.33 / 8.2 min
對此可以看出：
- Codex + GLM 4.6 是性價比最高
- OpenCode 極便宜但成功率低
- OpenCode + Opus 4.5 是最貴但效果很差（2%）
最後，下圖是論文的最終結果對比，例如在 Success 和 Pass 上：
- Cursor + Opus 4.5 → 12% / 28.1%
- Codex + GLM 4.6 → 12% / 19.6%
- OpenCode + GLM 4.6 → 8%
這麼看，OpenCode 的實際數據表現是真的一般。
這個在同一個模型，在不同 agent 上的成功率也有所體現，OpenCode 再一次被鞭屍：
所以，可以看出，目前的 AI 智能體離獨立完成中大型移動開發還有很大距離，主要瓶頸在於多模態理解、大規模代碼導航和跨文件邏輯一致性等。
另外，SWE-Bench Mobile 採用了托管基準挑戰（Hosted Benchmark）模式 ，不公開測試集答案，以防止數據洩露到未來的模型訓練中。
最後，論文只針對原生 iOS 開發進行測試，沒有測試 Android 原生、Flutter、RN 等其他情況，按照一般直覺，這些框架的 AI 表現應該會好於 iOS 原生，當然這也只是我的個人直覺，真實數據還是得有企業做過 Benchmark 才知道。
不過至少從目前看，在移動端開發領域寫程式上，至少比前端安全性高一些？你怎麼看？
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
