Codex-Driven Mobile Full-Stack: From Relay Prototypes to Deliverable Pipelines

Abstract

AI programming tools lower cross-platform development barriers, but "letting AI write pages" does not equal "completing mobile delivery." PC admin pages focus on functional closure with weak design constraints, allowing rapid assembly via component libraries. Mobile C-end pages face real users; Relay prototypes and UI designs are comprehensive contracts for interaction, information hierarchy, state feedback, and business trust.

Based on a mobile appointment page AI full-stack practice, the author extracts a reusable method: distinguish PC admin vs. mobile C-end delivery standards, have Codex parse Relay prototypes into five contract categories (visual, interaction, data, business, engineering), then follow a "backend closes complex decisions, frontend executes design expression, AI generates within constraints, screenshot and pipeline dual acceptance" flow to achieve stable delivery from prototype to frontend-backend closed loop.

1. Problem Definition: AI Full-Stack Is Not a Single Scenario

Many AI full-stack articles assume that if AI writes both backend and frontend, full-stack is done. This holds for PC admin scenarios but is insufficient for mobile C-end.

PC Admin Pages: Core is operational efficiency. Users are internal, goals clear, tolerance high. Pages consist of filters, tables, modals, pagination, buttons. Delivery value exists when fields are complete, permissions correct, flow usable. Essence: "data operation interface."

Mobile C-End Pages: Core is user experience. Users complete instant tasks: booking, payment, consultation, order viewing, service entry. Limited screen space, limited attention, page carries brand trust and conversion. Essence: "user task interface."

These two page types demand completely different things from AI. Before discussing "AI full-stack," one must judge page type:

PC Admin: AI value lies in rapid scaffolding, form/table generation, API calls, validation logic.

Mobile C-End: AI value is not free design but efficient generation of verifiable implementations under design constraints.

Core thesis: Mobile AI full-stack development is not a code generation problem; it is a contract management problem.

2. Relay Prototypes: Not Screenshots, But Requirement Protocols

Mobile Relay prototypes are often misunderstood as "what it looks like" screenshots. In engineering, they act as requirement protocols: how the product wants users to complete tasks, page modules, user selection/confirmation/jump flows, information emphasis, state feedback.

In AI full-stack, Relay's value is not just "showing Codex an image" but having Codex perform structured parsing:

Identify page regions: navigation, date card, time-slot selector, doctor list, bottom sheet, empty state.

Identify interaction paths: entry point, first selection, next click, final destination.

Identify visual constraints: colors, font sizes, radii, spacing, selected states, card hierarchy.

Identify data needs: which content comes from APIs, which is static copy, which requires backend delivery.

Identify acceptance criteria: final page must resemble Relay; real pipeline must run through.

Thus, Relay is not a "paint-by-numbers" image but the input protocol for Codex to understand requirements, decompose tasks, and generate code.

On this basis, Relay/UI prototypes can be further decomposed into five contract types:

Visual Contract: Colors, font sizes, radii, spacing, shadows, card hierarchy, icon ratios, empty-state styles. Mobile professionalism often stems from these details, not business logic.

Interaction Contract: User operations: horizontal date swipe, click to open bottom time-slot selector, tap overlay to close, doctor specialty expand/collapse, button press feedback, disabled state graying. Mobile is touch-first, not mouse-first; interactions cannot copy PC.

Data Contract: UI shows "good reviews," "hospital," "specialties," "video consultation," but real APIs may be nested objects, arrays, dynamic service items. Field extraction, empty-value display, whether to render object field as text or title must be defined upfront.

Business Contract: A button may represent complex decisions: already booked?, in consultation?, entitlement exists?, allowed to proceed?, jump link needs context params. These are not directly expressed in UI but determine if the page is truly usable.

Engineering Contract: Page must integrate into existing engineering: use existing components, API wrappers, routing system, styling solution, tracking methods, common utilities. AI-generated code cannot drift from project context.

These five contracts jointly determine mobile AI generation quality. Only giving Relay leads to static pages; only giving APIs leads to design mismatches; only giving business descriptions leads to field guesses; omitting engineering constraints leads to code alienated from project style.

Therefore, the first executable action in mobile AI development is not writing a prompt to start coding, but constructing a "UI Contract Specification."

3. Generating UI Contract Specifications from Relay

