Codex 驱动的移动端AI全栈开发：从 Relay 原型图到可交付链路

摘要

AI 编程工具降低了跨端开发门槛，但"让 AI 写页面"并不等于"完成移动端交付"。PC 运营端页面通常以功能闭环为中心，设计约束较弱，研发可以基于组件库快速搭建；移动端 C 端页面直接面对用户，Relay 原型图和 UI 设计稿不仅是视觉参考，更是交互、信息层级、状态反馈和业务信任感的综合契约。

本文基于一次移动端预约类页面的 AI 全栈开发实践，提炼一套可复用的方法：先区分 PC 运营端与移动端 C 端的交付标准，再让 Codex 理解并解析 Relay 原型图，将其拆解为视觉、交互、数据、业务和工程五类契约；在此基础上，通过"后端收口复杂决策、前端执行设计表达、AI 在约束内生成代码、截图与链路双重验收"的流程，实现从原型图到前后端闭环的稳定交付。

本文重点不在某段代码如何实现，而在回答一个更普遍的问题：后端工程师如何借助 AI 承担移动端全栈交付，但不把移动端页面做成一个"能跑的后台页面"。

一、问题定义：AI 全栈开发不是一个单一场景

很多 AI 全栈实践文章容易默认一个前提：只要能让 AI 同时写后端和前端，就完成了全栈开发。这个判断在 PC 运营端场景里基本成立，但在移动端 C 端场景里并不充分。

PC 运营端页面的核心是操作效率。用户是内部人员，目标明确，容忍度较高。常见页面由筛选区、表格、弹窗、分页和按钮组成。只要字段完整、权限正确、流程可用，页面就具备交付价值。它的本质是"数据操作界面"。

移动端 C 端页面的核心是用户体验。用户不是为了理解系统而来，而是为了完成一个即时任务：预约、支付、问诊、查看订单、进入服务。移动端屏幕空间有限，用户注意力有限，页面还承担品牌信任和业务转化。它的本质是"用户任务界面"。

这两类页面对 AI 的要求完全不同。





因此，讨论"AI 全栈开发"之前，必须先判断页面类型：

•如果是 PC 运营端，AI 的价值主要在快速搭建功能骨架、生成表单表格、补齐接口调用和校验逻辑。

•如果是移动端 C 端，AI 的价值不应是自由设计，而是在设计稿约束下高效生成可验证的实现。

这也是本文的核心观点：移动端 AI 全栈开发不是代码生成问题，而是契约管理问题。

二、Relay 图的本质：不是截图，而是需求协议

移动端 Relay 原型图经常被误解成"长什么样"的截图。真正进入工程实现时，它更像一份需求协议：产品希望用户如何完成任务，页面由哪些模块组成，用户如何选择、确认、跳转，哪些信息需要突出，哪些状态需要反馈。

在 AI 全栈开发里，Relay 图的价值不只是"给 Codex 看一张图"。更重要的是让 Codex 对图进行结构化解析：

•识别页面区域：导航、日期卡片、时段选择、医生列表、底部弹层、空态；

•识别交互路径：用户从哪里进入，先选什么，再点什么，最后跳到哪里；

•识别视觉约束：颜色、字号、圆角、间距、选中态、卡片层级；

•识别数据需求：哪些内容来自接口，哪些只是静态文案，哪些需要后端下发；

•识别验收标准：最终页面要和 Relay 图接近，真实链路也要走通。

也就是说，Relay 图不是"照着画"的图片，而是 Codex 理解需求、拆解任务和生成代码的输入协议。





在这个基础上，Relay/UI 原型可以进一步拆成五类契约。

第一类是视觉契约。它定义颜色、字号、圆角、间距、阴影、卡片层级、图标比例和空态风格。移动端页面的专业感往往来自这些细节，而不是业务逻辑本身。

第二类是交互契约。它定义用户怎么操作：横向滑动日期、点击弹出底部时段选择器、点击遮罩关闭、医生擅长展开收起、按钮点击反馈、不可用状态置灰。移动端是触控环境，不是鼠标环境，交互不能照搬 PC。

