一家航空公司的设计系统，为什么让AI团队都该抄作业

在这场 Figma Config 的 Deep Dive 里，西南航空展示的不是“好看的组件”，而是一套让设计、开发、文档、协作同时降噪的系统工程。从变量 API 的现场演示，到把文档、无障碍和 Jira 流程全部塞进 Figma，这套做法对所有 AI 团队都是一次认知暴击。

最反直觉的一幕：红蓝按钮不是 Bug，是系统在说话

视频一上来就丢出一个让人皱眉的画面：界面里出现了“疯狂的红蓝按钮”。主持人甚至直接要求现场演示 Figma 的变量 API。按常识，这应该是设计事故，但在西南航空的设计系统里，这是系统故意暴露状态的方式——变量没对齐、Token 没绑定，UI 就会“变丑”。这背后的逻辑很工程化：与其在发布前靠人肉检查，不如让系统在设计阶段就大声报错。对 AI 产品团队来说，这几乎是同一套思路：不要指望 prompt review 或人工验收兜底，而是让系统结构本身减少犯错空间。

“Heart” 不是情怀，是小团队的生存策略

设计系统被命名为 Heart，看起来很温柔，但它解决的问题极其现实：团队人不多。视频里反复提到一个前提——“尽管我们投入的人很有限”。正因为如此，组件文档并没有写成厚重的百科，而是明确只做一件事：定义组件“长什么样”。行为、逻辑、边界条件，交给系统和流程。这种克制对 AI 团队尤其重要：当模型、工具链变化极快时，文档越想包打天下，越容易过期。Heart 的做法是先稳住视觉与规范这一层，其他变化才有承载的基础。

把文档、无障碍和设计放在一个地方，是降本神器

视频里有一个关键追问：当文档也在 Figma 里，是不是所有人终于有了“唯一入口”？答案几乎写在使用习惯上。组件文档、无障碍指南、Token 应用方式，全都和设计稿贴在一起。结果是：开发不再凭感觉手动上色，设计也不需要反复解释对比度或可访问性要求。对 AI 从业者来说，这和把模型卡、评测结果、使用限制直接嵌进工具界面是同一个道理——减少跨工具切换，本身就是生产力。

衡量设计系统成功与否，只看一件事

当被问到“怎么衡量 Heart 的成功”，回答没有任何浪漫色彩：看设计师和开发者是否真的在用，以及是不是更少困惑。尤其是开发侧——不需要再猜颜色、不需要 overnight 手动修 UI。视频中还展示了一个很实用的细节：一次性应用多个设计 Token 的方式。这不是炫技，而是在帮开发省认知成本。对 AI 团队同样适用：评估一套内部工具，不要看功能列表，而要看它是否减少了‘我是不是用错了’的心理负担。

Onboarding、Jira 和“不要让开发猜”

最后的亮点藏在流程里。团队为新成员设计了 onboarding 和练习，甚至带点“pop quiz”的味道，目的只有一个：让预期透明。需求怎么提？不清楚就提 Jira ticket，就是这么简单。视频里一句话特别值得记住：“Nobody wants the developer to be taking a guess.” 这几乎可以作为所有 AI 工程流程的座右铭——无论是模型接口、数据依赖还是评测标准，猜测本身就是浪费。

总结

这场 Deep Dive 真正厉害的地方，不在于某个 Figma 技巧，而在于它展示了一种“系统先于个人”的工作方式。对 AI 从业者来说，设计系统、模型系统、评测系统，本质上解决的是同一件事：如何在不确定性中，把犯错成本前移、把协作摩擦降到最低。一个可执行的行动建议是：回到你自己的团队，找出那些“只能靠经验兜底”的地方，问一句——能不能让系统替人把话说清楚？

关键词： 设计系统， Figma Variables， 跨职能协作， AI团队工程化， 开发者体验

事实核查备注： 需要核查的视频信息包括：视频标题《Deep Dive into Southwest Airlines’ Design Systems | Figma》、发布时间 2025-08-01、主持人 Jay 与嘉宾 Jenny 的姓名拼写、是否确实在视频中演示了 Figma variable API 及设计系统名称 Heart。