Codex+Relay打造移动端AI全栈开发链路：从原型图到可交付应用

上个月我把手上一个移动端项目的开发流程整个重做了一遍：设计稿先在 Figma 里整理成 Relay 原型图，导出设计标记和组件结构，再交给 Codex 作为上下文，让它从页面骨架一路写到接口联调，最后直接构建出可安装的测试包。这套链路跑通之后，我最直观的感受是“可交付”的定义变了——以前是需求评审完再排期，设计稿落地之后还要等开发提测，现在 Relay 原型图一稳定，Codex 已经把第一版代码推到仓库里，我做的事情从“写代码”变成了“审代码、补边界、管链路”。

这篇记录不聊概念，只讲我这套 Codex 驱动的移动端 AI 全栈开发链路是怎么搭起来、怎么跑通的。你会看到从 Relay 原型图处理、Codex 配置与 prompt 策略，到移动端全栈工程化、再到测试构建部署这条完整链路里的关键动作，以及我踩过的坑。适合已经玩过 Codex 但觉得产出不够工程化的个人开发者，也适合想用 AI 重构移动端交付流程的小团队参考。

1. 链路设计与整体思路拆解

1.1 为什么是 Codex 加 Relay 这套组合

先说清楚 Relay 在这里到底解决什么问题。这里的 Relay 指的是 Figma Relay 这类设计转代码能力导出的原型图数据，它能把设计稿转换成带有语义化命名的组件代码和设计 token。过去设计师交付的是切图和标注，开发对着标注手写样式；现在 Relay 把“设计稿变组件”这一步自动化了，导出的代码能直接作为前端工程的地基。但 Relay 只覆盖了视觉层，它不负责业务逻辑、数据流、接口联调、工程化配置，这些恰好是 Codex 这类编码智能体的主场。

Codex 的价值在于它能理解整个工程上下文，不是补一段代码就完事，而是能跨文件修改。你给它一个任务描述，它可以创建页面、补 API 层、写测试、调整构建脚本。所以这套组合的逻辑很清晰：Relay 承担“从图到代码”的翻译，Codex 承担“从代码到系统”的组装，两件事拼起来才是一条完整的可交付链路。单独用任何一边都不完整——光靠 Relay 生成的是静态壳，光靠 Codex 从零写 UI 又容易跑偏设计稿。合起来才既保设计还原度，又有工程完整度。

打个比方，Relay 像是把设计蓝图翻译成预制构件，Codex 是带着施工队把构件拼成能住的房子，并且把水电网络都接通。没有 Relay，施工队得自己画图纸，效率低且还原度看运气；没有 Codex，预制构件堆在那里也变不成能住的房子。

1.2 一条链路里的五个关键节点

这套链路我拆成五个节点，每个节点都要有明确的出口产物。没有这些出口，链路就会失控，变成“AI 写了代码但没人知道到什么程度算完”。

第一个节点是设计输入。Figma 设计稿要整理到 Relay 可导出的状态，命名规范、样式 token 收敛都要前置做好。这个节点的出口产物是 Relay 导出包，里面包含组件代码和设计变量。第二个节点是上下文构建。把 Relay 导出的内容、项目文档、接口定义整理成 Codex 能理解的目录结构，同时写好 AGENTS.md 和 skills。出口产物是一个标准的 workspace 目录加项目说明书。第三个节点是代码生成。用会话式任务拆解，让 Codex 从路由骨架、页面组件、状态管理、API 层逐步实现。出口产物是能通过 lint 和 typecheck 的 PR。第四个节点是工程收敛。AI 生成完之后，人工做 code review、补边界条件、跑测试修错。出口产物是通过测试的版本。第五个节点是交付发布。配置构建签名、自动化流水线，产出可安装包并反馈到迭代。出口产物是可安装的产物和 changelog。

这五个节点里，最容易失控的是第二和第四。上下文构建做得不好，后面所有生成都会偏；工程收敛做得不好，代码能跑但不敢上线。所以这两个节点我宁可多花时间，也不让它糊弄过去。

1.3 这套方案的适用边界与团队要求

