Codex+Relay：移动端AI全栈开发从原型到交付的完整链路

做移动端全栈的人应该都有体会：过去大半年里，“用AI写个App”已经从概念变成了日常工作，但大多数团队的AI开发其实停在了Demo阶段——代码能跑、页面能看，离真正交付却还差着一整条工程链路。这个差距不在模型能力上，而在于缺少一条能把原型图自动变成可交付产物的完整路径。我最近把一个内部项目完整跑通了“Relay原型图 → Codex生成前后端 → 质量门禁 → CI打包交付”的链路，整个过程让我对Codex驱动移动端全栈开发有了完全不同的判断：它真正适合的，不是帮你写片段代码，而是作为整条链路的执行主体。这篇文章就围绕这条链路来拆，主题是Codex驱动的移动端AI全栈开发，从Relay原型图一直到可交付状态，涉及工程配置、Prompt策略、质量控制和交付标准化。

这条链路适合三类人看：第一类是想把AI编程从“玩具Demo”推进到“真实项目可发布”的移动端工程师；第二类是团队里负责搭开发流程的技术负责人，想了解AI时代的前后端协作怎么设计；第三类是已经在用Codex但总觉得生成质量不稳定、交付时心里没底的开发者。我会把我实际踩过、验证过、最后沉淀成机制的内容都放出来，尽量做到可直接复制到自己的项目里。

1. 移动端全栈开发的复杂度拐点：为什么AI链路不再停留在Demo阶段

移动端全栈之前最大的痛点是“链路太长”。设计稿拿到手，要拆组件、写样式、调接口、设计数据库、做状态管理、处理打包兼容，一个人全部扛下来，大部分时间不是花在“写代码”上，而是花在“切换上下文”上。切一次上下文，效率就掉一截，这是全栈开发最隐蔽的成本。

AI编程工具出现后，很多人以为这个痛点消失了，但实际用下来发现另一层问题：AI很擅长写单点代码，比如“帮我写一个日期选择器”“帮我写一个鉴权中间件”，但一旦要求它完成一个完整的可交付功能，它就开始顾此失彼。原因很简单——单点代码的上下文是封闭的，而功能级交付的上下文是开放的，涉及设计稿、数据结构、接口契约、错误处理、性能约束、平台差异，这些上下文如果没有被组织好，AI再强也输出不了稳定结果。

所以我说的“复杂度拐点”，指的就是这里：AI开发能不能从Demo走向交付，不取决于模型智商，而取决于你是否建立了一条把设计信息、工程约束、验收标准持续喂给AI的链路。我选择用Relay管住设计源头，用Codex承担代码生成和重构执行，把人的精力集中在审查和决策上，这个组合的核心逻辑就在于此。

1.1 从“AI写代码”到“AI承担工程链路”的转变

我最早用AI写代码的方式很原始：遇到问题，复制报错信息，粘到对话窗口里，让它给我一段代码。这种方式的问题在于，AI看到的永远只是项目的一个切片，它对整体架构、设计意图、数据流向毫无感知。结果就是代码能跑，但换个人来维护会崩溃，甚至两周后的自己都看不懂。

做这条链路时，我刻意把AI的角色从“代码生成器”换成了“工程执行者”。什么意思？我不再让它写某一个函数，而是让它读完整的设计系统文件、看完接口契约、知道这个项目的代码规范之后，替我把一个模块从前端到后端完整落地。这个转变带来的差异是巨大的——前者生成的是代码，后者生成的是功能。

为了支撑这种用法，项目本身的“可读性”成了关键。过去代码注释是写给同事看的，现在是写给人机共同维护的代码库看的。我们会看到，Relay阶段整理出来的命名规范、设计令牌、页面结构说明，本质上都是在给Codex建立“项目认知”。Codex能承担多少工程链路，很大程度取决于前期有多少信息被结构化地喂给了它。

1.2 这条链路适合谁、解决什么问题

这条链路不是银弹，它有明确的使用边界。我跑的是React Native前端加Node.js后端的中型移动应用，如果你做的是纯原生iOS/Android或者需要大量端侧算力的项目，链路需要调整，但核心方法论是一致的。

