作者 | Nexus AI 团队
编辑 | Kitty
大型语言模型（LLMs）的迅速发展催生了新一代自主编码智能体，它们能够理解需求、浏览代码库，并在最少的人工干预下实现功能。以 Cursor、Claude Code 和 Codex 为代表的 AI 编程工具在现有基准测试中已经取得了令人瞩目的成果。
然而，现有的评测基准（如 SWE-Bench 等）大多局限于孤立的算法问题或简单的错误修复。而真实的 App 开发并不是在一个真空环境中解数学题，它们的核心实现往往涉及以下几个要点：
对多模态产品需求（PRD 文字说明 + 素材资源等）的真正理解；
对来自 Figma 等工具的视觉设计转化为布局和交互的决策实现；
对庞大代码库的上下文理解，包括架构模块设计、功能实现以及私有库等；
对移动操作系统及其对应技术栈的知识储备。
针对这一行业空白，小红书联合多伦多大学、伊利诺伊大学香槟分校 U Lab、加州大学伯克利分校 Sky Computing Lab 等科研机构，正式发布了 SWE-Bench Mobile。与模型厂商发布会上节节攀升的高分评测不同：在面对真实的企业级大型 App 开发任务时，目前能够达到的任务成功率（Task Success Rate）也仅为 12%。
论文标题：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 是首个真正还原“端到端”开发流程的基准。它以 50 个 (后续会扩展到 100 个) 源自小红书 App 实际迭代的任务为核心，每项任务都源于亿级用户场景下的真实产品需求。有以下三个核心创新：
（1）真实的工业级任务输入与更精细化的多模态要求：无论是 450 词左右的标准 PRD（产品需求文档），71% 任务中所包含的 Figma 视觉设计，以及所用的代码库 Codebase，都是小红书日常研发生产中用过的真实素材，其中一些产品特性依然跑在线上持续迭代。并且与传统多模态评测中的平面截图不同，Figma 作为输入需要模型理解高精度的结构化视觉信息，这也是实际工业生产中对真人程序员的基本要求。
图 1 一个具体的 Task 例子：PRD 说“弱化关注内容流的交互信息，强化时间序列”，Figma 展示详细的视觉反馈，Agent 得同时输出 Swift 逻辑代码和布局逻辑。这考验的不仅是语言模型，更是视觉 - 代码桥接能力。
（2）主流 benchmark 的盲点——移动端编码任务。和模型厂商或是 Coding Agent 发布会中经常出现的演示 Demo 不同，目前市面上多数成熟的大型商业产品依然是 Mobile-First 的形态，如 Instagram、抖音、微信等。而移动端的编码任务又自带很多 debuff：
语言（如 Kotlin、Objc）和框架可供训练的公开语料显著少于 web 与 server 端一些系统（如 iOS）和语言本身也并不开源移动端往往同时包含 UI 编码（如 View 的展示、布局和动画等）以及数据编码（如 kv、database 等），且由于机型的多样性和用户容忍度，移动端往往需要考虑更多的性能优化与兼容性。
这些原因都导致了很多 LLM 在移动端编码任务的能力不尽人意。且本次我们评测使用的小红书移动端 App 项目是一个 14GB 的大规模生产级 iOS Mono Repo（60+ 万行 Swift 代码，15+ 万行 Objc 代码），这是现有基准测试都没有达到的。
（3）科学的任务设计与难度划分：按工业开发的实际复杂度，从 “修改文件数、代码行数、架构复杂度” 三个维度，把任务分成易 / 中 / 难三级，还覆盖了 UI 组件、数据管理、手势交互等 6 大移动端核心开发场景，能全面测试 AI Agent 的真实能力。
图 2 任务难度和类别分类
（4）贴合工业流程的输出与高效的评估方法：要求 Agent 输出 Git 统一 diff 补丁（和工业界 PR 提交流程一致），评估不用编译运行（避免移动端环境的不确定性以及冗长的编译流程），而是用 449 个人工精细编写并验证的 pytest 用例做补丁级静态 + 意图验证，既考验代码正确性，也考验代码是否符合产品需求和架构规范，比传统的单元测试（unit test）效率更高的同时达到同等的评测效果。
图 3 SWE-Bench Mobile 评测流程概览：从接收 PRD 和 Figma 设计稿，到基于大规模代码库进行检索与生成，最终提交 Git Patch 进行意图验证。
论文中评估了 3 类主流编码代理（Cursor/Codex/Claude Code）+7 种主流模型，搭了 14 种配置做了全面评估。这里展示一些对评测结果的观察及简单的分析：
第一，目前 AI Agent 在移动端开发上的能力上限依然很低。即使是表现最好的组合（Cursor + Opus 4.5），成功率也仅 12%。
图 3 各种 Agent 配置在 SWE-Bench Mobile 上的任务成功率任务成功率（Task Success Rate）
并且，随着任务复杂度的提升，Agent 的表现呈现出断崖式下跌：在需要修改 7 个以上文件的复杂任务中，成功率暴跌至 2%。而部分配置（如 Codex + GPT-5.1）的成功率甚至直接归零（0%）。这表明，目前的 Agent 距离成为可以独立完成任务的“开发者”还有很长的路要走，现阶段它们更适合的角色依然是人类的“Copilot”工具。
图 4 随着文件修改数量（复杂度）的增加，任务成功率从 18% 急剧下降至 2%
第二，Agent 的架构设计比模型本身更重要。 这是一个非常有趣的发现。实验数据显示，同样的 Claude Opus 4.5 模型，在 Cursor 框架下能达到 12% 的成功率，而在 Codex 框架下仅为 4%。这 3 倍的性能差距有力地证明：Agent 的工程化框架（Scaffolding），如工具调用、上下文管理、迭代策略等与底层模型能力同样重要。
第三，Prompt 工程存在“反直觉”现象。 我们通常认为，给 Agent 越详细的设定、越复杂的思维链，效果会越好。但在代码生成任务中，复杂的 Prompt 并未带来预期提升，反而可能导致模型“想太多”而跑偏。相反，简单的“防御性编程（Defensive Programming）”策略效果最佳。通过强调边缘情况处理，测试通过率（Test Pass Rate）提升了 7.4%。因此在工程实践中，侧重于代码质量的提示比强调工作流程的提示更有效。
第四，大多数失败源于“顾头不顾腚”。 在对失败案例的归因分析中，我们发现 45% 的失败源于“实现不完整（Incomplete Implementation）”。Agent 修改了部分但并非所有必需的文件。这说明主流 Coding Agent 在面对大型代码库时，对“全局观”和跨文件推理能力仍存在关键挑战。
总的来说，SWE-Bench Mobile 填补了工业级移动端 Coding Agent 评估的空白，也为后续的学术研究工作者提供了一个严格、真实、更贴近移动端开发的测试平台，明确了 LLM Coding Agent 的研究方向（比如跨文件推理、多模态需求理解，从简单的脚本生成，迈向真正复杂的、工业级的软件工程开发）。
同时，SWE-Bench Mobile 也为工业界 Agent 使用者提供了明确的参考：目前的 Agent 只能做“copilots“，且必须有人工监督才能可靠落地。但好消息是，像 GLM-4.6 这种成本可控的模型，配合靠谱的 Agent 框架，性能已经可以和昂贵的前沿模型相媲美。研究给出了未来大规模落地的可行路线：通过更好的框架设计 + 更经济的模型组合，在工业级移动开发场景中实现高性价比的规模化应用。
号外：将于 4 月 16 - 18 召开的 QCon 北京站设计了「Coding Agent 驱动的研发新范式」专题，本专题聚焦 Coding Agent 驱动的研发新范式，探讨其在需求理解、代码生成、测试修复与协作流程中的工程实践，以及对研发工作流、工程效率与研发组织方式带来的变化。如果你有相关技术案例，欢迎加入这场技术共创：
https://jinshuju.com/f/Cu32l5
作者团队介绍
Nexus AI 是小红书社区工程孵化的实验室，专注于 Agentic 系统的构建、评估与应用优化，探索其在真实业务场景中的落地与规模化实践。
会议推荐
2026，AI 正在以更工程化的方式深度融入软件生产，Agentic AI 的探索也将从局部试点迈向体系化工程建设！
QCon 北京 2026 已正式启动，本届大会以“Agentic AI 时代的软件工程重塑”为核心主线，推动技术探索从「AI For What」真正落地到可持续的「Value From AI」。从前沿技术雷达、架构设计与数据底座、效能与成本、产品与交互、可信落地、研发组织进化六大维度，系统性展开深度探索。QCon 北京 2026，邀你一起，站在拐点之上。
热门跟贴