这套方案适合的项目，我总结下来是 UI 密集、逻辑中等的移动端应用，比如工具类 App、内容社区、企业内部管理端、电商前台页面。这类项目设计稿规范、页面形态重复度高，AI 生成效率非常明显。不适合的是强实时、强状态机、底层性能敏感的应用，比如视频编辑器、音视频通话、游戏。AI 能搭框架，但这类项目的核心技术难点在引擎层和协议层，不在业务代码生成，硬套这套链路只会两头受苦。

团队层面，至少需要一个人懂全链路工程化，能做 code review 和兜底。如果是完全零基础的纯产品经理拿 Codex 搞，会很快卡在环境配置和隐藏问题上。Codex 是放大器，不是替代者，它放大的是你已有的工程能力。团队能力越强，AI 产出的质量越高；团队能力越弱，AI 产出的问题越难收拾。这一点在立项之前就要想清楚，否则半路会非常痛苦。

2. 环境搭建与 Codex 配置

2.1 Codex 安装与基础配置

Codex 目前有桌面版和 CLI 两条使用路径。桌面版适合主要在编辑器里操作的人，安装之后直接在图形界面里对话，对新手友好；CLI 适合要脚本化、自动化的人，我主力用的是 CLI，因为要在构建流水线里调用，跑批处理任务更方便。安装方式上，桌面版从官方渠道下载即可，CLI 按对应平台装好之后，第一件事是确认版本和登录状态，确保能正常发起请求再开始干活。

配置方面，Codex 的核心是 config.toml，里面有 model、model_provider、approval_policy、sandbox_mode 等字段。approval_policy 我建议不要设成全自动，至少在 read-only 和全自动之间保留一个需要确认的模式。代码生成阶段全自动容易在危险操作上失控，比如它可能为了装一个依赖擅自改 package.json，或者为了调试执行一些奇怪的命令。sandbox 模式也建议开着，Codex 默认有沙箱限制，文件写入、命令执行都需要授权，这对移动端项目尤其重要，能有效防止它乱改依赖版本或者执行危险脚本。

我见过不少团队栽在“哎呀 Codex 怎么把我 node_modules 删了”这种问题上，多半是 approval_policy 全自动加沙箱关闭的组合。工具本身没问题，是配置策略太激进了。

2.2 接入第三方模型：自定义 provider 配置

很多团队没有直接买官方模型的额度，而是接第三方 API 服务，这种场景在 Codex 里是通过 model_providers 配置实现的。在 config.toml 里新增一个 provider，指定 base_url 和模型名，然后把它配给默认模型即可。以接 deepseek 系的 API 为例，配置大概长这样：

model = "deepseek-chat" model_provider = "deepseek" [model_providers.deepseek] name = "DeepSeek" base_url = "https://api.deepseek.com" env_key = "DEEPSEEK_API_KEY"

这里面最容易出问题的是协议兼容性。如果第三方服务的 API 接口不是完全兼容官方的 /responses 接口，Codex 请求就会报错。尤其是带 reasoning/thinking 能力的模型，多轮对话时经常遇到必须把上一轮的 reasoning_content 字段原样回传的校验要求，少传了服务端直接 400。这种情况不是 Codex 本身的问题，是模型服务商的对话协议要求，排查方向要看请求体里有没有保留该传的字段，以及 provider 配置是否符合该服务的协议规范。

配置工具方面，如果要在多个模型服务商之间来回切换，用 ccswitch 这类图形工具会比较省心，它本质上还是在帮你改写 config.toml。但我个人建议团队里保留一份手写的 config 模板，出问题的时候能回到最小可配置状态排查。图形工具能加速，但不能替代对底层配置的理解。

2.3 AGENTS.md 与 skills：把项目规范写进上下文

Codex 支持在项目根目录放 AGENTS.md，相当于给 AI 的项目说明书。第一次打开仓库时 Codex 会读取这个文件，所以你要把自己的技术栈、目录约定、代码风格、命令规范都写进去。我自己的项目里大致是这样的：

- 前端使用 React Native + TypeScript，组件放在 src/components，页面放在 src/screens - 状态管理使用 zustand，禁止引入 redux - API 层统一走 src/services/client.ts 封装，禁止在组件里直接写 fetch - 提交前必须运行 npm run lint 和 npm run typecheck - 路由使用 react-navigation，新页面需要注册到路由表中

