vibecoding 在 Web 上已经跑通了"描述 → 生成 → 部署"全链路（见本系列 004、017），但同样的体验搬到手机上立刻降档。原因不在模型写不出代码，而在移动软件工程的四个结构性摩擦：工具链重——Xcode/Android Studio、签名证书、构建链，任何一环出错都不是"改代码"能解决的；验证回路断——Web 刷新即所见，移动端需要模拟器/真机/多机型，而多数 AI 生成环境只提供 Web 预览（Google AI Studio Build 模式的官方论坛讨论明确承认其"universal code"只能 Web 预览、无法启动虚拟 Android 设备）；分发有守门人——App Store 与 Google Play 的人工+自动审核，对 AI 生成应用的功能完整性、隐私声明、账号体系有硬要求；语料分布偏——公开训练数据里 Swift/Kotlin/Dart/小程序 WXML 的体量与新鲜度都不如 React 系 JS，平台 API 又年年换代，模型很容易生成"两年前的正确答案"。
因此讨论"移动端 vibecoding"必须分路线：跨端框架（React Native/Expo、Flutter）、原生（Swift/Kotlin）、Web 套壳（PWA/Capacitor）、以及中文生态特有的小程序。它们对 AI 的友好度差异极大，混为一谈是多数外行判断失准的根源。
| 路线 | 代表工具 / 生态 | AI 适配度 | 主要卡点 |
|---|---|---|---|
| React Native + Expo | Cursor/Claude Code + Expo；Create（create.xyz）官方对接 Expo；Tempo Labs 等垂直工具 | 较高——JS 语料充足、Expo 把原生复杂度封装掉、EAS 云构建免本地环境 | AI 参考过时文档导致 SDK 版本漂移；触达原生模块时质量骤降 |
| Flutter | 通用 IDE + AI 助手 | 中——能写 Widget，但 Dart 语料少、深层嵌套树的增量修改体验差 | 复杂状态管理与性能调优基本靠人 |
| 原生 Swift / Kotlin | 通用 AI 助手辅助片段 | 低——适合"问 API、补样板"，不适合整 App 委派 | 真机调试、签名、审核；新平台 API 覆盖滞后 |
| 微信小程序 | 腾讯云 CodeBuddy 等国内 AI 工具链（模板 + 云开发集成） | 中——中文场景与模板化开发匹配，工具链官方背书 | WXML/WXSS 是非公开标准 DSL、语料受限；平台 API 与审核规则迭代快（定性，公开资料整理） |
| PWA / Capacitor 套壳 | 先 Web 后打包（AI 友好度继承 Web） | 高——本质是 Web 项目加壳 | 推送/内购/后台等原生能力与商店体验打折 |
综合社区一手反馈（Reddit r/reactnative 等）与工具官方信息，2026 年年中各路线的"AI 生成可用度"大致排序是：PWA 套壳 ≈ RN/Expo（managed 工作流）> 小程序 > Flutter > 原生。注意这个排序衡量的是"一个有判断力的人借助 AI 能多快做出能上架的东西"，而不是"非程序员能否全自动生成"——后者在任何路线上都还不成立。
Expo 官方博客介绍了与 Create（create.xyz）的合作：用户用自然语言描述 App，Create 的 AI agent 生成 React Native 代码并直接落在 Expo 工程上，跳过本地 IDE、包管理与打包配置，宣称 100+ 内置集成，再经 EAS 云构建与提交走到双商店。这条链路的意义在于补齐了移动 vibecoding 最缺的一段——从"能跑的代码"到"能上架的产品"。它同时定义了当前的最佳实践形态：AI 负责生成与迭代，Expo 负责封装原生复杂度，云构建负责机械流程，人负责真机验收与商店材料。
r/reactnative 的高热度帖子记录了社区用 AI 生成 Expo App 的集体体验，结论相当一致："对原生来说很糟"——典型事故是 AI 参考旧文档把项目降级到过时的 Expo SDK 49，引出一连串依赖错配；发帖人直言没有经验的开发者"可能连发布都做不到"。这个案例的价值在于标出了失败的具体位置：不是界面生成，而是版本治理、原生依赖与发布流程——恰好都是可以靠流程预防的环节（见第 6 节）。
内部工具与员工端（无商店分发压力，TestFlight/企业分发即可）；MVP 与验证型产品（目标是一周内拿到真机 demo 给用户试，而非长期维护）；本地商家轻应用（点单、预约、会员卡类小程序：需求标准化、迭代浅、付费意愿明确）。这三类共享同一特征：原生深水区需求少，AI 的短板碰不到。
移动 vibecoding 的短板清单就是创业清单：真机测试自动化（AI 生成后自动跑真机冒烟测试，报告崩溃与布局问题——直接把"Web 预览 ≠ 真机"变成服务）；上架即服务（签名、商店截图、隐私政策、审核答辩一站式代办，按次收费）；Expo + AI 工作流模板（锁版本的 boilerplate + AGENTS.md 约束包，卖"不翻车的起点"，与本系列 080 模板生意逻辑一致）。
把移动端当"Web 产品的壳"来做：核心功能 PWA 化、Capacitor 打包、只有确有必要才下沉到 RN/原生模块。这条路 AI 适配度最高、维护面最小，且能同时覆盖 App Store、Play 与微信小程序三个分发面（小程序单独维护一套）。