从截图到响应式页面：用 Codex 生成 UI 的 7 步工作流

admin 设计创意 2小时前

9 0

把一张截图丢给 Codex，通常很快就能得到“像网页”的第一版；但要得到能合并、能响应、能维护的 UI，关键不是再加一句“更精致”，而是把参考图、项目规则、实现约束和验证循环组织成一条可复现的工作流。下面的方法适用于现有 React、Next.js 或 HTML/CSS 项目，也包含从 Figma 精确节点开始的分支。

从参考截图经 Codex 生成代码并得到桌面和移动端响应式页面 — 目标不是一次猜中所有像素，而是建立“参考—实现—截图—修正”的短循环。

适用场景

根据网页截图、线框图或视觉稿搭建营销页、产品页和后台界面；
把 Figma 中的指定 frame 或 component 转成现有项目组件；
在已有设计系统上补页面，而不是另起一套颜色、间距和按钮；
需要同时交付桌面、平板、手机与交互状态。

如果参考图版权不清、只提供了一个局部画面，或项目尚未确定信息架构，应先补资料。截图能够说明“看起来怎样”，却不会自动告诉模型数据结构、错误状态、权限逻辑和真实业务规则。

第一步：先让 Codex 读项目，不急着写页面

第一轮只要求它检查项目结构、AGENTS.md、现有组件、样式入口、构建命令与路由。让现有设计系统优先于截图中的偶然细节，可以避免生成第二套按钮、色板和间距规则。

请先阅读项目中的 AGENTS.md、package.json、现有页面与组件目录，不要修改文件。列出：1）技术栈与启动/测试命令；2）可以复用的布局、按钮、卡片、表单组件；3）颜色、字体、间距和断点来源；4）实现这张参考图最可能涉及的文件；5）仍缺少的信息。只输出检查结果和实施计划。

第二步：准备“参考包”，不要只给一张漂亮截图

理想参考包至少包含桌面与手机两种宽度，以及悬停、选中、空数据、加载或报错中的关键状态。再补一张内容优先级说明：哪些文字必须保留、哪些图片可以替换、哪些区域在窄屏应重排或隐藏。

桌面、移动端、悬停和加载状态组成的 UI 参考包 — 多宽度和多状态参考能减少模型对断点与交互的猜测。

最小参考清单

桌面：建议 1440px 宽的完整页面；
手机：建议 375px 或 390px 宽的完整页面；
状态：按钮 hover/focus、表单错误、列表 loading/empty；
资产：可用的图片、图标、字体及授权说明；
约束：内容不能删、组件必须复用、禁止新依赖等。

第三步：把“像素感觉”翻译成可检查的约束

与其写“做得高级一点”，不如描述页面结构、视觉层级、响应式规则和验收宽度。第一次实现提示词可以直接套用下面的模板。

任务：根据附件参考图，在现有项目中实现【页面/区块】。n项目约束：优先复用现有组件和 design tokens；不要新增 UI 框架；不要修改无关页面。n结构：按顺序实现【导航、Hero、功能卡、案例、CTA、页脚】。n响应式：在 1440、1024、768、390px 检查；窄屏时【说明重排规则】，不要只做等比缩小。n交互：实现 hover、focus-visible、菜单展开、loading 与 empty 状态。n内容：保留提供的中文文案；图片使用项目资产或清晰占位，不生成随机品牌文字。n验收：运行构建和现有测试，启动页面并截图；列出与参考图最明显的 5 处差异后再逐项修正。

第四步：先搭结构，再做精确视觉；Figma 项目从节点上下文开始

先完成语义结构、组件边界和响应式布局，再调颜色、阴影和微间距。若已经连接 Figma，官方工作流建议先获取指定 frame 或 node 的结构化设计上下文；返回过大时先读 metadata，再缩小到目标节点；随后获取截图，用它核对具体变体。实现时仍应转换为当前仓库的组件和 token，而不是把生成结果原样塞进项目。

从设计节点、结构化上下文和设计令牌到 React 组件的工作流 — Figma 节点提供结构和资产，项目组件与设计令牌决定最终代码形态。

Figma 分支提示词

请针对我提供的 Figma 链接，只处理【frame/node 名称】。先获取 design context；如果信息被截断，先获取 metadata，再只读取目标节点；随后获取该节点截图确认准确变体。实现时复用仓库现有组件、字体、颜色变量和间距 token，使用设计上下文返回的资产，不要添加占位 SVG 或新的图标库。完成后在 1440、768、390px 截图比对。

第五步：让 Codex 自己运行页面并说明失败

代码生成后必须运行安装、类型检查、构建或项目已有测试。若页面能在本地启动，再让 Codex 打开真实路由检查控制台错误、资源 404、布局溢出和交互。不要用“代码看起来合理”代替浏览器结果。

现在运行项目已有的 lint、typecheck、test 和 build；只使用 package.json 中已有命令。然后启动页面，访问真实路由，记录控制台错误、网络 404、横向滚动和未加载字体/图片。若命令失败，先解释根因并做最小修复，不要跳过验证。

第六步：做视觉回归，不要用“差不多”收尾

在固定视口截取实现图，与参考图并排或做半透明差异叠加。按影响排序：先修页面宽度和栅格，再修字号与行高，然后修间距、颜色和装饰。一次只改一类变量，能显著减少来回漂移。

参考界面、实现界面、差异叠加与可访问性检查面板 — 视觉一致性和可访问性应在同一轮最终验证中完成。

修正提示词

比较附件中的参考图与刚生成的 1440px、768px、390px 截图。先列出最多 8 处差异，按“结构与栅格 > 字体与行高 > 间距 > 色彩与装饰”排序。只修前三项，并保持现有组件 API、文案和交互不变。完成后重新截图，报告修正前后差异，不要重写整个页面。

第七步：补齐键盘、语义和真实内容压力测试

只用键盘走一遍导航、弹层、菜单和表单，确保 focus-visible 清楚可见；
检查标题层级、landmark、按钮与链接语义，以及每张信息图片的 alt；
用 2 倍长度标题、空数据、接口延迟和错误信息测试布局；
确认 390px 不产生横向滚动，触控目标和对比度满足项目标准；
最后复跑构建与测试，并检查修改范围没有扩散到无关文件。

最终检查提示词

对这个页面执行最终 UI QA：键盘顺序、focus-visible、标题层级、landmark、表单 label、图片 alt、颜色对比、390px 横向滚动、长文本、loading/empty/error 状态。只修确认存在的问题；不要为了“优化”重构无关组件。最后输出已运行的命令、修改文件、仍存在的限制和截图尺寸。