它解决的核心问题是三个：第一，让设计信息到代码的转换过程可追踪，不再依赖开发者的个人理解，Relay导出的组件树和设计令牌就是唯一事实来源；第二，让前后端并行开发成为可能，Codex依据同一份接口契约生成两端代码，天然就是联调完毕的；第三，让交付标准前置，不是等代码写完了再补测试、补性能优化，而是在Prompt阶段就把验收条件写进去。

我见过太多团队在AI开发上投入人力，最后收获的是一堆需要返工的高风险代码。归根结底，不是AI不行，是链路没建立。接下来的章节，我会按这条链路的实际执行顺序，从Relay侧的准备开始，一步步展开。

2. Relay原型图的可消费性改造：AI编程的第一道分水岭

项目里我用的是Figma Relay这套设计转代码工具链，它能把设计稿里的组件解析成语义化的结构，但如果你用的是其他原型标注工具，下面的原则同样适用。老话说Garbage in Garbage out，AI编程时代这句话的杀伤力被放大了十倍：设计稿不规范，AI生成的代码就会“看起来对，实际上全是坑”。

我把这个阶段叫“可消费性改造”。核心目标只有一个：让Relay导出的产物不只是图片，而是可以被Codex理解、引用、直接生成代码的结构化信息。这里有三件事必须做，缺一个，后面都会找补回来。

2.1 组件化命名：AI能否准确映射页面结构的起点

大多数设计稿的问题出在命名上。设计师习惯用“Group 132”“Frame 56”这种自动命名，组件语义完全丢失。Relay这类工具虽然能识别布局关系，但导出的代码里充满无意义的标识符，Codex拿到这种输入，只能靠猜。而AI一旦靠猜，第一次生成的代码大概率偏离设计意图。

我在项目开始时定了一个硬性规范：所有页面级组件必须按照“页面_模块_功能”的规则命名。比如首页顶部的搜索栏就是HomeHeader_SearchBar，商品卡片就是ProductList_Card。这个规范不仅是对设计师的要求，更是写给Codex的“语义词典”。实践下来，命名规范之后，Relay导出的组件树直接从“视觉分组”升级成了“页面结构说明书”，Codex生成React Native代码时几乎不需要我额外解释每个组件是干什么的。

命名规范里还要注意统一用英文、统一用PascalCase（组件）和camelCase（属性），避免中英混写。AI模型对英文语义的识别稳定性远高于混合语言，这是个很容易被忽略但影响很大的细节。

2.2 设计令牌与页面标注：把视觉细节转成机器语言

Relay导出的代码里，颜色、间距、字号往往是写死的具体数值。这种代码交给人没问题，交给AI继续开发就有问题——AI如果想在代码里维持视觉一致性，需要反复推断“这个颜色和那个颜色是不是同一个”，效率极低且容易出错。

解决办法是建立设计令牌（Design Tokens）文件。把项目里所有颜色、字体、间距、圆角、阴影等视觉变量抽出来，定义成结构化的Token，然后让Relay导出的组件引用这些Token，而不是直接用硬编码值。我项目的Tokens文件长这样：

export const colors = { primary: "#4F46E5", background: "#FFFFFF", textPrimary: "#111827", textSecondary: "#6B7280", border: "#E5E7EB", error: "#DC2626", success: "#16A34A", }; export const spacing = { xs: 4, sm: 8, md: 16, lg: 24, xl: 32, }; export const typography = { heading: { fontSize: 24, fontWeight: "700", lineHeight: 32 }, body: { fontSize: 16, fontWeight: "400", lineHeight: 24 }, caption: { fontSize: 12, fontWeight: "400", lineHeight: 16 }, }; export const radii = { sm: 8, md: 12, lg: 16, };

有了这个文件，Codex在生成页面样式时可以直接引用colors.primary，而不是对着设计稿猜色值。我之前看到一个数据让我坚定了这个做法：引入Tokens之后，AI生成的页面样式返工率下降了至少一半，视觉还原度明显提升。

2.3 剪裁原型范围：让AI只处理要交付的部分

设计稿里不是所有东西都要进代码。我见过团队把整个设计系统的几十个页面一次性丢给AI，结果生成出一堆互相矛盾的组件。实际操作中最有效的方式是“按迭代范围剪裁原型”——一次只给AI一个到三个页面的Relay产物。

