design.md与设计令牌在AI UI工作流中的对比
对比design.md与传统设计令牌在AI UI工作流中的应用，重点关注代理可读性、一致性和工作流可移植性。
我是 Dora。我每周大部分时间都泡在编程智能体和 AI UI 工具里——Cursor、Claude Code、Stitch，常见的那些——以比我有时间记录的更快的速度构建和重构界面。大约一个月前，我开始在我接触的每隔一个代码库里看到同一个文件：DESIGN.md。同样的名字，同样的 YAML 在上、散文在下的结构。到第三个项目的时候，我意识到这不是巧合。这是正在取代大多数人过去以 tokens.json 形式交付的那个东西。
于是我把自己的一个组件库重建了两次——一次用经典的 DTCG 风格 token 文件，一次用 DESIGN.md——并对两者运行了相同的编程智能体。这是我找不到现成记录的那部分比较：不是每种格式是什么，而是每种格式实际上在优化什么，以及现在哪一种适合你的技术栈。
design.md 与传统设计 Token 的对比
每种格式在优化什么
设计 token，在经典意义上，是一种方法论。这个术语大约在 2014 年由 Salesforce 提出，用于解决一个非常具体的规模化问题：如何在不提四张工单的情况下，让一个颜色决策在 Web、iOS、Android 和四个代码库之间保持同步？答案是一个与平台无关的名称-值对，存储在 JSON 或 YAML 中，在构建时转换为每个平台所需的格式。这种方法论现在已由 W3C 的设计 Token 社区组 编纂，截至 2025 年底，DTCG 格式已有稳定的 v1 规范。
Token 优化的是确定性分发。一个十六进制色值进去，同样的十六进制色值在每个平台、每次构建中永远出来。没有歧义。也没有叙述——token 文件告诉你 primary: #1A1C1E，但它不告诉你为什么这个颜色存在，或者什么时候不应该使用它。
DESIGN.md，由 Google Labs 于 2026 年 4 月开源，优化的是不同的东西：给编程智能体足够的上下文，让它能做出 token 文件未覆盖的决策。 它是一个单一的 markdown 文件，顶部是用于 token 的 YAML 前置内容，下方是用于说明理由的散文。同一个文件，两类受众——确定性部分给解析器，叙述性部分给正在读取代码库的 LLM。
这才是真正的区别。不是”新旧之别”。不是”JSON vs Markdown”。而是值与同一文件中的值加推理之间的区别。
为什么 AI 智能体创造了新的需求集
当人类实现设计时，“token 显示 #1A1C1E”与”这个空状态需要特定语气”之间的鸿沟由人类来填补。他们看过 Figma 文件，参加过品牌工作坊，知道次要按钮应该感觉安静而非强势。
编程智能体没有这些。它只有你放在代码库里的内容，以及它能从文件名中推断出的东西。所以当你要求它生成一个 token 文件未完全规定的屏幕——边缘情况、新组件、布局决策——它要么猜测，要么默认使用训练中最常见的内容。这就是大家抱怨的”AI 米色”美学的根源：不是模型太差，而是缺少上下文。
这正是 DESIGN.md 要解决的问题。GitHub 上的官方规范对此有明确说明——token 给智能体精确的值，散文告诉它这些值为何存在以及如何应用。该格式期待两部分都有。
design.md 在哪里增加价值
持久的叙述上下文
我在测试的前 48 小时注意到的事情：同一个智能体，给定同样的简报，当存在散文上下文时，生成的输出明显不同。不是”颜色稍微好一点”。而是不同的布局选择、不同的文案语气、不同的组件密度。两次运行中 token 值完全相同——变化的是智能体是否有一段说明”品牌语调是克制而编辑风格的；偏好留白而非装饰”的段落。
这是传统 token 流水线无法承载的部分。DTCG JSON 文件可以精确描述 —color-primary，但它无法告诉智能体主色应该被谨慎使用。DESIGN.md 将这种判断持久地带入每一次生成过程，无需任何人重新将其输入提示词。
它有效。
为生成工作流提供更好的多屏一致性
在我的第二次测试中，我在两天内为同一个应用生成了八个屏幕。仅有 token 上下文时，第 5-8 个屏幕开始漂移——调色板相同，但布局语言松散了。有 DESIGN.md 时，漂移小得多。不是零。是更小。
我的理解是：每次智能体读取文件时，散文部分都起到重新锚定的作用。仅靠 token，智能体足以在单个值上保持正确。叙述使它在token 未预见的决策上保持一致。对于一次性生成，这个差距无关紧要。对于多屏输出和持续迭代，它会累积放大。
这也是 DESIGN.md 与更广泛的智能体指令栈配合良好的地方——大多数设置现在从 AGENTS.md 中引用它，与 SKILL.md 文件并排，因此设计系统与智能体其他持久指令处于同一上下文层。
传统 Token 仍然胜出的地方
两种场景，都是真实的。
超出 Web 的跨平台分发。 如果你要将同一个设计系统部署到 iOS、Android、React Native 应用和营销网站，通过 Style Dictionary 或 Terrazzo 的 DTCG 流水线仍然是阻力最小的路径。DESIGN.md 的 YAML 可以通过官方 @google/design.md CLI 导出为 DTCG JSON，但真相来源问题仍然重要——如果你的 token 图很大、多主题，并且被非 AI 工具使用，那么将 DTCG 作为规范格式仍然是更简洁的设置。
拥有成熟治理的设计系统。 Token 不仅仅是一种文件格式。它是一种拥有约十年积累实践的方法论——原始层、语义层、别名、主题化，以及 Nathan Curtis 在设计系统中的 Token 中阐述的整个分类体系。如果你的团队已经按照这种方式运作，DESIGN.md 不会取代它。它位于其上方或旁边，作为智能体的上下文层。Token 保持规范来源；markdown 成为面向 AI 的翻译。
错误在于将 DESIGN.md 视为 token 流水线的替代品。它不是。它是一个不同的层，有不同的消费者。
为构建 AI UI 流水线的团队提供决策框架
在决定将什么放入代码库时，我一直回到四个问题：
- 谁在读这个文件？ 如果主要消费者是输出 CSS、Swift 和 Kotlin 的构建流水线，你需要规范格式的 token。如果主要消费者是按需生成 UI 的编程智能体，你需要 DESIGN.md。如果两者都是，你保留两者——让 markdown 文件的 YAML 镜像一部分 token。
- 你的 UI 界面多频繁地被重新生成？ 低频团队（稳定产品，偶尔有新屏幕）从 token 中获得大部分价值。高频团队（快速原型制作、智能体驱动的迭代、每周新屏幕）深刻感受到缺少上下文的差距。重新生成频率越高，散文层越值得保留。
- 有多少平台？ 仅 Web 或以 Web 为主加上智能体驱动的生成——DESIGN.md 是更简单的技术栈。三个及以上平台且有严肃的原生端——token 优先，DESIGN.md 作为下游产物。
- 理由已经在某处记录了吗？ 如果你的品牌指南、语气文档和组件哲学存在于智能体永远无法读到的 Notion 页面，DESIGN.md 是你本季度可以做出的单一最高杠杆举措。你不是在创建新文档——你是在将现有文档移动到智能体实际会打开的文件中。
这是我的框架。你的可能不同。我想指出的一点是：不要因为一种格式是新的就选择它。选择它是因为谁在读这个文件。
常见问题
design.md 是设计 token 的替代品吗？
不是。DESIGN.md 是一个包含设计 token（在 YAML 前置内容中）加上其周围理由（在 markdown 散文中）的包装器。其中的 token 在传统意义上仍然是设计 token。如果你已经有一个 DTCG 格式的 token 文件，DESIGN.md 不会替代它——它作为 AI 智能体的并行产物存在，或者你可以在需要时让 markdown 导出 DTCG JSON。
为什么 AI 智能体需要的不仅仅是数值 token？
因为大多数 UI 生成请求并未被 token 图完全规定。“生成一个定价页面”需要数百个微决策——层级、密度、语气、强调什么——这些都不在任何 token 文件中。没有叙述上下文，智能体用训练数据中看到的内容填补这些空白，产生大多数 AI 生成 UI 所共有的通用外观。DESIGN.md 中的散文正是填补这一差距的东西。
哪些工作流从 design.md 中受益最多？
我见过最有回报的三种模式：
- 使用 Cursor、Claude Code 或 Stitch 以比手写更快速度交付 UI 的独立构建者和小团队。
- 维护多个内部产品的设计系统团队，其中 AI 生成屏幕的一致性正在成为真实问题。
- 希望有一个单一的即插即用文件来为任何编程智能体编码客户设计语言的代理机构和合同团队。
如果你的工作流主要是手写代码偶尔有 AI 辅助，边际价值会下降。
什么时候经典的设计 token 基础设施仍然足够？
当你不使用智能体生成 UI，或者当你的平台覆盖范围远超 Web 时。重原生移动、多主题白标产品、成熟的设计运营实践——这些仍然从 DTCG 生态系统中获得比 markdown 文件更多的价值。两者并不互斥，但如果你必须选择一个来投入，答案取决于你的生成摩擦实际在哪里。
结论
诚实的版本：DESIGN.md 不是范式转变。它是针对特定差距的专注解决方案——编程智能体缺乏 token 文件无法承载的理由。对于该差距确实存在的工作流，收益是即时且明显的。对于它不存在的工作流，传统 token 仍然能胜任。
我已经在所有 AI 生成项目中使用 DESIGN.md 两个月了。它留在了工作流中，这是我唯一信任的测试。Token 文件也没有消失——它们仍在做它们一直做的事，只是现在有了一个为需要数字之外更多内容的受众而生的兄弟文件。
在一个项目上自己运行一下。两天会告诉你比这篇文章更多的东西。
往期文章：