A spec that guides AI should come from Relay parsing, not developer improvisation. Effective approach: have Codex do a "structured restatement" of Relay, then developers confirm and supplement API info.

The spec must include at least the following structure (represented as a table in the source):

Contract Layer | Questions to Answer | Example
--------------|---------------------|--------
Page Structure | What regions compose the page? | Nav bar, time selection card, doctor list, bottom sheet
Visual Rules | Colors, font sizes, spacing, radii | Light gray bg, white cards, green selected, subtle shadow
Interaction States | What states do components have? | Selected, unselected, disabled, loading, empty, expanded
Data Mapping | Which API field backs each UI element? | Doctor name, hospital, specialties, stats, button link
Business Rules | Which logic affects display and navigation? | Entitlement status, booking status, target page params
Engineering Boundaries | How does code land in current project? | Reference pages, allowed files, forbidden common components
Acceptance Criteria | What counts as done? | Screenshot close to design, real data pipeline works

The most critical are "Data Mapping" and "Business Rules." Many mobile reworks happen not because styles are hard, but because API fields and business states were unclear.

Example: Doctor list UI shows a card, but engineering must decompose:

UI Region | Data Source | Display Strategy
----------|-------------|----------------
Doctor Name | Doctor Basic Info | Primary, must show
Title/Dept | Doctor Basic Info | Same row or adjacent
Hospital Name | Hospital Info | Secondary, separate line
Tags | Doctor Tags Array | Count controlled to avoid card overflow
Specialties | Doctor Intro Field | Default two lines, expandable
Stats | Review/Consult/Wait Objects | Take display value, don't render object
Button | Backend-Delivered Result | Frontend only shows copy and navigates

Such tabular contracts significantly reduce AI field-guessing and facilitate human review.

4. Why Mobile Pages Must Not Let AI Design Freely

AI excels at completion. Given "video booking page," it will add nav, cards, buttons, illustrations, animations, empty states. Helpful in prototyping, dangerous in production mobile requirements.

Mobile C-end pages are not isolated artifacts; they are part of a product ecosystem. They must conform to existing App visual language, interaction habits, and user expectations.

Common AI free-design issues:

Turning medical page into marketing landing page with large gradients, illustrations, huge CTAs.

Making mobile lists into PC card flows, wrong information density and gesture habits.

Showing prices, tags, badges not required by UI spec.

Self-assembling business links causing missing params or inconsistent state calibers.

Ignoring empty, loading, disabled states.

Adding styles violating project design system for "good looks."

These are not traditional bugs but cause product/design rejection.

Hence, in mobile AI prompts, "what not to do" is as important as "what to do." Example negative constraints:

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

Reverse constraints compress AI's generation space into engineering-controllable range.

5. Backend Role in Mobile AI Full-Stack: Close Decisions, Not Just Provide APIs

In PC admin, backend provides CRUD APIs, frontend handles interaction. Division is straightforward.

Mobile C-end differs: many display states hide complex business decisions. Putting all logic on frontend bloats client complexity.

Example: Appointment button destination may depend on:

Current order type

User entitlement ownership

Entitlement usage status

Ongoing service existence

Need to enter IM

Need to enter doctor list

Context params for next page

Fallback to original flow on exception

These judgments rely on backend data and history, unsuitable for mobile self-derivation. Better: backend generates decision results.

Responsibility split (source table):

Decision Item | Backend Responsibility | Frontend Responsibility
--------------|------------------------|----------------------
Show Button? | Judge business state | Show/hide per result
Button Text | Deliver per scenario | Display as-is
Jump Link | Backend assembles final URL | Click to navigate
Exception Fallback | Keep old flow or degrade | Show default state
Special Scenarios | Isolate via whitelist or post-processing | Unaware of complex branches

Benefits:

Frontend lighter, implementation closer to design expression.

Business state caliber unified, no multi-end duplicate logic.

Special logic isolated in backend, not polluting common pages.

Thus, backend engineers doing mobile AI full-stack are not "incidentally writing frontend." They upgrade from API providers to pipeline designers: deciding which logic backend closes, which content mobile displays.

6. Recommended Process: Relay Input, Codex Decomposition, Seven-Step Execution

Mobile AI full-stack is not suited for "one-shot full page generation." Stable approach: use Relay as input source, have Codex parse first, then proceed stepwise.

Identify Page Type: Judge PC admin vs. mobile C-end. Affects all subsequent actions: prompt style, code boundaries, acceptance criteria, need for design alignment.

