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 center on functional closure with weak design constraints, allowing rapid assembly via component libraries. Mobile C-end pages face users directly; Relay prototypes and UI designs are comprehensive contracts covering interaction, information hierarchy, state feedback, and business trust.

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

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 prioritize 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 works. Essence: "data operation interface."

Mobile C-end pages prioritize user experience. Users come to complete instant tasks (booking, payment, consultation). Limited screen space, limited attention, pages carry 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 classify the page type:

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

If 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 Diagrams: 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 expects users to complete tasks, page modules, user selection/confirmation/jump paths, information emphasis, state feedback.

In AI full-stack, Relay diagrams serve not just as images for Codex but as structured parsing inputs:

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 layers.

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

Identify acceptance criteria: final page must resemble Relay diagram, live flow must work.

Thus Relay diagrams are input protocols for Codex to understand requirements, decompose tasks, and generate code.

3. Five Contract Categories from Relay/UI Prototypes

Relay/UI prototypes can be decomposed into five contracts:

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

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

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

Business Contract : A button may represent complex decisions: already booked?, in consultation?, has entitlement?, allowed to proceed?, jump link needs context params. These are not directly expressed in UI but determine actual usability.

Engineering Contract : Page must integrate with existing project: reuse components, API wrappers, routing, styling, tracking, shared utilities. AI-generated code cannot float outside project context.

These five contracts jointly determine mobile AI generation quality. Providing only Relay diagrams leads to static pages; only APIs leads to design mismatches; only business descriptions leads to field guesses; no engineering constraints leads to code alien to 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."

4. Generating UI Contract Specification from Relay Diagrams

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

The spec must include at least:

Page Structure : Regions composing the page (e.g., nav bar, time selection card, doctor list, bottom sheet).

Visual Rules : Colors, font sizes, spacing, radii (e.g., light gray background, white cards, green selected state, subtle shadows).

Interaction States : Component states (selected, unselected, disabled, loading, empty, expanded).

Data Mapping : Which API field backs each UI element (doctor name, hospital, specialties, stats, button links).

Business Rules : Logic affecting display and navigation (entitlement status, booking status, target page params).

Engineering Boundaries : How code lands in current project (reference pages, allowed files, forbidden public component changes).

Acceptance Criteria : What "done" means (screenshot matches design, live data flow works).

Most critical are "Data Mapping" and "Business Rules." Many mobile reworks stem not from styling inability but from unclear API fields and business states.

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

UI Area          | Data Source              | Display Strategy
-----------------|--------------------------|--------------------------------
Doctor name      | Doctor basic info        | Primary, must show
Title/Department | Doctor basic info        | Same row or adjacent
Hospital name    | Hospital info            | Secondary, separate line
Tags             | Doctor tag array         | Count controlled to avoid card overflow
Specialties      | Doctor intro field       | Default two lines, expandable
Stats            | Review/consultation/wait objects | Extract display values, don't render raw objects
Button           | Backend-delivered result | Frontend only shows copy and navigates

Tabular contracts significantly reduce AI field-guessing and ease human review.

5. Why Mobile Pages Must Not Let AI Design Freely

AI excels at completion. Given "video appointment 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 system. They must conform to existing app visual language, interaction habits, user expectations.

Common AI free-design issues:

Turning medical pages into marketing landing pages with large gradients, illustrations, 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 "prettiness."

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 generation space into engineering-controllable range.

6. 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 in frontend bloats client complexity.

Example: A button's final 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 error

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

Show button? Backend judges business state; Frontend displays/hides per result.

Button copy Backend delivers per scenario; Frontend renders as-is.

Jump link Backend assembles final URL; Frontend navigates on click.

Error fallback Backend retains old flow or degrades; Frontend shows default state.

Special scenarios Backend isolates via whitelist or post-processing; Frontend 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 public pages.

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

7. Recommended Process: Relay Input, Codex Parse, Seven Steps

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

1. Identify Page Type

Determine PC admin vs. mobile C-end. Affects all subsequent actions: prompt style, code boundaries, acceptance criteria, design alignment needs.

2. Decompose UI Spec

Break Relay diagram into visual rules, interaction rules, state matrix, content priority. Do not let AI decide page style.

3. Restore Business Flow

Clarify user entry, current page APIs, post-click destination, params to pass through. Mobile pages are not islands.

4. Front-load API Contracts

Fix field structures with real JSON. Especially clarify object field extraction, empty arrays, button link sources, error fallbacks.

5. Backend Closes Complex Logic

Orders, entitlements, states, navigation — backend unifies judgment; frontend only displays and triggers.

6. Frontend Controlled Generation

AI generates within explicit boundaries: reference Relay/UI prototype, reference existing project pages, modify only current page files, introduce no unrelated dependencies.

7. Dual Acceptance

Screenshot confirms "close to Relay diagram"; real data and navigation confirm "flow works." Mobile C-end must satisfy both.

8. Three Typical Issues in Practice

Issue 1: Functionally Complete but Not Like a Mobile Product

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

Fix is not "ask AI to polish" 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?

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

Issue 2: Looks Right but Real Data Breaks

Indicates insufficient API contract front-loading.

Common problems:

Object fields rendered directly → [object Object] appears.

Empty arrays cause page errors.

Wrong target service picked among multiple.

Button shows info not required by design.

URL params missing, next page cannot complete business.

Solution: establish field consumption table, require AI to fix per table, not continue guessing.

Issue 3: Current Page Works but Breaks Old Flows

Most dangerous in backend changes.

To satisfy one mobile special case, worst move is modifying shared 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 main flow.

Fallback to original flow on error.

Retain logs to verify special logic hits.

Non-target businesses must keep original responses.

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

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

PC admin acceptance leans functional: API works, 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 UI-spec-absent decorations?

Doctor list, buttons, sheets follow mobile conventions?

No crowding, occlusion, misalignment on small screens?

Flow Acceptance

Answers "can it be used for real?"

Entry params complete?

API requests correct?

Response fields consumed per contract?

Backend-delivered links complete?

Click lands correct page?

Special states follow correct branches?

Non-target businesses unaffected?

Logs prove flow completion?

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

10. Prompts to Codex: Upgrade from "Requirement Description" to "Delivery Protocol"

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

Reliable prompt structure:

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

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

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

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

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

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

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

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

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

Goal is not longer prompts but making implicit constraints explicit. Less AI guessing, less rework.

11. 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 with 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, business flows. AI's correct role in mobile is not replacing design/engineering judgment but accelerating implementation under explicit contracts.

Method summarized in four sentences:

Decompose UI spec into contracts first.

Fix APIs as field consumption tables first.

Backend closes complex business first.

AI generation must pass visual and flow 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 generation toward deliverable results.