“用 AI 48 小时做出一个完整移动 App，而且没写一行 Swift 或 Kotlin。”

这个标题听起来像魔法。
但真正有价值的部分，从来不是那个数字，而是它是怎么做到的、哪里差点崩掉、以及这对普通构建者到底意味着什么。

这不是“按一个按钮，AI 就把 App 做完了”。
这是一个新的工作流：AI 负责实现速度，人负责产品方向、架构决策、验证和质量控制。

这个区分，决定了你最终拿到的是一个能用的产品，还是一个看起来能用、实则脆弱的幻觉。

为什么现在突然可以这么做

五年前这个流程还很脆弱。今天有三个关键变化让它变得可行：

1. 跨平台移动栈已经足够成熟
   对于 MVP、内部工具、创作者 App、工具类产品，用 TypeScript + React Native + Expo 已经能完成验证、快速测试 UX 并交付给真实用户，而不需要一开始就维护两套原生代码库。

2. AI 编码工具在真实代码库里终于能用了
   Cursor 擅长本地快速编辑、组件迭代和小范围重构。
   Claude 擅长跨多文件推理、架构规划、调试和解释复杂逻辑。
   两者结合，比单独用任何一个都快得多。

3. 瓶颈从“写代码”转移到“判断”
   现在最难的不是打字，而是决定要建什么、选什么架构、控制范围、发现坏假设、审查生成结果、保持产品一致性。
   构建者的角色正在往上走，工程判断力反而变得更值钱。

真正用到的技术栈

核心组合是经过刻意选择的：

• React Native（移动 UI 层）
• Expo（快速初始化、本地测试、构建流程）
• TypeScript（应用代码）
• Cursor（代码库内的快速迭代编辑）
• Claude（多文件推理、规划、调试、架构支持）

这个栈让 AI 工具能发挥最大优势，因为它们在 TypeScript + React 生态里的训练数据非常丰富，模式识别能力强。

架构上保持极简：清晰的屏幕流 + 状态管理 + API/存储层。正是这种简洁让 48 小时成为可能。

48 小时真实构建时间线

Day 0：范围纪律（最重要的一天）
在动任何代码之前，先定义：

• 核心用户是谁
• 核心问题是什么
• 主流程是什么
• 必须有的屏幕
• 明确排除在外的功能

AI 在范围模糊时会迅速失控。这一步救了整个项目。

Day 1：脚手架 + 第一个可工作版本
目标是速度，不是完美。用 AI 完成：

• Expo 项目初始化
• 文件夹结构与导航
• 核心屏幕
• 可复用 UI 组件
• 模拟或真实数据流
• 端到端 Happy Path

Day 2：真实设备测试、调试与收尾
这是最花时间的一天：

• 修复布局问题
• 解决依赖和配置冲突
• 完善加载、空状态、错误状态
• 清理状态逻辑
• 在真机上验证
• 准备演示或构建

前 70% 很快，后 30% 依然是工程活。

Cursor 和 Claude 的真实分工

这不是随意切换工具，而是各司其职：

Cursor 更强的地方：

• 组件级 UI 编辑
• 屏幕布局快速迭代
• 修改 props、样式、事件处理器
• 快速修小 Bug
• 保持视觉锚点

Claude 更强的地方：

• 实施前规划
• 跨多文件推理
• 重构涉及状态、UI、服务的完整流程
• 结构化调试
• 解释为什么某个问题反复出现

最佳循环模式：
Claude 思考 → Cursor 快速实现 → Claude 调试/重构 → Cursor 继续迭代

这个组合远比让单一工具包打天下有效。

真正有效的提示策略（而非单个神提示）

质量来自可重复的模式，而不是某一条特别聪明的提示。

最佳流程是四步：

1. Research：先让 AI 检查相关代码或结构
2. Plan：让 AI 在改代码前提出实施计划
3. Implement：再要求生成具体改动
4. Review：最后要求做批判性审查

最常见的错误是让模型同时做设计和实现，这几乎必然导致混乱。

构建过程中真正崩掉的地方

诚实的案例必须包含这一部分：

• 依赖摩擦：AI 能快速装库，但兼容性、版本和移动端环境问题仍需要人工判断。
• UI 不一致：AI 擅长生成单个屏幕，但很难自然保持设计系统一致性。
• 状态管理混乱：简单流程还行，一旦跨屏幕共享数据和异步逻辑，就容易脆弱。
• “看起来能用”的虚假自信：屏幕能渲染 ≠ 功能可靠。表单能提交 ≠ 验证正确。Happy Path 能走通 ≠ 真实使用场景没问题。

AI 生成的软件经常在真正可靠之前就“看起来完成了”。这是危险的幻觉。

我仍然必须手动或强人工 oversight 的事情

AI 移除了大量打字工作，但没有移除责任。

我依然要亲自负责：

• 产品决策（哪些屏幕重要、V1 范围、用户最核心动作）
• 架构决策（状态该放在哪里、要不要提前抽象后端）
• 质量控制（真机交互是否合理、空状态和加载状态是否完备）
• 调试判断（问题是逻辑问题、包配置问题还是构建链问题）
• 最终把关（我是否愿意让别人用这个 App？代码是否可维护？）

这些问题依然是人的问题。

这个工作流适合和不适合的场景

适合：

• MVP、内部工具、创作者 App、工具类 App
• 内容/学习类 App、表单、仪表盘、追踪器
• 创始人主导的早期实验
• 在投入原生深度开发前验证产品想法

不适合（或明显变弱）：

• 依赖复杂原生模块
• 要求极致动画性能
• 重度离线优先
• 深度硬件集成
• 强安全合规要求
• 需要极高可靠性的成熟生产系统

给想自己尝试的人的实用 playbook

1. 选对 App 想法（清晰用户流、适度复杂度、无异常原生需求、有视觉回报）
2. 在打开编辑器前先把 App 定义清楚（用户画像、一句话问题、5-7 个屏幕、核心动作、明确排除项）
3. 用 Claude 先做规划
4. 用 Cursor 负责速度实现
5. 尽早真机测试
6. 保持代码库极简（最快的 AI App 往往是部件最少的）

最大的教训

AI 最擅长的是加速实现，而不是** authorship（ authorship）**。

坏的框架是：“帮我把 App 建出来。”
好的框架是：“帮我把实现周期压缩，而我来做重要的决策。”

当你用后一种方式思考时，AI 就会变得有用得多，也少很多挫败感。

AI 不会取代构建者，它会给真正会构建的人带来荒谬的杠杆。

你不再需要把移动 App 开发当作一个自动六个月、高摩擦的过程。
但这不代表每个人现在都能独自用 AI 交付生产级 App。
它意味着想法验证更快了、早期产品探索更便宜了、移动开发对非原生开发者更开放了，而清晰的产品思考能力变得前所未有地重要。

我是紫微AI，在做一个「人格操作系统（ZPF）」。后面会持续分享AI Agent和系统实验。感兴趣可以关注，我们下期见。