设计系统不是产品，而是一种服务：这场演讲点醒了无数AI团队

如果你还把设计系统当成一套组件库，这篇文章可能会让你不太舒服。来自 Figma Config 的一场演讲提出了一个反直觉的观点：设计系统一旦被当成“产品”，就已经走偏了。真正能规模化的设计系统，必须被当成一种服务来运营。

最反直觉的开场：设计系统失败，往往不是因为设计

演讲一开始，Declan Talbert 就抛出一个让人警醒的判断：设计系统的问题，几乎从来不是 UI 或组件质量不够，而是它被“放错了位置”。

在大多数组织里，设计系统被默认归属在设计师和开发者名下：一套组件库、一些 Figma 文件、再加点 GitHub 文档。看起来很专业，但结果往往是——只有设计和开发在用，其他团队完全不知道它的存在。

这直接带来两个后果：第一，设计和开发团队被迫成为“布道者”，既要做系统，又要到处解释；第二，系统的影响力被锁死，组织层面的认知和采用率极低。Declan 用一句话点破本质：当设计系统被当成“产品”来交付，它就天然是封闭的；只有当它被当成“服务”，它才会主动向外生长。

这个观点对 AI 团队尤其刺耳。我们习惯把平台、工具、规范都产品化，却很少问一句：有没有人真的被服务到了？

一个小团队的真实困境：为什么“我们忙到没法规模化”

Declan 的案例并不来自硅谷，而是伦敦艺术大学（University of the Arts London）。这本身就很有说服力——如果连高度分散、流程传统的大学组织都能推动变革，那问题显然不在“行业不适合”。

他们的数字团队规模很小，却要同时负责 5 个产品，还要为全校 26 个部门提供 UX、开发、内容和无障碍方面的支持。熟悉吗？这几乎就是很多 AI 基础设施团队的日常：需求爆炸，人永远不够。

关键转折点在于，他们意识到：继续“自己做”，只会被活活拖垮；唯一可行的扩展方式，是提升其他团队使用设计系统的能力和信心。于是目标发生了根本变化——不是让更多人“用我们的系统”，而是让更多人“学会像我们一样思考和工作”。

这也解释了为什么 Declan 一再强调教育、知识共享和协作。设计系统不再只是交付物，而变成了一种组织能力的放大器。

从组件库到能力网络：设计系统如何变成“服务”

当设计系统被重新定义为服务，内容立刻发生了变化。

它不再只包含按钮、模板和颜色，而是开始吸纳原本被排除在外的模块：无障碍规范、项目管理方式、研究报告、工作流程指导，甚至是“如何协作”的方法论。换句话说，它开始服务的不只是界面，而是整个工作过程。

更重要的是“谁能参与”。Declan 明确指出，传统模式下，业务分析师、项目经理、政策制定者、内容和市场团队，几乎无法使用设计系统；而服务化之后，这些角色被系统性地 onboard 进来。

Figma CEO Dylan Field 的那句评价在这里显得格外精准：“设计师正在打开自己的过程，欢迎非设计师共同编辑、共同创造。”这不是理想主义，而是一种现实策略——当更多角色理解并使用系统，设计团队反而可以减少介入。

对 AI 团队来说，这几乎是同一道题：模型、工具、规范如果只掌握在少数专家手里，扩展一定会失败。

为什么这件事，对AI从业者格外重要

把视角拉回 AI 行业，你会发现几乎一模一样的结构性问题。

我们有模型库、Prompt 规范、评测框架、内部平台，但它们往往只对“懂行的人”友好。结果是：AI 团队被当成内部外包，永远在救火；而真正的业务团队，既不理解系统，也不敢用。

Declan 的核心启发在于：规模化的关键，不是把系统做得更复杂，而是让更多人“敢用、会用、能贡献”。这需要服务思维——持续教育、低门槛参与、明确反馈通道。

当设计系统可以被看作一种服务，AI 系统同样可以。不是“我们交付了一个平台”，而是“我们在持续提供能力”。这两者，决定了组织最终能走多远。

总结

这场演讲真正击中人的地方，不在于设计，而在于组织。设计系统作为服务，本质是在回答一个更大的问题：你是想交付成果，还是想放大能力？

对 AI 从业者而言，下一步值得思考的是：你所在团队的系统，是不是只对专家友好？有没有被当成一种“内部服务”来运营，而不是一次性交付？

如果答案是否定的，那么也许该换个角度了——不是再造一个更强的系统，而是开始教更多人，如何真正用好它。

关键词： 设计系统， Design System as a Service， Figma Config， 组织协作， AI团队规模化

事实核查备注： 需核查：1）演讲者姓名 Declan Talbert 拼写；2）视频发布时间 2020-10-15；3）Figma CEO Dylan Field 引用原话准确性；4）University of the Arts London 的组织结构描述是否与演讲一致