这不是能力限制，而是上下文约束。Codex在一个会话里能处理的信息量是有限的，给它30个页面，它一定会平均用力，每个页面都做不到深度打磨。反过来，每次只让它构建一个完整闭环（比如商品列表页包含数据请求、加载状态、下拉刷新、错误重试），产物的完成度会明显更高。我在项目里把一次迭代限制在3个页面以内，这个粒度是目前实测下来效率和质量的平衡点。

3. Codex工程接入与上下文投喂：开发质量和开发效率同步提升

很多人在Codex接入阶段就翻车了，不是因为工具难用，而是因为接入方式停留在“安装完就开聊”的层面。Codex这套工具链和普通聊天式AI不一样，它可以直接操作你的代码库、读文件、运行命令，相当于一个真正坐在你工位上的AI工程师。但正因为权限大，你对它的“入职培训”就得做足。

我一般把Codex当成团队新成员来看待：新成员入职第一天，你会给他什么？项目说明、代码规范、架构文档、环境配置指南。Codex也一样，它的输出质量和这些入职材料的完备程度高度相关。

3.1 项目初始化与CLI配置

Codex CLI的安装本身不复杂，官方渠道装好之后，项目的配置都在~/.codex/config.toml这个文件里。我习惯把模型选择、默认行为和工作模式都固定下来，避免每个会话都要重复解释一遍。

一个我在实践中沉淀下来的基础配置：

# ~/.codex/config.toml model = "gpt-5.2-codex" # 以你安装的Codex CLI实际支持的模型列表为准 [profile] name = "mobile-fullstack" description = "React Native + Node.js 全栈项目的工作配置" [permissions] allow = ["shell", "file"]

这个配置有几个细节值得注意。model字段不要直接照抄网上的教程，本地CLI版本和云端模型支持范围是有对应关系的。我遇到过一次在配置里写了一个新版本模型，启动之后直接报model is not supported，换成当前CLI默认支持的模型就正常了。所以最稳妥的方式是先用默认配置跑通一次，再决定要不要换模型。

permissions里我只开了shell和file，这样Codex可以读文件、执行命令，但不会去碰网络请求之类的操作。权限控制是Codex使用里最容易被忽略的安全项，尤其是你有真实数据库、有生产环境配置的项目，一定要让Codex在可控范围内操作。

3.2 把Relay产物组织成Codex的“入职文档”

Codex不能直接读Figma，但它能读文件。所以我在项目根目录建了一个docs/目录，专门存放给Codex的“项目认知文件”。这里面的核心资产是两样：Relay导出的组件结构说明、我自己写的架构约定。

项目里我会维护一个信用文档，叫docs/architecture.md，内容大概是这样：

# 项目架构约定 - 前端框架：React Native 0.73，TypeScript - 后端框架：Node.js 18 + Fastify + Prisma - 项目结构：/mobile 前端代码，/server 后端代码 - 请求方案：React Query，统一错误处理 - 状态管理：Zustand，全局状态需要注释说明使用场景 - 数据库：PostgreSQL，所有表必须有 updatedAt - 命名规范：组件 PascalCase，函数 camelCase，常量全大写下划线

这个文件的价值在于，Codex在任何一个会话里都可以先读它，再开始写代码。它解决的是AI的“长期记忆”问题——模型本身没有跨会话记忆，但项目认知文件就是它的外置记忆。很多人在同一个项目里让Codex写了十次代码、风格出现了十种变体，就是因为没有这件事。

Relay的导出物我也做了二次加工。Relay直接导出的组件树会包含大量样式噪声，我不会直接丢给Codex，而是先人工整理成结构化的页面说明。比如：

# docs/pages/product-list.md ## 页面结构 - 顶部导航栏：返回按钮 + 标题“商品列表” + 筛选入口 - 商品列表：FlatList 横向通栏，每行为商品卡片 - 商品卡片：左侧商品图，右侧标题/价格/评价数 ## 交互状态 - 初次加载：显示骨架屏 - 加载失败：显示错误提示 + “点击重试”按钮 - 下拉刷新：重新请求第一页数据 - 触底加载：加载下一页，显示 FooterLoading ## 数据字段 - 商品名 name: string - 价格 price: number（分） - 首图 imageUrl: string - 评价数 reviewCount: number

