组件只是载体，真正的难点是让「什么时候该用、什么时候不该用」成为团队共识。
我们曾经以为把组件库建起来就解决了问题。三个月后，同一个项目里出现了四种不同样式的空状态和三种按钮层级——组件都在，但没人记得该用哪个。
参与一个中大型项目的设计师有三到四位，前端有五到六位，周期跨四个月。人员轮换时，新加入的人面对几十个组件，只能凭截图猜用法。
结果是：每个组件都被「合理使用」，但组合出来的界面并不一致。问题不在组件质量，而在使用规则缺失。
回答「我们为什么这样设计」——例如：重要操作只允许有一个主按钮，破坏性操作必须二次确认。
回答「用什么」——可复用的界面单元与状态，覆盖空态、加载、错误与禁用。
回答「什么时候用、什么时候不该用」，并给出反例。这一层最容易被跳过，也最决定成败。
我们把组件的属性直接映射为前端 props，并在 CI 里加了两条检查：禁止直接使用色值字面量，禁止新增与已有组件重复度超过 70% 的样式块。听起来严格，实际减少的是反复的视觉评审。
设计系统如果只有 Figma 版本，那么它只是一份参考图；只有同时存在于代码里，它才是一条约束。
一年后再看这套系统，最有价值的不是那 40 多个组件，而是那十几条原则和每个组件下面的反例。组件会被替换，判断标准不会。
告诉我们所在行业与业务阶段，我们提供对应的交付路径与周期参考。
