开放贡献并不等于“任何业务需求都进入组件库”。好的 Contribution Model 会让产品团队带着真实问题和证据参与，同时通过分级、评审、质量门槛和维护责任保护核心系统的长期质量。
设计系统发展到一定规模后，核心团队几乎一定会遇到同一个矛盾：如果所有组件都由核心团队开发，需求排队越来越长；如果完全开放贡献，系统又会迅速塞满只服务单一业务的特殊组件。Contribution Model 的目标，就是在“集中控制”和“完全放开”之间建立可运行的共建机制。
01 一、贡献的起点不是 Figma 文件，而是问题
Carbon 的贡献流程会先让贡献者选择或明确 issue，再细化任务范围并获得反馈。这个顺序很重要。很多失败的贡献一上来就是“我已经画好了一个新组件，请合并”，核心团队只能在最后阶段否决，双方都浪费时间。
更好的提案应该先回答：用户在什么任务里遇到什么问题？现有组件和组合为什么解决不了？这个问题出现在哪些产品？是否有真实使用证据？如果只是单一业务的一次性需求，为什么应该由全公司长期维护？
02 二、先把贡献分成三类，避免所有需求走 RFC
- 修复类：代码 Bug、Figma 错误、文档问题、无障碍缺陷。范围清晰，应该有快速通道。
- 小增强：新增图标、补充示例、增加兼容性属性，不改变现有核心行为。需要双角色评审，但不必开大型评审会。
- 系统级贡献：新组件、新模式、API 破坏性修改、Token 架构调整。必须有完整提案、验证与迁移方案。
Atlassian 当前公开贡献说明也采用类似思想：修复和小增强更容易接受，而新组件或大范围行为改变会影响多个产品，需要系统级协调。
03 三、设计一张真正有用的贡献提案模板
提案模板不应该是“组件名称、负责人、截止日期”三行表格。建议至少包含：问题陈述、目标用户、真实场景、现有方案分析、跨产品复用证据、设计探索、无障碍风险、国际化影响、API 草案、Token 需求、兼容性、测试计划、文档计划和 Owner。
模板的作用不是增加文书工作，而是尽早暴露“这个东西是不是应该进入系统”。如果一个贡献者无法说明谁会复用、如何维护、出现 Breaking Change 怎么处理，那么它更适合作为业务组件。
04 四、在设计之前先做 System Fit Review
核心团队最有价值的介入时间不是最终验收，而是方案还没有固定的时候。可以设置一个 30 分钟的 System Fit Review，只讨论三个问题：是否已有可复用能力；应该组合还是扩展；如果进入系统，公共 API 最小应该是什么。
这样可以避免贡献者花两周把一个不适合系统化的方案做完整后才被否决。Carbon 也建议贡献者在设计和开发过程中持续获得反馈，而不是最后才提交。
05 五、评审要覆盖“长期维护成本”
业务团队通常关注“现在能不能解决问题”，设计系统团队还必须考虑未来：这个组件的状态会不会快速膨胀？是否能在不同密度、主题和语言下成立？API 是否可以稳定？是否需要依赖业务数据？测试成本有多大？当原贡献团队一年后重组，谁来修 Bug？
因此贡献评审不能只做一次视觉评审，而应至少包含设计、开发和无障碍三个维度。复杂模式还需要内容设计、国际化或安全角色参与。
06 六、Definition of Done 是贡献机制的质量底线
一个贡献进入 Stable 前，应有明确完成标准。推荐至少包括：Figma 组件与属性、代码实现、所有关键状态、键盘与焦点行为、测试、响应式规则、内容规则、Token 使用、文档、Storybook 或示例环境、版本变更记录。
如果只合并代码、以后“有空再补文档”，最终文档几乎一定不会补齐。质量门槛必须和合并动作绑定。
07 七、贡献成功以后，谁负责？
“贡献完就交给核心团队”会迅速让核心团队背上所有维护债务。可以建立联合 Ownership：核心团队负责系统一致性和发布基础设施，领域贡献者或业务团队在一定周期内承担领域问题响应。对于非常专业的能力，例如数据可视化或 AI 交互，可以建立长期 Guild，而不是要求核心团队掌握所有细节。
08 八、贡献不等于永远进入 Core
可以设置不同层级：Core、Community / Labs、Product-specific。复用证据还不足的新能力先进入 Labs，让真实产品验证；使用稳定且覆盖多个团队后再晋升 Core。这样比“要么拒绝、要么永久维护”更灵活。
09 九、如何避免贡献流程变成官僚主义？
关键是风险分级。文档错字不应该填十页 RFC；新组件也不应该在群里一句“LGTM”就合并。用清晰的贡献类型决定审批深度，同时公开状态、Owner 和预计反馈时间。流程越透明，业务团队越愿意参与。
10 十、衡量 Contribution Model 是否有效
可以关注：贡献从提交到首次反馈的时间、合并周期、来自核心团队之外的贡献比例、被拒绝的主要原因、贡献后 6 个月的采用情况、贡献组件产生的缺陷和支持成本。最关键的是观察业务团队是否愿意在问题早期找系统团队合作，而不是做到最后才“申请入库”。
好的贡献机制不会让设计系统变得更松散。恰恰相反，它把过去隐藏在私聊和临时协作里的共建过程，变成公开、可复用、可追踪的组织能力。
常见问题
设计系统贡献一定要走 RFC 吗？
不需要。只有新组件、破坏性变更等高影响贡献才值得完整 RFC。文档修复和小增强应该提供快速通道。
业务组件和系统组件怎么区分？
看复用范围和长期稳定性。只服务单一流程、强依赖业务数据且变化频繁的能力通常更适合留在产品层。
核心团队可以拒绝贡献吗？
可以，而且应该透明说明原因，例如已有替代方案、复用证据不足、维护成本过高或不符合系统原则。
贡献者必须同时会设计和代码吗？
不必。可以由设计师、开发者或内容设计师发起，但系统级贡献最终需要跨职能协作完成完整交付。
怎样鼓励更多人贡献？
降低小贡献门槛、明确模板、提供 Office Hours、快速首次反馈并认可贡献者，比单纯号召“大家来共建”有效得多。
相关服务与进一步咨询
链接复制成功
