设计系统搭建月度反思：那些"理论上正确但实战翻车"的决策

一、引子：设计系统不是在白板上设计的

三个月前在 Miro 上画的设计系统架构图——Primitive → Semantic → Component 三层清晰、Token 命名规范漂亮、跨平台同步流程完美。三个月后在实战中验证，发现 40% 的设计决策需要修正。这篇文章记录那些"理论上正确"但在真实团队和真实产品中崩塌的决策。

二、5 个翻车决策

翻车 1：设计了 5 层 Token

Primitive → Foundation → Semantic → Component → Page，五层架构。实施两周后发现，从 Page Token 追溯到 Primitive Token 需要穿 4 层引用——调试一个按钮颜色花 10 分钟。缩减到 3 层后，开发效率回升 40%。

翻车 2：MVP 阶段就自研设计系统

团队 3 个人，产品还没 PMF，花 3 个月搭设计系统。最后因为业务调整，搭好的 60% 组件都没有上线过。正确做法：用 Ant Design 做到 B 轮融资后再考虑差异化。

翻车 3：设计规范 CI 检查零豁免

"所有 PR 必须通过设计规范检查才能合并"——这条规则在紧急 Bug 修复时成了阻碍。开发者被迫在注释里写"// TODO 豁免"来绕过检查。加入了正式的豁免机制（需要 Tech Lead 审批）后，CI 通过率从 70% 回升到 95%。

翻车 4：Figma 是设计系统权威源

设计师在 Figma 里改颜色，开发者不知道，三个月后发现 30% 的 Token 值不一致。修正：Git 中的 Token JSON 是唯一权威源，CI 自动同步到 Figma（用 Figma API 更新 Color Styles）。

翻车 5：一个人维护设计系统

唯一的设计系统工程师离职后，Token 更新停滞了 6 周。修正：设计系统需要至少 2 人共同维护，且知识必须文档化（不是"在这个人的脑子里"）。

三、总结

1. Token 分层 3 层是最佳实践，5 层是过度设计
2. MVP 阶段用第三方 UI 库，B 轮后再考虑自研
3. CI 规范检查需要豁免机制，否则会被开发者绕过
4. Git 中的 Token 文件是唯一权威源，Figma 是消费者
5. 设计系统维护至少 2 人，单点故障风险必须在组建团队时避免

资料说明

本文中的协议、版本、性能、成本和行业趋势应以可核验的一手资料为准。未标注统计口径的比例、时间表和预测仅作工程讨论，不应视为行业事实。可参考 0731 资料来源索引，并在发布前将具体来源贴到对应断言之后。