AI在设计系统中的失败之处

对于一个目标通常是稳定、高质量、持久输出的设计系统项目，我们能容忍工具中有多大的不稳定、低质量或短暂性？这是Nathan Curtis和我向设计系统社区提出的问题，用于《问题》第060集（The Question）。

2025年8月21日，Nathan和我深入探讨了从95位设计系统从业者那里收集到的数据。我们只问了两个问题：

你们的组织是否期望在不久的将来使用AI来完成数字界面的生产？
在你的日常工作中，AI在哪些地方过于不精确，无法满足你的需求——它在哪方面让你感到失败？

正如你可能预料的那样，答案是复杂的。在讨论中，我们承认AI在我们流程的一些部分确实非常出色，而在其他一些部分则相当糟糕。结果发现，AI在设计系统中失败的地方可能是我们对AI失败的地方。

1、组织背景

在很多将AI融入设计系统的努力中，AI固有的概率性输出不断与我们的系统必须做出的确定性承诺发生冲突。我们认为设计系统是一种合同——我们对消费者做出的承诺。由于其本质，正在颠覆我们工作的其他领域的大型语言模型非常快速且非常擅长猜测。但我们的承诺并不是猜测。

Jesse很好地表达了这一点：“我们的IT团队想要的是可以从确定性系统中获得的安全保障，这使得随机响应……在安全方面变得困难。”

虽然这并不完全相同，但他使用的短语（“安全保证”）大致对应于我们设计系统最擅长做的事情：建立可靠的模式、经过测试的代码和共享语言，产品团队可以信任这些内容。当你将AI插入流程时，生成答案的系统可能会每次给出不同的回答。在这种情况下，这种多样性意味着信任的削弱。

2、确定性合同 vs. 概率性助手

Nathan谈到同时保持这两种真相——使用AI，但保持合同的确定性：“预测性随机行为与确定性规范之间的平衡就是工作……我可能会用AI来预测数据可能是什么，但系统仍然需要明确的规格。”

他说得对——工作正在从巧妙的提示转向复杂的上下文。其他人称之为上下文工程，其中有很多内容。如果你曾经觉得写提示词可以成为全职工作（嘿，我确实在这样想），那这就不一样了。

工程上下文通常看起来像是整个系统构建必要的数据、边界、指令、输出格式等，以便从系统中得到的结果更加受控。你可以想象一个场景，这些上下文工程系统需要被测试和版本化，特别是随着上下文随时间变化。这为你的RACI矩阵增加了新的行。当然，这是大量的工作。而这正是对话开始转向AI容易实现和挑战的地方。

3、精度的光谱

当我阅读原始数据时，我开始看到你在分享的AI成功和失败中出现了一个模式。你们大多数人可能熟悉双钻石设计过程。

“双钻石是对设计和创新过程的视觉表示。它是描述任何设计和创新项目所采取步骤的一种简单方式，无论使用的方法和工具如何。两个钻石代表一个探索问题更广泛或更深入的过程（发散思维）然后采取聚焦行动（收敛思维）。”

双钻石设计过程——似乎在钻石的发散侧更容易获得成功的AI结果，而不是在收敛侧。

我在你的回答中看到的模式表明，当前一代AI工具在发散任务上帮助起来更容易，而在收敛任务上获得良好的AI结果则更具挑战性。

在左侧，不精确通常是可以接受的，甚至是有益的。在右侧，却不可以。根据原始数据，我听到的内容如下：

发散，AI目前有效的地方：这包括头脑风暴、总结笔记、研究协助、一次性原型和重复性或低风险任务。一位受访者总结道：“它提供了一个快速的起点，并可以自动化一些重复性任务。”（匿名调查回复）

收敛，AI破坏信任的地方：这包括创建生产级代码、严格的设计系统一致性、像素级的视觉决策和可重复性。有人这样说道：“没有人会信任它直接编写可发布的代码，肯定需要适当的审查和测试。”（匿名调查回复）

来自原始数据的其他想法也反映了相同的模式：“Figma Make 不遵守我们的设计系统……即使被提示这样做。”还有，“我们只达到了约80%的准确性……不到100%对我们来说没有意义。”（匿名调查回复）

在组件生成方面，一位受访者直言不讳：“当生成新组件时，它会产生可疑的结果……双重API，非理想的TypeScript实践。”（匿名调查回复）

但你也分享了它真正有帮助的地方：“AI作为搜索引擎和突出最佳实践非常棒”，一位受访者写道，另一位则表示它“帮助自动化简单的任务并加快我们的工作流程。”（匿名调查回复）

4、在AI表现良好的地方投入，尝试在它尚未表现良好的地方进行实验

从讨论、调查和工作笔记中，这是我将带入未来的简单模型：

在AI表现良好的地方投入

发现与探索（头脑风暴、研究、竞争分析）
摘要与初稿（高层次的综合、会议和笔记的总结）
结构化重构（批量重命名、标记差异报告、带有清晰规范的CSS清理）
低风险原型（快速流程以讨论选项，不是用于可用性证据）

在AI尚未表现良好的地方进行实验（目前）

设计系统一致性（“组件/标记必须准确”）
生产代码（“可重复性 > 创新”）
像素级的视觉决策（“品牌语言和空白判断仍失败”）
一致性和可重复性（“你可以多次给AI相同的提示，却得到不同的结果”）

在双方都帮助的方法：

上下文叠加（MCP、RAG、仓库访问，使模型能够看到你的系统，而不是互联网上的通用模型）
合同测试（模式检查、标记 linting、视觉差异等）
去除偏好（基于人类偏好的优化并不总是能带来好的结果）(参见XAI)。

5、一些下一步计划

如果你正在试点或加强你的设计系统程序中的AI，这里有一些你可以立即做的事情，直接从深入讨论和原始数据中提取：

写下合同。 命名你的系统保证的不可协商事项（API、无障碍规则、标记语义等）并为它们设置测试。
在收敛方面严谨。 当你进入使用AI进行收敛任务时，要求严格的检查。如果它触及已发布的系统资产，就必须通过这些测试。
衡量信心。 跟踪AI输出未经编辑就被接受的数量、平均清理时间以及推出后捕获的错误或偏差。这可以成为AI信心债务的衡量标准，这是一个Brandon在深入讨论中使用的术语。
更有意地构建上下文。 例如，你可以用20个从你的产品中提取的正确/错误示例注释一个小的“风格圣经”，并将它作为你上下文的一部分。
问为什么。 当AI未能达到你的期望时，将其纳入你的实践，询问原因——也许挖掘模型依赖哪些设计系统指南来进行故障输出。从长远来看，这可能对你的用户和AI一样有帮助。(参见XAI)。

总而言之，在模型能够保证你的系统所做的承诺之前，AI最好被视为一个协助者，它搭建、加速和提出建议，而不是一个工厂。

6、人类的部分仍然是最难的部分

这一切让我想到AI失败的原因与人类常常失败的原因是一样的。如果没有正确的信息作为起点，成功是非常困难的。

我在我的辅导实践中每天都能看到这一点。我们解决的99%的问题都是人的问题。这并不会因为你在流程中插入了一些出色的AI模型而改变。Murphy Trueman最近写过相关内容:

“我们把精力投入到错误的地方——我们一直解决错误的问题。完美的组件库，精心制作的标记，获奖的详细文档网站。与此同时，团队围绕系统构建，因为使用它比绕过它更容易。”

提醒自己不要忘记你组件另一端的人。

原文链接：Where AI is failing design systems, and where we are failing AI

汇智网翻译整理，转载请标明出处