夜雨聆风最近读了 thedesignsystem.guide 的 How I'd build a design system if I started over in 2026，作者是个人订阅 newsletter 的资深从业者。标题里的 "if I started over" 是关键——他不是讲"怎么搭"，是讲"如果重新做，会怎么做"。
他戳到了国内团队最常犯的错：花 6 个月搭组件库，结果没人用。
我之前 #1 那篇讲"组件库 vs 设计系统"就是同一类问题，但这篇角度更狠——它不讲怎么搭，讲怎么避免"搭了一坨没人用"。
他列了 12 个要点，我浓缩成国内团队最该做的 4 件事。看完这篇你会知道：
4 小时搭设计系统的视频为什么不靠谱 设计系统真正的护城河是"品味"不是"工具" AI 时代设计系统最大的机会是"被 AI 读懂" 治理比代码难 10 倍，怎么治
第 1 件事：别再追求"完美的 4 小时搭建设计系统"
原文说"4 小时搭设计系统的视频"是当下最危险的诱惑。国内 YouTube / B 站上一堆"30 分钟搭 Ant Design 二次封装"视频，看起来很爽，但你搭的是组件库，不是设计系统。
作者抛了一组国内很真实的痛点：
代码库里3 个不同的按钮实现（外加 Angular、Vue、jQuery 里的 5 个） 工程师问"该用哪个 Token？"（spacing、color、shadow 全混着命名） 设计系统团队1 个人，被维护请求淹没 高层问"为什么我们 App 跟其他创业公司长得一模一样？"
这 4 个症状本质都是同一个问题：组件库 ≠ 设计系统。
组件库是"按钮长啥样"，设计系统是"什么时候用哪个按钮、为什么"。国内 90% 团队都卡在第一步——做完了组件库，就以为做完了设计系统。
学到啥：
别被迷惑"4 小时搭设计系统"的承诺——那是搭组件库
设计系统是组织问题，不是技术问题——你没在解决"组织治理"前，组件库再完美也没用 先想清楚"为什么做"——是 ToB 复利？是品牌一致？还是被别部门吐槽？目标不同，路径不同
第 2 件事：护城河是"品味"不是"工具"
原文最颠覆的观点是"From tools to taste"。
他列了一个对比：
工具视角是"功能列表"，品味视角是"决策逻辑"。
举个例子：3 个不同的按钮实现问题，从工具视角看是"组件不统一"，从品味视角看是"我们没决定按钮的语义边界"——主按钮 vs 次按钮 vs 危险按钮的视觉权重该多大？什么场景用 ghost 按钮？禁用态该多深？
国内团队最常犯的就是工具视角：把 Ant Design 装上就以为有设计系统了。但你的设计师还在画"按钮边缘的圆角应该是 4px 还是 6px"这种争论——因为你们没记录 rationale。
学到啥：
记录每个设计决策的 rationale——写在文档里，写在 Confluence 上，写在任何业务团队能找到的地方 每季度 review 一次设计决策——半年后回头看，你当年的决定对不对 让设计师写"决策日志"——这是设计系统的"传承"部分 工具是手段，品味是结果——别本末倒置
第 3 件事：让设计系统"被 AI 读懂"
原文提了 "Making your system AI-readable"——这跟我 #1 那篇讲的 MX 设计是同一件事。但作者角度更技术，讲的是"设计系统本身"被 AI 读懂，不只是"产品被 AI 读懂"。
核心思路：2026 年设计师的搜索方式变了。
以前：设计师问"按钮的 border-radius 该用多少？" 现在：设计师问 AI "我们设计系统里按钮的圆角有几种，分别用在什么场景？"
如果你设计系统的文档是 HTML + 结构化数据，AI 能直接答：
"你的系统有 3 种按钮圆角：4px（小卡片）、6px（普通按钮）、999px（圆形头像按钮）。具体用例见 [文档]"
如果你设计系统的文档是 PDF 或扫描图片，AI 答不上。
国内实操：
文档站用 VitePress / Docusaurus（生成结构化 HTML） 每个组件带"语义化标签"（<button class="ds-button ds-button--primary" data-semantic="primary-action">） 每个 Token 带机器可读注释（--button-radius-primary: 6px; /* 用于主操作按钮，圆角半径小，传达稳重感 */） 设计系统元数据走 JSON（不是 Markdown 表）
学到一个反直觉的事：给 AI 写注释比给人类写注释重要。AI 不会"猜"——你要明确写"这个 Token 用于 X 场景，因为 Y 理由"。
第 4 件事：治理比代码难 10 倍
原文说"The governance problem"——这是国内团队 99% 没做好的。
治理是什么？不是写规范，是让规范被遵守。
3 个治理动作：
1. RFC（Request For Comments）流程
每改一个组件、每加一个 Token，先发 RFC，1 周讨论期。
国内实操：
内部用 飞书文档 或 语雀 做 RFC 平台 模板：背景、备选方案、影响范围、决策依据 业务团队 + 设计 + 前端 + 产品都参与讨论 没经过 RFC 的 PR 拒绝合并 2. Adoption 指标
组件库不是"建完就完了"，要看被用了多少。
国内实操：
每周爬一遍代码库，统计每个组件使用次数 用 MasterGo / 即时设计 + 代码扫描，看"设计师在设计稿用了哪些组件 vs 工程师代码里用了哪些组件" Adoption < 60% 的组件——要么是组件本身有问题，要么是文档没写好 每季度发布 Adoption 报告——让业务团队知道自己的代码偏离了多远
3. Deprecation 流程
组件库会老——3 年前写的组件现在没人用，但代码里到处都是。
国内实操：
每 6 个月公布"即将废弃的组件清单" 给 6 个月的迁移期，然后从主包移除 内部用 codemod 工具（如 jscodeshift）做自动迁移 废弃时间表 + 自动迁移工具 = 让业务团队"无痛"升级
国内 99% 团队只做了第 1 步（建组件库），第 2/3 步（用 + 弃）没做。这就是为什么"组件库建了没人用"。
学习曲线幻觉：别觉得"学会了就稳了"
原文提"learning curve illusion"——设计师觉得"我学会了 Figma Variables = 我懂设计系统"是错的。
真相：
Figma Variables 是工具，不是设计系统 Style Dictionary 是工具，不是设计系统 Storybook 是工具，不是设计系统 Ant Design 是组件库，不是设计系统
设计系统是"团队如何做产品决策"的集合。你换了 10 套工具，决策方式没变，设计系统还是 0。
国内最常见：设计师去学 Figma Variables，发个朋友圈"我学会新工具了"——但团队决策方式没变，产出的还是原来那套混乱。
学到啥：
别追工具——追"决策质量" 每个设计决策记录 rationale——这就是设计系统的"知识" 培训团队"决策方式"——比培训"工具使用"重要 10 倍 别误以为"学会新工具" = "变专业"——工具只是表达
2026 年的"做这周"清单
作者给了一个非常实操的"This week"清单，国内团队今天就能开始：
这周做的 4 件事：
写一份设计决策日志：从今天起，每个重要设计决定（颜色、间距、组件结构）记下来——为什么这样、备选方案是什么、什么时候改 让 AI 试试你的设计系统：打开豆包 / Kimi / DeepSeek，问"我们设计系统里 X 是什么"——看 AI 能不能答上来。答不上 = 你的文档不够 AI-friendly 发一个 RFC：选一个组件要改的点，发内部 RFC，1 周讨论期后定稿 看 Adoption 报告：爬一下代码库，看你的组件实际被用了多少
4 件事都做 + 1 个月后，你的设计系统会比"再建 1 套组件库"前进一步大。
国内设计系统团队的 3 个真实挑战
作者没明说，但国内设计系统团队 2026 的 3 个真挑战：
1. 业务方强势，设计系统被架空
国内 ToB 公司业务方权力很大，经常"绕过设计系统"自己画。你发 RFC 没人理，你的 Adoption 报告没人看。
应对：把 Adoption 纳入业务方 KPI——"本年度必须使用设计系统组件 80% 以上"。把"用了"和"没用"做成业务方年终汇报的数据。
2. 跨部门协作，设计系统团队变"客服"
业务方不会自己看文档，全来问设计系统团队——你变成"组件库客服"。
应对：建立"组件库大使"机制——每个业务团队指派 1 个"大使"，负责在本团队答疑 + 收集反馈。设计系统团队不直接对接业务，通过大使。
3. 资源有限，设计系统变成"副业"
国内大部分公司没有"专职设计系统团队"——1 个设计师 + 1 个前端兼职维护。
应对：先把"最小治理"做对——RFC 流程 + Adoption 报告 + 季度 review。3 件事做好了，比加 5 个组件还管用。
结尾：设计系统是马拉松不是短跑
原文结尾写道"In short"：设计系统不是产品，是过程。
国内团队最常犯的错是把设计系统当"项目"——做完就完事。实际它是"持续治理"——永远没"做完"的那天。
我自己的建议是：
小团队（< 10 人）：别建设计系统——直接用 Ant Design / TDesign，把精力放在产品上 中型团队（10-50 人）：建最小设计系统——Token + 1-2 个核心组件 + 文档站。别追求完美 大团队（50+ 人）：设计系统独立团队——设计师 + 前端 + 产品经理 + DevRel。4 个角色缺一不可 别再问"哪个组件库最好"——问"我团队适合什么程度的治理"。答案不同，路径不同。
关于这个话题，我还有一些想聊的，但今天先到这里。如果你在搭建设计系统，或者正在做"该不该建设计系统"的决策，欢迎在评论区给我留言，评论区见。也欢迎告诉我你最想看哪类内容，我来安排。
推荐阅读