这份文档就是Codex的“产品需求说明书”，有了它，Codex生成的页面几乎不需要结构性改动。

3.3 会话策略：一次会话只干一种活

使用Codex最常见的效率杀手，是试图在一个会话里让它“从页面写到数据库”。这不是模型能力不足，而是上下文污染的必然结果——前面生成页面时留下的上下文，会干扰后面写数据库时的决策。

我用了大概两周时间才形成的习惯，也是我强烈建议的：一次会话只干一种活。做页面生成，就只围绕页面结构、样式、组件交互来对话；做接口开发，就只带数据模型和接口契约。每个会话开始前，我会先给Codex一条“定位指令”：

你正在处理【商品列表页】的前端实现。 项目规范请先阅读 /docs/architecture.md。 页面结构说明在 /docs/pages/product-list.md。 本会话只做这个页面的组件实现，不涉及后端接口开发。

这条定位指令有三个作用：告诉Codex当前任务范围、强制它读取项目认知文件、限制它的工作边界。实测下来，加了这条指令之后，Codex的输出稳定性提升是非常显著的，尤其是不容易再跑偏去改其他模块的代码了。

4. 从UI到接口再到联调：Codex递进式生成移动端全栈代码

链路的前半段把所有准备都做扎实了，接下来就是核心开发阶段。这个阶段我把它分成三个递进层次：先做前端界面，再做后端接口，最后进入联调适配。每个层次都有自己特定的Prompt策略和审查重点，不能混在一起处理。

4.1 前端生成：视觉还原度怎么控制

前端生成阶段，Codex的输入是已经整理好的页面说明文档、设计令牌和项目架构规范。我在Prompt里会明确给出“从设计稿到组件”的映射关系，避免AI进行“自由发挥”。

一个典型的生成Prompt长这样：

请根据 /docs/pages/product-list.md 实现商品列表页组件。 要求： 1. 使用 TypeScript，函数组件，导出名为 ProductListScreen； 2. 样式值全部从 /mobile/src/theme/tokens.ts 引用，禁止硬编码； 3. 列表使用 FlatList，首屏加载用骨架屏组件 SkeletonCard； 4. 数据请求用 React Query 的 useInfiniteQuery，接口地址 /api/products； 5. 错误状态和空数据状态都要覆盖，空数据时显示“暂无商品”； 6. 组件文件放在 /mobile/src/screens/ 目录。

注意这个Prompt里的几个关键词：文件路径、组件导出名、样式引用方式、数据请求方案、目录位置。这些细节决定了Codex生成的代码是“项目内代码”还是“通用代码”。没有这些约束，它默认生成的是通用且安全的代码，但这种代码放进真实项目里往往需要大改。

生成之后我的审查重点有三个维度：第一是视觉还原，布局结构是否跟设计稿一致，间距是否引用了Tokens；第二是交互覆盖，是否处理了加载中、失败、空数据这些状态；第三是组件粒度，是否存在一个文件几千行的巨型组件，如果有就立刻让Codex拆分。审查通过后再进入下一页面的生成，绝不积压。

4.2 后端生成：数据模型与API Contract

前端页面有了，后端接口会在下一个会话里独立生成。我在这个阶段会让Codex先输出数据模型设计和接口契约，确认无误后才让它写实现代码。这个“先契约后实现”的顺序，是保证前后端能对上话的关键。

生成数据模型的Prompt，我会把前端的数据字段说明直接作为输入：

根据以下前端字段需求设计数据库表和API： 字段：商品名 name(required)、价格 price(required, 单位分)、 首图 imageUrl(required)、评价数 reviewCount(default 0)、 分类 categoryId(外键)、创建时间 createdAt、更新时间 updatedAt 请输出： 1. Prisma schema 中 Product 模型的定义； 2. /api/products 列表接口的查询参数（page, pageSize, categoryId）； 3. 成功/失败响应体的 TypeScript 类型定义。

Codex返回的Prisma schema和类型定义直接复用，然后再让它生成Fastify路由和数据库查询。这里有个经验：让Codex先输出类型定义再写实现，等于给它画了一个靶子，后面的路由代码会围绕类型来写，类型错误的比例大幅下降。

后端生成后我会特别关注几个点：接口鉴权是否遗漏、数据库查询有没有N+1问题、错误响应里是否统一了格式。这三点是AI生成后端代码的高频问题，也是上线后最容易爆雷的地方。

