做移动端全栈的人应该都有体会过去大半年里“用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 outAI编程时代这句话的杀伤力被放大了十倍设计稿不规范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.73TypeScript - 后端框架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先输出类型定义再写实现等于给它画了一个靶子后面的路由代码会围绕类型来写类型错误的比例大幅下降。后端生成后我会特别关注几个点接口鉴权是否遗漏、数据库查询有没有N1问题、错误响应里是否统一了格式。这三点是AI生成后端代码的高频问题也是上线后最容易爆雷的地方。4.3 联调阶段的Prompt技巧前后端都生成完了按传统开发模式要进入联调阶段。但Codex链路里联调的很多工作被前置了——因为前端的数据字段定义和后端的模型定义都源于同一份说明文档天然对齐。不过实际跑起来还是会遇到字段名不一致、数据类型不匹配、接口路径错误这类问题。联调阶段我通常会让Codex做一次“契约检查”把前端实际请求的接口和参数列出来把后端实际暴露的路由和接收的参数也列出来然后由Codex自动对照找出差异请对照以下两份文件找出前后端接口不一致的地方 - /mobile/src/api/ 目录下所有接口请求定义 - /server/src/routes/ 目录下所有路由定义 输出格式不一致的路径、差异详情、建议修改方前端/后端。 不要修改代码只输出检查结果。这一步非常实用。Codex读代码库的能力比人脑扫代码快得多尤其适合这种机械性的对照工作。检查结果出来后让它逐项修复基本能把联调时间压缩到一个小时以内。5. 交付前夜的质量门禁AI代码审查、性能清单与自动化测试AI生成的代码跑通功能只是开始真正决定能否交付的是质量门禁。这个阶段我把它当开发流程的半个骨架来对待因为AI开发速度越快质量问题越容易悄悄堆积。没有强制的质量关卡前一天生成的“快速代码”第三天就可能变成技术债。5.1 AI代码的典型雷区和审查重点用Codex生成了大量代码之后我总结出了AI代码的高频问题清单这些问题在人工审查时基本是必查项雷区类型典型表现严重程度硬编码魔法数值颜色、间距、文案直接写在组件里高缺乏防御性处理接口返回null直接崩溃、JSON字段缺失未兜底高类型滥用到处用any失去TypeScript保护中状态管理混乱全局状态滥用无注释说明适用场景中样式逻辑冗余一个按钮四种写法未抽取公共样式低错误处理欠缺网络请求失败后无用户提示静默失败高我在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/checkoutv4 - uses: actions/setup-nodev4 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全栈开发的可交付链路不能没有验收标准。我把“可交付”定义成一个检查清单严格区分“功能跑通”和“可交付”验收项标准检查方式视觉还原核心页面与Relay原型一致Tokens引用率100%截图对比功能完整性页面状态覆盖加载/失败/空数据/正常人工走查测试用例数据安全接口鉴权完整无敏感信息泄露代码审查性能达标列表滚动无明显卡顿包体积在预算内性能测试打包分析回归安全所有核心功能测试通过CI测试结果代码可维护无巨型组件无硬编码魔法数值AI自查人工抽检每一条验收标准都有对应的客观检查方式不靠感觉判断。只有清单上所有项都打了勾这个迭代才算是真正可交付的。6.3 几个值得记住的踩坑瞬间链路搭起来之后有几个坑我印象很深写出来供大家参考。第一个坑是Relay导出产物直接喂给Codex。我一开始以为Relay导出的代码已经足够结构化直接作为Prompt上下文给Codex用结果它生成了一堆被无用样式包裹的组件返工成本非常高。后来改成“人工整理页面说明文档设计令牌喂给Codex”的模式才稳定下来。AI时代并不意味着“省掉所有人工”而是把人工精力放在整理信息、约束上下文上这个投入回报率极高。第二个坑是一个会话里塞多个任务。有一次我图省事让Codex在一个会话里同时处理前端页面、后端接口和数据库迁移。前半段效果还行后半段它开始“遗忘”前端的设计规范生成的样式风格和前面不一致。后来强制实行“一次会话只干一种活”这种情况再没出现过。第三个坑是Codex把错误处理写得“太静默”。它默认生成的网络请求失败处理是只打一条console.error用户界面毫无反应。我是在一次演示时当面翻车的接口挂了页面却没有提示用户根本不知道发生了什么。这件事直接促使我在Prompt规范里强制加入“错误状态必须对用户可见且有重试入口”这条要求。还有一个关于上下文的小技巧Codex对上下文长度的消耗比想象中快尤其是代码库大了之后。我的做法是尽量让每个会话只涉及相关的几个文件不相关的文件不要提。Codex一旦开始读它不该读的文件注意力就会被带偏生成质量随之下降。最后再说一点个人体会把Relay到Codex的这条链路完整跑通之后我最大的感受是AI编程改变的不是写代码这个动作而是工程组织方式。过去我花大量时间在“写”上现在花时间最多的是三个地方——设计信息结构化、上下文投喂、验收把关。这三个地方恰恰都是机器不擅长的、需要业务判断的部分。操作链路本身不难难的是每次都忍住“让AI一口气把所有事情做完”的冲动。把链路拆细、把任务分段、把质量关卡前置短期看是慢了一点但放到一个完整迭代的周期里它是目前移动端AI全栈开发里最稳妥、最可复制的方式。如果你正在从Codex项目Demo往可交付状态推进建议从今天开始就按这条链路拆自己的项目先跑通一个小功能再逐步扩大边界。