这些规范看起来琐碎，但决定了 AI 生成的是“符合项目习惯的代码”还是“能跑的陌生代码”。没有 AGENTS.md，Codex 每次都会按自己的偏好来，产出风格不一致，review 成本翻倍。我接手过一个没有任何项目说明的仓库，Codex 一会儿生成 class component 一会儿生成 function component，一会儿用 fetch 一会儿用 axios，整个代码库像三个人写的，修起来心态直接崩。

skills 则是把高频任务封装成长文本指令，比如“生成一个列表页 + 下拉刷新 + 空态 + 错误态”这种模板化任务，写成 skill 之后就不用每次重复描述。移动端项目里我维护得比较多的 skill 有：列表页模板、表单页模板、API client 封装、新模块接入路由。这部分是投入小回报大的投资，维护好 skills 库比反复调 prompt 划算得多。

3. 从 Relay 原型图到工程代码

3.1 Relay 导出内容的预处理

Relay 导出的内容不是直接就能扔给 Codex 用的，先要处理几件事。

第一，收敛设计 token。在 Figma 里先定义好颜色、字号、间距、圆角的样式变量，确保 Relay 导出的是 token 引用而不是硬编码数值。如果导出文件里到处是 #333 这种魔法值，后续改主题会非常痛苦，Codex 也容易照着奇怪的值写。设计 token 的收敛程度，直接决定了生成代码的可维护性。

第二，命名规范化。图层命名决定生成组件的语义。一个叫 btn-primary 的图层，Relay 会生成 ButtonPrimary 组件；一个叫 Rectangle 328 的图层，生成的就是垃圾代码。预处理时把关键图层的名字整理一遍，收益远大于时间成本。这个工作可以让设计师在 Figma 里做，也可以自己在导出前批量改，总之不能跳过。

第三，按页面维度拆包。别把整个 App 的所有页面一次性导出，Codex 的上下文窗口消化不了，生成质量会急剧下降。我习惯一页一包，每包配一个需求描述文件，Codex 逐页处理，处理完再合流。一个页面一个 workspace 目录，里面放 Relay 导出代码和需求说明，这是我觉得最稳的粒度。

3.2 Prompt 策略：让 Codex 理解设计意图

给 Codex 的任务描述，关键不是“帮我做个页面”，而是把页面功能、数据来源、交互状态、边界情况说清楚。我常用的 prompt 模板大概是这样的：

基于 workspace/feeds-page-relay 目录下的 Relay 导出代码，实现“关注流”页面。 需求： - 数据源：GET /api/feeds?tab=following，接口响应结构见 docs/api/feeds.md - 页面结构：顶部 Tab（推荐/关注）+ 信息流列表 + 下拉刷新 + 上拉加载更多 - 状态：loading 展示骨架屏，空态显示“暂无内容”C 位按钮跳转发现页，错误态提供重试 - 交互：点击卡片跳转详情页，路由名 FeedDetail - 不要修改设计稿给出的布局和视觉样式 实现完毕后运行 typecheck 并把改动文件列出来。

这里的关键是状态和边界条件写得越具体，Codex 生成的东西越像产品级代码，而不是 Demo。它还应该拿到接口文档的路径，让 Codex 自己去读，比自己手贴接口字段更可靠。另外一定要给验收标准，比如“通过 typecheck”或“所有状态分支都有对应 UI”，没有验收标准的时候，Codex 倾向于“做了就完”，有验收标准才会考虑边界和异常。

我踩过的一个典型坑是：只写了“实现关注流页面”，没指定数据来源，结果 Codex 用 mock 数据写了一个完整页面，后面接真实接口时整个状态管理都要改。所以在 prompt 里明确“接口还没好之前可以 mock，但必须隔离在 service 层”，这会省掉后续大量返工。

3.3 从页面骨架到组件落地

实际生成的过程不是一次性对话，而是一步步加约束。我跑下来的节奏是：先让 Codex 根据 Relay 导出代码把页面的组件树建立起来，确认结构没问题；再让 Codex 接数据层，把接口字段映射到页面状态；然后让 Codex 补交互和边界状态；最后跑 lint 和 typecheck 收尾。