4.3 联调阶段的Prompt技巧

前后端都生成完了，按传统开发模式要进入联调阶段。但Codex链路里，联调的很多工作被前置了——因为前端的数据字段定义和后端的模型定义都源于同一份说明文档，天然对齐。不过实际跑起来还是会遇到字段名不一致、数据类型不匹配、接口路径错误这类问题。

联调阶段我通常会让Codex做一次“契约检查”，把前端实际请求的接口和参数列出来，把后端实际暴露的路由和接收的参数也列出来，然后由Codex自动对照找出差异：

请对照以下两份文件，找出前后端接口不一致的地方： - /mobile/src/api/ 目录下所有接口请求定义 - /server/src/routes/ 目录下所有路由定义 输出格式：不一致的路径、差异详情、建议修改方（前端/后端）。 不要修改代码，只输出检查结果。

这一步非常实用。Codex读代码库的能力比人脑扫代码快得多，尤其适合这种机械性的对照工作。检查结果出来后，让它逐项修复，基本能把联调时间压缩到一个小时以内。

5. 交付前夜的质量门禁：AI代码审查、性能清单与自动化测试

AI生成的代码跑通功能只是开始，真正决定能否交付的是质量门禁。这个阶段我把它当开发流程的半个骨架来对待，因为AI开发速度越快，质量问题越容易悄悄堆积。没有强制的质量关卡，前一天生成的“快速代码”第三天就可能变成技术债。

5.1 AI代码的典型雷区和审查重点

用Codex生成了大量代码之后，我总结出了AI代码的高频问题清单，这些问题在人工审查时基本是必查项：

我在Codex生成完每个模块后，都会让它“自查”一遍：

请对刚才生成的代码做一次质量审查，重点检查： 1. 是否有硬编码的魔法数值； 2. 是否有未处理的异常分支； 3. 是否所有类型都有明确声明，没有 any； 4. 是否有重复代码可以抽取。 输出问题清单和修改建议，逐项修复。

这个“让AI自查AI”的做法效果出乎意料地好。Codex对它自己刚生成的代码有完整的上下文，能快速定位问题，而且它不会像人类一样有“写出来的代码被否定”的情绪，修改得又快又准。但要注意，自查不等于最终审查，关键模块我会再过一眼，尤其是涉及支付、用户数据、权限控制的代码，必须人工确认。

5.2 移动端性能优化清单

移动端性能优化是整个链路里最容易被AI忽略的部分，因为性能问题在开发环境下很难暴露。我这个项目在性能宣讲时主要关注四个维度：列表渲染、图片加载、启动时间和包体积。

列表渲染方面，所有长列表强制使用FlatList，关闭无关的重新渲染，item组件用React.memo包裹。这一步在Prompt阶段就固化在规范里了，Codex生成列表时默认就会规避卡顿。

图片加载是移动端性能的大头，项目里统一用lazyload方案，列表页的图片都设置合适的尺寸，不直接加载原图。API层给图片URL做了动态裁剪参数，服务端返回的本来就是压缩后的图。

启动时间的优化重点是JavaScript的初始化逻辑，检查有没有在入口文件里同步执行耗时操作，比如大型状态管理库的初始化、大量本地数据读取。包体积管理则依赖打包分析，保证Trunk体积不超过阈值。

我把这些约束写成了一张清单文档，作为每个迭代的交付前检查项，Codex在生成代码时也会参考这份清单里的约束。性能优化从源头做起，比事后返工高效太多。

5.3 把自动化测试变成AI开发的强制关卡

AI开发最大的隐患就是“改坏了没人发现”。没有AI的时候，代码改动速度慢，出问题容易被人工发现；有了AI，几十分钟就能改十几个文件，没有自动化测试兜底，第二天醒来可能发现功能已经静默坏了。

我在这个项目里强制要求：每个新增模块必须包含基础测试。测试用例的生成也可以交给Codex，在一个能跑通的代码库里，让它先阅读功能说明和实现代码，再生成对应的测试用例：

