你有没有这种体验：让 AI 帮你写个页面，它生成的代码颜色全是瞎编的、间距全靠猜、按钮样式跟你们产品完全不搭？
然后你甩给它一份设计规范的 PDF，指望它能“学会”你们的设计体系。
结果呢？AI 看 PDF 基本等于盲人摸象——它看到的是一堆碎片化的文字和完全无法理解的截图。那些精心排版的视觉示例，在 AI 眼里跟噪音差不多。
问题不是 AI 不行，而是我们给 AI 的“学习资料”不对。
传统设计规范的问题
传统设计规范长这样：一份精美的 PDF，里面有品牌色卡、组件截图、do/don’t 的对比图、各种排版示例。
这东西给人看，完美。给 AI 看，灾难。
原因很简单：
第一，PDF 是视觉媒介，AI 是文本动物。 PDF 里那些色卡截图，AI 根本“看”不出来里面的色值是什么。它需要的是 #1A73E8 这个字符串，不是一个蓝色方块的图片。
第二，设计规范的“规则”通常是散文式的。 比如“不要在一个页面里放太多主按钮”——这句话人类一看就懂，但 AI 很难把它转化成一个可执行的判断。太多是多少？什么算主按钮？什么算一个页面？
第三，知识是碎片化的。 颜色写在第 3 页，间距写在第 7 页，按钮的规范在第 12 页，而按钮用到的颜色和间距需要 AI 自己去关联。这种跨页面的信息拼装，AI 做起来很吃力。
核心思路：把设计决策变成结构化数据
一句话总结：视觉示例给人看，结构化数据给 AI 读。
具体来说，就是把传统设计规范里的每一个设计决策，都翻译成 AI 能精确解析的格式。
那用什么格式呢？我让 Claude Opus 帮我调研了一下，它推荐的方案是：Markdown + JSON + YAML 的组合。其中：
- Markdown 负责描述性的内容：设计原则、使用场景、什么时候该用什么不该用
- JSON 负责精确的数值定义：颜色值、字号、间距、阴影
- YAML 负责组件级的结构化规范：组件的变体、状态、约束规则
为什么不统一用一种格式？因为各有所长。JSON 适合定义纯数据（Design Token），YAML 适合描述有层次的组件规范（因为可读性更好），Markdown 适合写需要段落和叙事的内容（设计原则、模式指引）。
具体分五步来做
1. Design Token 化：把所有“魔法数字”抽出来
传统规范里，设计师说“主色调是品牌蓝”，然后在 PDF 里放一个色块。
AI 友好的方式是把它变成一个 Token：
1 | { |
注意这里不只有色值，还有 usage（什么场景用）和 wcag_aa（是否满足无障碍标准）。这些上下文信息对 AI 来说极其重要——它不只要知道“是什么颜色”，还要知道“什么时候用”和“为什么选这个颜色”。
同理，字号、间距、圆角、阴影、动画时长……所有数值类的设计决策，都应该 Token 化。
2. 组件规范用结构化 Schema 描述
传统规范里，一个按钮组件的描述可能是一页截图加几段说明文字。
AI 友好的方式是用 YAML 写一个完整的结构化定义：
1 | component: Button |
这里面有几个关键设计：
用花括号引用 Token，比如 {color.brand.primary}。这样 AI 在生成代码时，会自动去 Token 文件里查对应的值，而不是硬编码一个色值。整个系统是关联的。
明确列出所有状态。人类设计师可能觉得“hover 状态不用说大家都知道”，但 AI 需要你把它列出来。缺什么它就不做什么。
有变体（variants）和尺寸（sizes）的穷举。 AI 最擅长在有限集合里做选择，而不是在模糊描述里做推断。
3. 把 do/don’t 改写成可执行的规则
这是最关键的一步。
传统规范里的“Don’t”通常配一张错误示例截图，AI 完全看不懂。
AI 友好的方式是把它写成带 ID、有严重等级、能机器检查的规则：
1 | rules: |
这种格式有几个好处：
- 有唯一 ID：AI 审查代码时可以引用“违反了规则 btn-001”
- 有严重等级：error 是必须修的，warning 是建议修的，AI 可以区分优先级
- 有原因：rationale 告诉 AI“为什么”，当遇到边缘情况需要取舍时，AI 能做更合理的判断
- 有正反例：而且是文字形式的，不是截图
4. 提供“AI 入口文件”
你的设计规范可能有几十个文件，AI 不知道该先看哪个。你需要一个 README.md 作为入口，就像给 AI 画一张地图：
1 | ## AI 使用指引 |
这个入口文件告诉 AI 三件事：有哪些文件、每个文件是干嘛的、不同任务应该按什么顺序查阅哪些文件。
5. 设计原则要可操作化
传统规范里的设计原则通常很抽象：“我们追求简洁”。
AI 友好的方式是让原则可操作——不只说“是什么”，还说“怎么用”和“冲突时怎么办”：
1 | ### 清晰优先于美观 |
特别是要提供一个 原则冲突解决矩阵。比如“清晰”和“包容性”冲突时谁优先？“性能”和“一致性”冲突时呢？人类设计师靠直觉判断，AI 需要明确的规则。
推荐的文件结构
说了这么多，最终的目录结构长这样：
1 | design-system/ |
每层的分工很清晰：
- tokens/ 是最底层的原子变量，纯数据，JSON 格式
- components/ 是组件级规范，结构化描述，YAML 格式
- patterns/ 是页面级模式，需要叙事和流程说明，Markdown 格式
一些实操建议
不要一步到位。 你不需要一次把整个设计规范都改造完。可以先从 Design Token 开始——把颜色和字号从 PDF 里抽出来做成 JSON 文件，这一步投入产出比最高。
保持两个版本同源。 理想情况下，JSON/YAML 是“源文件”，PDF 版本从源文件自动生成。这样改一处，两边都更新。如果做不到自动生成，至少保证人工同步。
给每个决策加上“为什么”。 这是很多人最容易忽略的。AI 在遇到边缘情况时，rationale 字段就是它做判断的依据。没有 rationale，它只会机械执行规则；有了 rationale，它能理解意图，做出更灵活的判断。
把规范放到代码仓库里。 设计规范不应该是一个飞书文档或者 Figma 链接，而是一个 Git 仓库里的文件夹。这样 AI 工具可以直接读取，开发者可以在 CI/CD 里做自动检查，版本变更有迹可循。
实际测试。 改造完之后，拿你的 AI 工具（Claude、Cursor、Copilot 等）实际跑一遍：让它基于你的设计规范生成一个页面，看看它是不是真的引用了 Token、遵守了规则。不好使就迭代。
最后
AI 时代的设计规范，本质上是一个 API——它不再只是给人“阅读”的文档，而是给机器“调用”的接口。
格式变了，但设计的本质没变。你仍然需要好的设计判断来决定什么颜色、什么间距、什么交互模式。只是表达方式要变一变：从“让人看懂”升级为“人机双读”。
如果你的设计师不知道如何输出上面的文件，没关系，把这篇文章发给你的 AI Agent（推荐使用 Claude Opus 4.6），然后说：我需要按照文章中的方案来产生一套面向 AI 的设计规范，你来帮我完成，现在你告诉我需要哪些文件和资料，我来负责提供。
放心，AI 会一步一步带着你完成这份规范。
希望对你有用。