Claude Code 设计系统：用 4 个部分生成品牌一致的 UI

Claude Code 设计系统是一套存放在代码仓库里的上下文结构。它告诉智能体品牌是什么样、应如何实现，以及完成后如何检查。一个实用版本由三个 Markdown 文件和一个 examples/ 目录组成。它用可版本管理的证据、规则和已批准模式，取代每次对话里重复解释品牌。

Charlie Hills 的四部分品牌系统与提示词让这套工作流受到广泛关注。真正有用的不是几个文件名，而是把视觉证据、实现规则和质量检查变成持久的项目输入，而不是埋在旧聊天里。

本文把这个思路整理成产品团队能审查、测试和维护的流程，专门回答如何让 Claude Code 遵循设计系统。更广泛的仓库上下文问题由我们的编程智能体上下文文章负责；生产质量则由AI 生成软件生产就绪清单负责。这样能避免搜索意图互相竞争。

Claude Code 设计系统包含哪四个部分？

严格来说，这是四部分系统，不是四个文件，因为第四项是目录。只有 CLAUDE.md 对 Claude Code 有特殊含义。Anthropic 的 Claude Code 记忆文档说明，项目级 CLAUDE.md 会作为持久指令加载，并建议指令具体、简洁、结构清楚。REFERENCE.md、DESIGN.md 和 examples/ 能生效，是因为你在指令中明确要求 Claude 读取它们。

项目目录应该怎样组织？

your-project/
├── CLAUDE.md
├── REFERENCE.md
├── DESIGN.md
├── examples/
│   ├── README.md
│   ├── dashboard-approved.png
│   ├── landing-page-approved.png
│   └── pricing-card-approved.html
├── src/
└── tests/

在 examples/README.md 中为每个素材记录负责人、批准日期、来源、可复用部分和已知例外。这份小清单能避免旧活动素材或实验界面悄悄变成永久产品规则。

提示词 1：从已批准作品生成 REFERENCE.md

选择三到五个能代表当前品牌的示例，优先使用自己的生产界面、品牌演示文稿、营销图或组件库。不要把竞争对手受保护的素材复制到仓库。灵感可以帮助做决策，但要长期复用的示例必须由你拥有或取得许可。

检查 examples/ 中的每个文件，把可观察事实与需要询问的问题分开。

起草 REFERENCE.md，包含：
1. 来源清单与批准状态
2. 实测颜色值及其观察到的用途
3. 字体、字号和层级
4. 间距、网格与对齐模式
5. Logo 位置与安全空间
6. 重复使用的组件与构图
7. 品牌必须避免的五种模式
8. 尚未解决的问题

不要编造缺失值。保存前先展示草稿。

最好的文档会区分证据和政策。“三个已批准界面的卡片间距都是 24 px”是观察。“所有卡片组必须使用 24 px”是需要人工批准的规则。混在一起会把历史偶然选择变成长期教条。

提示词 2：让 CLAUDE.md 负责路由

入口指令应保持简短。过长的指令文件会在每次会话里消耗上下文，而详细设计材料只在界面工作时有用。

## 界面工作

创建或修改 UI 前，先阅读 REFERENCE.md 和 DESIGN.md，再检查 examples/ 中最接近的已批准示例。
新增组件或 Token 前，先复用现有组件与语义 Token。
如果资料冲突，或没有覆盖重要决策，请先询问，不要猜测。
完成前，把渲染结果与设计规则逐项比较，并报告所有有意例外。

路由层应说明何时读取、哪个来源优先、如何验证。如果项目已有很长的 CLAUDE.md，可以为前端路径设置范围规则。导入文件能改善组织，但 Anthropic 文档明确说明，被导入的文本仍会进入启动上下文。

提示词 3：把参考资料转换成 DESIGN.md