请为 /mobile/src/screens/ProductListScreen.tsx 生成测试用例。 测试框架用 Jest + React Native Testing Library。 需要覆盖： 1. 加载中显示骨架屏； 2. 接口请求失败时显示错误提示和重试按钮； 3. 数据加载成功后渲染商品卡片； 4. 点击重试按钮会重新发起请求。 只生成测试代码，不要修改实现代码。

测试就位之后，CI流水线里每一步都会跑这些测试。实测跑了一个多月，AI修改导致的回归问题几乎都能在CI阶段被拦截下来。自动化测试不是AI开发的阻碍，反而正是AI开发提速的底气——因为改坏了能被最快发现，AI才敢大步修改。

6. 把链路变成项目机制：CI、打包、验收标准与踩坑备忘

开发链路跑通之后，最后一个问题是怎么把整条链路稳定复用到后续迭代里。我见过太多项目第一版做得漂亮，第二版开始变形，第三版就回到老路子去了。问题不在于方法不好，而在于没有把方法固化成机制。

6.1 可交付链路的CI/CD配置

项目走上正轨之后，我做的第一件事是把链路配置成自动化流水线。Codex负责代码生成，GitHub Actions负责质量门禁和交付物产出。每次有新代码推送到主干分支，流水线自动执行检查：

name: mobile-cd on: push: branches: [main] tags: ["v*"] jobs: quality: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: 20 - run: npm ci - run: npx tsc --noEmit - run: npm run lint - run: npm test - run: npm run build:android

这个流水线里有几个关键步骤：TypeScript类型检查兜住类型错误，lint规范代码风格，测试拦截功能回归，最后构建Android产物。任何一步挂了，代码不能合并且会直接通知到团队。这条流水线让Codex的生成速度和安全交付形成正循环。

6.2 验收标准

AI全栈开发的可交付链路不能没有验收标准。我把“可交付”定义成一个检查清单，严格区分“功能跑通”和“可交付”：

每一条验收标准都有对应的客观检查方式，不靠感觉判断。只有清单上所有项都打了勾，这个迭代才算是真正可交付的。

6.3 几个值得记住的踩坑瞬间

链路搭起来之后，有几个坑我印象很深，写出来供大家参考。

第一个坑是Relay导出产物直接喂给Codex。我一开始以为Relay导出的代码已经足够结构化，直接作为Prompt上下文给Codex用，结果它生成了一堆被无用样式包裹的组件，返工成本非常高。后来改成“人工整理页面说明文档+设计令牌喂给Codex”的模式才稳定下来。AI时代并不意味着“省掉所有人工”，而是把人工精力放在整理信息、约束上下文上，这个投入回报率极高。

第二个坑是一个会话里塞多个任务。有一次我图省事，让Codex在一个会话里同时处理前端页面、后端接口和数据库迁移。前半段效果还行，后半段它开始“遗忘”前端的设计规范，生成的样式风格和前面不一致。后来强制实行“一次会话只干一种活”，这种情况再没出现过。

第三个坑是Codex把错误处理写得“太静默”。它默认生成的网络请求失败处理是只打一条console.error，用户界面毫无反应。我是在一次演示时当面翻车的，接口挂了页面却没有提示，用户根本不知道发生了什么。这件事直接促使我在Prompt规范里强制加入“错误状态必须对用户可见且有重试入口”这条要求。

还有一个关于上下文的小技巧：Codex对上下文长度的消耗比想象中快，尤其是代码库大了之后。我的做法是尽量让每个会话只涉及相关的几个文件，不相关的文件不要提。Codex一旦开始读它不该读的文件，注意力就会被带偏，生成质量随之下降。

最后再说一点个人体会

把Relay到Codex的这条链路完整跑通之后，我最大的感受是：AI编程改变的不是写代码这个动作，而是工程组织方式。过去我花大量时间在“写”上，现在花时间最多的是三个地方——设计信息结构化、上下文投喂、验收把关。这三个地方恰恰都是机器不擅长的、需要业务判断的部分。

操作链路本身不难，难的是每次都忍住“让AI一口气把所有事情做完”的冲动。把链路拆细、把任务分段、把质量关卡前置，短期看是慢了一点，但放到一个完整迭代的周期里，它是目前移动端AI全栈开发里最稳妥、最可复制的方式。如果你正在从Codex项目Demo往可交付状态推进，建议从今天开始就按这条链路拆自己的项目，先跑通一个小功能，再逐步扩大边界。