每一轮都要有一次 review 关口，我会实际打开页面看一眼，或者至少检查 diff。Codex 经常犯的问题是：为了省事直接写死 mock 数据、样式用了内联覆盖导致和 token 体系脱节、事件处理没有防抖和错误处理。这些靠 AGENTS.md 能压一部分，剩下靠 review 关口拦截。不要完全信任 AI 自测，AI 的“自测”经常只是编译通过，运行时的崩溃和样式错乱它看不到。

有个小技巧：让 Codex 生成完代码后，先运行 typecheck，再把报错信息原样贴回去让它自己修。这比人工去翻报错高效得多，Codex 修编译错误的能力很强，基本是“报错-回贴-修复”的循环几次就干净了。我最高纪录是让 Codex 自己循环修了 12 个类型错误，全程没有手动改一行代码，整个流程也就花了十分钟。

4. 移动端全栈开发的关键实现

4.1 跨端方案选型与数据层设计

移动端全栈不等于只写 App，还包括 API 服务端、数据模型和移动端之间的衔接。前端跨端方案我建议根据团队技术栈来选，我这次用的是 React Native + TypeScript，生态成熟，Codex 对它的理解也是所有移动端框架里最好的。如果你团队是前端背景，RN 是上手曲线最低的；如果更看重性能和渲染一致性，Flutter 也可以，Codex 对 Dart 的支持也不错，但生态组件少一些。下面这个表格可以做个参考：

数据层设计上，我推荐把 API client 封装成独立模块，单一入口统一处理 token、错误码、超时，不要每个页面自己 fetch。Codex 在生成页面时参考这个 client，生成的代码就会很规范。服务端部分，如果只是给 App 提供 API，可以选一个轻量的 Node.js + Prisma 组合，让 Codex 基于数据模型生成 CRUD、分页、鉴权中间件，效率很高。前后端共享 TypeScript 类型这一点很重要，一个人也能靠 Codex 撑起全栈。

4.2 移动端适配与性能优化

“PC 端适配移动端”和“移动端适配方案”这类词条一直很多人搜，说明很多项目确实是先从 PC 端起步的。如果是这种情况，移动端改造的核心是：布局从固定宽度改成弹性布局、交互目标尺寸至少 44x44、图片资源和字体按 DPR 适配。如果是从头做移动端，建议直接把设计资源按 375 逻辑宽度出，配合响应式栅格，后顾之忧会少很多。

性能优化这块，移动端首屏和列表流畅度是关键。Codex 能帮你做一部分：生成 FlatList 时自动设置 getItemLayout、keyExtractor，图片组件默认带 lazy load，列表项抽成 memo 组件。但它不会主动做性能分析，所以交付前要跑一轮实测。我用 React Native 时的固定动作是：启动 App 后看 bundle 大小，React Native 的 bundle 超过 3MB 就要查是不是把大库误引入了；列表页滑动时看帧率，明显掉帧就检查 render 次数和列表项复杂度。

体积优化有一个容易踩的坑：AI 容易为了完成功能多引入依赖库。Codex 可能为了一个很小功能的实现装一个 800KB 的库，而这些功能明明手写 20 行就够了。所以我在 code review 时专门看依赖变化，每加一个依赖都要问一句“值得吗”。这个习惯救了我很多次，有一次 Codex 为了做日期格式化引入了整个 dayjs，而项目里其实只有一个地方用到了，完全可以用原生 API 替代。

4.3 Codex 在联调阶段的高频用法

联调阶段是 Codex 真正省时间的地方，不是让它写新功能，而是让它当“代码定位器”。比如后端返回的数据结构和页面预期不一致，直接描述现象和报错，让 Codex 在项目里定位是哪个类型定义的问题、哪些页面受影响、需要怎么改。它跨文件搜索和改动的能力在这时候最有价值。

另一个高频用法是接口 mock。后端接口还没好时，让 Codex 生成一个 mock 服务或者拦截层，按接口文档返回模拟数据，前端开发不阻塞。等真实接口好了，再让 Codex 把 mock 层撤掉，切换到真实 client。这里我建议 mock 层和服务层完全隔离，不要让 mock 逻辑混进生产代码。我当时对 Codex 的要求是：mock 文件集中放在一个目录，生产代码里不出现任何 mock 判断，环境变量控制走哪个数据源，这样切换的时候安全感拉满。

