登录
移动端开发稳了？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 才知道。
不过至少从目前看，在移动端开发领域写代码上，至少比前端安全性高一些？你怎么看？
