做产品设计时最耗费时间的往往不是画稿子而是让设计稿和 PRD 时刻保持一致。PRD 改一个字段名设计稿要跟着改前端组件也要跟着改设计稿微调间距或布局PRD 的功能描述又显得不够准确。如果这些改动全部靠人眼比对、手动同步一个迭代周期会浪费大量时间。把 Stitch 与 Codex 放进同一条工作流后界面生成、文档沉淀和反向修改页面可以由 AI 承担大部分重复工作Stitch 负责从 PRD 语义生成界面结构Codex 负责把界面结构翻译成可以运行的代码并能在需求变更时同步修改页面和文档。下面先解决一个问题这套流程到底是怎么跑起来的需要准备哪些环境每一步为什么这样设计。文章会以一个“团队任务管理工具”的列表页为例从 PRD 开始经过 Stitch 生成 UI 规范再让 Codex 生成 React 组件最后演示一次从列表改成看板的反向修改并附上安装、登录、模型报错和接口报错的排查思路。1. 先理清提效逻辑Stitch 出界面Codex 做工程化1.1 设计与 PRD 同步真正慢在哪里很多团队把一个需求落成页面要经过至少三次人工翻译第一次产品经理把业务想法写成 PRD里面包含页面字段、交互流程、状态说明和业务规则。第二次设计师把 PRD 翻译成设计稿决定布局、视觉层级、交互细节。第三次前端把 PRD 和设计稿一起翻译成代码定义组件、数据结构、接口字段和状态处理。问题在于这三次翻译的时间是错开的。PRD 更新后设计稿不一定马上改设计稿改完前端组件可能还停留在旧版本文档说明更是经常被遗忘。等所有内容都对齐时往往已经接近提测节点。真正慢的并不是某一个环节而是三个环节之间的“双向同步”。设计稿和 PRD 之间的字段对应关系、组件代码和设计稿之间的视觉关系、文档和代码之间的行为关系全部依赖人脑记忆和手动核对。Stitch 与 Codex 的组合能解决一部分核心问题Stitch 把 PRD 快速转成结构化的界面规范Codex 再把界面规范转成可运行代码并把文档作为产物一起维护。这样人工只需要确认 AI 的输出是否正确而不是从零开始写每一个版本。1.2 Stitch 与 Codex 的分工边界Stitch 在这个流程里主要解决“从业务语义到界面结构”的问题。它接收 PRD 片段、页面描述和设计约束输出类似 UI Spec 的中间产物里面包含页面分区、组件类型、字段、操作按钮、状态和设计 token。导出的结果不直接是最终前端代码而是一份结构化的界面规范。Codex 主要解决“从界面结构到工程代码”的问题。它能读取本地仓库理解项目里已有的组件、目录和依赖然后根据 UI Spec 生成或修改组件代码、类型定义和说明文档。相比普通代码补全工具Codex 更适合这类需要读多个文件、跨文件修改的工作。两者的边界可以这样理解环节负责工具输入输出需求到界面结构StitchPRD 片段、字段表、状态说明、设计约束UI Spec JSON界面结构到代码CodexUI Spec JSON、现有仓库结构、技术栈约定组件 TSX、类型、样式、文档需求变更回写Codex Stitch新 PRD、修改后的 UI Spec修改后的代码、文档、指定历史实际项目里并不存在严格的先后顺序。Stitch 可以先出一版初始界面Codex 再实现也可以反向修改时先用 Codex 改代码再让 Stitch 根据新页面结构导出新的 UI Spec。关键是两者通过“UI Spec JSON”这个中间格式交流而不是靠人用自然语言反复描述。1.3 一次可回放的产品设计工作流这套工作流的完整顺序可以这样设计在仓库docs/prd.md中维护最新 PRD。从 PRD 提取页面字段、状态、操作和设计约束交给 Stitch 生成docs/ui-specs/team-task-list.json。Codex 读取 PRD 和 UI Spec生成src/components/TaskList.tsx、src/types/task.ts等代码文件。Codex 根据 UI Spec 和组件实现生成或更新docs/components/team-task-list.md。人工检查生成结果运行类型检查、构建和页面验证。下次需求变更时先更新 PRD再反向修改页面最后同步 UI Spec 和文档。这套流程的核心价值在于每次修改都有可追溯的文件变化。PRD 是业务事实源UI Spec 是界面契约组件代码是最终实现文档是给后续开发者的说明。只要顺序固定就不会出现“代码改了、文档没改、设计稿还是旧版”的情况。2. 环境准备本地工程、Codex 与 Stitch 工作台2.1 环境要求与版本确认在开始之前先确认本机环境满足基本要求。本文以典型的 React TypeScript 项目为例这不是唯一选择但用这一类前端项目最容易理解 AI 生成步骤。工具用途确认方式备注Node.js运行前端项目和 CLI 工具node -v、npm -v建议使用当前 LTS 版本Git记录文件变化便于回滚git --version每次 AI 修改后查看 diffCodex CLI 或桌面版读取仓库并生成/修改代码codex --version或桌面版“关于”页面安装方式以官方文档为准Stitch 工作台从 PRD 生成界面结构浏览器打开工作台不同团队接入方式不同这里要说明Stitch 在不同团队里的形态可能完全不同有的是 Web 工作台有的是 Figma 插件有的通过 API 接入。本文不依赖某一家的具体界面只要求它能导出“界面结构 JSON”也就是后面统一说的 UI Spec JSON。如果你的 Stitch 没有导出功能也可以让 Codex 从设计稿描述生成等价的结构文件。2.2 安装 Codex 并完成登录Codex 的安装方式会随版本变化。桌面版直接下载官方安装包CLI 版本常见做法是 npm 全局安装。下面的命令用于说明思路执行前先以官方文档确认包名和命令。npm install -g openai/codex安装完成后先确认命令可用。codex --version如果命令提示找不到通常是 npm 全局安装路径没有加入系统 PATH也可能是包名有变化需要回到官方安装文档核对。确认版本后下一步是登录。codex login桌面版一般在设置页面完成账号登录。CLI 登录成功后会生成本地凭据后续调用会复用。如果你是通过 API 方式接入则需要在环境中配置对应的 API Key 或第三方服务地址。无论哪种方式最终判断标准只有一个在项目目录里运行的 Codex 能够读到当前仓库文件。注意不同版本的 CLI 交互方式有差异先执行codex --help查看当前版本支持的命令再开始实际任务。不要假设所有版本都有完全相同的exec或run子命令。2.3 确认 Stitch 的产物格式为了让 Stitch 和 Codex 能够顺畅配合需要先约定中间产物的格式。建议统一使用docs/ui-specs/目录存放 Stitch 导出的 JSON 文件。常见对接方式有三种Web 工作台导出在 Stitch 页面生成界面后导出结构 JSON。Figma 或前端插件从设计稿直接生成界面结构。API 方式调用 Stitch 接口把 PRD 片段作为参数传入返回结构化结果。不管用哪种方式落到仓库里的文件都应该包含页面名称、区块、字段、操作、状态和设计约束。Codex 只认这个文件不关心它来自哪个工具。2.4 先用最小工程验证两端已连通在正式写业务页面之前先创建一个最小前端工程验证链路。mkdir task-manager cd task-manager npm create vitelatest . -- --template react-ts npm install创建完成后做一个最简单的连通测试。先让 Stitch 生成一个“用户卡片”结构 JSON保存到docs/ui-specs/demo-user-card.json然后让 Codex 读取这个文件并总结页面结构。如果 Codex 能正确说出字段和状态说明两端已经连通。读取 docs/ui-specs/demo-user-card.json用中文说明 1. 页面里有哪些字段 2. 有哪些操作按钮 3. 有哪些状态 4. 建议对应到哪个 React 组件文件这一步不需要生成最终代码只验证两个环节Codex 能访问当前仓库和文件。Stitch 导出的结构 JSON 足够清晰能被 AI 理解。如果 Codex 给出的字段和 UI Spec 完全不相关问题大概率出在 Stitch 导出的 JSON 信息密度不够或者字段命名过于随意。此时不要急着生成页面先把中间产物做规范。3. 从 PRD 到界面用 Stitch 生成 UI 规范3.1 写一份结构化 PRD而不是一段自然语言Stitch 生成界面的质量取决于 PRD 提供的信息是否结构化。写一份适合 AI 处理的 PRD只需要把页面拆成“目标用户、核心字段、操作、状态、约束”五类信息。下面是一份极简的“团队任务管理工具”列表页 PRD用 YAML 表示是为了让字段更清楚实际项目也可以用 Markdown 表格维护。page: 团队任务列表 source: PRD v1.2 users: - 团队成员 persona: 成员需要查看自己负责的任务并能快速修改状态 fields: - key: title label: 任务标题 type: string - key: assignee label: 负责人 type: string - key: priority label: 优先级 type: enum values: [low, medium, high] - key: dueDate label: 截止日期 type: date - key: status label: 状态 type: enum values: [todo, in_progress, done] actions: - 新建任务 - 编辑任务 - 标记完成 states: - loading - empty - error constraints: - 列表每行高度固定 - 空状态文案暂无任务 - 优先级使用彩色标签这样写的好处是每个字段都有明确的 key、label 和类型。Stitch 生成页面时可以直接把这些字段映射到列表项或卡片上Codex 生成 TypeScript 类型时也能直接复用。3.2 给 Stitch 的输入提示词模板Stitch 的输入可以是上文这种结构化 PRD也可以是一段描述。为了稳定得到可用结果建议把提示词固定成模板每次只替换内容。请根据以下 PRD 信息生成页面界面结构。 页面名称团队任务列表 目标用户团队成员 核心字段 - title任务标题 - assignee负责人 - priority优先级 - dueDate截止日期 - status状态 操作按钮 - 新建任务 - 编辑任务 - 标记完成 需要覆盖状态 - loading - empty - error 设计约束 - 每行高度固定 - 空状态文案为“暂无任务” - priority 使用标签展示 输出要求 - 以 JSON 格式输出界面结构 - 包含 schemaVersion、page、sections、components、states、fields - 字段 key 要与 PRD 一致模板越稳定后续排查越容易。如果某一次生成结果明显偏离 PRD就可以先检查是否漏写了字段或状态而不是怀疑工具本身。3.3 Stitch 导出的 UI Spec JSON 长什么样Stitch 导出结果可能有很多字段和视觉细节但对 Codex 来说最核心的信息是页面分区、数据字段、操作按钮和状态。下面是一个简化的 UI Spec JSON。{ schemaVersion: 1.0, page: team-task-list, sections: [ { id: toolbar, type: toolbar, children: [ { id: new-task, type: button, label: 新建任务 } ] }, { id: task-list, type: list, item: { fields: [title, assignee, priority, dueDate, status], actions: [edit, complete] } } ], states: [loading, empty, error, ready], emptyStateText: 暂无任务 }这个 JSON 里有几个关键点schemaVersion标记结构版本避免后续升级导致解析混乱。sections描述页面从上到下的分区Codex 可以按分区生成组件。item.fields列表项要展示的字段顺序就是页面上字段的左右或上下顺序。states页面需要覆盖的状态Codex 生成代码时不会遗漏空态和错误态。Codex 拿到这份 JSON 后不需要猜测页面大概长什么样只需要按字段、操作、状态逐项实现。3.4 检查 Stitch 产物时的四个重点Stitch 生成的结果并不总是完全正确。重点检查以下四个维度。检查项判断方式常见问题信息层级对照 PRD 中的用户使用流程看核心操作是否在首屏次要操作放太靠前核心操作被折叠字段覆盖把 PRD fields 和 UI Spec fields 逐个对比漏字段、字段 key 被改名状态覆盖确认 loading、empty、error 是否都出现只做了正常态空状态和错误态缺失设计约束检查间距、颜色 token、字重是否复用现有体系生成结果使用新颜色或魔法间距这一步是最值得花时间的。UI Spec 里漏掉一个字段Codex 生成的代码就不可能完整。与其让 Codex 猜“应该还有一个状态字段”不如在 Stitch 导出后立刻补齐。4. 用 Codex 把 UI 规范实现成 React 页面4.1 给 Codex 一个清晰的任务上下文Codex 生成代码前需要先明确三件事仓库位置、要读的文件、输出要求。直接把任务写清楚能减少大量来回修改。你是当前仓库的前端工程师。 任务根据 docs/ui-specs/team-task-list.json 和 docs/prd.md 实现团队任务列表页。 要求 1. 先定义 src/types/task.ts类型字段与 ui-spec 中的 fields 保持一致。 2. 在 src/components/TaskList.tsx 实现列表页。 3. 必须覆盖 loading、empty、error 三个状态。 4. 不要引入新的 UI 框架样式使用 CSS Module。 5. 完成后运行 npx tsc --noEmit 检查类型错误。之所以要把 PRD 也一起读是因为 UI Spec 主要描述界面结构但交互细节和业务约束往往需要回到 PRD 确认。比如“标记完成”是否允许操作自己负责的任务这类规则只有在 PRD 里能看到。4.2 生成列表页组件可复用的实现顺序Codex 生成代码时建议按“类型 - 组件 - 样式 - 校验”的顺序完成。先定义数据模型再写展示组件最后补样式和状态处理。这样即使组件视觉要改类型定义也不用频繁变化。第一步是生成src/types/task.ts。// src/types/task.ts export type TaskStatus todo | in_progress | done; export type TaskPriority low | medium | high; export interface Task { id: string; title: string; assignee?: string; priority: TaskPriority; dueDate?: string; status: TaskStatus; }第二步是让 Codex 根据 UI Spec 生成列表组件。下面的组件示例用于说明生成目标实际项目中还要增加路由、数据请求和权限判断。// src/components/TaskList.tsx import { useEffect, useState } from react; import type { Task } from ../types/task; import styles from ./TaskList.module.css; interface TaskListProps { tasks: Task[]; loading: boolean; error?: string; onEdit: (task: Task) void; onComplete: (id: string) void; } export function TaskList({ tasks, loading, error, onEdit, onComplete }: TaskListProps) { if (loading) { return div className{styles.state}加载中/div; } if (error) { return div className{styles.state}{error}/div; } if (tasks.length 0) { return div className{styles.state}暂无任务/div; } return ( ul className{styles.list} {tasks.map((task) ( li key{task.id} className{styles.item} div className{styles.title}{task.title}/div div{task.assignee}/div div className{styles.priority}{task.priority}/div div{task.dueDate}/div div className{styles.actions} button onClick{() onEdit(task)}编辑/button button onClick{() onComplete(task.id)}完成/button /div /li ))} /ul ); }这个组件对应的正是 UI Spec 里的task-listsection。Codex 生成时应保持结构一一对应字段顺序、操作按钮、状态文案都来自 UI Spec而不是自己发明。4.3 关键代码示例与说明类型定义和组件中要注意的点Task类型里的字段来自 UI Spec 的fields必须保持 key 一致。loading、error、empty三个分支是 UI Spec 里states的直接体现。操作按钮由 UI Spec 的item.actions决定组件只负责触发事件不直接写业务逻辑。onComplete接收id这样父组件可以决定是否更新数据。组件生成后Codex 应该自动补一个 CSS Module 文件视觉 token 如果项目里已有设计系统就要复用已有变量不要生成新的颜色值。4.4 验证生成结果是否正确生成代码后不能只看页面能启动就认为完成。按顺序执行以下检查。npx tsc --noEmit npm run build npm run dev类型检查保证数据结构一致构建保证依赖和路径没有明显问题本地启动用于人工查看页面。最后打开页面分别模拟三种情况接口未返回数据时显示加载中。返回空数组时显示“暂无任务”。接口报错时展示错误信息。有一个常见误区AI 生成的代码能编译、能显示正常列表不代表状态覆盖完整。很多生成代码只写了正常态因为没有读取 UI Spec 里的states。验证时要把每个状态都手动过一遍。5. 文档沉淀让 PRD、UI 规范和代码保持一致5.1 没有文档沉淀提效流程只是改得快的代码生成如果只让 Codex 生成代码那么每次改需求时代码改动速度确实很快但代码一旦变化设计稿和 PRD 之间的一致性仍然要靠人工维护。真正能提升迭代效率的是把文档作为生成产物的一部分随代码一起更新。至少需要沉淀三类文档PRD 摘要记录页面目标、核心字段、状态和业务规则。组件说明记录组件的数据依赖、交互事件和状态表现。变更记录或 ADR记录每次反向修改的原因。这些文档放在仓库里新成员接手时可以快速理解页面为什么长成这样而不是通过聊天记录考古。5.2 用 Codex 生成 PRD 摘要和组件说明Codex 能同时读取 PRD 和组件代码因此很适合生成一致性说明文档。示例组件说明模板如下。# TeamTaskList 组件说明 ## 数据依赖 - task.title任务标题 - task.assignee负责人 - task.priority优先级 - task.dueDate截止日期 - task.status任务状态 ## 页面状态 - loading展示“加载中” - empty展示“暂无任务” - error展示接口错误信息 ## 交互事件 - 编辑触发 onEdit(task) - 完成触发 onComplete(id) ## 最近变更 - 2025-xx-xx根据 ui-spec v1.2 由 Codex 生成通过一次 prompt 让 Codex 生成这份文档读取 docs/ui-specs/team-task-list.json 和 src/components/TaskList.tsx 生成 docs/components/team-task-list.md。 文档结构 - 数据依赖 - 页面状态 - 交互事件 - 最近变更 字段名要同时出现在 UI Spec 和组件代码中。如果 Codex 生成的文档里出现了组件代码中没有的字段或者 UI Spec 里的状态缺失说明三份文件之间存在漂移需要人工修正。5.3 用 ADR 记录“为什么这么改”组件说明记录“是什么”ADR 记录“为什么”。下面是一个最小 ADR 示例。# 001任务列表使用单页列表而非分页 状态接受 日期2025-xx-xx 背景 PRD v1.2 要求任务列表一次展示当前团队所有任务不要求分页。 决策 列表页首屏最多展示 50 条任务超过后通过筛选条件缩小范围。 影响 - 前端不再维护分页状态。 - 接口返回需要按截止日期排序。 - 后续如果数据量增长再引入服务端分页。反向修改页面时所有规则变更都应该留一条 ADR。这样后续讨论“为什么这里不做分页”时可以直接看文档而不是重新问一遍产品经理。5.4 避免双头维护确立唯一事实源文档不能和 PRD 平级否则会出现两份互相矛盾的需求文档。推荐维护关系如下PRD 是业务事实源所有需求变化先改 PRD。UI Spec 是界面契约由 Stitch 从 PRD 生成或人工按 PRD 修改。组件代码是最终实现由 Codex 根据 UI Spec 生成。组件说明和 ADR 是阅读入口由 Codex 生成后人工确认。每次需求变更严格按照“PRD - UI Spec - 代码 - 文档”的顺序执行。如果发现顺序被打乱比如代码已经改了但 PRD 没更新要先把 PRD 补齐再继续否则下一次 AI 生成时会基于过期信息工作。6. 反向修改页面用一句需求变更驱动全链路更新6.1 什么场景需要反向修改反向修改指的是页面已经实现PRD 和设计稿发生变化需要同时更新界面、代码和文档。以下场景会频繁触发反向修改需求评审后新增字段或操作。视觉走查后调整布局和间距。数据模型变化导致页面展示逻辑变化。交互方式调整比如从列表改成看板。这类修改如果全靠手工最麻烦的不是改页面而是改完页面还要同步文档、更新 UI Spec、确认其他页面没有受到影响。Codex 比较擅长处理这种跨文件修改但前提是每一步指令足够明确。6.2 示例从任务列表改成看板视图假设新需求把“团队任务列表”改成“看板视图”任务是按状态列展示。PRD 需要先更新然后再让 Codex 执行修改。更新后的 PRD 中页面描述变为page: 团队任务看板 layout: kanban columns: - key: todo label: 待办 - key: in_progress label: 进行中 - key: done label: 已完成UI Spec 也需要对应调整核心是把task-list的 type 从list改为kanban。{ id: kanban-board, type: kanban, columns: [todo, in_progress, done], card: { fields: [title, assignee, priority, dueDate], actions: [edit, move] } }6.3 让 Codex 同步改代码、UI 规范和文档向 Codex 发出修改指令时要明确要求四件事一起完成。团队任务从列表改成了看板视图。 请按以下顺序处理 1. 读取 docs/prd.md 和 docs/ui-specs/team-task-list.json 的最新内容。 2. 更新 src/components/TaskList.tsx组件展示为三列看板按 status 分组。 3. 更新 docs/components/team-task-list.md补充看板列说明。 4. 更新 docs/ui-specs/team-task-list.json确保它和代码实现一致。 约束 - 数据模型 task 类型保持不变。 - 卡片上仍展示 title、assignee、priority、dueDate。 - 保留 loading、empty、error 三个状态。 - 移动任务的操作通过 onMove(task, targetStatus) 暴露。让 Codex 同时修改代码和文档看起来是四件事本质上是在同一个 prompt 里定义好“目标状态”。Codex 会读取旧文件识别差异然后输出新的实现和文档。6.4 反向修改后的验证清单反向修改完成后不能只看页面长得对不对。验证清单至少包含旧字段是否全部保留或明确移除。新增的onMove事件是否在父组件里有对应处理。看板三个列的空状态是否正确展示。组件说明是否描述看板结构而不是旧列表结构。UI Spec 里的 section 类型是否已经更新为 kanban。验证命令和生成时一样先跑类型检查再启动页面做交互验证。如果文档没更新要立即让 Codex 补齐不要拖到下一个迭代。7. 常见问题排查Codex 安装、模型与接口报错7.1 Codex 无法启动或登录失败Codex 无法启动是接入阶段出现最多的现象通常和安装路径、凭据和网络环境有关。问题现象常见原因检查方式处理建议命令提示找不到 codexnpm 全局路径未加入 PATHnpm config get prefix检查 bin 目录将 bin 目录加入 PATH或重新安装安装成功但打开闪退桌面版版本和系统不兼容查看系统日志确认安装包来源下载匹配系统版本的官方安装包登录提示未授权登录凭据过期或未完成浏览器授权重新执行登录命令查看日志退出后重新登录确认账号有权限CLI 能启动但无法访问仓库工作目录不在项目内执行pwd和git status进入项目目录后再运行 Codex登录成功只是第一步真正有效的验证是让 Codex 读取仓库文件并给出正确反馈。如果登录后依然报权限错误优先排查账号类型和模型访问范围。7.2 模型不可用gpt-5.6-sol not supported使用 Codex 时如果配置了当前账号或接入服务不支持的模型可能会出现类似下面的报错the gpt-5.6-sol model is not supported when using codex with a chatgpt account这个报错的意思是当前请求指定的模型不在当前账号或服务支持的范围内。常见原因有三个当前 ChatGPT 账号对应可用的模型列表并不包含这个模型名称。手动在配置里写死了某个模型名称但服务端点不支持。通过第三方 API 接入时模型名与请求规范不一致。排查时先检查 Codex 的模型配置把模型名称改成当前账号、接入服务明确支持的名称。如果使用的是第三方 API 端点需要以该服务的模型清单为准不要直接照搬某个公开示例里的模型名。注意模型名称、账号权限和接入服务列表会经常变化。出现 not supported 报错时先确认“当前接入方式支持哪些模型”而不是反复重试同一个模型名。7.3 cc switch local proxy failed 怎么查当 Codex 配置了第三方 API 端点或本地 API 转发服务时请求可能经过一个本地转发层再由它转发到真正的模型服务。如果这个转发层处理/responses端点失败会出现类似下面的错误cc switch local proxy failed while handling codex endpoint /responses这里的local proxy是开发环境中的 API 转发服务常见应用是把 Codex 请求转发到团队统一的模型网关。排查这个错误要沿着请求链路逐段确认。排查点检查方式说明本地转发服务是否启动查看进程列表、服务日志服务没启动时 endpoint 必然不可达地址和端口是否匹配核对 Codex 配置里的 baseUrl 与转发服务监听地址配置了 localhost但服务监听在另一个端口时会失败鉴权信息是否有效查看请求头里的 token 或 API Key过期或缺失会返回鉴权错误endpoint 路径是否正确确认请求确实打到了/responses不同服务版本对路径要求不一样转发服务日志是否记录错误查看最近一次请求的响应体日志通常能给出上游返回的具体错误码虽然现象看起来像 Codex 本身报错但根因往往不在 Codex而在转发服务这一层。先用 curl 单独测试转发服务的 endpoint确认转发服务能正常工作再回到 Codex 侧排查。curl -X POST http://localhost:8080/responses \ -H Content-Type: application/json \ -d {model:your-model,input:test}如果 curl 返回连通失败问题就在网络地址、端口或服务进程如果 curl 能通但 Codex 仍然失败继续核对鉴权信息和请求体格式。7.4 Stitch 生成结果与 PRD 不一致Stitch 生成界面时如果漏掉字段或状态原因通常集中在输入不够结构化。检查顺序如下PRD 里的字段是否都在 Stitch 输入模板中有明确 key。states 列是否完整是否包含 loading、empty、error。操作按钮是否写得具体而不是只写“相关操作”。UI Spec JSON 是否符合约定的 schemaVersion。如果字段都在但生成结果仍然不对可以考虑把 PRD 拆成更小的页面范围一次只生成一个区块。让 Stitch 一次性生成复杂页面很容易丢失次要字段。7.5 Codex 生成代码里的幻觉字段Codex 生成代码时偶尔会“脑补”一些 UI Spec 里不存在的字段。比如 UI Spec 里只有 title、assignee、priority、dueDate、status生成代码却出现了task.owner或task.createdBy。这类问题的防止方式是建立字段清单核对机制。把 UI Spec 里的 fields 抽成一份字段清单Codex 生成代码后逐项比对grep -Eo task\.[a-zA-Z] src/components/TaskList.tsx | sort -u运行上面命令能看到组件里实际用到的task字段再和 UI Spec 的 fields 对比。出现不一致时让 Codex 根据 UI Spec 修正不要直接保留。8. 能直接抄的提效清单与最佳实践8.1 一套完整操作顺序如果团队准备把这套流程落地可以直接按下面的顺序执行。在项目仓库里创建docs/prd.md、docs/ui-specs/、docs/components/。为当前需求准备结构化 PRD至少包含字段、操作、状态、约束。把 PRD 片段输入 Stitch生成 UI Spec JSON 并保存到docs/ui-specs/。检查 UI Spec 是否覆盖所有字段和状态。用 Codex 读取 UI Spec 和 PRD生成类型、组件和样式。运行tsc、build本地启动页面验证三种状态。用 Codex 生成组件说明文档保存在docs/components/。每次需求变更先更新 PRD再让 Codex 反向修改页面、UI Spec 和说明文档。重要决策写入 ADR。提交前执行一份完整的检查清单。8.2 人机分工建议AI 承担不了所有职责明确分工能减少无效往返。工作内容负责方理由业务规则定义产品经理业务判断不能交给模型猜测字段和状态清单维护产品经理 / 设计师数据契约必须稳定界面结构生成Stitch从 PRD 快速生成初步结构结构校验产品经理 / 设计师确认字段、状态、操作完整代码实现和修改Codex擅长跨文件生成和重构代码评审和验证前端工程师处理边界情况和性能问题文档同步Codex 生成人工确认减少手工维护成本分工的重点是AI 负责翻译人负责校验。把 AI 当作自动生成初稿的助手而不是业务决策者。8.3 提交前检查清单每次需求变更后至少完成以下检查。[ ] PRD 已更新且是当前唯一的业务事实源。[ ] UI Spec JSON 已由 Stitch 重新生成或人工确认修改。[ ] 组件代码字段与 UI Spec 的 fields 完全一致。[ ] loading、empty、error 状态都手动验证过。[ ] 关键操作事件在父组件中有实际处理逻辑。[ ] 组件说明文档已同步没有残留旧版描述。[ ] 重要变更已记录 ADR。[ ]npx tsc --noEmit和npm run build通过。[ ] 改动涉及关键路径时已执行回滚演练或至少确认 Git 状态可回退。这份清单可以放到 PR 模板里每次 AI 生成代码后都会自动提醒人工检查关键项。8.4 哪些场景不建议套用这套流程这套流程并不适合所有页面。遇到以下情况时建议回到传统方式视觉品牌要求极高布局和细节依赖长期打磨。需求本身还不稳定PRD 一天一变生成出来很快又作废。安全合规要求严格不能把内部业务数据或代码片段交给外部服务处理。改动极小比如只改一个按钮文案用 AI 流程反而增加上下文成本。项目没有条件运行本地生成环境AI 工具无法访问仓库。判断标准很简单如果人工手动修改只需要几分钟就不要搭一套生成链路。这套流程的核心不是让 AI 替代产品经理或前端而是把 PRD 到界面、界面到文档、文档回 PRD 变成可回放的文件流。对新手来说建议先不要碰复杂项目先找一个小页面跑通 PRD、Stitch、Codex、验证的完整链路再逐步把文档沉淀和反向修改加进去。下一步可以扩展的方向包括把设计 token 接入 Stitch 输出让 Codex 同时生成组件测试以及在 CI 里检查 UI Spec JSON 与组件实现是否发生漂移。