每个设计系统的开头都差不多：几个人坐在一起，拉出一份颜色与字号的清单，建一个 Figma 库，再开一个组件仓库。前两个月一切顺利。第三个月开始，有人绕过它做需求；第四个月，它变成了「那个旧库」。
我参与过三次这样的重建。第一次以为是组件覆盖率不够，第二次以为是文档写得不好，第三次才慢慢看清：崩塌的从来不是组件，而是围绕组件做出决策的那套关系。
崩塌通常不是技术问题
最典型的一次，是按钮组件缺一个「次要危险」状态。设计师在 Figma 里画了一个新样式，前端在业务代码里写了两行覆盖。两周后，另一个页面也遇到同样的需求，又复制了一遍。三个月后，仓库里出现了七种红色按钮。
表面上看，是组件不够用。真正的问题是：没有人知道该找谁加这个状态，也没有人知道加了之后会不会破坏别的页面。于是绕过系统，成了当时最理性的选择。
组件库的敌人从来不是需求变化，而是模糊的所有权。
一次内部复盘的结论
当「谁能改」和「改了谁负责」都不清楚时，系统就不再是一个可以依赖的契约，而只是一份可选的参考实现。
组件是结果，决策才是资产
一个按钮的圆角是 4px 还是 6px，本身并不重要。重要的是为什么选它，以及在什么情况下可以偏离。设计系统真正保存的，不是那几十个组件，而是一连串被明确过的判断：
- 为什么全局只有一个强调色，而不是每个业务线一个；
- 为什么表单控件不提供「超大号」，即使某个页面确实想要；
- 为什么空状态必须包含下一步动作，而不能只放一张插画；
- 为什么危险操作永远需要二次确认，即使它看起来很明显。
这些规则如果没有被写下来，下一次讨论就会从头再来。而每一次从头再来，都会消耗掉一点团队对系统的信任。
给决策留下位置
我们的做法很朴素：给每个 token 和关键组件建一份「决策记录」。不用很长，三句话就够——它解决什么问题、为什么不是另一种方案、什么时候应该重新考虑。
代码本身也可以承担一部分记录的责任：
/* tokens/color.css */
:root {
/* 强调色只用于「需要被看见的动作」，
不用于装饰，也不用于品牌表达。 */
--accent: #9d3f2b;
/* 文本层级只有三级。
如果需要第四级，先检查信息架构。 */
--ink: #1a1917;
--ink-soft: #5b564d;
--muted: #8a8377;
}注释不是文档的全部，但它是离代码最近的那一部分。一个新人改到这里时，会先看到这句话，再决定要不要加第四级灰色。
另一个变化，是把「发起变更」的成本降下来。我们设了一个每周三下午的 30 分钟窗口，任何人都可以带着一个具体问题来。能当场决定的就当场决定，不能决定的明确告诉对方：谁在什么时候给答复。听起来很轻，但它把大量私下绕过系统的行为，重新拉回了桌面上。
三个月检查清单
如果你的系统正在第三个月附近，可以问自己四个问题：
- 新同事能在 30 分钟内搞清楚，一个组件为什么长这样吗？
- 最近一次绕过系统，是因为缺少能力，还是因为流程太慢？
- token 的命名描述的是外观，还是用途？
- 谁有权说「不」？这个人在不在讨论现场？
四个问题里如果有两个答不上来，问题大概率不在组件数量上。先别急着加新组件，去把决策的路径补上。
系统也需要被维护关系
后来我不再把设计系统当成一个交付物。它更像一段需要持续维护的关系：有人提出需求，有人做出判断，有人记录原因，也有人定期回来看看那些判断是否仍然成立。
组件会过时，token 会改名，工具会换。但只要「为什么」还留在原地，下一个人就能接着往前走，而不是从废墟里重新开始。
三个月不是诅咒。它只是一个提醒：如果你只建了组件，没有建那条做决定的路径，那么第三个月发生的事，其实在第一个月就已经写好了。