Codex 极简画布设计系统

要解决的问题

多数团队在基于 Codex 构建界面时，会陷入两类反复出现的争论：一是设计意图靠口头约定传递，spacing 用了 15px、18px、22px 这类“差不多”的值，组件间距节奏不一致；二是风格描述里充斥着“极简”“高级”“通透”等形容词，开发拿到手无法验收，Code Review 时只能靠感觉判断。结果就是：同一个按钮在 A 页面是 pill 形，在 B 页面被改成了直角；阴影、渐变悄悄溜进 UI，与品牌规范冲突，却没人能指出违反了哪一条规则。

这个技能针对的正是这类无法落地的规范问题：把一套“极简画布”设计系统的抽象原则，转写成工程师可以直接执行、设计师可以直接对照的实现级指引。

技能如何工作

技能扮演的角色是 Codex 的设计系统规范撰写器，输出物是一份可直接交给工程团队的 guideline 文档，而不是代码组件本身。

核心能力包括：

• 先给意图，再给规则：在提出任何具体规则之前，先用一句话复述设计意图，避免后续规则互相打架。
• 令牌先行：规范的基础是一组语义化 token——primary=#000000、surface=#FFFFFF、text=#111827，以及 success / warning / danger 等语义色。规则要求优先使用语义 token，而不是裸色值，这样后续换肤或暗色化才不会失控。
• 视觉系统有硬约束：

- 排版基线为 12/14/16/20/24/32，字体使用 Open Sans（正文与标题）和 JetBrains Mono（等宽场景）；
- 间距节奏为 4/8/12/16/24/32，不允许出现节奏外的随机值；
- 黑色是页面中唯一的填充色，同时也是唯一的分割线和卡片底色；
- 交互元素统一采用 pill 形几何，图片卡片使用接近扁平的精确圆角；
- UI 中不使用阴影、不使用渐变、不放装饰性插图，色彩只出现在编辑性摄影图上。

• 组件规则必须完整：每个组件需要描述 anatomy、variants、以及 default / hover / focus-visible / active / disabled / loading / error 等状态，并明确键盘、指针、触摸三类交互行为。
• 无障碍是验收线：遵循 WCAG 2.2 AA，键盘优先、可见 focus 状态，且每条无障碍声明都必须可测试。

规范生成采用固定的六步流程：复述意图 → 定义 token 与基础约束 → 组件级规则 → 无障碍验收标准 → 反模式与迁移说明 → 输出一份可在 Code Review 中直接勾选的 QA checklist。

在措辞上，技能明确区分 must（不可协商）与 should（推荐建议），并且要求每一条 do 规则都至少配一个具体的 don't 示例，防止规范变成空泛口号。

适用边界与注意点

这个技能适合已经确定要走极简画布风格、需要统一落地标准的项目，例如内容站、编辑器工具、以黑白排版为主的产品界面。它不负责生成组件代码，也不替你做视觉探索——如果你还在“极简 vs. 拟物 vs. 玻璃拟态”之间摇摆，它给不出答案。

使用时需注意：

• 规则中所有数值（圆角、间距、字号）都是这套风格下的默认值，不是跨项目通用真理；如果业务需要调整，应先修改 token，而不是在组件层面硬编码覆盖。
• 规范强调“当不确定时，优先无障碍与清晰度，而不是视觉新颖性”，因此在某些追求强烈视觉冲击的场景，这套约束可能显得过于保守。
• 对于已有 UI 的迁移，技能要求附带迁移说明，避免新旧两套规则长期并存。
• 另一个风险是文档通胀：如果团队没人负责维护 guideline 版本，再好的规则也会逐渐失真。建议把生成的 QA checklist 直接挂进 PR 模板，让规范与实现同步演进。