DESIGN.md 是构建契约。新兴的 Google Labs DESIGN.md 格式定义了一种自包含文件，可在 YAML frontmatter 中放置机器可读 Token，并在 Markdown 正文解释设计理由。采用该格式有利于移植，但 Claude Code 并不强制。

阅读 REFERENCE.md 和 examples/README.md，再检查所有已批准示例。

把 DESIGN.md 写成实现契约，包含：
1. 按用途命名而非按色相命名的语义颜色 Token
2. 带精确值的字体与间距尺度
3. 布局、网格与断点规则
4. 组件结构、状态与复用政策
5. 交互、动效和 reduced-motion 行为
6. 无障碍要求
7. 响应式示例与边界情况
8. 包含日期、负责人和理由的决策日志

标记所有推断而非已批准的规则。资料冲突时先询问。保存前展示文件。

按用途命名更能适应品牌改版。color-text-primary 表达意图，dark-gray 只描述当前值。如果这些值还要进入设计工具和构建系统，应另设机器可读的 Token 源。

为什么示例比更长的提示词更重要？

规则说明什么可以做，已批准示例则展示比例、密度、层级和构图如何一起工作。Anthropic 对独立产品 Claude Design 也给出类似建议：其官方设计系统设置指南支持代码库、原型、演示文稿和品牌素材，并建议提供真实示例，而不只是规范。

选择示例要看覆盖面，不看数量。一个高密度仪表盘、一个营销页面、一个表单流程和一个移动端状态，通常比五十个相似的 Hero 区块更有信息量。

DESIGN.md 应该取代设计 Token 吗？

不应该。DESIGN.md 解释设计意图，Token 文件为工具提供严格交换格式。当值需要进入代码、设计工具和验证流程时，应同时使用两者。稳定的 Design Tokens Community Group 格式为 Token 名称、值、类型和元数据定义 JSON 模型。Token 文件负责精确机器值，DESIGN.md 负责说明何时以及为何使用。

如何防止系统把错误也复制下去？

1. 标记每个来源。注明已批准、历史、实验或仅作灵感。
2. 设定优先级。精确值以当前 Token 为准，交互行为以已审查组件为准。
3. 记录例外。如果某个活动故意打破网格，要在清单中说明。
4. 要求多个方案。先生成三个备选，再进行精修。选择仍是人工设计决策。
5. 只提升审查后的模式。批准后才放入 examples/，不是生成后立即放入。

验证循环应该检查什么？

不要让生成界面的智能体成为唯一裁判。它可以完成第一次比较，随后应由确定性检查和有批准权的人继续把关。

仓库文件与 Claude Design 应该选哪个？

团队应该如何落地？

1. 选择代表性工作。覆盖产品 UI、营销页面和至少一个困难状态。
2. 起草并审查源文件。设计团队负责视觉事实，工程团队负责可实现性。
3. 接入路由规则。保持 CLAUDE.md 简短，并测试 Claude 是否真的读取资料。
4. 试点三类任务。一个新组件、一次现有界面修改和一次响应式修复。
5. 衡量返工。记录审查轮次、未批准 Token、重复组件、无障碍缺陷和首版接受情况。
6. 指定维护人。分别明确 Token、组件、示例和决策日志的负责人。

企业真正要做的采购决策不是“买哪套提示词”，而是“谁拥有设计契约，如何验证合规，哪些变化需要批准”。Wavect 的 AI Enablement 服务能把零散的智能体使用变成带仓库上下文、评估和审查门禁的治理流程。如果 AI 生成产品已经需要加固，可以用从 vibe-coded 原型到生产的决策指南界定下一步。

研究边界

本文于 2026 年 9 月 2 日审查，依据包括原始工作流、当前 Claude Code 记忆文档、Google Labs DESIGN.md 规范、Anthropic Claude Design 指南以及稳定的 Design Tokens Community Group 格式。产品行为和测试版可用性可能变化。由于没有跨团队的独立基准，本文不声称该流程能带来具体比例的效率提升。