还有一个习惯值得养成：每次联调结束，把这次改动涉及的问题和原因追加到 docs/adr 或者代码注释里。Codex 现在还没有长期记忆，但它每次都会读 AGENTS.md 和项目文档，你沉淀的记录下次就会成为它的先验知识，产出质量会越来越高。这是我跑了几个月之后觉得最被低估的一个点。

5. 从“能跑”到“可交付”

5.1 测试策略：AI 写测试这件事

AI 写的代码不测就交付是不行的，但完全靠人工写测试也不现实。我的做法是让 Codex 写大多数测试，人工负责测试策略和关键用例。单元测试层面，让 Codex 为每个工具函数、组件 hook 生成测试，重点覆盖边界条件和错误分支；集成测试层面，让 Codex 按用户路径生成端到端用例，比如登录、浏览、下单这种完整流程。

让 Codex 写测试的一个注意点是，它容易写“快乐路径”测试，只覆盖正常情况，没覆盖异常和边界。所以 prompt 里要明确要求：补充空值、超时、网络错误、权限拒绝这些用例。测试跑挂之后也不用自己修，把失败日志丢回给 Codex，让它改测试或者改实现，循环到全绿，效率非常高。我见过一个队友把整个过程的定位修错都交给 Codex，他只在旁边确认方向和范围，实际效果出乎意料地好。

注意：测试的目的是验证行为，不是验证实现。review 时如果看到断言写的是“某函数被调用了几次”而不是“页面显示了预期结果”，要让它改成行为级断言。实现细节的断言在重构时全是噪音。

5.2 构建、签名与自动化流水线

可交付的另一个硬条件是构建产物能稳定产出。移动端构建的坑比 Web 多：iOS 签名证书、Android 的 Keystore、各渠道的包名和图标、App 版本号和 build number 规划，这些都是 Codex 不太能帮你做的，因为证书管理涉及密钥，不适合交给 AI。这部分我建议人工搭好流水线，让 Codex 只写构建脚本和配置文件，密钥证书全部走环境变量注入。

一个可用的方案是 GitHub Actions 加自建打包机：PR 合并到 main 后自动执行 lint、单测、类型检查，再跑构建。iOS 用 fastlane 管理证书和签名，Android 用 Gradle 配置不同 flavor。Codex 可以帮你写 workflow 文件，但证书的配置必须你亲手填。我第一次让 Codex 写 workflow 时它漏了缓存依赖这一层，导致每次构建都重新下载依赖，耗时直接翻倍，这种坑等踩到再修很浪费时间。

版本号规划也建议提前定好规则，比如语义化版本加 build number 递增。AI 不会主动帮你管理这个，但如果 AGENTS.md 里写清楚了，它生成的发布脚本就会遵守规则，不会出现两个包相同版本号的低级事故。

5.3 交付后的监控与迭代闭环

可交付链路不是发完包就结束，还要有反馈闭环。移动端的监控重点是崩溃率和启动耗时。代码里如果接了 Sentry 之类的 crash 收集，crash 的堆栈可以直接贴给 Codex，让它定位到对应代码并给出修复建议，这比我人工翻堆栈快很多。我自己试过几次，Codex 根据堆栈定位到具体行并给出修复方案的时间，通常比我手动查代码快一倍以上。

版本发布节奏也要固定，我通常用小版本加热修复两条线，AI 在这个节奏里负责“快速定位加生成修复补丁”，人工负责评估影响面和回归范围。热修复的场景尤其适合 AI，因为问题明确、范围小、时间紧，Codex 生成补丁的速度优势能发挥到最大。

还有一个闭环是沉淀问题库。每次交付后把本轮的测试报告、崩溃记录、用户反馈里可复现的问题整理成一份 Known Issues 文档放到项目里。这样无论是人还是 Codex 在下一次迭代时，都能第一时间避开历史雷区。这个动作短期看是文档工作，长期看是让 AI 开发质量持续上升的关键，值得坚持。

6. 常见问题与排查技巧实录

6.1 Codex 请求失败与模型接入问题