第三类是数据契约。UI 稿上写的是"好评""医院""擅长""视频问诊"，但真实接口可能是嵌套对象、数组、动态服务项。字段怎么取、空值怎么展示、对象字段展示 text 还是 title，这些都必须前置。

第四类是业务契约。页面中的一个按钮可能代表复杂业务决策：是否已预约、是否诊中、是否存在权益、是否允许进入下一步、跳转链接是否需要携带上下文参数。这些不是 UI 稿直接表达的内容，但决定页面是否真的可用。

第五类是工程契约。页面要融入现有工程：使用既有组件、API 封装、路由体系、样式方案、埋点方式和公共工具。AI 生成代码不能脱离项目上下文。





这五类契约共同决定移动端 AI 生成质量。只给 Relay 图，AI 容易生成静态页面；只给接口，页面容易不像设计稿；只给业务描述，字段容易猜错；不给工程约束，代码容易游离于项目风格之外。

因此，移动端 AI 开发的第一个可执行动作，不是写提示词让 AI 开始编码，而是构造一份"UI 契约说明"。

三、从 Relay 图生成 UI 契约说明

一份能指导 AI 的 UI 契约说明，应该来自 Relay 图解析，而不是研发凭空补充。比较有效的做法是先让 Codex 对 Relay 图做一次"结构化复述"，再由研发确认和补充接口信息。

这份说明至少应该包含以下结构。

契约层	需要说明的问题	示例
页面结构	页面由哪些区域组成	导航栏、时间选择卡片、医生列表、底部弹层
视觉规则	颜色、字号、间距、圆角	浅灰背景、白色卡片、绿色选中态、轻阴影
交互状态	组件有哪些状态	选中、未选、不可用、加载、空、展开
数据映射	UI 元素来自哪个字段	医生名、医院、擅长、统计项、按钮链接
业务规则	哪些逻辑影响展示和跳转	权益状态、预约状态、目标页面参数
工程边界	代码如何落到当前项目	参考页面、允许修改文件、禁止改公共组件
验收标准	什么叫完成	截图接近设计稿，真实数据链路可走通

这里最关键的是"数据映射"和"业务规则"。很多移动端页面返工不是因为样式不会写，而是因为接口字段和业务状态没说清楚。

以医生列表为例，UI 上看到的是一张医生卡，但工程上应拆成：

UI 区域	数据来源	展示策略
医生姓名	医生基础信息	主信息，必须展示
职称/科室	医生基础信息	与姓名同行或紧邻展示
医院名称	医院信息	次级信息，单独一行
标签	医生标签数组	数量受控，避免撑开卡片
擅长	医生介绍字段	默认两行，支持展开
统计项	评价/接诊/等待对象	取展示值，不直接渲染对象
按钮	后端下发结果	前端只展示文案并跳转

这种表格化契约能显著降低 AI 猜字段的概率，也方便人工 Review。

四、为什么移动端页面不能让 AI 自由设计

AI 很擅长补全。你给它"视频预约页面"，它会补导航、补卡片、补按钮、补插画、补动效、补空态。这在原型阶段可能有帮助，但在正式移动端需求中反而危险。

因为移动端 C 端页面不是一个孤立作品，而是产品体系的一部分。它必须符合现有 App 的视觉语言、交互习惯和用户预期。

AI 自由设计常见的问题包括：

•把医疗页面做成营销落地页，加入大渐变、大插画、大 CTA；

•把移动端列表做成 PC 卡片流，信息密度和手势习惯都不对；

•在 UI 稿没有要求的地方展示价格、标签、角标；

•自行拼接业务链接，导致参数缺失或状态口径不一致；

•忽略空态、加载态、不可用态；

•为了"好看"加入不符合项目设计系统的样式。

这些问题并非传统意义上的 bug，但会导致页面无法通过产品和设计验收。

所以移动端 AI 提示词里，"不要做什么"与"要做什么"同样重要。例如：

不要把页面做成 PC 后台风格。
不要增加设计稿没有的渐变、头图、装饰卡片。
不要自行设计医生卡片结构，优先参考项目已有医生列表。
不要展示 UI 稿没有要求的价格和内部状态字段。
不要在前端拼接复杂业务跳转链接。
不要修改公共组件来满足单个特殊场景。

