博客一家 SaaS 团队用 Flutter + AI coding agent，5 人 3 个月完成 iOS、Android、鸿蒙三端上线，人力成本比传统方式降 62%。本文拆解选型逻辑与落地细节。
今年初，一家深圳 SaaS 公司决定把核心产品——库存管理工具——从仅支持 Web 扩展到 iOS、Android 和 HarmonyOS NEXT 三端。团队只有 5 个前端开发，没有专职移动端工程师。他们用 3 个月完成了三端上线，总人力投入比传统外包报价少了 62%。
当下的移动端格局比以往更复杂。HarmonyOS NEXT 已彻底剥离 AOSP，形成三足鼎立局面。对于资源有限的 B2B SaaS 团队，为每个平台分别组建原生开发团队不现实——三个平台至少需要 6-8 人，而多数 SaaS 创业公司的前端团队不超过 5 人。
该客户选择了 Dart 生态的自绘引擎方案搭配 AI coding agent。自绘引擎保证了三端 UI 一致性，社区版 ohos 适配层已相当成熟，能通过 C-API 直接调用鸿蒙底层能力。但真正让这个选择变得可行的，是 AI 工具填补了团队在 Dart 语言和移动端原生能力上的经验缺口。关于 AI 编程工具本身的企业选型逻辑，可参考我们之前的对比文章：Cursor vs Claude Code vs Copilot 企业落地实录。
跨平台项目最头疼的不是 UI 渲染，而是平台特有能力的调用——推送、蓝牙打印、本地文件系统。传统做法是手写 Platform Channel，每个平台一套。该团队的做法是：用自然语言描述业务需求（"在 Android 上通过广播监听 USB 打印机连接，在 iOS 上用 CoreBluetooth，在鸿蒙上用 @ohos.bluetooth"），让 AI 生成三套原生代码骨架。开发者只需验证和微调。这部分工作从预估的 3 人周压缩到了 0.5 人周。
该产品已有 4 年历史的 Web 版，核心业务逻辑（库存计算、订单流转、权限校验）全部在 TypeScript 中。重写 Dart 版本既不现实也不经济。AI 在这里发挥了关键作用：将 TypeScript 业务函数逐段输入，要求 AI 翻译为等价的 Dart 代码，并保持相同的单元测试覆盖率。根据 相关实践报告，这种"业务逻辑迁移"模式已成为 AI 编程最成熟的场景之一。该团队最终迁移了约 1.2 万行核心逻辑，AI 生成代码的直接可用率约 78%，剩余 22% 需要人工调整的主要是 Dart 类型系统的差异和异步模式。
三端上线意味着三套测试用例。团队用 AI 生成了基于 Integration Test 的跨平台测试脚本，同一套测试用例通过 AI 自动适配各平台的定位符差异。测试覆盖率从 Web 版的 52% 提升到了移动端的 81%。
| 维度 | 传统方式 | AI + Dart 方案 | 变化 |
|---|---|---|---|
| 团队规模 | 8 人 | 5 人 | -37.5% |
| 开发周期 | 6 个月 | 3 个月 | -50% |
| 总人力成本 | 约 96 人月 | 约 36 人月 | -62% |
| 代码复用率 | Web→移动端约 30% | Web→Dart 迁移约 70% | +40pp |
| 上线后 Bug 率 | 预估 2.3/千行 | 实际 1.1/千行 | -52% |
Bug 率反而更低，团队归因于两个因素：AI 生成的代码在语法层面极少出错，以及 AI 自动生成的测试用例覆盖了更多边界条件。
团队在立项时也评估了另外两条路线。React Native 开发者基数大、热更新能力强，但团队没有 React 背景，学习曲线反而比 Dart 更陡。uni-app x 国内生态适配最好、鸿蒙支持最成熟，但底层基座闭源，团队担心未来遇到性能瓶颈时无法深入调优。
最终选择 Dart 生态的核心原因是 AI 工具对 Dart 的生成质量优于 UTS——在实测中，AI 对 Dart 的代码生成准确率比对 uni-app x 的 UTS 高出约 15 个百分点。这个差距在多个评测中也被印证：主流 AI 工具对 Dart 的支持成熟度已超过国内定制框架。关于跨平台落地时团队能力如何跟上，可参考：企业 AI 应用跨平台落地：团队能力建设的四个关键阶段。
Native SDK 的鸿蒙兼容性：项目用到的蓝牙打印 SDK 在鸿蒙上没有现成的 HAR 包。团队不得不让 AI 基于 OpenHarmony 的 N-API 文档生成桥接代码，前后迭代了 4 轮才稳定。建议在项目启动前先拉一张"三方 SDK 平台覆盖矩阵"。
代码风格不一致：不同 session 生成的代码在命名规范、错误处理模式上有差异。团队在第 2 周就引入了统一的 Rules 文件（类似 Trae 的 Spec/Rules 体系），让 AI 遵循一致的编码规范。
热更新在鸿蒙上的限制：鸿蒙 NEXT 对动态代码执行有严格限制，团队原本依赖的热更新方案不可用。最终改为通过 AI 辅助的 CI/CD 流水线实现"每日发版"，用频率换灵活性。
可以，但需要人工 review。该团队的经验是：UI 代码和纯逻辑代码直接可用率在 75-85%，涉及平台特有 API 调用的代码需要人工验证。建议建立"AI 生成 → 自动化测试 → 人工 Code Review"的三段式流水线。
不能完全替代，但能大幅降低门槛。团队需要至少 1-2 人理解移动端的基本概念（生命周期、权限模型、包管理），AI 负责具体实现。完全零基础团队不建议直接上生产项目。
社区版 ohos 适配层已迭代到 3.x，基础渲染和输入事件处理已稳定。但部分高级特性（如 Platform Views、自定义着色器）仍有兼容问题。建议在原型阶段就针对鸿蒙做专项测试。
主流 AI coding agent（如 Trae、Cursor、Claude Code）都支持命令行模式和 API 调用，可以嵌入 Git hooks 和 CI 流水线。该团队在 GitLab CI 中加入了"AI Code Review"阶段，每次 MR 自动触发 AI 审查。关于 AI 编程从个人原型到企业交付的完整路径，可参考：AI Coding 落地小程序：从个人原型到企业级交付的实战案例。
最适合 10 万行代码以内的中小型项目。大型项目（50 万行以上）的上下文窗口限制和架构一致性要求仍是 AI 的短板。该客户的库存管理工具约 4.2 万行 Dart 代码，正好在 AI 的舒适区内。
这个案例的核心启示不是"AI 取代了程序员"，而是 AI 改变了跨平台开发的成本曲线。当 AI 能承担 60-70% 的编码工作，团队的技术栈经验门槛大幅降低，原来需要 8 人才能做的三端覆盖，现在 5 人就能完成。对于预算有限但需要多平台覆盖的 B2B SaaS 团队，当下的技术栈选择已经不再是"选哪个框架"，而是"选哪个框架 + AI 工具的组合效率最高"。