设计系统不是把组件库改个名字，而是一套让团队少做重复决定的基础设施。搭建的正确顺序是：先从真实任务里找出反复出现的决定，再把它们固化成变量、组件和页面模式，最后用评审与人工审核保证它不被用坏。AI 可以帮你写草稿、想命名、补文档，但取舍和验收仍然要人来做。
如果组件库已经在用但越来越乱，先解决治理问题会更划算，可参考组件库版本、复用与废弃策略；本文解决的是从零到第一版设计系统的搭建路径。
先回答三个问题，再动手画组件
很多团队一上手就建组件，结果半年后组件很多、复用很少。开始之前先把三个问题写下来：团队最常重复的决定是什么、谁负责维护、什么叫“已经够用”。
| 问题 | 回答不清楚的后果 | 建议的答案形态 |
|---|---|---|
| 最常重复的决定 | 做了一堆没人复用的组件 | 列出近三个月反复讨论的视觉与交互问题 |
| 谁负责维护 | 组件被改坏后无人收敛 | 指定一名设计系统负责人和一名前端负责人 |
| 什么叫够用 | 范围无限扩大，永远完不成 | 明确第一版只覆盖核心页面与高频组件 |
第一步：从真实任务反推要沉淀什么
不要先定规范，先挑一条真实业务链路走通，例如“新建—编辑—审核—导出”。走完之后你会发现，真正重复的不是页面，而是中间那些反复要定义的东西：字段的校验提示、列表的批量操作、状态的表达方式。
把这条链路上出现过的重复决定记下来，就是第一版设计系统的需求清单。相比凭空规划“我们要做一个完整的设计系统”，这种方式范围小、可验收，也更容易在团队里推广。
三层结构：变量、组件、页面模式
三层各解决一类问题，混在一起就会出现“改一个颜色动到十个页面”的情况。
| 层次 | 解决什么 | 产出物 | 谁维护 |
|---|---|---|---|
| 变量 | 颜色、字号、间距、圆角等取值统一 | 语义变量表 | 设计系统负责人 |
| 组件 | 结构、状态与交互规则统一 | 组件规范与组件库 | 设计系统与前端共同维护 |
| 页面模式 | 业务结构、字段与流程统一 | 列表页、详情页、表单页骨架 | 业务线与设计共同确认 |
先做变量还是先做组件都可以，但两者要衔接：组件内部只引用变量，不写死具体数值。变量体系怎么建，可参考什么是设计变量里的变量类型与主题切换做法。
组件规范要写什么
组件规范的重点不是截图，而是读者能照着做判断的信息：有哪些类型和尺寸、在什么场景用哪一版、命名怎么定、状态如何反馈。规范里最好直接给出可对照的示例，让评审时有据可依。
组件的状态覆盖与方法同源：可交互组件至少要交代默认、禁用、加载和失败反馈，这部分清单可直接沿用组件状态与变体清单。
页面模式：把重复的业务结构沉淀下来
页面模式是从真实页面里抽出来的骨架，例如“带筛选的列表页”“分步表单”“带操作日志的详情页”。它比组件更贴业务，比整页模板更灵活，是团队效率提升最明显的一层。
沉淀页面模式时保留结构和字段，不保留具体业务文案：结构可以复用，字段和权限必须按业务重做。需要先补齐组件资源时，可先看后台原型组件库怎么用，再决定哪些结构值得沉淀。
AI 能加速哪些环节
把 AI 放在“产生草稿”的位置最有效：根据已有规范生成命名候选、把零散讨论整理成规范初稿、为同一组件补齐状态说明、把差异对比整理成变更说明。这些工作量大但不涉及最终取舍，适合先出草稿再人工修订。
在墨刀设计里，组件和变量用来统一规范，选中、禁用等状态按需补充，交付前再结合开发者模式核对尺寸、样式与资源；代码生成结果仍需接入真实数据、业务逻辑和接口并完成测试。AI 负责把初稿做快，人负责判断它对不对。
AI 不能替你做的判断
三类判断必须由人负责：一是业务规则，例如什么条件下按钮不可用；二是取舍，例如两个相近组件是否合并；三是验收，例如这版组件是否真的能覆盖核心任务。把这些判断写进评审清单，AI 的产出才会被用起来，而不是变成新的技术债。
评审与人工审核机制
设计系统能不能长期有效，取决于有没有固定的评审动作。建议至少固定三件事：新组件入库评审、破坏性变更通知、废弃组件下线检查。评审不需要长会，但必须有负责人和明确结论。
| 环节 | 审核要点 | 结论形态 |
|---|---|---|
| 入库评审 | 是否达到复用门槛、命名与属性是否对齐实现 | 通过 / 留在页面 / 退回修改 |
| 变更评审 | 影响哪些页面与交付物、是否需要并行期 | 变更清单 + 通知范围 |
| 下线评审 | 引用是否为 0、替代方案与迁移说明是否就绪 | 标记弃用 / 允许移除 |
落地节奏：三个阶段推进
- 第一阶段（打底）：整理语义变量，沉淀 10–20 个高频组件，挑一条业务链路做试点。
- 第二阶段（推广）：补齐页面模式，把试点结论写成规范和检查清单，扩展到第二条业务线。
- 第三阶段（治理）：建立入库、变更与下线评审，用季度清理保持组件库可用。
每个阶段都要有可见产出，否则团队会把设计系统当成一个永远在做的项目。资源层面可以先复用现成的组件库，例如大厂设计系统与组件库资源，再用自己的变量和规范统一表达。
设计系统搭建检查清单
| 维度 | 检查项 |
|---|---|
| 起点 | 从真实任务反推需求，第一版有明确范围 |
| 变量 | 颜色、字号、间距按语义命名，组件只引用变量 |
| 组件 | 类型、尺寸、状态与使用场景写清楚，有可对照示例 |
| 页面模式 | 沉淀结构与字段，业务文案与权限按业务重做 |
| AI 分工 | AI 产出草稿，业务规则、取舍与验收由人负责 |
| 评审机制 | 入库、变更、下线三类评审都有负责人和结论 |
常见问题
设计系统一定要从零开始建吗？
不必。更高效的做法是先复用现成组件库搭建骨架，再用自己的语义变量、命名与规范统一表达；从零开始只适合有明确品牌与交互差异的场景。
团队只有几个设计师，也需要设计系统吗？
需要，但可以极简：先做语义变量和 10 个左右高频组件，再固定入库评审这一个动作。小团队最大的风险不是缺规范，而是重复决定没有被记录下来。
AI 生成的规范初稿能直接用吗？
不能直接用。AI 初稿适合做整理和补充，但业务触发条件、组件取舍和验收标准必须由人确认；把 AI 产出当成待评审的草稿，而不是最终规范。
总结
搭建设计系统的关键是顺序：先回答三个问题，再从真实任务反推需求，按变量、组件、页面模式三层落地，最后用评审机制和人工审核保证长期有效。AI 让草稿更快，人的判断决定它是否可用。