这种反向约束的意义，是把 AI 的生成空间压缩到工程可控范围内。

五、后端在移动端 AI 全栈中的职责：收口决策，而不是只给接口

在 PC 运营端开发中，后端通常提供 CRUD 接口，前端负责页面交互。这种分工相对直接。

移动端 C 端页面不同。很多展示状态背后是复杂业务决策。如果把这些逻辑全部放到前端，会造成端侧复杂度膨胀。

以预约链路为例，一个按钮最终跳哪里，可能依赖：

•当前订单类型；

•用户是否拥有权益；

•权益是否已使用；

•是否存在进行中的服务；

•是否需要进入 IM；

•是否需要进入医生列表；

•下一页需要哪些上下文参数；

•异常时是否回退原链路。

这些判断依赖后端数据和历史状态，不适合让移动端页面自行推导。更好的做法是由后端生成决策结果：

决策项	后端职责	前端职责
是否展示按钮	判断业务状态	按结果展示或隐藏
按钮文案	根据业务场景下发	原样展示
跳转链接	后端拼接最终 URL	点击跳转
异常兜底	保留老链路或降级	展示默认状态
特殊场景	后端用白名单或后置逻辑隔离	不感知复杂分支

这个分工能带来三个好处：

1.前端更轻，页面实现更接近设计表达；

2.业务状态口径统一，不会多端各写一套；

3.特殊逻辑可以在后端隔离，不污染公共页面。

因此，后端工程师做移动端 AI 全栈，并不是"顺便写点前端"。更准确地说，是从接口提供者升级为链路设计者：负责判断哪些逻辑该后端收口，哪些内容交给移动端展示。

六、推荐流程：Relay 输入、Codex 拆解、七步推进

移动端 AI 全栈开发不适合"一句话生成完整页面"。更稳定的方式是把 Relay 图作为输入源，让 Codex 先解析，再按步骤推进。





1. 识别页面类型

先判断页面是 PC 运营端还是移动端 C 端。这个判断会影响后续所有动作：提示词写法、代码边界、验收标准、是否需要设计稿对齐。

2. 拆解 UI 稿

把 Relay 图拆成视觉规则、交互规则、状态矩阵和内容优先级。不要让 AI 自行决定页面风格。

3. 还原业务链路

画清楚用户从哪里进入、当前页面调用什么接口、点击后去哪里、哪些参数需要透传。移动端页面不是孤岛。

4. 前置接口契约

用真实 JSON 固定字段结构。尤其要明确对象字段取值、数组为空、按钮链接来源、异常兜底方式。

5. 后端收口复杂逻辑

订单、权益、状态、跳转这类复杂逻辑尽量由后端统一判断，前端只做展示和触发。

6. 前端受控生成

让 AI 在明确边界内生成页面：参考 Relay/UI 原型图、参考项目已有页面、只修改当前页面相关文件、不引入无关依赖。

7. 双重验收

用截图确认"是否贴近 Relay 图"，用真实数据和跳转确认"链路是否走通"。移动端 C 端页面必须同时满足两者。

七、实战中的三类典型问题

问题一：页面功能完整，但不像移动端产品

这是 AI 初版最常见的问题。页面有功能，但视觉上像一个普通 Web 页面，甚至像 PC 后台缩小版。

解决方式不是让 AI "美化一下"，而是回到 UI 契约：

•背景色是否正确；

•卡片是否过重；

•列表是否过度卡片化；

•字号是否符合移动端层级；

•底部弹层是否像移动端组件；

•空态是否符合设计稿。

"美化"是模糊指令，"按契约修正"才是工程指令。

问题二：页面像了，但真实数据一接就出错

这通常说明接口契约前置不足。

常见问题包括：

•对象字段直接渲染，出现 [object Object]；

•数组为空时页面报错；

•多个服务项中取错了目标服务；

•按钮展示了设计稿没有要求的信息；

•URL 参数漏传，下一页无法完成业务。

解决方式是建立字段消费表，并要求 AI 按字段表修正，而不是让它继续猜。

问题三：当前页面能跑，但影响老链路

