一场设计系统问答，意外点醒了AI团队最容易忽略的底层问题

这不是一场炫技的设计大会问答，而是一群一线实践者在复盘真实踩坑：设计系统如何落地、如何被团队真正使用、以及当复杂性失控时，为什么“简单”反而是最难的事。对AI团队来说，这些经验几乎是镜像级的启示。

最反直觉的一点：设计系统越成熟，越容易“失控”

在这场 Schema 2022 的 Q&A 里，一个被反复提到却很少被公开讨论的问题是：当设计系统走到一定规模后，问题不再是“有没有”，而是“有没有人在正确地用”。

来自 Uber 的 Hiroshi 提到，他们已经拥有相当成熟的体系，但真正的挑战变成了治理：组件越来越多、适配场景越来越复杂，而设计师和工程师的理解并不总是同步。这里有一句很值得记住的隐含判断——系统本身并不会自动带来一致性，一致性是被持续“运营”出来的。

这对 AI 团队尤其刺耳。我们总以为：模型、工具、平台一旦搭好，效率自然会上来。但现实往往是：Prompt 风格分裂、评估标准不统一、Demo 各自为战。设计系统的“失控”，本质上和 AI 工作流的失控一模一样。

加入新团队的“前置期”，决定系统能活多久

Lauren 分享了一个很少被写进方法论的阶段：加入新公司、或新团队的 pre-phase（前置期）。这个阶段不是急着画组件、定规范，而是理解已有文化、决策方式和隐形规则。

她强调，如果在这个阶段就试图“空降一套完美系统”，几乎注定会失败。因为系统不是文档，它是一种协作方式的外化。

放到 AI 语境里，这对应的是模型或平台落地前的“组织准备度”。如果团队还没有共识：什么算好结果？谁对输出负责？什么时候可以推翻模型结论？那再先进的 AI 体系，最后也只能变成少数人的玩具。

组件、子组件、再到自由度：人真正抗拒的不是新工具

Nathan 的话点出了另一个关键矛盾：当你引入更细粒度的组件和子组件时，你以为是在提高效率，但很多设计师感受到的却是“自由被拿走了”。

他观察到，适应这种变化需要时间，因为人并不是抗拒系统，而是抗拒在不理解收益之前就被迫改变工作方式。

这对 AI 产品的启示非常直接。无论是引入自动生成、智能推荐，还是 Agent 工作流，真正的阻力往往不来自技术，而来自心理预期的落差——我是不是被替代了？我还能掌控结果吗？

好的系统设计，必须让人逐步感受到：约束不是限制，而是换取更大规模自由的门票。

被反复追问的三个词：简单、可访问、可持续

在来自 Twitter 的提问中，“Simplicity is the key” 被直接点名。这不是口号，而是一种长期成本意识。

讨论无障碍（accessibility）和动效（motion）时，嘉宾们强调：设计系统必须允许被测试、被关闭、被替代。能在没有动效、通过屏幕阅读器的情况下成立，才算真正健壮。

这其实是高级系统思维：不是为“理想用户”设计，而是为“最苛刻条件”设计。

对 AI 从业者来说，这几乎是一个预言式提醒——如果你的系统只在 Demo 数据、理想输入下表现良好，那它迟早会在真实世界里崩溃。

激励机制，才是系统能不能长大的分水岭

当话题转向“如何激励贡献”时，讨论变得异常具体。是否奖励？如何明确贡献边界？谁来维护质量？

一个重要共识是：如果贡献是额外负担，而不是被认可的工作成果，系统一定会停止进化。

这和开源社区、也和 AI 内部平台建设高度一致。没有清晰激励的系统，最终都会变成“只读文档”。

总结

这场看似围绕设计系统的问答，本质上讨论的是复杂技术如何在人类组织中长期存活。对 AI 从业者来说，最大的 takeaway 不是某个具体做法，而是一个判断标准：你的系统，是否真的在帮助人做决策、而不是制造新的负担？

如果你正在搭建 AI 工具、平台或流程，不妨反问三个问题：它是否足够简单？是否能在最差条件下工作？是否有人愿意持续为它负责和贡献？

设计系统踩过的坑，AI 正在一个不落地再走一遍。提前看懂这些信号，可能就是你领先半步的机会。

关键词： 设计系统， Schema 2022， 团队协作， 复杂系统治理， AI落地

事实核查备注： 需要核查：Schema 2022 举办时间；Hiroshi 是否来自 Uber；各位发言者的具体原话是否为转述而非逐字引用；讨论是否确实来自 Twitter 提问。