构建适配多端的前端界面
说明如何让 Codex 根据 screenshots、design brief 或视觉参考生成 responsive UI，并在真实浏览器中迭代。
当你有 screenshots、短 design brief 或几个视觉参考时，Codex 可以把它们变成 responsive UI，并尽量贴合当前 repo 已有的 design system。关键不是“照着图写一版”，而是让 Codex 在真实 browser 中比较实现和参考图，在不同屏幕尺寸下迭代。
Responsive UI 不能只在一个桌面宽度验收。至少检查 mobile、tablet/窄屏和 desktop，并确认文字不溢出、状态不重叠、交互区域不漂移。
官方页面：https://developers.openai.com/codex/use-cases/frontend-designs
官方封面图路径：https://developers.openai.com/codex/use-cases/frontend-designs-use-case.png
适合什么任务
| 场景 | Codex 应该做什么 |
|---|---|
| 从零创建新的 front-end project | 根据截图和说明搭建第一版 UI，并做 responsive 检查 |
| 在现有 codebase 中实现已设计的 screen 或 flow | 复用 repo 的 design system components、tokens 和 patterns |
| 需要视觉对齐 | 用 $playwright-interactive 打开真实页面，对比 references 并调整 layout 和 behavior |
使用的能力
| 能力 | 用法 | 链接 |
|---|---|---|
$playwright / $playwright-interactive | 在真实 browser 中验证实现，调整 layout 和 behavior | https://github.com/openai/skills/tree/main/skills/.curated/playwright-interactive |
相关官方说明：
- Codex skills：https://developers.openai.com/codex/skills
起始提示词
请在当前项目中实现这个 UI，以我提供的 screenshots 和 notes 作为 source of truth。
要求：
- 复用现有 design system components 和 tokens。
- 把 screenshots 翻译成这个 repo 的 utilities 和 component patterns，不要另造一套平行系统。
- 尽量贴近 spacing、layout、hierarchy 和 responsive behavior。
- 尊重 repo 现有 routing、state 和 data-fetch patterns。
- 页面要同时适配 desktop 和 mobile。
- 如果 screenshot 中某个细节不明确，选择仍符合整体方向的最简单实现，并简短说明假设。
验证：
- 对照提供的 screenshots 检查最终 UI 的外观和行为。
- 使用 $playwright-interactive 检查 UI 是否匹配 references，并按需要迭代，直到匹配为止。这个 prompt 把 screenshots 和 notes 明确为 source of truth，同时要求 Codex 尊重当前 repo 的 design system，而不是另起一套 UI。
从 References 开始
给 Codex 最清楚的 UI 参考。一个窄任务只给一张 screenshot 也可以，但如果有多种状态，最好一起提供：
- desktop layout。
- mobile layout。
- hover state。
- selected state。
- empty view。
- loading view。
参考图不必是完整设计交付物，但必须让 hierarchy、spacing 和 visual direction 足够具体，减少 Codex 猜测。
说清楚你想要的风格
如果参考图里看不出你想要的 interaction pattern 或 style，Codex 可能会落到常见默认样式。越复杂的 UI，越应该明确：
- 哪些元素必须严格对齐截图。
- 哪些地方可以按 repo conventions 处理。
- 哪些 breakpoint 重要。
- 哪些 states 必须做。
- 哪些内容不要改。
准备 Design System
Codex 在目标 repo 已有 component layer 时表现最好。如果不是标准栈，直接告诉它：
- primitives 在哪里。
- tokens 在哪里。
- buttons、inputs、cards、typography、icons 的 canonical 用法是什么。
如果是已有项目，Codex 通常能自己找到 components 和 tokens；但从零项目开始时，最好显式写清楚。
让 Codex 把 screenshots 当作 visual target，并翻译成项目真实的 utilities、component wrappers、color system、typography scale、spacing tokens、routing、state management 和 data-fetch patterns。
用 Playwright 验证
Playwright interactive 可以让 Codex：
- 打开真实 app。
- 调整 browser window 到不同 screen sizes。
- 检查 breakpoints。
- 对比实现和 screenshots。
- 根据视觉差异继续迭代。
不要只问“页面能 build 吗”。要让 Codex 回到截图，对比 look 和 behavior。
迭代方式
第一版应该方向接近参考图。复杂 layout、interaction 或 animation-heavy UI 往往需要几轮调整。
当 screenshot 和 repo design system 冲突时，优先使用 repo tokens 和 components，只做保持整体视觉需要的最小 spacing 或 sizing 调整。
后续可以补充 screenshot 或短 notes，澄清单张图里看不出的 state。