设计系统搭建月度反思那些理论上正确但实战翻车的决策一、引子设计系统不是在白板上设计的三个月前在 Miro 上画的设计系统架构图——Primitive → Semantic → Component 三层清晰、Token 命名规范漂亮、跨平台同步流程完美。三个月后在实战中验证发现 40% 的设计决策需要修正。这篇文章记录那些理论上正确但在真实团队和真实产品中崩塌的决策。二、5 个翻车决策翻车 1设计了 5 层 TokenPrimitive → Foundation → Semantic → Component → Page五层架构。实施两周后发现从 Page Token 追溯到 Primitive Token 需要穿 4 层引用——调试一个按钮颜色花 10 分钟。缩减到 3 层后开发效率回升 40%。翻车 2MVP 阶段就自研设计系统团队 3 个人产品还没 PMF花 3 个月搭设计系统。最后因为业务调整搭好的 60% 组件都没有上线过。正确做法用 Ant Design 做到 B 轮融资后再考虑差异化。翻车 3设计规范 CI 检查零豁免所有 PR 必须通过设计规范检查才能合并——这条规则在紧急 Bug 修复时成了阻碍。开发者被迫在注释里写// TODO 豁免来绕过检查。加入了正式的豁免机制需要 Tech Lead 审批后CI 通过率从 70% 回升到 95%。翻车 4Figma 是设计系统权威源设计师在 Figma 里改颜色开发者不知道三个月后发现 30% 的 Token 值不一致。修正Git 中的 Token JSON 是唯一权威源CI 自动同步到 Figma用 Figma API 更新 Color Styles。翻车 5一个人维护设计系统唯一的设计系统工程师离职后Token 更新停滞了 6 周。修正设计系统需要至少 2 人共同维护且知识必须文档化不是在这个人的脑子里。三、总结Token 分层 3 层是最佳实践5 层是过度设计MVP 阶段用第三方 UI 库B 轮后再考虑自研CI 规范检查需要豁免机制否则会被开发者绕过Git 中的 Token 文件是唯一权威源Figma 是消费者设计系统维护至少 2 人单点故障风险必须在组建团队时避免资料说明本文中的协议、版本、性能、成本和行业趋势应以可核验的一手资料为准。未标注统计口径的比例、时间表和预测仅作工程讨论不应视为行业事实。可参考 0731 资料来源索引并在发布前将具体来源贴到对应断言之后。