设计系统：组件、通证和文档中的人工智能 — UI/UX 设计中的人工智能

收益：

能够利用人工智能起草并制定一致的设计标记、组件命名和使用规则
能够利用人工智能快速生成组件文档、做/不做示例和使用文本
能够检查人工智能建议是否与现有设计系统冲突并保留奇点

设计系统是使产品系列外观和行为一致的通用语言：可重用组件（按钮、卡片、表单字段）、设计标记（颜色、间距、版式等值的命名定义）以及解释如何使用它们的文档。一个好的设计系统允许十名设计师设计相同的产品，就好像它是由单一来源生产的一样。安装和维护这个系统是一项劳累、重复、文本密集的工作；这正是人工智能的闪光点。但系统的本质是单一性和一致性；如果不检查与当前系统的冲突，人工智能的建议就不能被接受。

令牌和命名：一致性的基础

设计标记是设计决策的命名的、可重用的值：颜色主色、空间中心、文本标题大写。借助令牌，您可以在一个位置更改颜色并在整个产品中更新它。但代币的力量取决于命名的一致性；如果blue-1、main-blue、primaryBlue混合使用，系统会崩溃。

人工智能在这里擅长两件事：根据一致的命名方案检查现有的令牌集，并为新令牌建议符合架构的名称。诸如“将此标记列表转换为语义（基于含义）命名”之类的请求将帮助您生成传达含义的名称，例如 color-action-primary 而不是 blue-500。但最终的命名决定是球队的合同；该模型仅提供一个轮廓。

提示：在为 AI 命名代币时，请给出 5-6 个当前方案的示例，并说“保持相同的模式”。无样本请求会生成对您的系统来说陌生的名称。

组件文档：AI最具生产力的领域

组件的文档包括：它的作用、何时使用它、何时不使用它、它的变体、状态（默认、悬停、被动、错误）、可访问性注释以及“做/不做”示例。手工编写这些文本需要几个小时，这就是许多团队忽视文档的原因。

人工智能填补了这一空白：当您描述一个组件时，它会以一致的格式生成草稿文档、使用规则以及该做/不该做的示例。这样，文档就从“没有”变成了“有草案，会修复”，这是一个很大的收获。然而，模型并不知道组件的实际行为；您的工作是将其产生的规则与系统的实际情况相匹配。

文档片段

人工智能的贡献

人工验证

它有什么作用？

清晰的轮廓定义

真正适合目的

何时使用

一般场景

产品具体规则

做/不做的例子

快速草稿对

实际滥用情况

无障碍说明

标准提醒

经过实际测试证实

变体/案例列表

可能的清单

那些实际存在于系统中的人

矛盾检查：保留奇点

设计系统的大敌是重复：两个按钮执行相同的工作，两个不同的空间尺度，两个相互冲突的规则。当人工智能建议新的组件或规则时，该建议可能与现有系统相冲突——它不会记住你的整个模型系统。因此，我通过询问“这是否与已经存在的内容冲突？”来评估每个建议。用问题过滤。您还可以在冲突扫描中使用人工智能：您可以提供当前系统摘要和新建议，并列出冲突。但最终的“单一正确”决定取决于团队。

三个迷你箱子

案例 1 — 文件债务已清偿。团队的 24 个组件中只有 6 个有文档。其余 18 个人工智能组件已制定文件草案；该团队在 10 到 15 分钟内修复了每个问题。这项推迟了几周的工作在两天内就完成了。

案例 2——令牌命名变得一致。在一个系统中，颜色混合在一起，如蓝色1、主蓝色、品牌蓝色。 AI 将现有 40 个标记翻译成语义模式；该团队对其进行了修改并改用单一标准。在后续设计中颜色错误明显减少。

情况 3 — 冲突组件被拒绝。 AI提出了一个名为“辅助操作按钮”的新组件。当团队扫描矛盾时，他们发现它的作用与现有的“幽灵按钮”相同，因此拒绝了该建议。教训：并非每个建议都会向系统添加新组件；有时，使用现有的东西是正确的。

可复制的提示

将此标记列表转换为语义（基于含义）命名方案。我当前的架构示例：<<5-6 个示例>>。继续以相同的模式。对于每个标记，给出旧名称 -> 新名称 -> 理由表。列表：<<代币>>

扫描矛盾：我当前设计系统的摘要：<<摘要>>。新提议的组件/规则：<<建议>>。此建议是否与现有系统冲突（执行相同工作的组件、冲突规则、重复令牌）？列出冲突和您的建议。

为此组件生成“做/不做”示例对：现实的正确用法和现实的错误使用场景。对于每一对，用一句话解释为什么它是对/错。组件：<<名称和用途>>

弱提示/强提示

弱：“为这个按钮编写文档。”

结果：与系统无关的通用格式化文本。

强：“按照以下格式记录此按钮（它的作用/何时不使用/变体/案例/可访问性/不该做的事情）；弥补你不知道的行为，写下‘团队必须填写’。”

结果：格式一致、间距适当、可编辑的手稿。

区别：强提示格式+禁止捏造+做/不做提示。

常见错误

请求令牌命名但没有示例。该模型生成的名称对于您的系统来说是陌生的；一致性被打破。
添加组件而不扫描矛盾。重复是系统的大敌。
假设模型发明的行为是正确的。 AI 不知道组件的实际行为。
无需测试即可接受可访问性评级。标准提醒不能替代实际测试。
文档只写一次，不再更新。该文档应随着系统的变化而更新。

综上所述

设计系统是一致性和可扩展性的基础设施；但它的维护经常被忽视，因为它是文本密集型和重复性的。人工智能通过快速生成组件文档、做/不做示例、使用脚本和令牌命名草稿来解决这一问题。但系统的本质是单一性和一致性：每个令牌名称都必须根据样本模式进行验证，每个组件提案都必须进行矛盾扫描，每个行为描述都必须根据现实进行验证。使用模型作为高效的绘图员；团队做出个人正确的决定。

应用任务

选择缺少文档的组件并在第一个提示下生成草稿文档。
用实际行为填写标记为“团队必须填写”的字段。
根据第二个提示，将 8-10 个标记转换为语义方案并创建旧/新名称表。
对于新的组件想法，请扫描与第三个提示的矛盾。
使用第四个提示，为组件生成“做/不做”示例对并将它们添加到系统中。

清单

[ ] 我将令牌命名链接到示例架构。
[ ] 我扫描了新组件是否存在冲突。
[ ] 我用现实验证了模型制作的行为。
[ ] 我计划通过实际测试来确认可访问性注释。
[ ] 我使文档保持一致的格式。
[ ] 我保留了独特性并防止了重复。