设计系统治理与 RFC 流程
贡献模型、变更请求工作流与决策权，维持设计系统健康。
设计系统进阶
为什么
没有治理，设计系统变成无人管理：每个团队加一次性变体，API 表面爆炸，无人知道谁负责什么。轻量 RFC 流程保持系统连贯同时接受贡献。
根据 2024 Spark 设计系统调查，78% 拥有设计系统的组织报告产品交付更快。JavaScript is used by 62% of developers per the Stack Overflow 2024 survey，与设计令牌对齐的组件库将交接时间缩短 60%。
何时使用
当 3+ 团队使用系统时引入治理。早期维护团队直接评审 PR；后期正式化 RFC 委员会带轮换评审者。
如何做
1. 定义所有权 — CODEOWNERS 文件将每个目录映射到维护团队
2. RFC 模板 — 标题、动机、提案、权衡、上线、回滚
3. 分诊 — 小变更（笔误、bug）跳过 RFC；中等需 1 评审者；破坏性需 2 + 委员会
4. 决策权 — 谁可批准令牌 vs 组件 vs 破坏性 API
5. 版本化 — 每个合并的 RFC 发布带 semver 升级的 changeset
6. 弃用路径 — 旧 API 保留 1 个 minor 版本，console.warn + 迁移指南
示例
# RFC：为 Button 增加 `size="xs"`
## 动机
营销落地页需要更密集 CTA；现有 `sm`（32px）对 hero 变体太高。
## 提案
向 Button size 联合增加 `xs`（24px）。复用现有 padding 令牌，无新颜色。
## 权衡
+ 解锁 3 个落地页 PR
- 增加第 4 个 size 需维护；考虑弃用 `lg`
## 上线
- 2.1.0 发布，无 flag（增量、非破坏性）
- 同 PR 更新 Storybook + Figma 组件
## 回滚
回滚安全；尚无消费者依赖 `xs`。
## 评审者
@design-lead @frontend-lead（破坏性？否 → 1 评审者）
常见问题
- ⚠RFC 流程过重 — 每个笔误需 2 周 RFC，贡献者放弃并 fork
- ⚠无 CODEOWNERS — PR 无人评审因无人分配，系统停滞
- ⚠破坏性变更无迁移指南发布 — 消费者升级后全部崩溃
最佳实践
- ✓按风险分层变更 — 笔误/bug 跳过 RFC，增量需 1 评审者，破坏性需委员会 + 迁移指南
- ✓自动化 changesets — PR 改组件无伴随 changeset 时 CI 失败
- ✓发布公开路线图 — 消费者看到即将到来并规划迁移