写给设计师:如何设计一份 AI 友好的设计规范

在企业面向 AI 转型的过程中，设计师对 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：

{
 "color": {
 "brand": {
 "primary": {
 "value": "#1A73E8",
 "usage": "主操作按钮、重要链接、选中态",
 "contrast_on_white": "4.6:1",
 "wcag_aa": true
 }
 }
 }
}

注意这里不只有色值，还有 usage（什么场景用）和 wcag_aa（是否满足无障碍标准）。这些上下文信息对AI来说极其重要——它不只要知道"是什么颜色"，还要知道"什么时候用"和"为什么选这个颜色"。

同理，字号、间距、圆角、阴影、动画时长……所有数值类的设计决策，都应该Token化。

2. 组件规范用结构化 Schema 描述

传统规范里，一个按钮组件的描述可能是一页截图加几段说明文字。

AI友好的方式是用YAML写一个完整的结构化定义：

component: Button

variants:
 - name: primary
 description: "主操作按钮，页面中最重要的行动号召"
 styles:
 background: "{color.brand.primary}"
 text_color: "#FFFFFF"
 border_radius: "{border_radius.md}"

sizes:
 - name: md
 height: "40px"
 padding: "0 {spacing.md}"
 font_size: "{typography.scale.body-md.size}"

states: [default, hover, active, focus, disabled, loading]

这里面有几个关键设计：

用花括号引用Token，比如 {color.brand.primary}。这样AI在生成代码时，会自动去Token文件里查对应的值，而不是硬编码一个色值。整个系统是关联的。

明确列出所有状态。人类设计师可能觉得"hover状态不用说大家都知道"，但AI需要你把它列出来。缺什么它就不做什么。

有变体（variants）和尺寸（sizes）的穷举。 AI最擅长在有限集合里做选择，而不是在模糊描述里做推断。

3. 把do/don't改写成可执行的规则

这是最关键的一步。

传统规范里的"Don't"通常配一张错误示例截图，AI完全看不懂。

AI友好的方式是把它写成带ID、有严重等级、能机器检查的规则：

rules:
 - id: btn-001
 rule: "同一视图中最多一个 primary 按钮"
 severity: error
 rationale: "多个 primary 按钮导致用户无法识别主操作"

 - id: btn-003
 rule: "按钮文案不超过6个中文字符"
 severity: warning
 examples:
 correct: ["提交订单", "确认删除", "开始学习"]
 incorrect: ["好的", "订单信息", "下一步操作确认提交"]

这种格式有几个好处：

有唯一ID：AI审查代码时可以引用 "违反了规则 btn-001"
有严重等级：error 是必须修的，warning 是建议修的，AI可以区分优先级
有原因：rationale 告诉AI"为什么"，当遇到边缘情况需要取舍时，AI能做更合理的判断
有正反例：而且是文字形式的，不是截图

4. 提供 "AI入口文件"

你的设计规范可能有几十个文件，AI不知道该先看哪个。你需要一个 README.md 作为入口，就像给AI画一张地图：

## AI 使用指引

### 生成 UI 代码时
1. 先读取 tokens/ 中的变量，禁止硬编码颜色/字号/间距值
2. 查找对应 components/*.yaml 获取组件结构和约束规则
3. 查阅 patterns/*.md 确认页面级布局要求
4. 检查 accessibility.md 确保符合无障碍标准

### 审查 UI 代码时
1. 逐条检查组件 YAML 中的 rules 字段
2. 验证 Token 引用是否正确
3. 检查 severity: error 的规则是否被违反

这个入口文件告诉AI三件事：有哪些文件、每个文件是干嘛的、不同任务应该按什么顺序查阅哪些文件。

5. 设计原则要可操作化

传统规范里的设计原则通常很抽象："我们追求简洁"。

AI友好的方式是让原则可操作——不只说"是什么"，还说"怎么用"和"冲突时怎么办"：

### 清晰优先于美观
- **含义**: 用户能否在3秒内理解界面意图，比视觉精致更重要
- **实践**: 信息层次分明，操作路径可预期，文案直白无歧义
- **权衡**: 当装饰性元素影响信息传达时，移除装饰性元素

特别是要提供一个 原则冲突解决矩阵。比如"清晰"和"包容性"冲突时谁优先？"性能"和"一致性"冲突时呢？人类设计师靠直觉判断，AI需要明确的规则。

一些实操建议

不要一步到位。 你不需要一次把整个设计规范都改造完。可以先从Design Token开始——把颜色和字号从PDF里抽出来做成JSON文件，这一步投入产出比最高。

保持两个版本同源。 理想情况下，JSON/YAML是"源文件"，PDF版本从源文件自动生成。这样改一处，两边都更新。如果做不到自动生成，至少保证人工同步。

给每个决策加上"为什么"。 这是很多人最容易忽略的。AI在遇到边缘情况时，rationale 字段就是它做判断的依据。没有rationale，它只会机械执行规则；有了rationale，它能理解意图，做出更灵活的判断。

把规范放到代码仓库里。 设计规范不应该是一个飞书文档或者Figma链接，而是一个Git仓库里的文件夹。这样AI工具可以直接读取，开发者可以在CI/CD里做自动检查，版本变更有迹可循。

实际测试。 改造完之后，拿你的AI工具（Claude、Cursor、Copilot等）实际跑一遍：让它基于你的设计规范生成一个页面，看看它是不是真的引用了Token、遵守了规则。不好使就迭代。

最后：如何落地

如果你的设计师不知道如何输出上面的文件，没关系，把这篇文章发给你的 AI Agent（推荐使用 Claude Opus 4.6），然后说：我需要按照文章中的方案来产生一套面向 AI 的设计规范，你来帮我完成，现在你告诉我需要哪些文件和资料，我来负责提供。

放心，AI 会一步一步带着你完成这份规范。

如果你的AI无法方便地阅读这篇文章，可以把这个链接给他：

https://www.devtang.com/2026/04/11/ai-friendly-design-spec/

希望对你有用。