拿到一套移动端原型图之后过去我的第一反应是切图、标注、手动还原、联调接口一版MVP没个两周出不来。但这次我直接用 Codex 从 Figma Relay 原型图一直干到可交付的测试包整个过程变成了一条可以被描述、复制和优化的流水线。这篇稿子想聊的就是这套 Codex 驱动的移动端 AI 全栈开发链路Relay 原型图如何变成真实可运行的 React Native 代码、Codex 在整个链路里到底承担了什么、哪些步骤必须由人来把关以及我在这条链路上踩过的所有坑。先说结论如果你的目标是“快速交付一个能装到手机上、能把核心流程跑通的应用”这条链路目前已经相当值得投入。它尤其适合独立开发者、四五人的小团队以及手里有现成 Figma 设计稿但不想在重复性还原工作上耗太久的移动端工程师。复杂的大型项目也可以借鉴这个思路只是拆解任务的粒度需要更细。1. 为什么“设计稿到可交付应用”值得用 AI 链路重构1.1 传统移动端开发链路里最消耗人的三个环节第一个环节是设计交付的失真。设计师在 Figma 里用的自动布局、颜色变量、字体样式到了工程师手里往往要重新定义一遍。即便是经验丰富的移动端工程师把十几个页面的间距、圆角、状态逐一还原也免不了枯燥的重复劳动。第二个环节是胶水代码。每个页面都要处理 loading、空态、报错、刷新、分页这些代码结构相似但细节处处不同写起来没有技术含量却非常耗时。第三个环节是前后端联调。接口字段和页面状态之间的对接经常要来回确认一改就是半天。过去这三个环节是串行的设计稿出来之后前端先写页面后端并行写接口最后联调。任何一个环节出问题整个排期都会被拖住。1.2 AI 链路里的分工方式这条新链路的分工逻辑完全不同Figma Relay 负责把视觉设计变成可编译的组件代码Codex 负责把自然语言描述变成业务逻辑和后端服务而人的工作重心转移到定义边界、审查代码和验收质量上。Relay 是 Figma 官方推出的设计转代码插件选中画板里的 Frame一键生成 React / React Native 组件。它的价值在于不产生“一次性截图”而是产出与设计变量、样式 token 绑定的真实代码。Codex 的工作则是把组件骨架接上接口、状态、路由、数据库模型任务全栈。这里需要澄清一个常见的混淆标题里的 Relay 指的是 Figma 官方设计转代码插件并不是 GraphQL 生态里那个 Relay。两条技术线没有任何关系但在移动端 AI 开发流程里Figma Relay 是入口Codex 是引擎两者配合起来才形成链路。1.3 什么是“可交付链路”“可交付”不是“能编译通过”而是满足三个条件用户能装、核心流程能跑、异常情况有反馈。所以整个链路的每个环节都有明确出口。用一张表来看这条链路的全貌链路环节负责工具产出物人工介入点原型图Figma Relay 插件可编译的 React Native 组件、设计 token确认组件命名与层级业务逻辑Codex CLI / 桌面版页面状态、交互逻辑、API Client编写任务描述、审查代码后端服务Codex 生成 Node.js API路由、校验、数据库访问层确认接口字段与鉴权策略本地联调终端 模拟器前后端打通的可运行应用验收交互细节构建分发EAS Build 内测平台可安装的测试包真机验证、收集反馈从这条表里可以清楚看到AI 不是替代了全部工作而是把重复劳动挤到了两边人负责“描述清楚”和“验收结果”。这就是我认为真正的 AI 全栈开发该有的样子。2. Codex 环境搭建安装方式、模型选择与连接排错2.1 安装与登录不是装完就完事Codex 目前主要分为命令行工具和桌面应用两条使用路径。命令行工具适合批量任务和脚本化工作流安装方式直接npm install -g openai/codex如果你本机已经有 Node.js 环境这条命令就能完成安装。桌面版则适合像我这样习惯在图形界面里看文件变更的人从官方渠道下载安装包即可。两种方式共用底层配置但使用体验差异挺大桌面版对文件变更的展示更直观适合刚开始接触 AI 编码流程的开发者CLI 则更适合批量处理文件级任务后面我会讲到为什么批量执行反而是这条链路效率最高的用法。安装完成后需要登录。Codex 支持两种授权方式一种是使用 ChatGPT 账号登录另一种是配置 API Key。这两者的差异直接影响后续模型选择下一步细说。2.2 模型选择与账号类型的匹配我在环境搭建阶段遇到的第一条硬报错是这样的The gpt-5.6-sol model is not supported when using Codex with a ChatGPT account当时一度以为是版本问题后来把报错拆开看核心矛盾在于“模型名”和“授权方式”不匹配。Codex 在决定能不能调用某个模型时会同时校验两个东西配置里写的模型名以及当前登录账号对这个模型的访问权限。ChatGPT 账号和 API Key 账号能访问的模型范围并不完全一致直接在配置里把一个未授权的模型名写进去就会得到上述报错。这类问题排查起来有固定套路我整理了一个检查顺序排查项检查方法常见结果配置中的模型名打开~/.codex/config.toml确认model字段拼写错误、默认模型与账号不匹配授权方式确认当前是 ChatGPT 登录还是 API Key权限范围不同可访问模型不同自定义 Provider确认model_providers里的base_url与env_key是否配置第三方服务模型标识与官方模型命名不统一环境变量确认对应的 API Key 变量是否已导出未设置环境变量导致鉴权失败这里也顺带提一下 Codex 的扩展能力它允许通过配置文件接入任何兼容 OpenAI 接口协议的模型服务不需要改动业务代码。接入的关键就是model_providers这段配置里三个字段必须对齐接口地址、模型名称、密钥环境变量。我见过不少人在这一步把模型名写成了官方名而实际服务商用的是另一个模型标识结果一样是“不支持”的报错。配置项之间不存在模糊地带逐一核对永远比反复尝试更高效。2.3 用 Skills 和 AGENTS.md 让 Codex 学会你的项目规范Codex 单独的代码生成能力很强但如果不加约束它产出的代码风格会和你的项目格格不入。我的做法是双管齐下在项目根目录放一份AGENTS.md在用户级目录放置自定义 Skills。AGENTS.md相当于项目施工手册内容不需要长但要明确几条硬约束。比如我的移动端项目里写的是# 项目约束 - 技术栈React Native Expo TypeScript - 所有 API 请求必须通过 src/api/client.ts禁止在组件内直接 fetch - 样式优先使用 src/theme/tokens.ts 中的设计 token - 新组件文件需要附带默认导出 - 禁止引入未使用的依赖Codex 在处理本仓库任务时会主动读取这份文件相当于新成员入职第一天先看规范文档。而 Skills 则是可复用的指令包你把“React Native 页面开发规范”做成一个 Skill放在~/.codex/skills/目录下每个 Skill 就是一个包含SKILL.md的文件夹。这样不管以后接多少个移动端项目这些规范都能复用。2.4 连接失败类报错的通用排查路径Codex 使用过程中出现连接失败的频率比我想象中高常见的错误提示包括error sending request以及链路切换失败导致的/responses端点请求异常。这类问题有一个共性报错信息只告诉你“请求没成功”不会告诉你“为什么”。经过多次实际排错我总结了一套固定的排查路径。第一步看本地请求路由Codex 发出的请求走的是本机某个端口如果本地服务没有正常监听就会表现为连接失败第二步看请求端点配置如果使用了自定义服务地址需要确认 endpoint 字段是否与本地服务实际路径完全一致第三步看鉴权状态API Key 或者登录态过期是连接失败的高频原因第四步看配置缓存改过配置文件后部分旧配置会驻留在内存里重启 Codex 进程再试往往能解决。这套顺序不是随意定的。请求路由是本机层面的问题影响面最大优先排除成本最低鉴权状态改变频率最高但排查需要额外调用接口放到后面更合理。排错不是撞运气是给可能性排序。3. Relay 原型图导入从 Figma 到 React Native 组件的落地过程3.1 我为什么不让 Codex“看着设计稿直接写代码”很多 AI 编码工具宣传自己能根据截图生成页面实际操作过就会发现一个尴尬问题截图生成代码适合单屏、结构简单的页面一旦遇到包含复杂列表、多状态、嵌套组件的真实业务页面效果会急剧下降经常是“远看像、近看像素对不上”。Relay 解决的正是这个问题。它直接读取 Figma 文件里的结构数据而不是靠图像识别所以导出的组件能够保留自动布局、样式变量、组件嵌套关系。Codex 再在这个基础上补充业务逻辑效率和准确率都远高于“看图写码”。说白了Relay 的价值在于把“像素”变成“积木”。它本质上是从设计师的工具链里直接提取工程化信息不让 AI 去猜按钮的位置和间距。3.2 实操步骤选中 Frame、生成组件、同步到本地先说前置条件你需要在 Figma 社区安装 Relay 插件并且确保自己在文件里拥有 Dev 模式权限这一点经常被忽略没有权限时插件会静默加载失败。完整操作分三步在 Figma 中打开设计稿选中要生成代码的 Frame。最好按照页面维度选择一个 Frame 对应一个页面这样生成出来的组件边界清晰。运行 Relay 插件点击 Generate code。插件会在几秒钟内生成对应的组件代码以及一份设计 token 文件。token 文件集中了颜色、字号、间距、圆角这些基础变量。在 VS Code 中安装 Relay for VS Code 扩展登录同一个 Figma 账号执行同步命令组件代码就会写入本地项目的指定目录。生成出来的组件风格是函数组件加样式对象和 React Native 的常见写法一致。比如登录页会生成一个LoginScreen.tsx内部包含输入框、按钮的骨架并引用tokens.ts里的颜色变量。这个骨架的 UI 结构已经接近最终效果剩下的工作是接状态、接接口。3.3 导出的代码怎么组织才不会变成“一次性代码”Relay 生成的组件默认会带一些插件特有的样式表达方式直接用没有问题但如果团队有更严格的代码规范建议在导入后先做一次轻量整理。我通常会让 Codex 做一次“风格归一化”把 Relay 导出代码中的样式变量统一映射到项目的tokens.ts把组件内的魔法数字提取成常量。这里有个重要心得不要让 Relay 导出的组件直接“裸奔”在业务代码里。正确的做法是把它当成页面级骨架包含基础布局和静态 UI而数据绑定、事件回调全部由 Codex 在后续任务中填充。这样设计的好处是设计稿迭代后重新导出组件时业务逻辑代码不会因为组件结构微调而被覆盖。3.4 从原型图到任务清单给 Codex 的“施工图”有了组件骨架之后下一步不是急着让 Codex 写代码而是先产出任务清单。我在 Relay 导出完成之后会为每个页面写一段任务描述这段描述将来直接粘贴给 Codex。一段合格的任务描述包含五要素涉及文件、功能目标、接口协议、状态要求、验收条件。实际案例如下任务完成登录页业务逻辑 文件src/screens/LoginScreen.tsx已包含 Relay 导出的 UI 骨架 目标用户输入手机号和验证码点击登录后调用 POST /api/auth/login 接口请求体 { phone, code }成功返回 { token, user }失败返回 { message } 要求 - 使用 react-hook-form 管理表单校验手机号格式 - 登录中按钮显示 loading 状态禁止重复提交 - 成功后写入 auth store并跳转 /home - 失败时在按钮上方展示服务端返回的 message 验收tsc 无报错模拟器上输入错误验证码能看到服务端错误提示这段描述的本质是把产品需求转译成 AI 能直接执行的施工图。描述的颗粒度决定了 Codex 产出的质量给它越明确的边界它就越不会自由发挥出奇怪的行为。4. Codex 全栈编码实践页面、状态、API、数据库一次打通4.1 任务拆解与批量执行为什么拆得越细跑得越快Codex 的执行模式是我选择 CLI 的主要原因。它会先出一个执行计划然后在你的确认下逐文件修改代码。CLI 模式下我发现把一个大任务拆成多个文件级小任务执行效率远高于让它一口气改 20 个文件。原因不复杂上下文长度受限任务跨度越大模型越容易在中途丢失前文约束任务拆小后每个任务都把相关文件完整放进去生成的代码与现有代码的冲突更少。我的拆法遵循三层结构页面模块层每个页面一个任务负责该页面的状态、交互、API 调用数据层集中在数据获取与缓存统一封装请求方法服务层后端 API 的骨架、路由、数据库访问独立任务生成。这个顺序不能乱。先有页面级组件再写数据层服务最后生成后端接口后端的字段定义又反哺前端的类型定义。每一层完成后我会本地跑一遍类型检查通过后再进入下一批任务避免错误层层累积。4.2 前端接缝把 Relay 组件接上状态与接口Relay 组件本身是“死”的界面上没有数据流动。Codex 要干的活是把“活水”引进去。以商品列表页为例Relay 导出ProductListScreen.tsx后我会给 Codex 下达一段任务描述核心要求包括使用FlatList渲染商品卡片、支持下拉刷新与触底分页、loading 状态展示骨架屏、接口失败时展示空态和重试按钮。Codex 生成代码时最需要注意的是不要让它绕过统一请求通道。如果AGENTS.md里已经声明“所有请求走 src/api/client.ts”它在绝大多数情况下会遵守。AI 与人的协作就是如此规范写在哪模型的随性发挥空间就被压缩到哪。这里也体现出前面配置AGENTS.md的长期价值。状态管理方面我推荐在中小型项目里直接用 zustand 加 React Query 的组合前者管全局登录态和用户信息后者管服务端状态缓存。Codex 对这种流行库的组合套路非常熟悉生成出来的代码可读性通常不错。4.3 后端生成Codex 写 API 的优势与边界全栈链路里的“后端”在 AI 协作模式下并不意味着一个资深后端工程师被替代而是说常规的 CRUD 接口、鉴权中间件、数据库模型生成可以交给 Codex工程师专注在接口设计和数据安全上。我会给 Codex 一个后端任务示例任务创建商品列表 API 技术栈Fastify Prisma SQLite 文件src/server/routes/products.ts 要求 - GET /api/products?page1pageSize20 - 返回 { list: Product[], total, hasMore } - Product 类型包含 id, title, price, coverUrl - 需要登录态校验从 Authorization Header 读取 tokenCodex 可以很快生成完整的路由文件、数据模型和校验逻辑。但它生成的数据校验尤其是权限相关逻辑一定需要人工复核一遍。我在实际使用中发现AI 对“谁有权限访问什么资源”的理解是偏弱的它倾向于照着任务描述字面实现而不会主动考虑越权访问这种安全边界问题。所以后端任务里鉴权策略和敏感数据字段要写得更细致生成后也必须走一遍 code review。4.4 自动审查与本地联调别急着信任 AI 代码每次 Codex 执行完任务我做的第一件事永远是看git diff不是逐行读而是按类型筛查有没有意外删除的文件、有没有新增的奇怪依赖、有没有暴露在代码里的硬编码密钥、有没有把测试代码混入生产路径。本地联调时起一个后端服务再用 curl 验证关键接口。例如curl -X POST http://localhost:3000/api/auth/login \ -H Content-Type: application/json \ -d {phone:13800138000,code:123456}这个动作看着很简单却能筛掉大量“编译能过但接口打不通”的问题。AI 写代码时经常假设接口已经存在或者字段名称恰巧一致真实的联调是检验这些假设的唯一方法。5. 移动端可交付的三个关卡性能、质量与构建分发5.1 性能不是最后才考虑的而是每个页面都要过的关卡很多 AI 生成的移动端代码单独跑起来没问题一进真实场景就卡顿问题基本出在列表没做性能优化、图片没有尺寸约束、请求被写成串行。移动端性能优化的核心原则和 Web 不同不能指望用户在性能好的旗舰机上测试。我在每条列表里坚持做几件事FlatList必须设置keyExtractor和getItemLayout避免滚动时重复计算图片组件必须指定宽高否则列表滚动时会频繁触发布局计算分页加载要加onEndReachedThreshold并且用一个布尔锁防止重复请求首屏请求和次要请求要并行发出而不是写成链式等待。下面是我整理给 Codex 的移动端性能硬性约束场景硬性约束理由长列表使用 FlatList 而非 ScrollView 嵌套避免一次性渲染全部节点图片必须指定 width/height尽量使用 CDN 裁剪参数避免布局抖动与流量浪费请求首屏并行请求不超过 3 个分页加锁缩短白屏时间防重复请求状态更新避免在 render 中直接修改 state防止无限循环与性能劣化包体积移除未使用依赖图片资源走网络降低安装包大小性能优化的本质是建立约束而不是事后调优。Codex 在写代码时如果看到这些约束生成出来的列表天然就带上分页和 key 了。5.2 质量关卡类型、lint、e2e 冒烟三条线同时守住交付之前没有质量闸门AI 生成的代码就是一个黑箱。我做的最小质量防线是三层第一层是 TypeScript 严格模式noUnusedLocals和strict必须打开这能拦住变量未使用、空值访问一大批低级错误。第二层是 ESLint 加 Prettier统一代码风格Codex 生成代码的风格一致性通常不错但偶尔会犯“引用了没安装的包”这类问题lint 能帮助发现。第三层是轻量级冒烟测试我用 Detox 或 Maestro 写一个最小 e2e 脚本启动 App、登录、加载列表、进入详情页、退出五个步骤全通过才算“可交付”候选版本。很多小团队认为自动化测试成本高实际上在 AI 编码链路里自动化测试反而是省钱利器。每次 Codex 改完代码我只要在 CI 里跑一下这三条命令就能在几分钟内判断是否回归不需要人工反复点击。5.3 构建与分发从开发机到内测包的最后一公里模拟器上跑通离交付还差一步真机安装。移动端可交付链路里我最常用的构建方案是 Expo 生态下的 EAS Build。它的好处是云构建不依赖本地环境一致性且能同时产出 iOS 和 Android 的安装包。流程相对固定在项目根目录执行eas build --profile preview云构建完成后会生成一个可安装的链接。iOS 设备可以通过 TestFlight 分发Android 可以直接下载 APK。整个过程 AI 帮不上太多忙但前面所有工作的目的都是为了在这一步得到一个能被测试者安装的产物。这里有一个容易被 AI 链路带偏的地方开发者容易追求“生成更多代码”而忽略“构建是否顺利”。EAS Build 的失败信息往往能暴露真机环境才有的问题比如原生依赖不兼容、iOS 权限描述缺失、图标尺寸不符合规范。这些问题在模拟器上发现不了一旦构建报错优先看日志里第一个错误即可后面的错误绝大多数是第一个错误的连锁反应。5.4 AI 代码的验收清单在把测试包发出去之前我会拿着这张清单过一遍冷启动后能否完成核心流程不闪退弱网场景下是否有 loading 和失败提示登录态过期后是否被正确踢回登录页列表分页加载是否出现重复数据或跳闪新安装包能否覆盖旧版本数据不丢失生产环境接口地址是否已被替换没有残留本地地址。这六项是我踩过坑之后沉淀的底线尤其是最后一项AI 在生成代码时会把本地调试地址硬编码进业务代码如果不检查就打包测试包在用户手机上必然连不上接口。6. 复盘那些高频报错的排查方法和关键取舍6.1 “连接失败”报错先看哪里Codex 使用中最高频的报错是连接失败表现形式各种多样常见的有error sending request、connection failed以及本地链路切换失败导致的/responses端点请求异常。我的排查顺序基本固定在四步先确认本地请求路由是否正常也就是相关本地服务有没有监听正确的端口这是成本最低的一步其次检查请求端点地址是否匹配特别是自定义接口服务时地址的路径前缀、版本号都要逐字符核对再看鉴权凭证是否有变化API Key 暴露在公共仓库被自动吊销、或者登录态过期都是常见因素最后重启 Codex 进程清掉旧配置缓存再发起一次请求。如果四步走完仍然报错我会把日志级别调高观察请求实际发往的地址和返回的状态码。大多数“不明原因”的连接问题在日志里都会现出原形。6.2 “模型不支持”到底是谁的问题前面提到的gpt-5.6-sol报错本质是模型名、Provider 和授权方式三者没有对齐。Codex 不会自动帮你做“模型名到可用模型的降级映射”它只会严格按配置执行。解决这类问题的思路是三步走。第一步确认当前登录方式是什么ChatGPT 账号和 API Key 账号可用的模型集并不相同。第二步看配置文件里model_providers段有没有声明这个模型的接入信息如果没有Codex 根本不知道去哪里找这个模型。第三步确认接入了第三方模型服务时模型标识要用服务商自己的命名而不能照抄 OpenAI 官方模型名。这一类问题之所以难排查是因为报错信息太有迷惑性看起来像“模型能力不够”实际却是“配置绕错了路”。我建议把模型选择这件事固定下来一个项目只用一个稳定可用的模型组合不要频繁切换。6.3 Codex 与 Claude Code 的取舍很多朋友问过 Codex 和 Claude Code 怎么选。我的实际感受是两者都在快速迭代选型不必太纠结。Claude Code 在长上下文对话和复杂推理类任务上表现突出Codex 的优势则在于与 OpenAI 生态的模型深度绑定以及对 Skills 机制的原生支持。如果手上已经积累了 Figma Relay 生成的组件代码又需要批量执行文件级修改Codex CLI 的工作流更顺畅。如果你的需求集中在“理解大量存量代码、做较大规模重构”Claude Code 的表现也值得一试。工具选型不是信仰之争关键是哪个能更快把你带到“可交付”的终点。6.4 整条链路跑通之后我最想分享的三条经验第一条把任务描述当作一等公民对待。Codex 生成质量的瓶颈不在模型而在任务描述的清晰度。描述里没有写清楚的东西AI 不会替你脑补只会用最保守的方式实现。多花十分钟写任务描述能省掉数小时返工。第二条所有 AI 生成的代码都要过一遍git diff。这不是不信任模型而是建立人机协作的安全边界。AI 负责产出人负责把关这条链路才能稳定向前。第三条从设计稿到测试包始终用“可交付”倒推每一步的产出标准。每一步都问一句“这个产物能支撑最终交付吗”如果不能就说明这一步还没做完。清楚这个边界之后AI 全栈开发就不神秘了它只是一条被压缩了时间的工程流水线而流水线上的质检员始终得是你自己。