--- title: "Claude Code 设计系统：4 个部分保持品牌一致" canonical: https://wavect.io/zh/blog/claude-code-design-system-files/ language: zh description: "用 REFERENCE.md、CLAUDE.md、DESIGN.md 和示例构建 Claude Code 设计系统，包含提示、QA 检查与团队落地方案。" image: "https://wavect.io/img/blog/headers/header_claude-code-design-system-files.png" --- [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 9 分钟 阅读 · 2026年9月2日 最近审核 2026年9月2日 [**下一篇**](/zh/blog/ai-coding-agents-context-not-intelligence/) # Claude Code 设计系统：用 4 个部分生成品牌一致的 UI 要点速览 Claude Code 设计系统可以作为仓库内的四部分工作流存在：REFERENCE.md 记录视觉证据与不可妥协的品牌规则，CLAUDE.md 告诉 Claude 何时加载并验证这些规则，DESIGN.md 把它们翻译为可实施的 Token 和组件决策，examples/ 则保存获批作品以便复用。只有 CLAUDE.md 是 Claude Code 的原生指令机制，其他名称是实用的项目约定，并非 Anthropic 的要求。先从真实作品出发，区分观察事实与设计决策，按用途命名 Token，要求多个方案，再用截图、无障碍检查和自动化测试验证结果。团队还应明确负责人、对文件做版本控制，并先在代表性任务上试点，再将流程标准化。 **Claude Code 设计系统是一套存放在代码仓库里的上下文结构。它告诉智能体品牌是什么样、应如何实现，以及完成后如何检查。**一个实用版本由三个 Markdown 文件和一个 `examples/` 目录组成。它用可版本管理的证据、规则和已批准模式，取代每次对话里重复解释品牌。 Charlie Hills 的 [四部分品牌系统与提示词](https://charliehills.substack.com/p/ai-design-system) 让这套工作流受到广泛关注。真正有用的不是几个文件名，而是把视觉证据、实现规则和质量检查变成持久的项目输入，而不是埋在旧聊天里。 本文把这个思路整理成产品团队能审查、测试和维护的流程，专门回答**如何让 Claude Code 遵循设计系统**。更广泛的仓库上下文问题由我们的 [编程智能体上下文文章](/zh/blog/ai-coding-agents-context-not-intelligence/) 负责；生产质量则由 [AI 生成软件生产就绪清单](/zh/blog/vibe-code-production-readiness-checklist/) 负责。这样能避免搜索意图互相竞争。 ## Claude Code 设计系统包含哪四个部分？ | 部分 | 职责 | 应该包含 | 不应包含 | | --- | --- | --- | --- | | `REFERENCE.md` | 证据 | 观察到的颜色、字体、间距、Logo 用法、常见布局和禁用模式 | 未经验证的猜测或实现代码 | | `CLAUDE.md` | 路由 | 在 UI 工作前读取设计资料，并在完成后验证的简短指令 | 整本品牌手册 | | `DESIGN.md` | 实现契约 | 语义 Token、组件规则、响应式行为、无障碍要求和决策 | 只有模糊形容词的情绪板 | | `examples/` | 已批准模式 | 团队拥有并允许复用的代表性界面或素材 | 未经筛选的灵感素材库 | 严格来说，这是四部分系统，不是四个文件，因为第四项是目录。只有 `CLAUDE.md` 对 Claude Code 有特殊含义。Anthropic 的 [Claude Code 记忆文档](https://code.claude.com/docs/en/memory) 说明，项目级 `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 格式](https://github.com/google-labs-code/design.md/blob/main/docs/spec.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 也给出类似建议：其 [官方设计系统设置指南](https://support.claude.com/en/articles/14604397-set-up-your-design-system-in-claude-design) 支持代码库、原型、演示文稿和品牌素材，并建议提供真实示例，而不只是规范。 选择示例要看覆盖面，不看数量。一个高密度仪表盘、一个营销页面、一个表单流程和一个移动端状态，通常比五十个相似的 Hero 区块更有信息量。 ## DESIGN.md 应该取代设计 Token 吗？ **不应该。DESIGN.md 解释设计意图，Token 文件为工具提供严格交换格式。**当值需要进入代码、设计工具和验证流程时，应同时使用两者。稳定的 [Design Tokens Community Group 格式](https://www.designtokens.org/tr/2025.10/format/) 为 Token 名称、值、类型和元数据定义 JSON 模型。Token 文件负责精确机器值，DESIGN.md 负责说明何时以及为何使用。 ## 如何防止系统把错误也复制下去？ 1. **标记每个来源。** 注明已批准、历史、实验或仅作灵感。 2. **设定优先级。** 精确值以当前 Token 为准，交互行为以已审查组件为准。 3. **记录例外。** 如果某个活动故意打破网格，要在清单中说明。 4. **要求多个方案。** 先生成三个备选，再进行精修。选择仍是人工设计决策。 5. **只提升审查后的模式。** 批准后才放入 `examples/` ，不是生成后立即放入。 ## 验证循环应该检查什么？ | 检查 | 方法 | 失败信号 | | --- | --- | --- | | Token 使用 | 检查 CSS 或主题引用 | 未经批准的硬编码颜色、间距或字体值 | | 组件复用 | 审查导入与渲染状态 | 新增近似重复组件，而不是扩展现有组件 | | 响应式行为 | 截取代表性的桌面与移动端画面 | 溢出、层级丢失或状态缺失 | | 无障碍 | 自动检查，加键盘和屏幕阅读器测试 | 对比度、焦点、标签、动效或交互失败 | | 视觉一致性 | 与最接近的已批准示例并排比较 | 密度、对齐、字体或构图无理由偏移 | | 产品正确性 | 验收测试与人工审查 | 界面看起来正确，却解决了错误任务 | 不要让生成界面的智能体成为唯一裁判。它可以完成第一次比较，随后应由确定性检查和有批准权的人继续把关。 ## 仓库文件与 Claude Design 应该选哪个？ | 需求 | 仓库工作流 | Claude Design | | --- | --- | --- | | 规则与代码一起版本管理 | 非常适合 | 可能需要导出或同步 | | 实现时复用真实组件 | 非常适合 | 连接代码库后有帮助 | | 让非开发成员共同进行视觉探索 | 需要仓库工作流 | 更适合 | | 确定性的 CI 检查 | 非常适合 | 应在代码仓库执行 | | 组织级统一管理的 UI Kit | 需要自己建立治理 | 面向共享组织系统 | ## 团队应该如何落地？ 1. **选择代表性工作。** 覆盖产品 UI、营销页面和至少一个困难状态。 2. **起草并审查源文件。** 设计团队负责视觉事实，工程团队负责可实现性。 3. **接入路由规则。** 保持 `CLAUDE.md` 简短，并测试 Claude 是否真的读取资料。 4. **试点三类任务。** 一个新组件、一次现有界面修改和一次响应式修复。 5. **衡量返工。** 记录审查轮次、未批准 Token、重复组件、无障碍缺陷和首版接受情况。 6. **指定维护人。** 分别明确 Token、组件、示例和决策日志的负责人。 企业真正要做的采购决策不是“买哪套提示词”，而是“谁拥有设计契约，如何验证合规，哪些变化需要批准”。Wavect 的 [AI Enablement 服务](/zh/services/ai-enablement/) 能把零散的智能体使用变成带仓库上下文、评估和审查门禁的治理流程。如果 AI 生成产品已经需要加固，可以用 [从 vibe-coded 原型到生产的决策指南](/zh/software-development-guide/vibe-coded-prototype-to-production/) 界定下一步。 ## 常见问题 ### Claude Code 会自动读取 DESIGN.md 吗？ 不会。Claude Code 会自动加载受支持的 CLAUDE.md 指令文件。请在 CLAUDE.md 中明确说明何时读取 DESIGN.md 和 REFERENCE.md，再通过记忆视图或观察实际任务来验证。 ### DESIGN.md 是 Anthropic 官方标准吗？ 不是。它是一种项目约定，也是 Google Labs 推动的新兴开放格式。只要指令明确指向，Claude Code 可以使用任何可读文件名。 ### REFERENCE.md 应该写规则还是观察？ 先写观察并标明来源，只有在人类负责人批准后才转为强制规则。这样可以防止偶然模式变成永久政策。 ### 应该给 Claude Code 多少示例？ 先提供三到五个已批准、覆盖不同界面问题的示例。只有在新示例能解决反复出现的歧义时才增加。覆盖面和来源比数量重要。 ### 这套文件能取代真实组件库吗？ 不能。文件负责解释决策并引导智能体。生产一致性仍依赖可复用组件、机器可读 Token、自动检查和人工责任。 ## 研究边界 *本文于 2026 年 9 月 2 日审查，依据包括原始工作流、当前 Claude Code 记忆文档、Google Labs DESIGN.md 规范、Anthropic Claude Design 指南以及稳定的 Design Tokens Community Group 格式。产品行为和测试版可用性可能变化。由于没有跨团队的独立基准，本文不声称该流程能带来具体比例的效率提升。* ## 最终思考 持久优势不来自一条聪明提示词，而来自一套小而可审查的系统。它把证据、指令、实现规则和已批准示例分开。 从团队已经信任的作品开始，让不确定性保持可见，保持路由简短，并测试真实渲染结果。Claude 可以持续遵守规则，但规则是否优秀仍由人来决定。 ## 你可能也喜欢.. [**编程智能体需要上下文，而不是更多智能** 了解为什么持久仓库上下文、聚焦任务和独立验证不只对视觉设计重要。](/zh/blog/ai-coding-agents-context-not-intelligence/) [**AI Enablement 与通用 AI 咨询** 比较有治理的实施工作流和只提供战略建议的项目。](/zh/compare/ai-enablement-vs-generic-ai-consultancy/) 智能体工程 ## 继续浏览此集群 编程智能体、MCP、上下文系统、评估与可靠自动化控制。 [从核心文章开始**AI 智能体的图工程：知识图谱什么时候值得做？**](/zh/blog/graph-engineering-ai-agents/) - [Obscura 浏览器评测：性能主张、限制与生产适用性](/zh/blog/obscura-rust-browser-ai-agents/) - [ChatGPT 能登录网站，而且模型看不到密码](/zh/blog/chatgpt-cloud-browser-secure-login/) - [AI 智能体 Harness 图解：LLM 周围的可靠性层](/zh/blog/agent-harness-engineering/) - [智能体编辑为何需要语义身份：用 Rust 构建 SEMAPRAX](/zh/blog/semantic-identity-rust-agent-edits/) - [LangChain Deep Agents 评测：Agent Harness 能否用于生产？](/zh/blog/langchain-deep-agents-review/) [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 9 分钟 阅读 · 2026年9月2日 最近审核 2026年9月2日 [**下一篇**](/zh/blog/ai-coding-agents-context-not-intelligence/) ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/zh/blog/claude-code-design-system-files/#webpage", "@type": "WebPage", "dateModified": "2026-09-02", "inLanguage": "zh", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-09-02", "url": "https://wavect.io/zh/blog/claude-code-design-system-files/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Claude Code 设计系统可以作为仓库内的四部分工作流存在：REFERENCE.md 记录视觉证据与不可妥协的品牌规则，CLAUDE.md 告诉 Claude 何时加载并验证这些规则，DESIGN.md 把它们翻译为可实施的 Token 和组件决策，examples/ 则保存获批作品以便复用。只有 CLAUDE.md 是 Claude Code 的原生指令机制，其他名称是实用的项目约定，并非 Anthropic 的要求。先从真实作品出发，区分观察事实与设计决策，按用途命名 Token，要求多个方案，再用截图、无障碍检查和自动化测试验证结果。团队还应明确负责人、对文件做版本控制，并先在代表性任务上试点，再将流程标准化。", "articleBody": " 博客概览/AI 与智能体/智能体工程 Claude Code 设计系统：用 4 个部分生成品牌一致的 UI 要点速览 Claude Code 设计系统可以作为仓库内的四部分工作流存在：REFERENCE.md 记录视觉证据与不可妥协的品牌规则，CLAUDE.md 告诉 Claude 何时加载并验证这些规则，DESIGN.md 把它们翻译为可实施的 Token 和组件决策，examples/ 则保存获批作品以便复用。只有 CLAUDE.md 是 Claude Code 的原生指令机制，其他名称是实用的项目约定，并非 Anthropic 的要求。先从真实作品出发，区分观察事实与设计决策，按用途命名 Token，要求多个方案，再用截图、无障碍检查和自动化测试验证结果。团队还应明确负责人、对文件做版本控制，并先在代表性任务上试点，再将流程标准化。 Claude Code 设计系统是一套存放在代码仓库里的上下文结构。它告诉智能体品牌是什么样、应如何实现，以及完成后如何检查。一个实用版本由三个 Markdown 文件和一个 examples/ 目录组成。它用可版本管理的证据、规则和已批准模式，取代每次对话里重复解释品牌。 Charlie Hills 的四部分品牌系统与提示词让这套工作流受到广泛关注。真正有用的不是几个文件名，而是把视觉证据、实现规则和质量检查变成持久的项目输入，而不是埋在旧聊天里。 本文把这个思路整理成产品团队能审查、测试和维护的流程，专门回答如何让 Claude Code 遵循设计系统。更广泛的仓库上下文问题由我们的编程智能体上下文文章负责；生产质量则由AI 生成软件生产就绪清单负责。这样能避免搜索意图互相竞争。 Claude Code 设计系统包含哪四个部分？ 部分职责应该包含不应包含 REFERENCE.md证据观察到的颜色、字体、间距、Logo 用法、常见布局和禁用模式未经验证的猜测或实现代码 CLAUDE.md路由在 UI 工作前读取设计资料，并在完成后验证的简短指令整本品牌手册 DESIGN.md实现契约语义 Token、组件规则、响应式行为、无障碍要求和决策只有模糊形容词的情绪板 examples/已批准模式团队拥有并允许复用的代表性界面或素材未经筛选的灵感素材库 严格来说，这是四部分系统，不是四个文件，因为第四项是目录。只有 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 负责说明何时以及为何使用。 如何防止系统把错误也复制下去？ 标记每个来源。注明已批准、历史、实验或仅作灵感。 设定优先级。精确值以当前 Token 为准，交互行为以已审查组件为准。 记录例外。如果某个活动故意打破网格，要在清单中说明。 要求多个方案。先生成三个备选，再进行精修。选择仍是人工设计决策。 只提升审查后的模式。批准后才放入 examples/，不是生成后立即放入。 验证循环应该检查什么？ 检查方法失败信号 Token 使用检查 CSS 或主题引用未经批准的硬编码颜色、间距或字体值 组件复用审查导入与渲染状态新增近似重复组件，而不是扩展现有组件 响应式行为截取代表性的桌面与移动端画面溢出、层级丢失或状态缺失 无障碍自动检查，加键盘和屏幕阅读器测试对比度、焦点、标签、动效或交互失败 视觉一致性与最接近的已批准示例并排比较密度、对齐、字体或构图无理由偏移 产品正确性验收测试与人工审查界面看起来正确，却解决了错误任务 不要让生成界面的智能体成为唯一裁判。它可以完成第一次比较，随后应由确定性检查和有批准权的人继续把关。 仓库文件与 Claude Design 应该选哪个？ 需求仓库工作流Claude Design 规则与代码一起版本管理非常适合可能需要导出或同步 实现时复用真实组件非常适合连接代码库后有帮助 让非开发成员共同进行视觉探索需要仓库工作流更适合 确定性的 CI 检查非常适合应在代码仓库执行 组织级统一管理的 UI Kit需要自己建立治理面向共享组织系统 查看相关服务： RAG 与 AI 架构 看看生产环境中的应用: Twinsoft AI 先做决定: 如何为 MVP 选择技术栈 团队应该如何落地？ 选择代表性工作。覆盖产品 UI、营销页面和至少一个困难状态。 起草并审查源文件。设计团队负责视觉事实，工程团队负责可实现性。 接入路由规则。保持 CLAUDE.md 简短，并测试 Claude 是否真的读取资料。 试点三类任务。一个新组件、一次现有界面修改和一次响应式修复。 衡量返工。记录审查轮次、未批准 Token、重复组件、无障碍缺陷和首版接受情况。 指定维护人。分别明确 Token、组件、示例和决策日志的负责人。 企业真正要做的采购决策不是“买哪套提示词”，而是“谁拥有设计契约，如何验证合规，哪些变化需要批准”。Wavect 的 AI Enablement 服务能把零散的智能体使用变成带仓库上下文、评估和审查门禁的治理流程。如果 AI 生成产品已经需要加固，可以用从 vibe-coded 原型到生产的决策指南界定下一步。 常见问题 Claude Code 会自动读取 DESIGN.md 吗？ 不会。Claude Code 会自动加载受支持的 CLAUDE.md 指令文件。请在 CLAUDE.md 中明确说明何时读取 DESIGN.md 和 REFERENCE.md，再通过记忆视图或观察实际任务来验证。 DESIGN.md 是 Anthropic 官方标准吗？ 不是。它是一种项目约定，也是 Google Labs 推动的新兴开放格式。只要指令明确指向，Claude Code 可以使用任何可读文件名。 REFERENCE.md 应该写规则还是观察？ 先写观察并标明来源，只有在人类负责人批准后才转为强制规则。这样可以防止偶然模式变成永久政策。 应该给 Claude Code 多少示例？ 先提供三到五个已批准、覆盖不同界面问题的示例。只有在新示例能解决反复出现的歧义时才增加。覆盖面和来源比数量重要。 这套文件能取代真实组件库吗？ 不能。文件负责解释决策并引导智能体。生产一致性仍依赖可复用组件、机器可读 Token、自动检查和人工责任。 研究边界 本文于 2026 年 9 月 2 日审查，依据包括原始工作流、当前 Claude Code 记忆文档、Google Labs DESIGN.md 规范、Anthropic Claude Design 指南以及稳定的 Design Tokens Community Group 格式。产品行为和测试版可用性可能变化。由于没有跨团队的独立基准，本文不声称该流程能带来具体比例的效率提升。 最终思考 持久优势不来自一条聪明提示词，而来自一套小而可审查的系统。它把证据、指令、实现规则和已批准示例分开。 从团队已经信任的作品开始，让不确定性保持可见，保持路由简短，并测试真实渲染结果。Claude 可以持续遵守规则，但规则是否优秀仍由人来决定。 你可能也喜欢.. 编程智能体需要上下文，而不是更多智能 了解为什么持", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "四部分品牌系统与提示词", "url": "https://charliehills.substack.com/p/ai-design-system" }, { "@type": "WebPage", "name": "Claude Code 记忆文档", "url": "https://code.claude.com/docs/en/memory" }, { "@type": "WebPage", "name": "Google Labs DESIGN.md 格式", "url": "https://github.com/google-labs-code/design.md/blob/main/docs/spec.md" }, { "@type": "WebPage", "name": "官方设计系统设置指南", "url": "https://support.claude.com/en/articles/14604397-set-up-your-design-system-in-claude-design" }, { "@type": "WebPage", "name": "Design Tokens Community Group 格式", "url": "https://www.designtokens.org/tr/2025.10/format/" } ], "dateModified": "2026-09-02", "datePublished": "2026-09-02", "description": "Claude Code 设计系统可以作为仓库内的四部分工作流存在：REFERENCE.md 记录视觉证据与不可妥协的品牌规则，CLAUDE.md 告诉 Claude 何时加载并验证这些规则，DESIGN.md 把它们翻译为可实施的 Token 和组件决策，examples/ 则保存获批作品以便复用。只有 CLAUDE.md 是 Claude Code 的原生指令机制，其他名称是实用的项目约定，并非 Anthropic 的要求。先从真实作品出发，区分观察事实与设计决策，按用途命名 Token，要求多个方案，再用截图、无障碍检查和自动化测试验证结果。团队还应明确负责人、对文件做版本控制，并先在代表性任务上试点，再将流程标准化。", "headline": "Claude Code 设计系统：用 4 个部分保持品牌一致", "image": "https://wavect.io/img/blog/headers/header_claude-code-design-system-files.svg", "inLanguage": "zh", "keywords": "AI 工程, 设计系统", "mainEntityOfPage": { "@id": "https://wavect.io/zh/blog/claude-code-design-system-files/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/zh/blog/claude-code-design-system-files/", "wordCount": 446 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/zh/", "name": "首页", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/overview/", "name": "博客概览", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/topics/ai-agents/", "name": "AI 与智能体", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/clusters/agent-engineering/", "name": "智能体工程", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/claude-code-design-system-files/", "name": "Claude Code 设计系统：4 个部分保持品牌一致 | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "不会。Claude Code 会自动加载受支持的 CLAUDE.md 指令文件。请在 CLAUDE.md 中明确说明何时读取 DESIGN.md 和 REFERENCE.md，再通过记忆视图或观察实际任务来验证。" }, "name": "Claude Code 会自动读取 DESIGN.md 吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "不是。它是一种项目约定，也是 Google Labs 推动的新兴开放格式。只要指令明确指向，Claude Code 可以使用任何可读文件名。" }, "name": "DESIGN.md 是 Anthropic 官方标准吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "先写观察并标明来源，只有在人类负责人批准后才转为强制规则。这样可以防止偶然模式变成永久政策。" }, "name": "REFERENCE.md 应该写规则还是观察？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "先提供三到五个已批准、覆盖不同界面问题的示例。只有在新示例能解决反复出现的歧义时才增加。覆盖面和来源比数量重要。" }, "name": "应该给 Claude Code 多少示例？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "不能。文件负责解释决策并引导智能体。生产一致性仍依赖可复用组件、机器可读 Token、自动检查和人工责任。" }, "name": "这套文件能取代真实组件库吗？" } ] } ```