规范、版本与设计债

先理解这个概念

设计系统需要使用记录、贡献流程、变更说明和淘汰策略。新增组件前先判断现有组件是否能合理扩展；反复出现的例外可能说明抽象错误。升级必须说明对使用方的影响。

设计系统会不断变化，治理的目标是让变化可预测。新组件如何进入、旧组件如何淘汰、例外由谁维护，都比是否有漂亮组件墙更重要。设计债来自已知且未解决的不一致或约束缺口，应记录影响和迁移计划，而不是只列视觉瑕疵。

记住这三个原则

1. 01

   先解决重复频繁且影响大的不一致。

2. 02

   变更附带使用场景、迁移方式与兼容性说明。

3. 03

   定期检查代码与设计稿是否表达同一套规则。

实际设计时，分三步做

1. STEP 01

   定义提出需求的条件：重复场景、现有组件不足和预期使用者。先判断是局部需求还是系统能力。

2. STEP 02

   变更时说明行为与接口影响，区分可兼容调整和需要迁移的改变，并提供明确替代方式。

3. STEP 03

   为例外记录原因、责任与复查条件，定期检查真实使用情况，删除无人使用或被重复替代的能力。

一个容易理解的例子

一致性依赖协作机制，而不仅是一份漂亮规范。

适用边界与取舍

治理过重会让团队绕过系统，过轻则让规则失去意义。小团队可以用简短提案和变更记录，重点是决定可追溯，而不是模仿大公司流程。