你让 AI 做一个品牌主按钮，它很可能交出一块圆角适中、颜色安全，却放到哪个公司都成立的蓝灰色矩形。问题未必是 AI 不会设计，而是它动手时找不到品牌规则：颜色在设计稿里，使用原则在幻灯片里，例外情况只存在于资深设计师脑中。DESIGN.md 想把这些信息收进一份纯文本文件，让设计师和 coding agent——能读取说明并生成代码的 AI 智能体——面对同一个版本。不过，目前关于它的介绍主要来自 Patrick Neeman 在 uxdesign-cc 发表的一篇文章，以下功能与效果尚无独立测试佐证。
一份文件，写给两种读者
DESIGN.md 的核心并不复杂。文件上半部分放设计令牌（design tokens）——把颜色、字号、间距、圆角等决定保存成有名称的结构化数值。下半部分用 Markdown 写解释。Markdown 是一种源码也便于阅读的轻量级标记语言，程序可以解析，人也能直接看懂。
例如，令牌可以规定主色的准确色值，文字则说明主色只用于每个页面最重要的操作。前者回答“用什么”，后者回答“为什么、何时可以变通”。这比单独给 AI 一张色表多了一层判断依据：它不仅知道按钮该是什么颜色，也知道这种颜色不能铺得到处都是。
文章给出的示例采用 YAML frontmatter——放在 Markdown 文件开头、以分隔线围起的一组结构化字段——保存颜色、字体、间距、圆角和组件参数。正文则按顺序描述品牌气质、颜色、字体、布局、层级、形状、组件以及注意事项，共八部分。参数还能通过类似 {colors.primary} 的引用重复使用，让颜色只定义一次，其他位置都指向它。
这让 DESIGN.md 成为一种“单一事实来源”（single source of truth）：团队为品牌规则指定一个权威版本，设计工具、代码和 AI 都尽量从这里读取，减少信息在交接中逐渐分叉。它仍是设计系统的一种交付方式。所谓设计系统，就是让不同产品保持一致的一套视觉规则、组件和协作约定。
真正稀缺的是设计理由
样式表里通常已经有色值和字号，但它未必解释为什么主色不能同时标记五个操作，也不会说明何时可以打破栅格。DESIGN.md 最值得注意的地方，正是把这些过去依靠口头传递的理由写下来。
Neeman 举例称，没有这份文件时，coding agent 容易采用 Material、shadcn 等通用组件或默认样式；有了文件后，它可以按品牌色和指定圆角生成按钮。这是直观的使用主张，但文章没有给出对照实验、成功率或不同模型的测试结果。因此，更稳妥的理解是：DESIGN.md 为 AI 提供了明确上下文，而不是保证所有 AI 都会稳定服从。
为什么现在值得看
过去，品牌规范主要写给人看。AI 开始直接生成界面后，规范还要能被机器找到、读取和引用。DESIGN.md 试图在两者之间搭一座很朴素的桥：不发明一套只供机器使用的黑箱格式，也不要求 AI 从设计稿中猜意图，而是把精确参数和自然语言放在同一个仓库文件里。
文章称 Google Labs 在 2026 年 4 月将这一格式开源，并把它描述为“agent standards”的开端。但供稿未附官方公告、仓库地址或版本信息，刊发前仍需查验。这也意味着，现阶段更适合把 DESIGN.md 看作一种值得试用的规范提案，而不是已经获得行业共识的正式标准。
局限与未知
- 现有材料只有一个独立信源，没有证明单靠一份文件就能约束所有模型、工具和生成任务。
- 材料虽列出八个正文部分，却未提供完整正式规范，无法确认固定顺序究竟是强制要求还是作者建议。
- 文件如何与现有设计稿、组件库和代码保持同步，以及规则冲突时由谁裁决，供稿没有说明。