详细内容或原文请订阅后点击阅览
设计系统作为AI生成UI的控制平面
AI辅助开发使快速生成前端代码变得更加容易。开发者可以要求一个表单、仪表板小部件、设置页面或模态流程，并在几秒内获得可工作的初稿。这种速度很有用，尤其是当团队快速推进时……
来源:O'Reilly Media _AI & MLAI辅助开发使快速生成前端代码变得更加容易。开发者可以请求一个表单、一个仪表板小部件、一个设置页面或一个模态流程，并在几秒钟内获得可用的初稿。这种速度很有用，特别是当团队在处理常规UI工作时。
但速度会带来一个一开始容易被忽视的问题。如果每个AI生成的功能都引入自己的组件、样式选择、交互模式和无障碍决策，前端很快就会变得不一致。一个产品最终可能会出现错误处理方式不同的表单、行为不同的模态框、看起来差不多但行为不一致的按钮，以及逐渐变得代价高昂的小交互差异。这就是设计系统变得更加重要的地方。
设计系统通常被描述为保持视觉设计一致的方式。它提供共享的颜色、字体、间距、组件和使用规则。这仍然很重要。但在AI辅助工作流中，设计系统可以做的不仅仅是让界面看起来一致。它可以成为AI生成UI的控制平面。
所谓控制平面，我指的是指导界面如何创建、允许哪些模式、以及在每次构建新屏幕时哪些决策不应被重新发明的层。一个强大的设计系统可以对无障碍性、交互行为、内容指引、组件边界和安全默认值进行编码。它为开发者和编码代理提供了一套共享的规则。没有这个层，AI工具就有太多的自由度。
AI生成UI的速度快过团队标准化它的速度
前端团队已经在为一致性而挣扎。即使没有AI，在一个产品中也常常会发现同一模式的多个版本。部分原因是团队快速推进，部分原因是旧代码存留多年，部分原因是人们在没有看到整体系统的情况下解决局部问题。
AI可能加速这一问题。当编码代理被要求构建新功能时，它通常会尝试满足即时请求。如果提示说“构建一个筛选面板”，它可能创建一个在孤立情况下有效但不符合产品其余部分处理筛选、验证、加载状态或键盘行为的解决方案。
这就是风险所在。AI生成的UI在单个拉取请求中看起来合理，同时在产品中悄然增加不一致性。设计系统通过减少需要从头做出的决策数量来提供帮助。问题不应该是“AI能生成一个可用的下拉菜单吗？”更好的问题是“这个功能应该使用现有的下拉菜单模式吗？该模式是否已处理了我们所需的行为？”当答案是肯定的，AI应该组合现有模式，而不是发明新的。
设计系统不仅仅是组件库
许多团队将设计系统视为组件库。这是一个好的开始，但这还不够。组件库为开发者提供可复用的构建块。设计系统还应该解释何时使用这些构建块、它们如何运作、需要什么内容以及携带哪些约束。当涉及AI工具时，这变得尤为重要，因为代理需要的是上下文，而不仅仅是代码。
例如，一个按钮组件不仅是一个样式化元素。它承载着关于层级、状态、标签、禁用行为、加载行为和焦点可见性的决策。一个模态框承载着关于焦点移动、escape行为、标题、可访问名称、背景交互以及关闭时发生什么的决策。一个表单字段承载着关于标签、帮助文本、验证、错误消息、必填状态和程序化关系的决策。
如果这些规则只存在于人们的头脑中，AI工具将不会知道它们。如果它们存在于设计系统中，它们就可以被复用、记录、测试和引用。设计系统成为人类和代理的真实来源。
设计系统为AI提供更安全的默认值
AI生成的代码受上下文影响。如果代理没有项目上下文，它将依赖通用模式和开发者包含在提示中的任何内容。有时这行得通。通常，它产生的代码很接近，但不完全符合产品。
设计系统为代理提供更安全的默认值。团队可以指示其使用现有的模态组件、标准按钮变体、批准的警告模式以及已记录的破坏性操作内容结构，而不是要求AI工具“创建一个确认模态框”。代理仍然帮助组装功能，但风险最大的决策已由系统处理。
这很重要，因为许多UI决策不仅仅是视觉偏好。它们影响人们是否可以使用该产品。一个自定义模态框可能忘记管理焦点。一个自定义按钮可能丢失可见焦点样式。一个自定义表单字段可能视觉上显示错误，但未能将其连接到输入。当生成的界面看起来精致时，这些细节很容易被忽略，而它们正是优秀设计系统组件默认应该携带的细节类型。
项目指令应将代理指向设计系统
提示很有用，但它们不是完整的工作流。如果开发者必须在每个提示中重复每一条设计系统规则，这个过程就会变得脆弱。有人会忘记。有人会写更短的提示。有人会假设工具已经知道标准。
更好的方法是将设计系统期望作为代理持久项目上下文的一部分。对某些团队来说，这可能意味着一个CLAUDE.md文件、一个代理启动文件或另一个项目级指令源。确切机制因工具而异，但原则是相同的：代理应在开始生成功能代码之前了解既定的规则。
这些规则可能包括：在创建新组件之前使用现有设计系统组件，尽可能优先使用原生HTML元素，避免无明确理由使用自定义控件，遵循已记录的表单和模态模式，包含有意义的加载和错误状态，以及遵循项目的无障碍期望。
然后功能提示可以聚焦于任务的独特之处。持久指令描述了团队如何构建UI。任务提示描述了该特定功能需要做什么。这种分离使得AI辅助开发不那么依赖提示质量本身，而更多依赖共享的工程标准。
设计系统可以减少审查负担
当AI生成大量看似合理的代码时，代码审查变得更困难。审查者可能看到一个干净的差异并假设显而易见的决策已被正确处理。但前端质量充满细节，这些细节在快速浏览中并不总能显现。
设计系统可以减少审查者需要手动检查的事项数量。如果功能使用已批准的模态组件，审查者无需每次都重新评估焦点处理。如果表单使用标准的FormField组件，审查者可以更有信心标签、描述和错误消息已正确连接。审查可以从“生成的代码是否正确发明了此模式？”转向“生成的代码是否以正确的方式使用了正确的模式？”
这是一个好得多的问题。它还有助于团队避免每个功能略有不同时发生的缓慢漂移。小的差异在原型中可能不重要。在生产产品中，它们会累积。它们使UI更难维护、更难测试、更难让用户学习。
设计系统应包括行为
对于AI生成的UI，最有用的设计系统是那些清晰记录行为的系统。组件的视觉示例有帮助，但还不够。代理和开发者还需要知道组件在实际情况中应如何行为。
设计系统中的模态页面不仅应显示模态框的样子。它应解释何时使用模态框、何时不使用、焦点应如何表现、需要什么类型的标题以及破坏性操作应如何确认。表单模式应解释标签、帮助文本、验证时机、错误恢复和提交行为。
这些模式记录得越清晰，它们就越容易作为AI上下文使用。该上下文不必完美。它只需要比让代理猜测更好。
更难的部分是纪律性
技术方面只是故事的一部分。当人们不使用、不信任或找不到所需内容时，设计系统就会失败。AI增加了该问题的另一个版本。如果代理无法找到正确的组件或没有足够的上下文来正确使用它，它可能会生成新的东西。这并不总是意味着代理失败了。有时这意味着系统不够容易遵循。
团队需要使正确的路径比错误的路径更容易。组件应可被发现。文档应可读。示例应现实。使用指南应具体。弃用的模式应被明确标记。如果一个组件不应再被使用，代理和开发人员都应该能够看到这一点。
但也存在人为纪律性问题。AI工具不会自动知道哪些不一致对产品很重要、哪些模式值得保护，或者何时一个小的UI变化可能影响那些已围绕现有界面建立习惯的用户。这些决策需要人们在一致性被破坏之前就关心它。如果团队尚未定义这种纪律，AI工具不太可能自行提供。它们可能使生成同一想法的略微不同版本变得更容易，除非团队给它们更清晰的界限。
这并不意味着设计系统应阻止每一个新模式。有时新模式是必要的。但新模式应是有意的、经过审查的，并且如果可复用，最终应纳入系统。没有这种纪律，AI生成的UI可能导致许多“差不多标准”的组件。它们看起来接近系统，但行为不同，这往往使它们比明显的自定义代码更难清理。
前端工程师的角色变得更具架构性
随着AI工具编写更多代码，前端工程不再是逐行手动生产，而是更多关于塑造代码生产的环境。
这包括定义组件API、记录模式、设定无障碍期望、创建项目级代理指令、审查生成的代码，以及决定何时新模式属于设计系统。这些都是影响众多功能的架构决策。
这就是经验丰富的前端工程师变得更加重要的地方。他们理解一次性工作的组件与可安全复用的组件之间的区别。他们知道何时自定义交互值得付出代价。他们知道无障碍问题通常隐藏在哪里。他们能够看出何时生成的解决方案对一个功能有效，但不符合更广泛的前端系统。
AI可以快速生成代码。它不能自行决定一个团队应该拥有什么样的前端系统。
生成界面的控制平面
AI生成的UI只会变得更加普遍，许多团队已经在使用AI构建界面。但这些生成的界面会变得更一致、更可访问、更可维护，还是只会增加另一层漂移？
设计系统可以帮助团队选择更好的路径。当一个设计系统包含清晰的组件、记录的行为、无障碍期望、经过测试的模式和编码代理的持久指令时，它就成为了生成UI的控制平面。它为AI工具提供了界限。它为开发者提供了共享语言。它为审查者提供了可执行的具体内容。最重要的是，它为用户提供了更一致的体验。
AI辅助前端开发的未来将不仅由更好的提示塑造。它将由我们让这些提示在其中工作的系统塑造。
. . .
AI使用声明
AI辅助在本草案的部分措辞、编辑和精简方面被轻度使用。文章的观点、结构、示例和最终审阅均由本人完成。