夜雨聆风为什么 AI 能写网页，却写不出能上架的 App？
AI 编码工具对 Web 应用的改造已经完成。一个提示词就能生成落地页、Dashboard 甚至完整的 SaaS 原型。但同样的工具放到 iOS 开发里，大多数人得到的却是一堆无法编译的代码、错乱的路由逻辑和永远无法通过审核的构建包。问题不在于 AI 不够强，而在于移动端开发有一整套 Web 世界不存在的隐性规则。
iOS 的人机交互规范是隐形成本。底部标签栏的高度、手势返回的优先级、状态栏与 Safe Area 的适配，这些细节不会在需求文档里出现，却决定了应用能不能通过苹果审核。更关键的是，移动端用户的行为惯性比 Web 更强——他们不需要创新，他们需要熟悉感。一个把按钮放在屏幕中央的情绪追踪应用，无论功能多完整，都会让用户感到别扭。
"Vibe coding" 在移动端有一个致命的陷阱：没有设计蓝图时，AI 会自由发挥。 你同时丢给它五张截图，它可能把"继续"按钮放到屏幕顶端；你让它"做一个情绪追踪应用"，它可能先给你搭一个图表系统而不是核心记录流程。在 Web 端，这种错误刷新一下就能改；在 iOS 端，一次返工意味着重新走一遍构建和签名流程。
移动端开发的复杂度不在代码量，而在"体验一致性"
iOS 开发的难度被误解了。它不是比 Web"更难写"，而是比 Web"更难改"。Web 的迭代是热重载，移动端的迭代是重新编译、重新签名、重新上传。这种延迟让"边做边想"的成本变得极高。
这也是为什么逐页开发会失败。当你对 AI 说"先做欢迎页，再做主页，再做详情页"，如果 AI 没有理解这三页之间的数据流关系，它会给每一页独立的状态管理。用户选了"愤怒"作为主情绪，进入子情绪页后，数据可能传不过去；写完日记回到首页，列表可能没有刷新。这些不是代码错误，是架构错误。
真正的时间黑洞不是写代码，是修架构。 四年前做一个类似的功能需要四人团队一个月。今天 AI 能在 20 分钟内生成相同体量的代码，但如果架构理解错了，调试时间仍然会被拉回到以小时为单位。
另一个被低估的门槛是分发。苹果的开发者证书、App Store Connect 的配置、Bundle ID 的管理，这些传统上需要专门运维知识的工作，至今仍是很多独立开发者的拦路虎。
可复现的五步法
以下工作流可以把"想法"变成"真机上可测的 App"。
第一步：选题必须做单功能 MVP
不要试图在第一个版本里取悦所有人。开发者选择了一个情绪追踪应用，核心功能只有三个：选主情绪、选子情绪、写一句日记。竞争对手相似App有图表分析、资源推荐、多维度统计，这些功能全部砍掉。
逻辑很直接：开发周期每增加一天，你就离真实用户反馈远一天。 一个只有记录和查看功能的应用，如果用户愿意每天打开，就说明需求真实存在；如果没人用，加上图表也不会有人用。
选题的灵感来源应该是 TikTok 和 App Store 榜单，而不是技术社区。观察已经验证过的爆款，理解它们解决的是什么场景问题，然后用更简单的方案重新做一遍。
第二步：在 Figma 里画完所有页面再打开代码编辑器
这是整个工作流中最反直觉、也最关键的一步。大多数人想跳过设计直接 coding，因为"vibe coding"让人感觉"边做边改更快"。但数据显示，在 Figma 里发现"首页缺一句引导文案"只需要一分钟；在代码里发现这个问题，返工成本可能是设计阶段的数十倍。
具体做法：先下载三到五个竞品的截图，不是抄袭视觉风格，是理解用户心智模型。然后画出完整的用户路径：欢迎页 → 情绪选择 → 子情绪 → 日记输入 → 首页列表 → 详情页。每一页的每一个元素都要有明确位置标注。
Figma 的另一个价值是提前暴露逻辑漏洞。当你看着静态原型时，你会自然地问：用户第一次进入应用和第二次进入，看到的页面应该一样吗？情绪数据存在哪里？如果用户没有写日记，详情页要怎么显示？这些问题在代码阶段提出来，AI 可能会答错；在设计阶段提出来，你只需要拖动一个矩形。
第三步：逐页喂给 AI，不要一次给全部
把 Figma 截图交给 AI 时，一次只给一页。同时给出明确的布局指令："顶部是标题和 Logo，底部是副文案和继续按钮。" AI 对视觉元素的空间感知仍然有限，如果你不说"按钮在底部"，它可能把它放到屏幕中央。
在让 AI 写代码之前，先进行"预热对话"。告诉它你在做什么项目、有哪些页面、数据如何流转，然后让它提问。这个过程看起来像浪费时间，实际上是在对齐上下文。AI 的幻觉往往发生在上下文不足时，而不是任务太难时。
工具选择上，Expo 是移动端的 Next.js。它封装了 React Native 的复杂度，提供了 iOS 模拟器和一键构建能力。模型选择上，Claude Sonnet 4.6 处理移动端的状态管理和路由逻辑明显比低配模型更稳定。
第四步：调试时给 AI 一句具体线索，而不是只说"有 bug"
移动端调试有一个优势：iOS 模拟器上的 bug 和真机上的 bug 高度一致。当发现应用重启后回到欢迎页（而不是首页）时，有效的提示不是"有 bug"或"页面错了"，而是："当本地存储已有情绪记录时，应用启动应直接进入首页；目前它会回到欢迎页，说明启动路由的判断条件没有读取存储状态。"
AI 不是搜索引擎，它是合作者。你给它的线索越具体，它的修复路径越短。
另一个实用技巧：用语音输入写提示词。Windsurf 的语音按钮可以把描述页面功能的时间压缩一个数量级。在赶时间的情况下，这种提效是指数级的。
第五步：用 Expo 绕过传统 iOS 部署的复杂度
传统 iOS 上架需要手动配置开发者证书、创建 Bundle ID、在 App Store Connect 填写十几张表格。Expo 的 EAS Submit 把这些步骤自动化了：运行一条命令，它会自动在 App Store Connect 创建应用、配置构建环境、生成签名证书。
构建时间通常在十分钟以内，实战中的记录是 6 分 47 秒。构建完成后，再运行 EAS Submit，应用就会进入 TestFlight 内测通道。从代码到真机安装，整个过程不需要打开 Xcode。
TestFlight 还有一个被低估的功能：测试者截图时可以直接写反馈，截图和文字会自动汇总到开发者的后台。这是最低成本的用户调研工具——告诉你的朋友："看到哪里不对就截图写一句，我就能看到。"
这个工作流会改变什么？
短期内，独立开发者获得了一个可复现的"一小时原型"能力。你不需要懂 Objective-C，不需要配证书，甚至不需要会写 Swift。你只需要会画原型、会描述页面、会判断 AI 的输出对不对。
中期来看，TikTok 获客 + TestFlight 验证会成为一个标准闭环。录一个 20 秒的钩子视频，第一句用竞品的爆款话术，后面接应用演示，Bio 里放 TestFlight 链接。用户下载、使用、截图反馈、你迭代。这套流程的成本接近于零。
长期最大的不确定性仍然是 App Store 审核。 审核周期最长可达 48 小时，审核标准在不同审核员之间有不一致性。有些拒绝理由甚至与苹果自己的指南矛盾。但这是每个 iOS 开发者都要经历的必经过程，不是 AI 能解决的。
下一步的功能迭代方向也很清晰：接入 LLM 分析用户过去一周的情绪记录，生成"情绪周报"，指出高频情绪、触发因素和改善建议。从工具变成服务，从免费变成付费，这是商业化最自然的路径。
结语
AI 没有改变 iOS 开发的专业门槛。设计规范、用户行为、审核规则，这些知识仍然重要。但它把"从 0 到上架"的路径从"一个月 + 四人团队"压缩到了"一小时 + 一个人"。在这个新范式里，真正的瓶颈不再是技术能力，而是开发者是否愿意在编码前花十分钟画一张原型图。 那些愿意的人，会先拿到 App Store 的入场券。
