把审美写成规则：用 Codex 生成一致 UI 的 6 步工作流

昨天我们讨论了如何让 Codex 根据截图或 Figma 参考实现响应式页面；今天再往前一步：同一套参考图为什么交给不同人、不同轮次，还是会得到风格漂移的 UI？问题通常不在模型“审美差”，而在团队没有把自己的设计判断写成可执行规则。Figma 设计师倡导者 Miggi Cardona 在最新官方文章中把 Skills 定义为纯文本 Markdown 指令，用来保存设计师的判断与操作顺序。下面把这一思路改写成适合 Codex 项目的六步工作流。

适用场景

• 用 Codex 连续生成多个营销页、后台页面或产品功能，希望视觉语言保持一致；
• 项目已有组件库和 design tokens，但模型经常绕开它们重写按钮、颜色和间距；
• 设计稿只覆盖顺利路径，需要补齐 loading、empty、error、disabled 与键盘状态；
• 多人协作，希望把资深设计师的评审标准变成可复用项目规则。

如果项目还没有确定信息架构、品牌方向或基础组件，不要急着写一份几十页规则。先用一个真实页面验证规则是否可执行，再逐步扩大范围。

第一步：只提炼“能检查”的设计判断

先回看最近三次 UI 评审，把反复出现的意见分成四类：排版与层级、布局与响应式、组件与状态、内容与可访问性。删除“更高级”“更有感觉”这类无法验收的词，改写为带对象、条件和结果的句子。

含糊：按钮再突出一点。
可检查：每个页面只能有一个 primary CTA；主按钮使用现有 Button/primary，正文区同屏不再出现第二个高饱和填充按钮。

含糊：手机端紧凑一点。
可检查：390px 下双栏改为单栏，正文行宽不超过 36 个汉字，卡片内边距使用 spacing-4，页面不得出现横向滚动。

第二步：在 AGENTS.md 中建立最小 UI 规则区

把已验证的规则放进项目现有 AGENTS.md，或由它链接到 docs/ui-rulebook.md。规则文件要短、靠近代码，并明确优先级；不要把完整品牌手册原样粘进去。建议先覆盖组件复用、token 来源、断点、状态和验证命令。

## UI implementation rules
- 先复用 src/components/ui 和现有页面模式，禁止平行创建第二套 Button、Input、Card。
- 颜色、圆角、阴影、字号和间距只能来自现有 tokens；需要新增 token 时先说明用途与影响页面。
- 每个数据区域必须实现 loading、empty、error；交互控件补齐 hover、focus-visible、disabled。
- 固定检查 1440、768、390px；390px 不得横向滚动。
- 完成前运行已有 lint、typecheck、test、build，并在固定视口截图。

第三步：先写状态矩阵，再让 Codex 生成页面

Figma 最新示例中的 /ui-state-expander 会把顺利路径扩展为完整状态。Codex 项目也应先定义状态矩阵，避免完成漂亮首屏后才发现错误、权限和空数据没有设计。

状态扩展提示词

先不要写代码。阅读 AGENTS.md 和目标页面需求，为页面中的每个数据区、表单与交互控件建立状态矩阵。至少覆盖 loading、empty、error、disabled、focus-visible、长文本和权限不足。指出设计稿未说明的状态，并给出最小文案与交互建议；不要擅自改变业务规则。

第四步：让 Codex 按“规则—组件—页面”顺序实现

实现提示词不要重复整份规则，只需指向规则文件、目标路由、可复用组件和验收范围。第一轮先完成结构、组件边界与状态，不要同时追像素级装饰。

请实现【目标路由/区块】。先读取 AGENTS.md 的 UI implementation rules，并盘点可复用组件与 tokens。按已确认的状态矩阵完成桌面和移动端结构；禁止新增 UI 框架，禁止复制现有组件后改名。完成后运行项目已有检查，并列出：复用组件、新增文件、仍缺信息、尚未通过的状态。先保证结构和状态正确，不做无关重构。

第五步：单独做组件与 token 审计

页面能运行后，再让 Codex 检查重复组件、硬编码颜色和任意间距。Figma 官方示例中的 /create-color 与 /analyze-components 说明了这种审计思路：它们不是再生成一版，而是把实现拉回设计系统。

审计本次 UI 修改，不改文件。列出：1）可替换为现有组件的重复实现；2）没有使用 token 的颜色、字号、间距、阴影；3）组件 API 与项目惯例不一致之处；4）缺失的 variants 与状态。按影响排序，只提出最小修复方案，并标注涉及文件。

第六步：用固定截图和 Playwright 收尾

最后在 1440、768、390px 访问真实路由，检查控制台、资源 404、横向滚动、键盘顺序和长文本。Playwright 官方支持用 toHaveScreenshot() 保存并比较基准图；基准截图应在稳定环境生成，并在有意变化时人工审核后更新，不能把“更新全部截图”当作修复。

import { test, expect } from "@playwright/test";

test("dashboard visual states", async ({ page }) => {
  await page.goto("/dashboard");
  await expect(page).toHaveScreenshot("dashboard-1440.png", {
    fullPage: true,
    animations: "disabled",
  });
});

最终验收提示词

在 1440、768、390px 检查真实页面。记录控制台错误、失败请求、横向滚动、未加载字体/图片、键盘焦点、长标题与 loading/empty/error 状态。比较基准截图，按“结构 > 字体 > 间距 > 装饰”列出差异；只修前三项并重新截图。不得直接更新基准图来隐藏回归。

限制

• 规则只能减少重复判断，不能替代品牌策略、用户研究和产品决策；
• AGENTS.md 写得过长会让关键约束被淹没，应把细节拆到链接文档；
• 视觉截图无法覆盖可访问名称、焦点顺序和真实数据逻辑，仍需语义与交互测试；
• Figma Skills 与 Codex 项目规则不是同一产品格式，本文是方法迁移；若使用 Figma MCP，应先按团队安全要求单独配置并验证；
• 第三方社区规则可能带入不适合本项目的审美和依赖，采用前必须审查。

总结

Codex 生成一致 UI 的关键，不是把提示词写得越来越像设计散文，而是把团队判断变成短、明确、可检查的规则：组件必须复用、token 有唯一来源、状态先于装饰、截图必须复测。当规则、实现与验收都能版本化，AI 才会从一次性页面生成器变成稳定的设计系统协作者。

本文由「设计创意1984」整理编辑，转载请注明出处。

关注设计创意1984，持续获取设计趋势、AI创作方法与创意灵感。

via：Figma：Try these 10 skills（Miggi Cardona）、OpenAI Academy：Create frontend designs（官方）、OpenAI Academy：Turn Figma designs into code（官方）、Playwright：Visual comparisons（官方）