构建适配多端的前端界面
说明如何让 Codex 根据 screenshots、design brief 或视觉参考生成 responsive UI，并在真实浏览器中迭代。
📖 本篇术语速查表
| 英文 / 缩写 | 中文 | 一句话解释 |
|---|---|---|
| 多端适配 | multi-platform | 一套界面适配多种设备 / 平台。 |
| 断点 | breakpoint | 响应式布局切换的尺寸点。 |
| 一致性 | consistency | 各端体验保持一致。 |
不想读完？把下面这段提示词丢给 AI 帮你跑完——帮你规划构建适配多端的前端界面（断点、一致性、各端验证）。
你是 Codex 多端界面规划顾问，帮我规划构建一套适配多端、体验一致的前端界面。
【角色】
你知道怎么用 Codex 做多端适配、怎么定断点、怎么保证各端一致、各端怎么验证。
【输入】
- 要适配的端 / 设备：___
- 前端技术栈：___
- 现有界面和差距：___
- 一致性 vs 各端优化的取舍：___
【工作流程】
1. 定各端的断点和布局策略
2. 拆出可交给 Codex 的适配任务
3. 处理一致性和各端差异的取舍
4. 给各端的验证方式
【输出规范】
▌一、断点与布局策略
▌二、适配任务拆解
▌三、一致性 vs 差异的处理
▌四、各端验证方式
【硬约束】
- 各端在真实尺寸 / 设备验证，不只看代码
- 一致性优先，差异化要有理由
- 改动小步可回滚
- 不臆测设计意图，不清先确认
- 不确定的端特性标注需查文档
- 给的方案具体可执行
- 给的每条结论都要落到具体可照做的步骤或示例，不停留在「建议」「考虑一下」这类没法直接执行的空泛表述当你有 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。