Figma Config 2025最反直觉一幕：设计系统不是给设计师用的

在这场 Config 2025 的分享里，Bharat Batra 和 Noah Silverstein 抛出一个让人不安却真实的判断：如果你的设计系统只存在于 Figma，它已经失败了一半。这不是一场炫功能的演示，而是一次关于“AI 时代设计系统该住在哪里”的重新定义。

最反直觉的开场：设计系统最大的敌人不是不统一，而是“各自为政”

大多数团队以为设计系统的问题是“不够规范”，但 Bharat 一上来就把矛头指向了更深层的痛点：信息被切得太碎。设计在 Figma，文档在 Notion，决策在 Slack，流程在 Jira——每个团队、每个角色，都活在自己的工具孤岛里。

这直接导致一个结果：设计系统看起来存在，但实际上没人真正“生活在”里面。工程师找不到最新规范，产品经理不知道组件的真实使用边界，设计师自己也在不同文件之间来回横跳。Bharat 的原话很直接：当信息和流程不在同一个地方，协作就注定是高摩擦的。

这也是他们反复强调“central place”的原因。不是再造一个设计工具，而是让设计系统成为团队真实工作的中心，而不是一个被偶尔翻看的资源库。

KOD 想做的不是工具，而是设计系统的“操作系统”

在 Noah 的定义里，KOD 并不是另一个文档平台，而是一个承载设计系统、流程和知识的中央平台。这个定位很微妙：它不和 Figma 竞争，而是试图把 Figma、文档、讨论、决策全部“拉”到同一个上下文里。

视频中他们展示了三种典型用法，每一种都指向同一个目标：减少上下文切换。Figma Embed 让设计稿直接成为文档的一部分，而不是一个冷冰冰的链接；FigJam Widget 把讨论过程本身沉淀为长期可用的团队知识；Figma Pack 则让设计资产真正进入产品和工程文档的工作流。

这里的关键信号是：设计系统不再只是“给设计师用的组件库”，而是跨角色共享的工作语言。谁能掌控这个语言，谁就能决定协作的效率。

当设计系统遇到 AI：数据第一次“像同事一样”被使用

真正让 AI 从业者竖起耳朵的，是后半段关于数据和智能的讨论。当所有设计、组件、文档和决策都集中在一个地方，AI 的角色才第一次变得现实。

他们没有大谈模型参数，而是用一个非常工程化的比喻：当数据足够结构化、足够集中，用户和系统交互的方式会发生质变——你不是在“查资料”，而是在“问一个同事”。

这句话的分量在于，它暗示了 AI 在设计系统里的真实价值：不是生成几个组件，而是理解上下文、历史决策和团队习惯，并在正确的时间给出可用的答案。前提只有一个：你的设计系统，必须真的承载了这些信息。

一个被低估的信号：网站变漂亮不是重点，协作变顺才是

演示的最后，他们轻描淡写地说了一句：现在网站更漂亮了。但如果你回看整个分享，会发现这几乎是最不重要的结果。

真正的变化在于，设计、产品、工程开始围绕同一个“真相源”工作。设计系统不再是一个需要推广的东西，而是自然被使用的基础设施。这也解释了为什么他们一开始就在讲 adoption（采用率），而不是 aesthetics（美感）。

在 AI-first 的语境下，任何不能被机器理解、不能被跨角色复用的系统，都会迅速失去价值。这场分享本质上是在提醒大家：别等 AI 来了，才发现你的设计系统喂不动它。

总结

这场分享给所有 AI 和设计系统从业者留下了一个清晰的 takeaway：未来的竞争，不在于谁的组件更漂亮，而在于谁的系统更“可被理解”。如果你的设计系统仍然只是 Figma 里的文件，它既帮不了团队，也喂不了 AI。下一步你可以做的，不是重画组件，而是审视：你的设计决策、使用记录和讨论，是否真的在同一个地方被保存和复用？这个问题，决定了你是否已经站在 AI-first 的起跑线上。

关键词： Figma Config 2025， 设计系统， AI First， KOD， 协作平台

事实核查备注： 需要核查：Bharat Batra 的职位与背景；KOD 是否已被 Grammarly 收购；视频中关于“central platform”的原始表述；Figma Embed、FigJam Widget、Figma Pack 的具体命名与功能描述；发布时间 2025-06-02