刚接触 AI 生成界面时我也经历过类似困惑Stitch 能根据设计稿生成前端页面Codex 能直接改代码PRD 文档却还得自己一遍遍手动同步。直到我把三者串成一条工作流才发现真正耗时间的不是写代码而是设计稿、页面、文档之间的反复对齐。这篇文章会完整拆解这套组合的落地方法包含 Stitch 从设计稿生成界面的步骤、Codex 反向修改页面的实战命令、以及从页面回写 PRD 的完整思路。无论你是产品经理、前端开发还是独立开发者都可以直接照着操作把零散的 AI 工具变成一条真正可用的产品设计流水线。1. 背景为什么界面生成、页面修改与文档沉淀需要组合起来1.1 产品设计链路中的最大浪费在日常产品迭代中一个功能从想法到上线通常要经历这样的路径产品经理写 PRD描述需求背景、用户故事和交互细节。设计师根据 PRD 出视觉稿。前端开发照着视觉稿实现页面。页面实现后如果发现交互不合理再回头改 PRD、改设计稿、改代码。这条链路看起来清晰但真正的问题是“信息同步成本”。设计稿改了PRD 可能还停留在两个版本之前前端实现了一版页面产品经理只能靠肉眼对比页面和文档是否一致。如果是小需求还好一旦涉及多页面、多状态、多角色权限手工对齐的时间会呈指数级上涨。1.2 Stitch 是什么Stitch 是 Google Labs 推出的 AI 前端生成工具目标是“把设计稿直接变成可运行的网页”。它的核心能力是读取用户上传的图片或设计描述生成对应的 HTML、CSS、JavaScript 代码并且采用 Web Components 的组件化方式输出方便二次改造。和很多纯聊天式生成工具不同Stitch 更强调视觉还原。你可以上传一张高保真设计稿它能把布局、配色、间距、交互状态都转成页面代码。Stitch 本身是开源项目可以本地部署也可以直接使用在线版本后者适合快速验证效果前者适合接入公司内部项目流程。1.3 Codex 是什么Codex 是 OpenAI 推出的编程智能体它可以理解整个代码仓库的上下文执行多步骤开发任务。比如你让它“把登录页的按钮改成主色并在点击时增加 loading 状态”它会自动定位相关文件、修改代码并给出修改说明。Codex 有多种使用形态CLI 命令行工具适合脚本化执行和自动化流程。桌面客户端适合交互式对话和跨项目操作。VS Code 扩展适合在编辑器里直接调用。在本文的场景里Codex 主要承担两个职责一是对 Stitch 生成的前端代码做“反向修改”二是根据页面代码或修改记录生成、更新 PRD 文档。1.4 为什么这套组合能显著提效Stitch 负责“从设计稿到页面”的初始生成Codex 负责“从文字指令到代码修改”的后续迭代PRD 则通过 Codex 生成和同步。三者串起来后产品经理和开发不再需要频繁地手工同步信息而是让工具自动完成大部分翻译工作设计稿变成页面Stitch 完成。页面按反馈修改Codex 完成。修改内容沉淀成文档Codex 根据代码变更生成 PRD 更新记录。文档反哺后续迭代Codex 读取 PRD 直接修改页面。这套流程当然不是万能的遇到复杂业务逻辑、特殊交互或强设计规范时仍然需要人工介入。但至少它把“重复性的信息搬运”从日常工作中剥离出去了。2. 环境准备先把工具链跑通无论你用的是在线版还是本地部署都需要先准备好基础环境。这里以本地使用为主来讲解因为本地环境更适合后续接 Codex 做二次修改。2.1 安装 Node.js 与包管理器Stitch 和 Codex CLI 都依赖 Node.js 环境。建议使用 LTS 版本避免因为版本过新而出现兼容性问题。node -v npm -v如果没有安装可以去 Node.js 官网下载对应操作系统的安装包。Windows 用户注意勾选“Add to PATH”macOS 用户也可以直接用 Homebrew 安装brew install node2.2 安装 Codex CLICodex CLI 可以通过 npm 全局安装安装命令如下npm install -g openai/codex安装完成后执行版本检查codex --version如果命令找不到可能是全局 bin 目录没有加入 PATH需要根据 npm 的提示配置环境变量。Codex 也提供桌面客户端可以在官网下载桌面版安装包桌面版适合不想操作命令行的用户。2.3 登录 Codex 账号或配置 API KeyCodex 需要 OpenAI 账号或 API Key 才能运行。最简单的登录方式是codex login执行后会打开浏览器完成授权。如果你使用的是 API Key可以通过环境变量注入export OPENAI_API_KEYsk-xxxxWindows 用户在 PowerShell 下使用$env:OPENAI_API_KEYsk-xxxx如果公司内部使用的是第三方兼容服务可以在 Codex 的配置文件~/.codex/config.toml中自定义 base URLmodel gpt-5.6 api_base_url https://your-api-endpoint.example.com/v1需要说明的是不同版本的 Codex 配置文件字段可能不同请以实际安装版本的官方文档为准。重点在于理解Codex 支持通过自定义端点接入其他兼容 OpenAI 协议的服务这一点在部分网络环境下比较实用。2.4 启动 Stitch 项目Stitch 在线版可以直接访问 Google Labs 的 Stitch 页面使用入口路径不固定可以搜索“Google Stitch AI”找到最新地址。如果你想在本地部署需要先克隆项目代码git clone https://github.com/google-labs/stitch.git cd stitch npm install npm run dev启动成功后终端会输出本地访问地址通常类似http://localhost:5173或http://localhost:3000具体端口以实际输出为准。本地部署的好处是可以把生成结果直接落到自己的项目目录方便后续用 Codex 做二次修改。3. Stitch 从设计稿生成界面把一张图变成可运行页面3.1 准备设计稿Stitch 对输入图片有一定要求。为了保证生成效果建议满足下面几个条件设计稿导出为 PNG 或 JPG 格式分辨率不要太低。页面宽度和实际目标宽度尽量一致比如 1440px 的桌面端设计稿。如果要生成移动端页面先裁剪成移动端比例再上传。避免在同一张图里混合多个页面状态最好一页一图。如果你使用的是 Figma可以先把画板导出为 PNG也可以截图后稍微裁剪。3.2 让 Stitch 生成页面打开 Stitch 后在对话区域上传设计稿图片并输入生成指令。下面是一个可复制的提示词模板请根据我上传的设计稿生成一个响应式页面。 要求 1. 布局和间距尽量与设计稿保持一致。 2. 使用 Tailwind CSS 的类名不要使用内联样式。 3. 页面需要在 1440px、768px、375px 三种宽度下正常展示。 4. 按钮、输入框等交互元素需要包含 hover 状态样式。 5. 生成完成后告诉我主要文件的结构和如何运行。这里强调“使用 Tailwind CSS 类名”是因为 Stitch 支持多种输出风格明确指定之后生成结果的二次修改成本会更低。如果不指定Stitch 默认可能会生成自定义 CSS 文件而后端开发接手时往往更倾向于使用已有的样式体系。3.3 保存 Stitch 生成结果Stitch 生成结果后通常会在界面中展示代码预览。你需要把生成的代码保存到项目目录中。以本地部署为例可以在当前工作目录下创建前端项目结构my-app/ ├── index.html ├── src/ │ ├── styles.css │ └── app.js └── assets/把 Stitch 生成的 HTML 内容写入index.html把样式部分拆分到src/styles.css把交互脚本放入src/app.js。如果你使用的是 Vite 或 Next.js 这类框架项目也可以直接把 Stitch 生成的组件代码复制进对应目录。3.4 Stitch 生成代码的基本结构Stitch 基于 Web Components 输出页面它生成的 HTML 片段经常包含自定义标签。例如my-page-header titleWelcome/my-page-header my-feature-card titleAI 驱动 description根据设计稿快速生成前端代码 /my-feature-card这种组件化写法更适合工程化项目但如果你不熟悉 Web Components也可以在 Stitch 提示词里直接要求“生成纯 HTML CSS JavaScript不使用自定义元素”这样得到的代码更直观更适合快速落地。3.5 本地预览生成结果保存文件后在项目目录执行npx serve .然后浏览器访问终端输出的地址。如果样式没有生效优先检查 CSS 文件路径是否正确如果交互没有生效检查 JavaScript 文件是否在 HTML 底部引入。4. 用 Codex 反向修改页面从自然语言直接到代码变更Stitch 生成页面只是第一步。实际产品迭代中页面从“初版”到“可上线版本”还要经历很多轮修改这些修改如果继续用 Stitch 反复生成成本太高如果用人工手工改效率太低。Codex 在这里的价值就是“反向修改页面”。4.1 让 Codex 读取项目上下文进入项目目录cd my-app codex进入交互式对话后可以直接提需求。Codex 会先扫描项目结构理解文件之间的关系再定位需要修改的文件。这个过程不需要你手动指定文件路径它自己会分析。4.2 示例一修改按钮样式在 Codex 对话中输入把页面里所有主按钮的背景色从原来的颜色改成 #1E88E5字体改成白色并增加点击时的按下动画。Codex 会定位按钮相关代码通常会自动修改 CSS 和 HTML。如果项目里按钮样式是通过类名统一的它只需改一处如果按钮样式分散在多处它会逐个检索并替换。4.3 示例二新增交互状态继续输入在表单提交按钮点击后增加 2 秒的 loading 状态期间按钮文字变为“提交中…”并禁用重复点击。这个修改涉及 HTML 结构、CSS 状态和 JavaScript 逻辑Codex 会同时修改多个文件。修改完成后它会给出变更摘要你只需要确认变更是否符合预期。4.4 使用非交互模式一次性执行修改如果你希望跳过交互式对话直接让 Codex 执行一次性任务可以使用 exec 模式codex exec 把登录页标题从‘欢迎回来’改成‘欢迎使用 Stitch Codex’这种模式适合批量修改和 CI 集成。不过要注意exec 模式默认不会弹出确认窗口建议在代码已纳入 Git 管理的目录中使用方便出问题时回滚。4.5 验证修改结果Codex 改完代码后一定要自己跑一遍页面确认效果。可以在项目目录中启动开发服务器npm run dev如果项目里没有配置 dev 脚本也可以用npx serve .在浏览器里检查修改是否生效尤其要看控制台有没有报错。Codex 能改代码但最终的视觉还原和交互体验仍然需要人工判断。5. 页面改完后沉淀 PRD让文档与界面保持同步页面改了PRD 不更新问题很快会出现在下一次迭代。更常见的情况是文档里写着 A 方案线上页面实际是 B 方案新接手的人只能靠猜。利用 Codex 生成和更新 PRD可以避免这种信息断裂。5.1 为什么不能让 PRD 脱离页面PRD 是产品团队的共同语言但如果它跟代码不同步就会变成“纸面文档”。我见过很多团队出现下面这些情况产品经理花大量时间写文档开发拿到后不看直接看 Figma。页面改了很多轮PRD 还停留在最早版本。测试同学照着 PRD 写用例结果界面表现和文档描述不一致只能反复确认。解决思路不是取消 PRD而是让 PRD 的生成和更新成本降到最低。Codex 恰好能承担这个工作。5.2 用 Codex 生成 PRD 初稿当 Stitch 生成页面、Codex 完成第一轮修改后可以把代码路径交给 Codex让它生成结构化 PRD。示例指令请根据 my-app 目录下的页面代码生成一份 PRD。 内容包括 1. 需求背景 2. 用户故事 3. 功能需求清单 4. 页面交互细节 5. 状态与异常场景 6. 验收标准Codex 会读取页面文件结合代码中的按钮、表单、弹窗等元素自动整理成一份文档。生成结果可能不会百分之百符合你的要求但作为初稿它已经可以省去 80% 的整理时间。5.3 PRD 模板参考为了让 Codex 输出更稳定可以在项目里准备一份 PRD 模板比如docs/templates/prd-template.md# 【需求文档】功能名称 ## 1. 需求背景 - 用户痛点 - 业务价值 - 成功指标 ## 2. 用户故事 - 作为角色我希望功能以便收益。 ## 3. 功能需求 - [ ] 功能点 1描述 - [ ] 功能点 2描述 ## 4. 交互细节 - 页面入口 - 默认状态 - 加载状态 - 空数据状态 - 错误状态 ## 5. 异常与边界 - 场景 1描述 - 场景 2描述 ## 6. 验收标准 - [ ] 标准 1 - [ ] 标准 2 ## 7. 变更记录 - 版本 | 日期 | 变更内容 | 修改人之后每次让 Codex 生成 PRD都可以在提示词里指定这个模板请参考 docs/templates/prd-template.md 的格式根据 my-app 目录的页面代码生成 PRD。5.4 从 PRD 反向驱动页面迭代PRD 生成后后续的页面迭代反而可以反过来以 PRD 为准。你只需要把 PRD 丢给 Codex让它实现文档里的需求请根据 docs/prd.md 的需求清单检查 my-app 目录中是否已经实现所有功能点。如果没有实现请补全代码。这样 PRD 和页面就形成了一个双向通道页面改完了Codex 更新 PRDPRD 更新了Codex 反推页面。整个团队对需求的理解可以随时对齐。6. 常见问题与排查思路实际使用中很多人会在环境配置和网络环节卡住。下面整理几个高频问题的排查方案。问题现象常见原因解决思路Codex 安装后命令无法识别npm 全局 bin 目录未加入 PATH执行npm config get prefix把输出的 bin 目录加入系统 PATHCodex CLI 报 model not supported使用了 ChatGPT 账号默认模型但该模型在 Codex 中不受支持在~/.codex/config.toml中显式指定兼容模型例如model gpt-5.6-codex-max或查看官方模型列表调整第三方 API 接入时 Codex 报代理或端点错误本地代理服务不支持 Codex 的/responses端点检查代理服务是否兼容/v1/responses将 base URL 配置为完整可用的端点不要只填域名Codex 连接后一直转圈无响应模型选择错误或网络环境不稳定切换模型、检查api_base_url、重启 Codex 进程Stitch 在线版访问缓慢网络限制或在线服务容量问题改用本地部署或者将设计稿压缩后重新上传Stitch 生成的页面样式错乱设计稿尺寸比例和输出容器不一致在上传前裁剪画板比例并在提示词里指定目标设备宽度Codex 修改代码后页面报 JS 错误新旧代码逻辑冲突或 DOM 结构变化让 Codex 先阅读控制台报错再基于报错信息修复如果无法修复使用 Git 回滚补充说明一下模型配置问题。Codex 在使用 ChatGPT 账号登录时可能会继承账号默认模型。如果你看到这类报错The gpt-5.6-sol model is not supported when using Codex with a ChatGPT account原因通常是账号默认模型是 GPT-5.6-sol但它并不在 Codex 的支持列表里。解决方式是在配置文件里强制指定 Codex 支持的模型例如model gpt-5.6-codex具体模型名称需要以你安装的 Codex 版本支持列表为准不同版本差异较大。7. 最佳实践与工程建议7.1 所有生成代码必须纳入 GitStitch 生成页面、Codex 修改页面这些操作的共同特点是“变更速度很快”。如果不做版本管理一旦 Codex 改出问题想回退会非常被动。建议在项目一开始就执行git init git add . git commit -m init: Stitch 生成页面初版每次 Codex 修改后都创建一次提交并在提交信息里写清楚改了什么。7.2 用约定式提交记录变更Codex 修改代码后不妨让它顺手生成提交说明codex exec 根据最近的代码变更生成符合 Conventional Commits 规范的 git commit message这样 PRD 的变更记录、代码提交记录和实际功能可以实现一一对应后续追溯需求来源的时候非常方便。7.3 控制单次修改的粒度在给 Codex 下指令时不要一次塞太多需求。比如“把登录页按钮改色、首页重新布局、结算流程增加优惠券、顺便把导航栏改成吸顶”这种任务对 Codex 来说上下文过长容易漏改或误改。更稳妥的做法是第一批只修改按钮色彩和字体。 第二批增加按钮 loading 状态。 第三批调整页面对齐方式。每批修改后都验证一遍确认没问题再进下一批。7.4 检查生成代码的安全性和合规性Stitch 生成的页面如果只是原型风险不大但如果是生产环境页面必须做安全审查。重点检查是否包含敏感信息或外部资源引用。表单提交是否有基础校验和后端认证。是否引用了未知来源的脚本或样式。是否满足可访问性要求例如图片 alt 属性、表单 label 关联。尤其不要直接把生成代码中的 API Key、Token 提交到公开仓库。7.5 明确 PRD 的所有权和最终审核权Codex 能生成 PRD但 PRD 代表的是产品决策AI 只能帮你整理和结构化不能代替你判断需求是否合理。建议把 Codex 生成的 PRD 当成“初稿”产品经理仍然需要审核用户故事是否准确功能优先级是否符合产品规划验收标准是否可衡量是否有遗漏的异常场景7.6 建立团队内的 AI 使用规范如果团队里多个成员都用 Stitch 和 Codex建议提前约定设计稿统一存放在哪个目录Stitch 生成代码放在哪个子目录哪些文件允许 Codex 直接修改哪些需要人工 reviewPRD 更新由谁负责最后提交这些规范不用很重但能避免多个成员各跑一套流程最后代码合并时冲突不断。8. 总结从设计稿到 PRD 的完整闭环可以这样搭回到最初的问题Stitch、Codex、PRD 三者怎么配合核心不是某一个工具而是把“设计稿生成页面、Codex 修改页面、Codex 沉淀文档”串成一条可重复执行的流程用 Stitch 把设计稿生成前端页面。用 Codex 根据反馈修改页面代码。用 Codex 根据页面代码生成 PRD 初稿。用 PRD 反向指导下一轮 Codex 修改。所有代码变更和文档变更都纳入 Git 管理。这套流程不需要一次性做到完美你可以先跑通第 1 步和第 2 步感受一下 AI 生成和修改代码的效率再逐步加入 PRD 沉淀环节。等整条链路稳定之后你会发现重复性的信息搬运工作大幅减少产品经理可以把更多时间放在真正的需求分析和业务判断上。如果你刚接触 Stitch 和 Codex建议从一个小页面开始练手准备一张登录页设计稿用 Stitch 生成页面再用 Codex 改三次样式和交互最后让它生成一份 PRD。整个过程跑完你对这套组合的理解会比看十篇文章更深入。