Decompose UI Spec: Break Relay into visual rules, interaction rules, state matrix, content priority. Do not let AI decide page style.

Restore Business Flow: Clarify user entry, current page APIs, click destinations, params to pass through. Mobile pages are not islands.

Predefine API Contracts: Fix field structures with real JSON. Especially clarify object field extraction, empty arrays, button link sources, exception fallbacks.

Backend Closes Complex Logic: Order, entitlement, state, navigation — backend unifies judgment; frontend only displays and triggers.

Frontend Controlled Generation: AI generates within clear boundaries: reference Relay/UI, reference existing project pages, modify only current page files, introduce no unrelated dependencies.

Dual Acceptance: Screenshot confirms "close to Relay"; real data and navigation confirm "pipeline runs." Mobile C-end must satisfy both.

7. Three Typical Issues in Practice

Issue 1: Page Functional But Not Mobile-Like

Most common in AI first version. Page has functions but visually resembles generic web page or shrunken PC admin.

Solution is not "ask AI to beautify" but return to UI contract:

Background color correct?

Cards too heavy?

List over-cardified?

Font sizes match mobile hierarchy?

Bottom sheet resembles mobile component?

Empty state matches design?

"Beautify" is vague; "correct per contract" is engineering instruction.

Issue 2: Page Looks Right But Real Data Breaks

Indicates insufficient API contract upfront.

Common problems:

Object fields rendered directly, producing [object Object].

Empty arrays cause page errors.

Wrong target service picked among multiple service items.

Button shows info not required by design.

URL params missing, next page cannot complete business.

Fix: establish field consumption table, require AI to correct per table, not continue guessing.

Issue 3: Current Page Works But Breaks Old Flows

Most dangerous in backend changes.

To satisfy a mobile special case, worst move is modifying common components or shared scripts. Short-term fix, but may affect historical orders, other service packages, other entry pages.

Safer approach:

Restrict special logic with explicit conditions.

Add post-processing, don't alter common main flow.

Fallback to original flow on exception.

Retain logs to verify special logic hit.

Non-target businesses must keep original responses.

Closer to C-end core pipeline, impact control must be priority.

8. Acceptance: Mobile Cannot Only Check "Function Complete"

PC admin acceptance leans functional: API through, data correct, permissions right, flow complete.

Mobile C-end requires dual acceptance.

Visual Acceptance

Answers "does it look like design?"

Page structure consistent?

Cards, radii, spacing close?

Font hierarchy accurate?

Empty, loading, disabled states complete?

No decorations absent from UI spec?

Doctor list, buttons, sheets follow mobile habits?

No crowding, occlusion, misalignment on small screens?

Pipeline Acceptance

Answers "can it be used for real?"

Entry params complete?

API requests correct?

Response fields consumed per contract?

Backend-delivered links complete?

Click navigates to correct page?

Special states follow correct branches?

Non-target businesses unaffected?

Logs prove pipeline execution?

Only passing both visual and pipeline acceptance means mobile page is done.

9. Prompts Upgrade: From Requirement Description to Delivery Protocol

In mobile AI development, prompts must not just describe requirements but constrain AI like a delivery protocol.

Reliable prompt structure (source code block):

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

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

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

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

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

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

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

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

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

Goal of such prompts is not "write longer" but make implicit constraints explicit. The less AI guesses, the less rework.

10. Conclusion: Core of Mobile AI Full-Stack Is Controlled Generation

AI can significantly boost full-stack efficiency, but mobile C-end pages cannot be equated to PC admin pages.

PC admin leans functional implementation; mobile C-end leans experience delivery. Former can rapid-build on component libraries; latter must respect Relay/UI prototypes, real data, and business pipelines. AI's correct position in mobile development is not replacing design and engineering judgment, but accelerating implementation under explicit contracts.

This method summarizes to four sentences:

UI spec first decomposed into contracts.

APIs first fixed as field consumption tables.

Complex business first closed by backend.

AI generation must pass visual and pipeline dual acceptance.

When we organize context this way, AI becomes not just a page generator but a collaboration tool that improves delivery efficiency within engineering boundaries. For backend engineers, this is a more realistic mobile AI full-stack path: not magically acquiring frontend design skills, but using business understanding, API contracts, and engineering boundaries to steer AI's generation toward deliverable results.