React 移动端实战 · 一个人用 AI 做完一个能上架的移动 App 靠谱吗？codex + Stitch 实战复盘

FungLeo

442人浏览 · 2026-08-22 10:19:32

FungLeo · 2026-08-22 10:19:32 发布

React 移动端实战 · 一个人用 AI 做完一个能上架的移动 App 靠谱吗？codex + Stitch 实战复盘

各位看官，最近我用 AI 把一个能装到手机上、能真机跑、能打签名包的移动 App 从零做出来了——不是那种 hello world 玩具，是带登录、列表、反馈、统计、历史、离线补传一整套的正式应用。全程代码由 codex 写、界面稿由 Stitch 出、接口来自我提前写好的后端规格。

在这里插入图片描述

这篇不聊具体业务，就聊一个很多同行都纠结的问题：一个人 + AI，到底能不能把移动 App 这条链路真正走通？踩了哪些坑？又靠什么把 AI 摁在轨道上不跑偏？ 我把真实流程摊开讲。

一、三个人怎么分工：codex、Stitch、接口文档

这套组合里，三个角色各管一段，谁也别越界：

角色	负责什么	产出
codex	写代码、跑命令、改 bug、提交 git	React + Vite + TypeScript + Capacitor 工程
Stitch	出高保真 UI 设计稿（PNG/HTML）	登录页、列表页、反馈弹窗、统计页的视觉稿
后端接口文档	规定所有字段、枚举、错误码（被声明为"唯一真实来源"）	一份 `api.md`，前端不臆造任何接口

关键点在于：UI 和接口都不是 codex 自己拍脑袋生成的。Stitch 负责"长什么样"，接口文档负责"数据从哪来、字段叫什么"，codex 只做"把这两者翻译成可运行的代码"。这一条是我后面所有约束的地基。

在这里插入图片描述

二、最值钱的不是 prompt，是约束清单

很多人用 AI 写项目翻车，不是因为不会写 prompt，而是没给 AI 划红线。我这个仓库的 README 里直接写死了一组"禁止事项"和"开发原则"，相当于给 codex 立了规矩。几个真正救命的：

不允许臆造接口：所有字段必须来自接口文档，缺字段就问，不能自己编；
不允许保存明文密码：密码必须先哈希再出站；
不允许绕过业务结果回填：每一项操作必须落库、可追踪；
不允许跳过状态更新：数据状态流转一步不能漏；
不允许一次性生成完整 App：必须分阶段开发、逐阶段验收。

这五条不是装饰。AI 写代码最大的毛病就是"看起来跑通了但其实抄了近路"——比如为了省事把密码明文存了、把没定义的接口字段自己造一个、为了快速出活把整个 App 一次性糊出来结果状态满天飞。把禁止项写进项目根文档，比在聊天里反复叮嘱十条都管用，因为 codex 每次开工都会先读它。

约束手段	解决什么坑	生效方式
接口文档声明为"唯一真实来源"	AI 臆造端点/字段	根文档 + 提示词双重强调
README 禁止项清单	明文密码、漏状态、抄近路	项目根文件，每次必读
分阶段开发原则	一次性生成导致结构失控	拆 commit、逐阶段验收
codex 命令白名单	防止 AI 乱跑危险命令	`rules` 里放行 `pnpm`/`curl` 等

三、分阶段开发：git 历史证明"一次性生成"必翻车

我不信"一句 prompt 出一个完整 App"。这个项目真实的提交节奏是这样的（泛化描述）：

先初始化 React + TypeScript + Capacitor 空壳；
再实现核心业务流程（登录 → 列表 → 反馈 → 统计）；
然后把 Stitch 出的视觉稿逐页替换进去、调样式；
接着补移动端专属能力——把"读取系统通话记录"重构为独立的 Capacitor 原生插件；
再加离线优先与离线补传；
最后才是安卓签名、真机调试、发版。

每一阶段都是独立 commit、独立验收。一次性让 AI 吐出全部代码，结果一定是：状态管理混乱、边界漏处理、移动端原生能力缺席。分阶段的核心价值不是"慢"，是让每个阶段都有清晰的验收标准，AI 跑偏了能立刻发现、立刻回滚，而不是等到十几个文件全乱了再抢救。

在这里插入图片描述

四、三个真坑，全是 AI 协作的专属坑

坑 1：AI 最爱臆造接口。 你让它"做个提交"，它顺手就编了个文档里根本不存在的字段。解法是把接口文档钉死成唯一真实来源，并在提示词里反复强调"缺字段就问、不许造"。配合后端返回的真实错误码（比如参数非法直接 400），让 AI 的每一次"自由发挥"都会在联调时撞墙。

坑 2：Web 标准 ≠ 移动端能力。 这是这个项目和纯前端工程最大的分水岭。codex 默认只会 Web 那套——fetch、<a>、浏览器 API。但 App 要调系统拨号盘、读系统通话记录，这些 Web 根本没有。我的做法是：业务逻辑仍交给 codex，但系统能力亲手补一个 Capacitor 原生插件，再用 registerPlugin 把它桥接成前端能 import 的模块。AI 负责 90% 的普通代码，剩下 10% 真正吃移动端底层经验的活，必须人自己上。

// 自己写的原生桥接层，AI 不碰这块系统能力
import { registerPlugin } from '@capacitor/core';

export const CallLog = registerPlugin<CallLogPlugin>('CallLog');

export async function getLatestCallForNumber(phone: string) {
  const result = await CallLog.getLatestForNumber({ phone });
  return result.entry; // 系统通话记录，Web 拿不到
}

坑 3：移动端发布是另一门手艺。 代码写完只是开始。安卓要自己生成并保管 keystore 签名密钥（丢了就再也没法更新已上架的包）、要开 ProGuard 混淆、要管 versionCode 版本号、要真机跑 release 包验证。这些 codex 能帮你写配置，但密钥保管和发版决策必须人拍板——我专门写了发布指南文档，把命令、坑、检查清单都固化下来，避免每次发版现查。