上个月我们做了一款给汽修门店用的移动端管理工具从Figma里一套Relay原型到可安装的App包总耗时两天半。三年前这种项目我不敢想前端、后端、测试三个人排期不算需求拉扯光是把视觉还原成像素级页面再等接口联调一周能出一个能点来点去的Demo已经算相当顺利。现在把Codex放进这条链路设计稿到可交付产物的路径被压缩到不可思议的程度。我不是说AI替代了所有工作而是移动端AI全栈开发已经从“玩具阶段”走到了“能跑通正式交付”的阶段。这篇文章把我最近几次实操的完整链路拆开讲清楚Relay怎么把原型图变成Codex能理解的任务书Codex怎么在同一套项目里推进移动端、服务端和数据模型交付前必须卡住哪几道关以及这条链路里反复翻车的细节和我的兜底方案。内容不浮夸核心目标就一个——让你能照着这套方法把一份设计稿变成真正可安装、可体验、可交付的移动端产品而不是停留在“AI写了个页面Demo”的层面。1. 为什么我现在敢让 AI 直接参与“从图纸到交付”的全过程1.1 Codex 不是聊天补全工具是能动手干活的编码代理很多人对Codex的理解还停留在“它能在对话框里写代码”这完全低估了它。Codex是一个长在终端里的编码代理它不只是生成代码片段而是能读你仓库里的文件、执行命令、跑测试、观察报错信息然后自己修改代码继续重试。换句话说它具备一个完整“执行闭环”这是它和普通AI代码补全最本质的区别。我实盘用过之后最大的感受是Codex适合承接“从零搭工程”和“按指令改工程”这两类脏活。比如初始化一个 React Native TypeScript 项目它会真的去执行脚手架命令装依赖然后自己把基础目录建好。中间如果出现依赖冲突它会把报错贴回来分析版本关系再执行修复命令。这个过程的体验很像带一个基础扎实但经验不足的实习生你给它明确任务它在执行中会撞坑但关键是它能“自己爬起来继续走”。1.2 Relay 的价值把设计语言转成可编程资产Relay 是 Figma 官方的 AI 插件它做的事情听起来很简单但实际意义很大把设计稿翻译成可用的前端代码和设计令牌。你在 Figma 里选中的一组 FrameRelay 会识别出按钮、列表、输入框、表单这些组件输出对应的组件代码还会抽取颜色、字体、间距、圆角等样式常量统一成 Design Tokens。对全栈开发链路来说Relay 最大的贡献不是“能生成代码”这个噱头而是它把设计稿变成了一份结构化的、可被另一个 AI 消费的上下文。以前你给AI描述需求只能靠嘴说“登录页要一个居中的卡片圆角16主色是#2563EB”中间的信息损耗很大。Relay 导出的内容本身就带着层级、属性和设计规范这让 Codex 拿到项目时是在“参照图纸施工”而不是“凭印象发挥”。1.3 两者的分工正好补上移动端交付链路的空档一条完整的移动端交付链路通常包含四条线并行设计线、前端线、后端线、交付线。设计线负责产出视觉稿和交互前端线要把视觉稿实现成页面后端线要提供接口、数据模型、鉴权交付线要把代码打包成能在真机上安装运行的产物。过去AI编程工具大多只助攻“前端线”你给它一张图它给你一段代码。但代码能跑不代表链路能通。直到 Codex 这种能管理整个工程目录、能同时操作前后端代码的编码代理出现后端线和交付线才真正可以被AI介入。Relay 解决“设计到代码的翻译”Codex 解决“代码到可交付系统的工程化”中间靠一份清晰的上下文文件衔接。这就是标题里“从 Relay 原型图到可交付链路”的完整含义。1.4 什么场景真的适合这套链路我实际跑下来最适合这条链路的场景有三类一类是MVP验证创业团队需要快速把想法变成能拿给投资人演示的App第二类是内部工具公司内部用的移动端应用重流程、轻并发不追求极致的性能第三类是活动页或产品改版的前期探索需要快速验证多个视觉风格的可行性和真实用户体验。反过来核心业务链路、涉及复杂权限模型和高并发交易的场景我不建议直接让AI全盘接管。这些系统的难点往往不在“代码生成”而在“架构决策”和“边界条件”AI可以帮你写其中80%的代码但剩下20%的设计判断仍然需要人来做。把它当作高强度加速器而不是完全自动驾驶这是我这几次实操下来最重要的心态。2. Relay 导出上下文把设计稿变成 Codex 能读懂的任务书2.1 我实际使用 Relay 导出原型的操作流程第一步是在 Figma 里选中要开发的整块 Frame注意必须是一块完整的导航流程最好包含多个页面状态而不是只选一个静态图。选完之后在插件面板中唤起 Relay它会要求你选择代码生成目标我在移动端项目里通常选 React Native TypeScript。Relay 的导出结果一般包含三部分一是页面级的组件代码二是整个项目的 Design Tokens也就是颜色、字号、间距、圆角、阴影这些变量三是一份组件依赖树告诉你看得见的每个 UI 元素是从哪里继承、如何组合的。导出完成后建议把代码复制到本地临时目录里不要直接在 Figma 内部编辑因为我们后面要做大量二次改写本地文件操作更方便。这里有个容易被忽略的动作导出之后花十分钟把 Relay 生成的代码里那几个典型页面过一遍核对核心交互是否被正确识别。比如登录按钮是否标了 onPress 事件列表行是否识别出可点击态表单是否区分了 label 和 placeholder。AI 工具对视觉语言的识别偶尔会有偏差你提前纠正的成本远比让 Codex 在你写的几百行代码里找问题低。2.2 从导出物到 PROJECT_CONTEXT.md我的模板与转换脚本直接让 Codex 去读 Relay 导出的原始文件不是不行但效果不稳定。原文件通常带有大量 Figma 特有的节点标记和自动生成的奇怪变量名Codex 会花掉不少上下文额度去理解这些噪音。所以我每次都会先做一次“转译”把 Relay 的导出物整理成一份浓缩的任务书我把它命名为 PROJECT_CONTEXT.md放进仓库根部。我常用的 PROJECT_CONTEXT.md 结构是这样# 项目上下文 ## 项目背景 一句话说明产品是什么、给谁用、解决什么问题。 ## 技术栈 移动端: React Native Expo TypeScript 服务端: Fastify TypeScript 数据库: SQLite开发/ PostgreSQL生产 共享类型: apps/shared/src/types.ts ## 设计 Tokens - 主色: #2563EB - 背景色: #F8FAFC - 正文字号: 16px行高 24px - 卡片圆角: 16px - 主按钮高度: 48px圆角 12px ## 页面清单与交互 - /login: 手机号 验证码登录点击登录后校验手机号格式 - /workbench: 今日工单列表下拉刷新点击单行跳转详情 - /order-detail/:id: 工单详情包含状态流转按钮 ## 数据字段约定 - User: { id, phone, name, role } - WorkOrder: { id, orderNo, status, customerName, createdAt } ## 非功能需求 - 冷启动时间控制在 3 秒以内 - 支持 Android 8.0 及以上iOS 13 及以上 - 主要操作路径在弱网环境下可用 ## 验收标准 1. 登录 → 工单列表 → 工单详情 核心链路可闭环 2. 接口错误统一提示不出现白屏 3. 打包产物可安装到真机你可以写个小脚本把 Relay 导出的 Tokens 自动映射到你项目里的变量文件页面组件树自动转成页面清单里的交互说明省时又不容易漏。没有脚本也没关系手动整理这份文档只需要二十分钟但它直接决定了 Codex 接下来的输出质量这笔投入非常值。2.3 为什么说这个“任务书”决定了 Codex 输出质量的上限关于 AI 编程我自己的观察是模型的生成能力已经普遍够用真正拉开差距的是喂给模型的上下文质量。同样是写一个登录页如果你只告诉 Codex “做个登录页”它大概率会给你一套漂亮的表单但如果你在上下文里写明“手机号 验证码登录前校验手机号格式接口路径是 /api/auth/sms-login失败时用 toast 提示后端返回的 message”它产出的就是可以直接联调的页面。PROJECT_CONTEXT.md 起的作用正是把隐性需求显性化。它不是什么高科技本质上是把产品经理脑子里的需求、设计师稿子里的细节、后端接口的约定全部压缩成一份 Codex 反复参考的“施工说明”。Codex 在生成代码的每个阶段都会回看这个文件你在上下文里写清楚了 tokens、页面状态、验收标准它产出的代码天然更贴合设计稿你不写它就会用自己训练数据里的默认审美去自由发挥结果往往是一个看起来很现代但和设计稿没有半毛钱关系的页面。2.4 导出时容易漏掉的信息状态、边界、空数据设计稿通常是理想状态下的静态呈现但真实软件的核心工作恰恰在“非理想状态”。我的经验是在整理 PROJECT_CONTEXT.md 时除了 Relay 导出的那部分必须额外补充状态与边界的说明。具体来说我至少会写清楚三类情况一是按钮的 loading 态和禁用态比如登录请求发出后按钮要转圈并禁止重复提交二是空数据态工单列表为空时展示什么内容三是错误态接口超时或返回非 2xx 时用户会看到什么提示。这块内容如果不写Codex 产出的页面会在所有正常路径上表现得不错但一到断网、空列表、后端异常这些边界情况就会暴露出粗糙的一面。移动端产品做得“糙”和“扎实”的区别通常不在主流程的页面上而在这类边界处理里。把这些状态提前写进上下文等于在施工前就把验收标准定好了。3. Codex 全栈搭建实战移动端、服务端与数据模型的同步推进3.1 把项目骨架交给 Codex初始化指令怎么写才不容易跑偏代码代理的第一课是“指令要具体到可执行”。我刚开始用 Codex 时喜欢说“帮我初始化一个移动端全栈项目”它每次都会和我确认半天技术栈浪费上下文额度。现在我会在一句话里把技术栈、目录结构、共享包全部讲清楚codex exec init a monorepo at current directory. apps/mobile must be expo react native with typescript. apps/server must be fastify with typescript. apps/shared must contain shared types. install dependencies and verify both apps can typecheck为什么选 React Native Expo因为对“从原型到可交付”这条链路来说Expo 是收敛速度最快的方案扫码真机预览、统一的依赖管理、内置构建服务这些都省掉了纯 React Native 原生配置的琐碎成本。服务端选 Fastify 是因为它类型友好、插件体系干净和 TypeScript 的共享类型配合起来很顺畅。数据库开发阶段用 SQLite原因只有一个——零部署成本Codex 不需要为它配置任何外部依赖等进入生产部署再替换成 PostgreSQL。这里的关键原则是把“学习成本和运维成本”从开发期剥离让注意力全放在业务链路上。需要特别提醒的是第一次跑这个初始化命令时不要指望一次成功。Codex 在执行脚手架命令时经常遇到网络超时、npm 版本告警、包冲突之类的问题它自己会读取报错并重试你要做的只是在旁边观察如果它连续两次朝错误方向努力再出手打断。实际观察下来codex 在初始化阶段的核心价值在于它能把 monorepo 里三个子项目一起拉起来并且自动安装各自依赖这步手动做至少一个小时它十分钟内就完成了。3.2 我的推进顺序数据契约优先于页面渲染项目骨架就绪后我习惯遵循“数据契约优先”的推进顺序这也是我认为全栈 AI 开发最重要的一条经验。关系型数据库的建模、后端接口的出入参、移动端的类型定义这三者其实是同一件事的不同表现。如果让 Codex 先做移动端页面它会出现接口还没有、数据类型全靠猜的尴尬局面如果先做后端接口移动端又会因为拿不到确切的类型定义而频繁返工。正确顺序是先把数据契约定死。我在 PROJECT_CONTEXT.md 里写了核心实体但到了 Codex 这里我会让它把实体定义成一个 TypeScript 类型文件放在 apps/shared/src/types.ts 里这样后端和移动端共享同一份类型。比如工单模块的核心类型export type WorkOrderStatus PENDING | PROCESSING | COMPLETED | CANCELLED; export interface WorkOrder { id: string; orderNo: string; status: WorkOrderStatus; customerName: string; customerPhone: string; vehiclePlate: string; description: string; createdAt: string; updatedAt: string; } export interface WorkOrderListItem extends WorkOrder { workItemsCount: number; }这份类型文件就是整条链路的“共同语言”。Codex 生成后端路由时Fastify 的 request handler 会 import 这些类型生成移动端页面时React Native 的 API client 也会 import 同一份类型。类型对上了前后端联调的问题就少了一大半。命令可以是codex exec create apps/shared/types.ts from PROJECT_CONTEXT.md data fields. Then in apps/server, add a route GET /api/orders that returns WorkOrderListItem[] from sqlite. In apps/mobile, create a typed fetch wrapper in src/api/client.ts that imports from apps/shared3.3 任务拆解与验证每个阶段都留下可回滚的节点Codex 执行长任务时容易陷入“越改越乱”的状态所以我不会让它一口气从数据模型干到页面联调而是把整条链路拆成可验证的阶段。每个阶段结束代码必须通过该阶段的质量门槛我才会进入下一阶段。我实际是这样拆的阶段一跑通 monorepo 骨架tsc 无错误git init 并打第一个 tag。阶段二完成 shared types后端能读写 SQLite移动端能编译通过git 打 tag。阶段三后端核心路由全部可用用 curl 验证关键接口返回结构git 打 tag。阶段四移动端接入路由和页面Expo 真机扫码能走通登录到列表git 打 tag。每个阶段我都会让 Codex 自己跑一遍验证命令比如npx tsc --noEmit、curl http://localhost:3000/api/orders。代理会自己看命令输出决定是否需要继续修代码。这里我强烈建议你在关键节点使用 git tag哪怕是临时的 v0.1.0因为 Codex 在后续阶段改代码时偶尔会破坏前一个阶段已经验证过的逻辑有 tag 才能快速回到稳定版本重来。3.4 联调阶段的“隐身”问题接口地址、跨域、真机访问前后端代码都有了联调才是全栈开发真正花时间的地方。AI 生成的代码在本地跑通常很丝滑但一拿到真机上就经常出现连不上接口的问题。原因很简单本地服务默认监听 127.0.0.1而移动端真机访问你的电脑需要走局域网 IPiOS 模拟器用的是 localhostAndroid 模拟器要用 10.0.2.2真机则要用你电脑在局域网里的 IP。我的常用解法是让 Codex 在移动端生成一个环境配置模块按平台区分接口地址import { Platform } from react-native; const LOCAL_IP 192.168.1.100; // 你电脑的局域网 IP export function getApiBaseUrl(): string { if (__DEV__) { if (Platform.OS android) { return http://10.0.2.2:3000/api; } return http://localhost:3000/api; } return https://api.example.com/api; }同时在服务端明确要求 Fastify 监听 0.0.0.0 而不是默认的 localhost否则真机请求根本到不了服务。跨域问题也比想象中常见如果你在 Expo Web 模式下预览服务端没有配置 CORS 的话请求照样被浏览器拦截。所以我在服务端初始化时就会加一条await fastify.register(cors, { origin: true });这些细节如果写进上下文Codex 会在生成代码时自动处理省得后面返工。4. 交付前必须卡住的四道关接口、权限、构建、真机体验我见过太多团队玩 AI 编程玩得很嗨页面一个比一个炫但到了真正交付的时候就是拿不出手。原因不是 AI 不行而是没有人把交付标准立起来。移动端 AI 全栈开发做到最后拼的不是生成速度而是你有没有在交付前认真卡住那几道关键关卡。我总结为四个字接口、权限、构建、真机。4.1 接口关AI 写的接口先过契约测试再过联调Codex 生成后端接口的速度确实快但它默认产出的接口有两个毛病一是错误处理过于简化几乎只有成功路径的返回二是返回结构不稳定同一个接口在不同版本里可能一次返回数组一次返回带分页的对象。针对这两个问题我的做法是统一响应封装和契约校验。先在上下文里约定所有后端路由的返回结构export interface ApiResponseT { code: number; data: T; message: string; }再让 Codex 引入 zod把 shared types 转成运行时校验器Fastify 路由层统一校验入参和出参。每次接口改动后让 Codex 自己跑一组契约自测脚本codex exec create a contract test file for API /api/orders. It should start the server, call GET /api/orders, assert status 200 and data matches WorkOrderListItem[] from shared types. run the test and fix errors这样做的价值在于AI 在后续优化过程中无论怎么改内部实现只要它跑不过契约测试你就能立刻发现。契约测试本质上比人肉点页面可靠得多尤其是在快速迭代的 AI 工作流里。4.2 权限关密钥管理、登录态与数据越权权限问题在 AI 生成代码里极其容易被忽视。Codex 为了让你“快速跑通”会把数据库连接串、第三方密钥直接硬编码在配置文件里这在交付时是绝对不能接受的。我的兜底方案是初始化时就在上下文里写入“敏感信息必须通过环境变量注入”并让 Codex 生成 .env.example 文件开发环境的真实密钥放在 .env.local 里。登录态的设计也要提前约定。移动端拿到短期 access token 后统一放内存或 Keychain/Keystore不要把 token 写进 AsyncStorage 之类的明文存储区。后端每个需要鉴权的路由都用同一套 JWT 校验中间件包裹避免出现“部分路由有鉴权、部分路由裸奔”的漏网之鱼。最终 review 时我会重点跟一遍数据越权链路一个普通用户登录后能否通过拼接请求参数访问别人的工单AI 不会自动理解“这是一个多租户系统用户只能访问自己门店的数据”这些规则必须显式写在上下文里。写清楚了Codex 生成的查询条件才会带上 ownerId 或 shopId 的过滤逻辑。4.3 构建关iOS/Android 打包过程的典型翻车点开发环境跑得再好构建不出安装包就是零。移动端 AI 全栈开发的构建阶段我观察 Codex 反复遇到的典型问题有三个第一是依赖版本脆弱AI 重装依赖后package-lock.json被更新某个中间版本引入原生方法失效第二是 Metro 配置或 Babel 配置缺失Transform 阶段报错第三是 iOS 的 CocoaPods 版本和 Xcode 版本不匹配Android 的 Gradle 插件版本和 SDK 版本冲突。我的经验是不要人工去查这些报错直接把报错丢给 Codex 让它自己排查代码代理在这类“执行-报错-读栈-修复”的任务上表现相当好。例如codex exec expo run:android build failed with error [贴报错]. inspect the gradle files and fix the version conflict, then rebuild. do not change app logic真正需要人盯的是构建流程的稳定性。我要求 Codex 把 iOS 和 Android 的 release 构建写到 package.json 的脚本里并在每次阶段收尾时让 Codex 跑一次npm run build:android确保产物始终可安装。只跑开发调试模式是不够的因为 release 构建会开启 ProGuard/R8 混淆和资源压缩暴露很多 dev 模式下不出现的错误。4.4 真机体验关像素、滚动、加载态才是移动端交付的临门一脚构建出包只是开始用户真正感知到的是真机上的体验。AI 生成的移动端页面经常在视觉上没有问题但真机操作起来总有微妙的违和感列表滚动掉帧、图片加载白屏、按钮点击没有反馈。我的做法是把“核心链路真机走查”列为交付的强制项。首当其冲的性能优化点是长列表。Codex 默认会用 FlatList但它经常忘记给每个 item 设置正确的 key也容易在 renderItem 里写复杂的匿名函数。这些问题在数据量少的 Demo 里无感但一旦列表到了几百条卡顿感就会变得很明显。我会直接要求 Codex 把核心列表替换为 FlashList这个库对列表项的回收和渲染优化比 FlatList 更激进是真机滚动流畅度的保底方案。其次是图片。Relay 导出的设计稿里通常包含大量图片资源AI 往往直接外链到原地址这在真机上不仅慢而且不靠谱。交付策略是统一走自己的资源托管且请求时按屏幕尺寸裁剪压缩。第三是加载态接口请求中要显示 loading请求失败要给出重试入口否则用户看到的就是一个静默的白屏。这几条听起来基础但 AI 生成的代码不强制约定的话默认就是不做。真机走查还有个容易被忽略的点软键盘弹出时页面会不会被顶出可视区、手势滑动返回会不会和页内交互冲突、Android 返回键的逻辑是否正确。这些属于平台交互习惯AI 初版基本不会考虑周全必须在真机走查时逐一排查把问题反馈给 Codex 修复。5. 这套链路里最容易翻车的 8 个细节与我的兜底方案前四章讲的是正向流程这一章我把从 Relay 到 Codex 的实操中反复踩到的细节集中列出来。每一条都是我付出过时间成本换来的教训配套的兜底方案也比较成熟可以直接照用。5.1 图片资源不能直接用 Figma CDNRelay 导出的代码里图片往往指向 Figma 的临时 CDN 链接。这些链接时效性强正式包如果依赖它过几天图片可能就失效了。兜底方案在导出阶段就把用到图片筛选出来统一放到项目的 assets/images 目录让 Codex 在代码里引用本地资源或你的对象存储地址。这个动作不能拖到打包前再做越早替换越省事。5.2 设计 Token 中的小数位与冗余变量Relay 导出的 Design Tokens 有时会产生一堆近似色比如主色的 hover 态被描述成 #2563EB 和 #2563EB 两个看起来一样的值。AI 生成的代码风格也不一致可能同时存在colors.primary、colors.blue[600]、#2563EB三种写法。兜底方案让 Codex 锁定唯一 Token 来源在 shared 层定义一个样式变量文件页面里禁止直接写颜色字面量。这个约束靠人 review 成本太高我会让 Codex 用 ESLint 规则去拦截。5.3 数据库索引缺失联调到一半开始慢查询AI 建数据库表的时候只会关心字段不会主动加索引。开发阶段数据量小看不出来但联调时一旦有人开始导入真实一批工单数据按订单号或门店 ID 查询的接口立马就慢下来。兜底方案在 context 的非功能需求里直接写“数据库表必须为查询条件字段建立索引”同时阶段验证里加一条“用 1000 条测试数据跑一遍核心查询接口响应小于 300ms”的验收标准。5.4 AI 改一处回归另一处必须给关键路径加保护这是 AI 全栈开发给我留下的最深教训。Codex 修一个登录页 bug 时有可能顺手改坏了列表页的路由参数而且它自己毫无感知。兜底方案不是禁止它改而是给核心路径建立自动化保护。我会让 Codex 写一份“核心链路冒烟测试”用 Node 脚本或 Detox 模拟登录到工单详情的完整流程每次阶段任务结束先跑一遍冒烟测试过了才算完成。这套保护网建立得越早后续迭代的信心越足。5.5 服务监听地址不对真机永远连不上这个坑在 3.4 已经提过但它值得在翻车清单里单独占一条。Codex 默认启动 Node 服务时通常监听 localhostAndroid 模拟器访问宿主机要用 10.0.2.2真机要访问局域网 IP三者之间有一处没对上就联调失败。兜底方案一句话服务端统一监听 0.0.0.0移动端 API 地址按平台区分把这两个规则写进 PROJECT_CONTEXT.md让 Codex 在生成阶段就处理掉。5.6 环境变量串用多会话共用同一个 .env 的灾难Codex 的一个隐藏风险是它在多个会话里操作同一份 .env容易把测试环境的配置写到生产环境文件里或者反之。我自己遇到过数据库连接串被 AI 在某个实验分支里改掉主分支拉到最新后莫名连不上库的情况。兜底方案固定环境文件命名和加载优先级开发环境只用 .env.local生产配置放在部署平台的环境变量里仓库里只允许提交 .env.example。我会在代码 review 时特意检查有没有 .env 被意外提交。5.7 依赖没有锁版本隔天 install 就崩Codex 装依赖的默认行为是安装最新版很多包会以^x.y.z的形式写进 package.json导致同一个项目今天装没问题、明天重装就崩。兜底方案项目初始化完成那一刻立刻提交 package-lock.json后续每次 Codex 改依赖我都会要求它跑一次完整安装并检查 lock 文件的 diff确认变更可接受再提交。重要项目进一步建议开启 CI 构建检查每次合并前都跑一遍干净环境的 install build。5.8 接口改了文档没改交付物是完整的但不是可持续的Codex 让变更成本大幅降低但文档滞后的问题被放大了。它会很快地改掉一个接口的出参却完全不会想起来同步 OpenAPI 文档。这个问题的风险在当下交付时不明显但下一轮迭代或新成员加入时就是灾难。兜底方案阶段验证清单里强制包含“更新接口文档”。我会让 Codex 在每次修改后端路由后运行一个脚本从 Fastify 路由配置里生成 OpenAPI 描述并提交到仓库。这样每个阶段的交付产物都是闭环的代码和文档同步更新不会留技术债。这套链路我现在已经跑过三个项目最大的体会是AI 真正的杠杆不在于“生成”而在于“验证闭环”。过去人写代码写完靠自己 review 和测试去发现问题现在 Codex 写代码它自己会执行、会报错、会修但最终能不能交付仍然取决于你有没有给它建立足够强的验收标准。Relay 负责把视觉意愿转译成清晰上下文Codex 负责把上下文加速成真实产物人则负责定义那一条条完成的边界。想让这条链路跑得顺我建议从一个小而完整的项目开始一个登录、一个列表、一个详情三张页面一条通到底。等你把从上下文整理到真机交付的每个环节都踩过一遍再让它处理复杂业务也不迟。
上个月我们做了一款给汽修门店用的移动端管理工具从Figma里一套Relay原型到可安装的App包总耗时两天半。三年前这种项目我不敢想前端、后端、测试三个人排期不算需求拉扯光是把视觉还原成像素级页面再等接口联调一周能出一个能点来点去的Demo已经算相当顺利。现在把Codex放进这条链路设计稿到可交付产物的路径被压缩到不可思议的程度。我不是说AI替代了所有工作而是移动端AI全栈开发已经从“玩具阶段”走到了“能跑通正式交付”的阶段。这篇文章把我最近几次实操的完整链路拆开讲清楚Relay怎么把原型图变成Codex能理解的任务书Codex怎么在同一套项目里推进移动端、服务端和数据模型交付前必须卡住哪几道关以及这条链路里反复翻车的细节和我的兜底方案。内容不浮夸核心目标就一个——让你能照着这套方法把一份设计稿变成真正可安装、可体验、可交付的移动端产品而不是停留在“AI写了个页面Demo”的层面。1. 为什么我现在敢让 AI 直接参与“从图纸到交付”的全过程1.1 Codex 不是聊天补全工具是能动手干活的编码代理很多人对Codex的理解还停留在“它能在对话框里写代码”这完全低估了它。Codex是一个长在终端里的编码代理它不只是生成代码片段而是能读你仓库里的文件、执行命令、跑测试、观察报错信息然后自己修改代码继续重试。换句话说它具备一个完整“执行闭环”这是它和普通AI代码补全最本质的区别。我实盘用过之后最大的感受是Codex适合承接“从零搭工程”和“按指令改工程”这两类脏活。比如初始化一个 React Native TypeScript 项目它会真的去执行脚手架命令装依赖然后自己把基础目录建好。中间如果出现依赖冲突它会把报错贴回来分析版本关系再执行修复命令。这个过程的体验很像带一个基础扎实但经验不足的实习生你给它明确任务它在执行中会撞坑但关键是它能“自己爬起来继续走”。1.2 Relay 的价值把设计语言转成可编程资产Relay 是 Figma 官方的 AI 插件它做的事情听起来很简单但实际意义很大把设计稿翻译成可用的前端代码和设计令牌。你在 Figma 里选中的一组 FrameRelay 会识别出按钮、列表、输入框、表单这些组件输出对应的组件代码还会抽取颜色、字体、间距、圆角等样式常量统一成 Design Tokens。对全栈开发链路来说Relay 最大的贡献不是“能生成代码”这个噱头而是它把设计稿变成了一份结构化的、可被另一个 AI 消费的上下文。以前你给AI描述需求只能靠嘴说“登录页要一个居中的卡片圆角16主色是#2563EB”中间的信息损耗很大。Relay 导出的内容本身就带着层级、属性和设计规范这让 Codex 拿到项目时是在“参照图纸施工”而不是“凭印象发挥”。1.3 两者的分工正好补上移动端交付链路的空档一条完整的移动端交付链路通常包含四条线并行设计线、前端线、后端线、交付线。设计线负责产出视觉稿和交互前端线要把视觉稿实现成页面后端线要提供接口、数据模型、鉴权交付线要把代码打包成能在真机上安装运行的产物。过去AI编程工具大多只助攻“前端线”你给它一张图它给你一段代码。但代码能跑不代表链路能通。直到 Codex 这种能管理整个工程目录、能同时操作前后端代码的编码代理出现后端线和交付线才真正可以被AI介入。Relay 解决“设计到代码的翻译”Codex 解决“代码到可交付系统的工程化”中间靠一份清晰的上下文文件衔接。这就是标题里“从 Relay 原型图到可交付链路”的完整含义。1.4 什么场景真的适合这套链路我实际跑下来最适合这条链路的场景有三类一类是MVP验证创业团队需要快速把想法变成能拿给投资人演示的App第二类是内部工具公司内部用的移动端应用重流程、轻并发不追求极致的性能第三类是活动页或产品改版的前期探索需要快速验证多个视觉风格的可行性和真实用户体验。反过来核心业务链路、涉及复杂权限模型和高并发交易的场景我不建议直接让AI全盘接管。这些系统的难点往往不在“代码生成”而在“架构决策”和“边界条件”AI可以帮你写其中80%的代码但剩下20%的设计判断仍然需要人来做。把它当作高强度加速器而不是完全自动驾驶这是我这几次实操下来最重要的心态。2. Relay 导出上下文把设计稿变成 Codex 能读懂的任务书2.1 我实际使用 Relay 导出原型的操作流程第一步是在 Figma 里选中要开发的整块 Frame注意必须是一块完整的导航流程最好包含多个页面状态而不是只选一个静态图。选完之后在插件面板中唤起 Relay它会要求你选择代码生成目标我在移动端项目里通常选 React Native TypeScript。Relay 的导出结果一般包含三部分一是页面级的组件代码二是整个项目的 Design Tokens也就是颜色、字号、间距、圆角、阴影这些变量三是一份组件依赖树告诉你看得见的每个 UI 元素是从哪里继承、如何组合的。导出完成后建议把代码复制到本地临时目录里不要直接在 Figma 内部编辑因为我们后面要做大量二次改写本地文件操作更方便。这里有个容易被忽略的动作导出之后花十分钟把 Relay 生成的代码里那几个典型页面过一遍核对核心交互是否被正确识别。比如登录按钮是否标了 onPress 事件列表行是否识别出可点击态表单是否区分了 label 和 placeholder。AI 工具对视觉语言的识别偶尔会有偏差你提前纠正的成本远比让 Codex 在你写的几百行代码里找问题低。2.2 从导出物到 PROJECT_CONTEXT.md我的模板与转换脚本直接让 Codex 去读 Relay 导出的原始文件不是不行但效果不稳定。原文件通常带有大量 Figma 特有的节点标记和自动生成的奇怪变量名Codex 会花掉不少上下文额度去理解这些噪音。所以我每次都会先做一次“转译”把 Relay 的导出物整理成一份浓缩的任务书我把它命名为 PROJECT_CONTEXT.md放进仓库根部。我常用的 PROJECT_CONTEXT.md 结构是这样# 项目上下文 ## 项目背景 一句话说明产品是什么、给谁用、解决什么问题。 ## 技术栈 移动端: React Native Expo TypeScript 服务端: Fastify TypeScript 数据库: SQLite开发/ PostgreSQL生产 共享类型: apps/shared/src/types.ts ## 设计 Tokens - 主色: #2563EB - 背景色: #F8FAFC - 正文字号: 16px行高 24px - 卡片圆角: 16px - 主按钮高度: 48px圆角 12px ## 页面清单与交互 - /login: 手机号 验证码登录点击登录后校验手机号格式 - /workbench: 今日工单列表下拉刷新点击单行跳转详情 - /order-detail/:id: 工单详情包含状态流转按钮 ## 数据字段约定 - User: { id, phone, name, role } - WorkOrder: { id, orderNo, status, customerName, createdAt } ## 非功能需求 - 冷启动时间控制在 3 秒以内 - 支持 Android 8.0 及以上iOS 13 及以上 - 主要操作路径在弱网环境下可用 ## 验收标准 1. 登录 → 工单列表 → 工单详情 核心链路可闭环 2. 接口错误统一提示不出现白屏 3. 打包产物可安装到真机你可以写个小脚本把 Relay 导出的 Tokens 自动映射到你项目里的变量文件页面组件树自动转成页面清单里的交互说明省时又不容易漏。没有脚本也没关系手动整理这份文档只需要二十分钟但它直接决定了 Codex 接下来的输出质量这笔投入非常值。2.3 为什么说这个“任务书”决定了 Codex 输出质量的上限关于 AI 编程我自己的观察是模型的生成能力已经普遍够用真正拉开差距的是喂给模型的上下文质量。同样是写一个登录页如果你只告诉 Codex “做个登录页”它大概率会给你一套漂亮的表单但如果你在上下文里写明“手机号 验证码登录前校验手机号格式接口路径是 /api/auth/sms-login失败时用 toast 提示后端返回的 message”它产出的就是可以直接联调的页面。PROJECT_CONTEXT.md 起的作用正是把隐性需求显性化。它不是什么高科技本质上是把产品经理脑子里的需求、设计师稿子里的细节、后端接口的约定全部压缩成一份 Codex 反复参考的“施工说明”。Codex 在生成代码的每个阶段都会回看这个文件你在上下文里写清楚了 tokens、页面状态、验收标准它产出的代码天然更贴合设计稿你不写它就会用自己训练数据里的默认审美去自由发挥结果往往是一个看起来很现代但和设计稿没有半毛钱关系的页面。2.4 导出时容易漏掉的信息状态、边界、空数据设计稿通常是理想状态下的静态呈现但真实软件的核心工作恰恰在“非理想状态”。我的经验是在整理 PROJECT_CONTEXT.md 时除了 Relay 导出的那部分必须额外补充状态与边界的说明。具体来说我至少会写清楚三类情况一是按钮的 loading 态和禁用态比如登录请求发出后按钮要转圈并禁止重复提交二是空数据态工单列表为空时展示什么内容三是错误态接口超时或返回非 2xx 时用户会看到什么提示。这块内容如果不写Codex 产出的页面会在所有正常路径上表现得不错但一到断网、空列表、后端异常这些边界情况就会暴露出粗糙的一面。移动端产品做得“糙”和“扎实”的区别通常不在主流程的页面上而在这类边界处理里。把这些状态提前写进上下文等于在施工前就把验收标准定好了。3. Codex 全栈搭建实战移动端、服务端与数据模型的同步推进3.1 把项目骨架交给 Codex初始化指令怎么写才不容易跑偏代码代理的第一课是“指令要具体到可执行”。我刚开始用 Codex 时喜欢说“帮我初始化一个移动端全栈项目”它每次都会和我确认半天技术栈浪费上下文额度。现在我会在一句话里把技术栈、目录结构、共享包全部讲清楚codex exec init a monorepo at current directory. apps/mobile must be expo react native with typescript. apps/server must be fastify with typescript. apps/shared must contain shared types. install dependencies and verify both apps can typecheck为什么选 React Native Expo因为对“从原型到可交付”这条链路来说Expo 是收敛速度最快的方案扫码真机预览、统一的依赖管理、内置构建服务这些都省掉了纯 React Native 原生配置的琐碎成本。服务端选 Fastify 是因为它类型友好、插件体系干净和 TypeScript 的共享类型配合起来很顺畅。数据库开发阶段用 SQLite原因只有一个——零部署成本Codex 不需要为它配置任何外部依赖等进入生产部署再替换成 PostgreSQL。这里的关键原则是把“学习成本和运维成本”从开发期剥离让注意力全放在业务链路上。需要特别提醒的是第一次跑这个初始化命令时不要指望一次成功。Codex 在执行脚手架命令时经常遇到网络超时、npm 版本告警、包冲突之类的问题它自己会读取报错并重试你要做的只是在旁边观察如果它连续两次朝错误方向努力再出手打断。实际观察下来codex 在初始化阶段的核心价值在于它能把 monorepo 里三个子项目一起拉起来并且自动安装各自依赖这步手动做至少一个小时它十分钟内就完成了。3.2 我的推进顺序数据契约优先于页面渲染项目骨架就绪后我习惯遵循“数据契约优先”的推进顺序这也是我认为全栈 AI 开发最重要的一条经验。关系型数据库的建模、后端接口的出入参、移动端的类型定义这三者其实是同一件事的不同表现。如果让 Codex 先做移动端页面它会出现接口还没有、数据类型全靠猜的尴尬局面如果先做后端接口移动端又会因为拿不到确切的类型定义而频繁返工。正确顺序是先把数据契约定死。我在 PROJECT_CONTEXT.md 里写了核心实体但到了 Codex 这里我会让它把实体定义成一个 TypeScript 类型文件放在 apps/shared/src/types.ts 里这样后端和移动端共享同一份类型。比如工单模块的核心类型export type WorkOrderStatus PENDING | PROCESSING | COMPLETED | CANCELLED; export interface WorkOrder { id: string; orderNo: string; status: WorkOrderStatus; customerName: string; customerPhone: string; vehiclePlate: string; description: string; createdAt: string; updatedAt: string; } export interface WorkOrderListItem extends WorkOrder { workItemsCount: number; }这份类型文件就是整条链路的“共同语言”。Codex 生成后端路由时Fastify 的 request handler 会 import 这些类型生成移动端页面时React Native 的 API client 也会 import 同一份类型。类型对上了前后端联调的问题就少了一大半。命令可以是codex exec create apps/shared/types.ts from PROJECT_CONTEXT.md data fields. Then in apps/server, add a route GET /api/orders that returns WorkOrderListItem[] from sqlite. In apps/mobile, create a typed fetch wrapper in src/api/client.ts that imports from apps/shared3.3 任务拆解与验证每个阶段都留下可回滚的节点Codex 执行长任务时容易陷入“越改越乱”的状态所以我不会让它一口气从数据模型干到页面联调而是把整条链路拆成可验证的阶段。每个阶段结束代码必须通过该阶段的质量门槛我才会进入下一阶段。我实际是这样拆的阶段一跑通 monorepo 骨架tsc 无错误git init 并打第一个 tag。阶段二完成 shared types后端能读写 SQLite移动端能编译通过git 打 tag。阶段三后端核心路由全部可用用 curl 验证关键接口返回结构git 打 tag。阶段四移动端接入路由和页面Expo 真机扫码能走通登录到列表git 打 tag。每个阶段我都会让 Codex 自己跑一遍验证命令比如npx tsc --noEmit、curl http://localhost:3000/api/orders。代理会自己看命令输出决定是否需要继续修代码。这里我强烈建议你在关键节点使用 git tag哪怕是临时的 v0.1.0因为 Codex 在后续阶段改代码时偶尔会破坏前一个阶段已经验证过的逻辑有 tag 才能快速回到稳定版本重来。3.4 联调阶段的“隐身”问题接口地址、跨域、真机访问前后端代码都有了联调才是全栈开发真正花时间的地方。AI 生成的代码在本地跑通常很丝滑但一拿到真机上就经常出现连不上接口的问题。原因很简单本地服务默认监听 127.0.0.1而移动端真机访问你的电脑需要走局域网 IPiOS 模拟器用的是 localhostAndroid 模拟器要用 10.0.2.2真机则要用你电脑在局域网里的 IP。我的常用解法是让 Codex 在移动端生成一个环境配置模块按平台区分接口地址import { Platform } from react-native; const LOCAL_IP 192.168.1.100; // 你电脑的局域网 IP export function getApiBaseUrl(): string { if (__DEV__) { if (Platform.OS android) { return http://10.0.2.2:3000/api; } return http://localhost:3000/api; } return https://api.example.com/api; }同时在服务端明确要求 Fastify 监听 0.0.0.0 而不是默认的 localhost否则真机请求根本到不了服务。跨域问题也比想象中常见如果你在 Expo Web 模式下预览服务端没有配置 CORS 的话请求照样被浏览器拦截。所以我在服务端初始化时就会加一条await fastify.register(cors, { origin: true });这些细节如果写进上下文Codex 会在生成代码时自动处理省得后面返工。4. 交付前必须卡住的四道关接口、权限、构建、真机体验我见过太多团队玩 AI 编程玩得很嗨页面一个比一个炫但到了真正交付的时候就是拿不出手。原因不是 AI 不行而是没有人把交付标准立起来。移动端 AI 全栈开发做到最后拼的不是生成速度而是你有没有在交付前认真卡住那几道关键关卡。我总结为四个字接口、权限、构建、真机。4.1 接口关AI 写的接口先过契约测试再过联调Codex 生成后端接口的速度确实快但它默认产出的接口有两个毛病一是错误处理过于简化几乎只有成功路径的返回二是返回结构不稳定同一个接口在不同版本里可能一次返回数组一次返回带分页的对象。针对这两个问题我的做法是统一响应封装和契约校验。先在上下文里约定所有后端路由的返回结构export interface ApiResponseT { code: number; data: T; message: string; }再让 Codex 引入 zod把 shared types 转成运行时校验器Fastify 路由层统一校验入参和出参。每次接口改动后让 Codex 自己跑一组契约自测脚本codex exec create a contract test file for API /api/orders. It should start the server, call GET /api/orders, assert status 200 and data matches WorkOrderListItem[] from shared types. run the test and fix errors这样做的价值在于AI 在后续优化过程中无论怎么改内部实现只要它跑不过契约测试你就能立刻发现。契约测试本质上比人肉点页面可靠得多尤其是在快速迭代的 AI 工作流里。4.2 权限关密钥管理、登录态与数据越权权限问题在 AI 生成代码里极其容易被忽视。Codex 为了让你“快速跑通”会把数据库连接串、第三方密钥直接硬编码在配置文件里这在交付时是绝对不能接受的。我的兜底方案是初始化时就在上下文里写入“敏感信息必须通过环境变量注入”并让 Codex 生成 .env.example 文件开发环境的真实密钥放在 .env.local 里。登录态的设计也要提前约定。移动端拿到短期 access token 后统一放内存或 Keychain/Keystore不要把 token 写进 AsyncStorage 之类的明文存储区。后端每个需要鉴权的路由都用同一套 JWT 校验中间件包裹避免出现“部分路由有鉴权、部分路由裸奔”的漏网之鱼。最终 review 时我会重点跟一遍数据越权链路一个普通用户登录后能否通过拼接请求参数访问别人的工单AI 不会自动理解“这是一个多租户系统用户只能访问自己门店的数据”这些规则必须显式写在上下文里。写清楚了Codex 生成的查询条件才会带上 ownerId 或 shopId 的过滤逻辑。4.3 构建关iOS/Android 打包过程的典型翻车点开发环境跑得再好构建不出安装包就是零。移动端 AI 全栈开发的构建阶段我观察 Codex 反复遇到的典型问题有三个第一是依赖版本脆弱AI 重装依赖后package-lock.json被更新某个中间版本引入原生方法失效第二是 Metro 配置或 Babel 配置缺失Transform 阶段报错第三是 iOS 的 CocoaPods 版本和 Xcode 版本不匹配Android 的 Gradle 插件版本和 SDK 版本冲突。我的经验是不要人工去查这些报错直接把报错丢给 Codex 让它自己排查代码代理在这类“执行-报错-读栈-修复”的任务上表现相当好。例如codex exec expo run:android build failed with error [贴报错]. inspect the gradle files and fix the version conflict, then rebuild. do not change app logic真正需要人盯的是构建流程的稳定性。我要求 Codex 把 iOS 和 Android 的 release 构建写到 package.json 的脚本里并在每次阶段收尾时让 Codex 跑一次npm run build:android确保产物始终可安装。只跑开发调试模式是不够的因为 release 构建会开启 ProGuard/R8 混淆和资源压缩暴露很多 dev 模式下不出现的错误。4.4 真机体验关像素、滚动、加载态才是移动端交付的临门一脚构建出包只是开始用户真正感知到的是真机上的体验。AI 生成的移动端页面经常在视觉上没有问题但真机操作起来总有微妙的违和感列表滚动掉帧、图片加载白屏、按钮点击没有反馈。我的做法是把“核心链路真机走查”列为交付的强制项。首当其冲的性能优化点是长列表。Codex 默认会用 FlatList但它经常忘记给每个 item 设置正确的 key也容易在 renderItem 里写复杂的匿名函数。这些问题在数据量少的 Demo 里无感但一旦列表到了几百条卡顿感就会变得很明显。我会直接要求 Codex 把核心列表替换为 FlashList这个库对列表项的回收和渲染优化比 FlatList 更激进是真机滚动流畅度的保底方案。其次是图片。Relay 导出的设计稿里通常包含大量图片资源AI 往往直接外链到原地址这在真机上不仅慢而且不靠谱。交付策略是统一走自己的资源托管且请求时按屏幕尺寸裁剪压缩。第三是加载态接口请求中要显示 loading请求失败要给出重试入口否则用户看到的就是一个静默的白屏。这几条听起来基础但 AI 生成的代码不强制约定的话默认就是不做。真机走查还有个容易被忽略的点软键盘弹出时页面会不会被顶出可视区、手势滑动返回会不会和页内交互冲突、Android 返回键的逻辑是否正确。这些属于平台交互习惯AI 初版基本不会考虑周全必须在真机走查时逐一排查把问题反馈给 Codex 修复。5. 这套链路里最容易翻车的 8 个细节与我的兜底方案前四章讲的是正向流程这一章我把从 Relay 到 Codex 的实操中反复踩到的细节集中列出来。每一条都是我付出过时间成本换来的教训配套的兜底方案也比较成熟可以直接照用。5.1 图片资源不能直接用 Figma CDNRelay 导出的代码里图片往往指向 Figma 的临时 CDN 链接。这些链接时效性强正式包如果依赖它过几天图片可能就失效了。兜底方案在导出阶段就把用到图片筛选出来统一放到项目的 assets/images 目录让 Codex 在代码里引用本地资源或你的对象存储地址。这个动作不能拖到打包前再做越早替换越省事。5.2 设计 Token 中的小数位与冗余变量Relay 导出的 Design Tokens 有时会产生一堆近似色比如主色的 hover 态被描述成 #2563EB 和 #2563EB 两个看起来一样的值。AI 生成的代码风格也不一致可能同时存在colors.primary、colors.blue[600]、#2563EB三种写法。兜底方案让 Codex 锁定唯一 Token 来源在 shared 层定义一个样式变量文件页面里禁止直接写颜色字面量。这个约束靠人 review 成本太高我会让 Codex 用 ESLint 规则去拦截。5.3 数据库索引缺失联调到一半开始慢查询AI 建数据库表的时候只会关心字段不会主动加索引。开发阶段数据量小看不出来但联调时一旦有人开始导入真实一批工单数据按订单号或门店 ID 查询的接口立马就慢下来。兜底方案在 context 的非功能需求里直接写“数据库表必须为查询条件字段建立索引”同时阶段验证里加一条“用 1000 条测试数据跑一遍核心查询接口响应小于 300ms”的验收标准。5.4 AI 改一处回归另一处必须给关键路径加保护这是 AI 全栈开发给我留下的最深教训。Codex 修一个登录页 bug 时有可能顺手改坏了列表页的路由参数而且它自己毫无感知。兜底方案不是禁止它改而是给核心路径建立自动化保护。我会让 Codex 写一份“核心链路冒烟测试”用 Node 脚本或 Detox 模拟登录到工单详情的完整流程每次阶段任务结束先跑一遍冒烟测试过了才算完成。这套保护网建立得越早后续迭代的信心越足。5.5 服务监听地址不对真机永远连不上这个坑在 3.4 已经提过但它值得在翻车清单里单独占一条。Codex 默认启动 Node 服务时通常监听 localhostAndroid 模拟器访问宿主机要用 10.0.2.2真机要访问局域网 IP三者之间有一处没对上就联调失败。兜底方案一句话服务端统一监听 0.0.0.0移动端 API 地址按平台区分把这两个规则写进 PROJECT_CONTEXT.md让 Codex 在生成阶段就处理掉。5.6 环境变量串用多会话共用同一个 .env 的灾难Codex 的一个隐藏风险是它在多个会话里操作同一份 .env容易把测试环境的配置写到生产环境文件里或者反之。我自己遇到过数据库连接串被 AI 在某个实验分支里改掉主分支拉到最新后莫名连不上库的情况。兜底方案固定环境文件命名和加载优先级开发环境只用 .env.local生产配置放在部署平台的环境变量里仓库里只允许提交 .env.example。我会在代码 review 时特意检查有没有 .env 被意外提交。5.7 依赖没有锁版本隔天 install 就崩Codex 装依赖的默认行为是安装最新版很多包会以^x.y.z的形式写进 package.json导致同一个项目今天装没问题、明天重装就崩。兜底方案项目初始化完成那一刻立刻提交 package-lock.json后续每次 Codex 改依赖我都会要求它跑一次完整安装并检查 lock 文件的 diff确认变更可接受再提交。重要项目进一步建议开启 CI 构建检查每次合并前都跑一遍干净环境的 install build。5.8 接口改了文档没改交付物是完整的但不是可持续的Codex 让变更成本大幅降低但文档滞后的问题被放大了。它会很快地改掉一个接口的出参却完全不会想起来同步 OpenAPI 文档。这个问题的风险在当下交付时不明显但下一轮迭代或新成员加入时就是灾难。兜底方案阶段验证清单里强制包含“更新接口文档”。我会让 Codex 在每次修改后端路由后运行一个脚本从 Fastify 路由配置里生成 OpenAPI 描述并提交到仓库。这样每个阶段的交付产物都是闭环的代码和文档同步更新不会留技术债。这套链路我现在已经跑过三个项目最大的体会是AI 真正的杠杆不在于“生成”而在于“验证闭环”。过去人写代码写完靠自己 review 和测试去发现问题现在 Codex 写代码它自己会执行、会报错、会修但最终能不能交付仍然取决于你有没有给它建立足够强的验收标准。Relay 负责把视觉意愿转译成清晰上下文Codex 负责把上下文加速成真实产物人则负责定义那一条条完成的边界。想让这条链路跑得顺我建议从一个小而完整的项目开始一个登录、一个列表、一个详情三张页面一条通到底。等你把从上下文整理到真机交付的每个环节都踩过一遍再让它处理复杂业务也不迟。