接第三方模型时最常碰到的一类报错，是指向 /responses 端点的请求失败，错误里会带 upstream_status: 400 之类的内容。这种问题百分之八九十是 API 协议兼容问题。第三方服务的接口和官方 /responses 的请求结构有出入时，Codex 发出的请求对方解析不了。解决办法是先确认你用的模型是否支持 responses 接口，如果不支持，换成兼容模式或者明确标注兼容的模型。

还有个很典型的坑：带了 reasoning/thinking 能力的模型，在多轮对话时需要把上一轮生成的 reasoning_content 原样传回去，否则服务端直接报 400，错误信息里会提到 reasoning_content。这个不是 Codex 自身的问题，是模型服务的对话协议要求。排查方向就是看多轮请求体里是否保留了这个字段，以及配置的 provider 是否符合这个模型服务的协议规范。

如果用的是 ChatGPT 账号登录，有时会碰到“当前模型不支持”的提示，比如某些模型只对特定账号类型开放。这种情况要么切换可用模型，要么改用 API key 认证方式。我整理了下面这个排查表，供参考：

通用排查顺序是：先看配置是否生效，再看网络链路是否走到了预期服务，最后看请求体和响应体的协议细节。别一上来就怀疑是工具坏了，大概率是配置或者协议的问题。

6.2 生成质量与上下文管理问题

Codex 生成质量下滑，八成的根因是上下文失控。具体表现是：改 A 文件时把 B 文件的无关代码也改了、风格逐渐偏离项目规范、开始重复造已经存在的工具函数。我自己的止损做法是：长时间会话后发现质量下滑，就新开一个会话，把 AGENTS.md 和当前任务描述重新贴进去，不要让上下文里堆积太多历史噪声。上下文越脏，生成质量越差，这是我在实际使用中验证过很多次的规律。

另一个管理技巧：把大任务拆成小任务，每个任务有明确的验收标准。Codex 在没有验收标准的时候倾向于“做了就完”，有验收标准的时候才会考虑边界和异常。比如“把列表页做完”和“列表页满足：数据渲染、下拉刷新、错误重试、点击跳转，且通过 lint”是两种完全不同的结果。验收条件写进 prompt 之后，产出质量稳定了很多。这个经验我反复用在各种项目里，无一例外。

还有一个细节：不要让 Codex 在同一个会话里同时处理多个不相关的任务。比如既让它做列表页，又问它“项目里有没有现成的上传组件”，这类交叉提问会污染当前任务的专注度。我现在的做法是，查询类问题单独开一个只读会话，生成类任务再开一个专门的会话，互不干扰，效果明显。

6.3 移动端特有的工程化坑

移动端和 Web 的工程化差异很大，AI 很难凭空补上这些经验。比如 React Native 的图标字体加载，iOS 和 Android 的处理方式不同；图片资源在不同平台的行为不同；Android 的 release 包要做 R8 混淆，混淆之后反射调用会炸，这种问题 AI 生成的代码里特别容易埋雷。

我的建议是，任何涉及原生配置、打包签名、平台特有行为的改动，都不要让 AI 在没有监督的情况下直接操作，必须有人工 review 并在真机或模拟器上验证。AI 生成的移动端代码要过三层检查：一编译，二跑测试，三在低端机上看真实帧率和内存。性能问题在模拟器和高端机上是看不出来的，必须在真实设备上测。

注意：低端机是移动端性能的底线，不是高端旗舰。交付前至少在一台两三年以上的真机上跑一遍主流程，你会发现很多在模拟器和旗舰机上完全发现不了的问题。这个建议值回整个工具链的搭建成本。

最后说一个我自己的切身体会。Codex 这波工具刚出来的时候，周围很多人都在担心工作效率会不会被替代，我跑完这条链路之后的结论完全相反：工具把“写代码”的门槛拉低了，但把“判断什么该写、写完之后怎么确保能交付”的门槛抬高了。现在团队里效率最高的人，不是写代码最快的人，而是最会定义任务、最会 review、最懂工程化边界的人。如果你也在用 Codex 做移动端项目，我建议你先不要追求让它一次生成几百行代码，而是从一条小链路开始：一张设计稿变成能跑通接口、能出包的页面。那条链路跑顺了，后面所有事情都是复制粘贴。