这是后端改造中最需要警惕的问题。

为了满足一个移动端特殊场景，最危险的做法是直接修改公共组件或公共脚本。这样短期能解决当前问题，但可能影响历史订单、其他服务包、其他入口页面。

更稳妥的做法是：

•用明确条件限定特殊逻辑；

•新增后置处理，不改公共主流程；

•异常时回退原链路；

•保留日志，便于验证是否命中特殊逻辑；

•非目标业务必须保持原返回。

移动端页面越靠近 C 端核心链路，越要把影响面控制放在第一位。

八、验收：移动端不能只看"功能完成"

PC 运营端页面验收通常偏功能：接口通、数据准、权限对、流程完整。

移动端 C 端页面要做双重验收。





视觉验收

视觉验收回答"像不像设计稿"：

•页面结构是否一致；

•卡片、圆角、间距是否接近；

•字号层级是否准确；

•空态、加载态、不可用态是否完整；

•是否出现 UI 稿没有的装饰；

•医生列表、按钮、弹层是否符合移动端习惯；

•小屏下是否拥挤、遮挡或错位。

链路验收

链路验收回答"能不能真实使用"：

•入口参数是否完整；

•接口请求是否正确；

•返回字段是否按契约消费；

•后端下发链接是否完整；

•点击后是否进入正确页面；

•特殊状态是否走正确分支；

•非目标业务是否不受影响；

•日志能否证明链路走通。

只有同时通过视觉验收和链路验收，移动端页面才算完成。

九、给 Codex 的提示词应从"需求描述"升级为"交付协议"

移动端 AI 开发中，提示词不能只描述需求，而要像交付协议一样约束 AI。

一个更可靠的提示词结构如下：

这是移动端 C 端页面，不是 PC 运营后台。
请先理解并解析 Relay 原型图，再基于解析结果实现页面。
必须严格根据 Relay/UI 设计稿实现，不允许自由设计。

1. 页面定位
- 面向真实用户
- 目标是完成预约/选择/跳转
- 体验和设计稿还原优先

2. Relay 图解析
- 页面区域
- 用户操作路径
- 视觉重点
- 交互状态

3. UI 契约
- 页面结构
- 颜色、字号、间距、圆角
- 列表、卡片、弹层、空态
- 选中、不可用、加载、展开等状态

4. 业务链路
- 用户入口
- URL 参数
- 当前页接口
- 点击后的目标页
- 需要透传的上下文

5. 接口契约
- 请求参数
- 真实返回示例
- 字段消费表
- 对象字段取值规则
- 空值兜底规则

6. 工程边界
- 参考已有页面
- 使用现有 API 封装
- 只修改当前页面相关文件
- 不修改公共组件

7. 反例约束
- 不要做成 PC 后台风格
- 不要添加设计稿没有的装饰
- 不要展示内部字段
- 不要前端拼复杂业务链接

8. 验收标准
- 截图接近 Relay/UI 原型图
- 真实数据不报错
- 点击链路走通
- 非目标业务不受影响

这类提示词的目标不是"写得更长"，而是把隐含约束显式化。AI 猜得越少，返工越少。

十、结语：移动端 AI 全栈的核心是受控生成

AI 可以显著提高全栈开发效率，但移动端 C 端页面不能简单等同于 PC 运营端页面。

PC 运营端偏功能实现，移动端 C 端偏体验交付。前者可以基于组件库快速搭建，后者必须尊重 Relay/UI 原型图、真实数据和业务链路。AI 在移动端开发中的正确位置，不是替代设计和工程判断，而是在明确契约下承担实现加速。

这套方法可以概括为四句话：

•UI 稿先拆成契约；

•接口先固定为字段消费表；

•复杂业务先由后端收口；

•AI 生成后必须做视觉与链路双重验收。

当我们用这套方式组织上下文时，AI 才不只是一个页面生成器，而是一个能在工程边界内提高交付效率的协作工具。对于后端工程师来说，这也是更现实的移动端 AI 全栈路径：不是凭空掌握前端设计能力，而是用业务理解、接口契约和工程边界，把 AI 的生成能力导向可交付结果。