近期，由小红书联合多伦多大学等高校的研究人员发布了 《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 才知道。

不过至少从目前看，在移动端开发领域写代码上，至少比前端安全性高一些？你怎么看？

最近看到一个很有意思的项目，它是一个由国外 Rork 团队推出的 AI 移动应用开发平台，宣称是“全球首个在浏览器中构建原生 Swift 应用的 AI 工具”，也就是，你可以不需要 Mac 和 Xcode ，同时一次性完成 iPhone、手表、iPad、电视和 Vision Pro 的应用，甚至还有 AR 和 3D 支持。

所以它的产品逻辑是：用户只需在浏览器中输入自然语言描述，AI 就会自动生成 SwiftUI 代码，然后编译并在云端模拟器中运行，最后支持一键发布到 App Store。

什么 swift 版本 uniapp ？

听起来有点玄乎，但是实际上其实就是 Rork 在后端部署了大量的物理 Mac 节点或 Mac 云实例，当你开始一个项目时，系统就会动态分配一台运行着 Xcode 和 iOS SDK 的 Mac 给对应会话。

也就是所有的编译、链接、资产打包过程都在真实的 macOS 环境下完成，生成的是 100% 的原生 Swift/SwiftUI 代码。

所以实际上就是：Cloud 版本的 Xcode/Mac ，然后搭配 Claude Code 和 Opus 4.6 ，然后生成对应的 iOS App 并提交 Apple Store 审核。

而 Rork 在这里也是采用了类似于云游戏的实时视频流协议（低延迟传输），所以你在浏览器里的每一次点击都会传回云端 Mac 的模拟器，画面变化再实时推送到前端

实际上就是一个远程主机，本质和 AI Studio 类似。

当然，Rork Max 的核心肯定还是他们的 Agent 管理和产品流程，这里的 AI Agent 除了利用 Opus 4.6 写代码之外，还要管理它的所有报错，测试运行和工程管理，同时 Rork 内置了 App Store Connect 的自动化流程，用户登录 Apple ID 后，AI 可以代理证书配置、App 打包和提审等流程。

从这里看，Rork Max 的客户更多的可能是非开发者，所以它的目标是将复杂的工程基座（Mac 硬件 + Xcode SDK + 苹果证书体系）完全抽象化，让开发者只需要关注逻辑和创意。

另外，这里 Rork 自己强调了“非模版化”。它不是通过预设模版拼凑应用，而是通过大模型实时推理，通过自己实现的“持续上下文注入”的技术，让 AI 记住你之前所有对 UI 的微调，确保跨平台迁移时风格的一致性。

实际上它更多是一个从零构建、测试、安装并上架的 Apple 体系生产平台。它直接把“idea → 上架 App Store 的原生 Swift 应用”压缩成一个网页操作，从而大幅度降低了门槛。

官方演示视频中，从零到可玩的游戏原型大概 30–60 分钟：

另外 Rork 也表示后续会支持直接导入老项目的功能，不过对于这种场景，基本都是已经有开发者维护的项目场景，我比较怀疑是否会有受众，虽然貌似真的有：

目前已经有一些 Rork max 用户开始体验，反馈褒贬不一，但是我是没真实体验的，因为 Rork Max 的价格还是挺感人：

为什么不体验其他的？因为我看到所有说不好用的回复里，官方都是问：你是否打开了 Rork Max ？

当然，觉得它有意思的原因，也是它这个产品形态或者是未来的代表之一，开发者不再需要装什么 IDE 或者 SDK ，甚至都不需要纠结是 win 还是 mac 甚至 linux ，只需要一个入口，就可以完成需要开发，当然，那时候如果真的到来的话，也许开发者也不是开发者了，可能更多只是 token 账单的消费者。