AI Agent 可以生成界面代码，也可以参与布局、组件和交互方案的设计。要让这些产物适合实际使用，需要把用户任务、视觉方向、操作状态和项目规范一起交给它，并检查最终实现是否兑现了这些要求。

用 AI Agent 做 UI/UX 设计，可以按“明确任务 → 确定视觉方向 → 定义交互状态 → 固化设计规范 → 实现与验证”的流程推进。 审美需要具体的设计选择，交互需要完整的任务路径，规范则让这些决定在多个页面和多轮修改中持续生效。

本文面向使用 Agent 开发网页、后台和工具界面的开发者。以作者构造的任务管理页面贯穿说明，结合公开设计系统与无障碍资料，讨论设计说明、实现和审查。图示与规范片段均为原创教学示例；UX Engine 仅作工具案例，本文没有安装或运行其付费插件，也没有进行有无插件的效果对照实验。

明确用户任务与界面范围

UI（用户界面）包含文字、颜色、控件和布局等可感知、可操作的呈现；UX（用户体验）的讨论还要覆盖用户如何理解任务、完成操作和处理问题。两者会在具体设计中相互影响：按钮的位置和样式影响发现与选择，失败后的提示和恢复方式也需要通过界面表达。

给 Agent 下任务前，先说明用户、场景、内容和平台。一个供运营人员高频使用的批量任务后台，与面向首次访问者的产品介绍页，通常需要不同的信息密度和视觉重点。网页、桌面程序和原生手机应用也有各自的组件与平台约定，不能仅凭一张参考图复用全部交互。

本文的教学案例是一页导出任务管理界面：用户创建导出任务，查看正在执行的任务，并处理失败项。页面展示任务名称、状态、创建时间和当前可用操作。示例中的设计目标是让用户看清哪些任务需要处理，并找到下一步。

这个目标会影响后续决定：执行失败的任务需要明确的恢复入口；运行中的任务需要说明状态；完成的任务可以提供下载结果。界面是否需要大幅装饰、统计卡或侧栏，应由这些任务和实际内容决定。

把审美要求变成具体设计选择

“高级一点”“更简洁”“不要像模板”可以表达偏好，但不足以决定字号、信息密度和组件关系。给 Agent 的视觉要求应继续说明：希望形成什么气质、哪些内容优先、参考中的哪些特征值得保留，以及哪些既有样式需要沿用。

排版与层级：先安排阅读顺序

在任务页面中，可以让页面标题先说明位置，让任务名称承担内容识别，让状态和操作说明帮助决策，再将时间等辅助信息放到次一级。层级可以通过位置、字号、字重、颜色与留白共同表达，不需要让每个区域都争夺注意力。

对这一教学页面，我会先采用克制、清晰的工具型排版：正文使用易读的常规字重，任务名适度强调，标题与内容之间保留明显分组。中文字体回退、长任务名、数字与英文混排也要进入样张，而非只用几条整齐的短占位文字。

Carbon 的排版文档将字号、字重和行高组合为可复用样式，并区分产品界面与更具表现力的内容场景。可以借鉴其建立层级的方法；字体和具体尺寸仍应按产品需求选择。

留白与密度：让相关内容形成分组

任务名与它的状态应被看成一组，不同任务之间则要有足够区分。若组件之间的距离比同组内容的距离还小，用户就需要额外判断信息属于哪里。

可以先选择一组间距值，再约定组内、组间和页面边缘分别使用哪些值。这样既便于 Agent 实现，也方便发现例外。高频后台可以保留较高密度，但应优先减少无用字段、重复标签和装饰占位，再决定是否收紧行距与空间。

Carbon 的间距系统用间距令牌支持布局一致性，并通过距离表达关系和层级。它提供的是一种具体设计系统的做法，不意味着所有项目都必须采用同一组数值。

色彩与材质：解释每一种强调的用途

可以为页面背景、内容表面、主要文字、辅助文字、主要操作和危险操作分别定义角色。品牌强调色与状态色也需要区分，避免让“品牌使用绿色”与“任务执行成功”在同一处产生含义冲突。

状态应有文字或其他明确线索，不能只依赖色差；阴影、描边、圆角和渐变也应承担分组、层次或品牌表达的作用。统一使用大圆角不自动等于有质感，完全去掉装饰也不自动等于专业。

可读性有可核对的要求。例如，WCAG 2.2 的文本对比度解释说明了普通文本、大文本及相关例外。检查时需要核对实际前景和背景，而不能仅凭“看起来颜色够深”。至于偏好温暖还是冷静、紧凑还是舒展，仍要结合产品定位与目标用户讨论。

图标、图片与动效：保持同一种表达

图标的线宽和尺寸应协调，重要操作优先使用明确名称；图片或插画需要与产品内容建立联系。动效可以帮助理解展开、排序或反馈的变化，但应控制等待成本，并考虑减少动态效果的用户偏好。

向 Agent 指定参考时，可以写“参考这张页面的低饱和背景、紧凑列表与明显标题层级”，再补充希望保留的项目组件。这样比要求完整复制某个知名产品更容易讨论取舍，也能保留自己的产品气质。

原创任务页面设计示意：排版层级、间距分组、语义色彩与任务操作分别对应可检查的设计决定
原创设计示意：把审美要求对应到排版、空间、色彩与操作。图中内容为虚构教学样张，不是 UX Engine 的生成结果或产品实测截图。

让交互体验覆盖完整任务

视觉方案需要与任务状态一起设计。列表、按钮和提示文案应当反映系统当前能做什么，而不只是填满页面上的位置。

场景 用户需要知道什么 教学页面的处理方案
首次加载 内容尚未返回，页面在工作 保留布局结构并表达加载状态；不提前显示“没有任务”
尚无任务 为什么为空，怎样开始 说明任务用途，提供创建任务入口
搜索无结果 当前条件没有匹配项 保留搜索条件，提供调整或清空条件的操作
刷新失败但已有内容 当前展示是否仍可信 保留已有任务，提示刷新失败及必要的时间信息，提供重试
任务运行中 执行到了哪里，可以做什么 展示真实可获得的阶段或进度；取消能力由实际任务系统决定
部分任务失败 哪些成功，哪些还需处理 分别保留成功结果和失败原因，提供针对失败项的恢复入口

Carbon 的空状态指南区分首次无数据、用户操作后的无结果以及错误情境，并建议提供适合当前情况的下一步。这些情况可以共用视觉结构，但说明和操作需要随原因变化。

反馈应说明发生了什么，以及接下来能做什么

“操作失败”通常还缺少用户决策所需的信息。对于导出任务，可以在已确认原因的前提下说明输入需要修改、权限不足或服务暂时不可用，并分别给出可执行的下一步；不知道原因时，不应编造“网络异常”。

表单校验失败时，应帮助用户找到问题并保留适合继续编辑的输入。GOV.UK 的校验错误模式说明了保留已填内容、关联错误摘要与字段提示的做法；它的具体校验策略属于该设计系统，应结合项目研究和控件环境采用。

动态反馈还要考虑辅助技术能否感知。WCAG 状态消息解释讨论了不转移焦点时，怎样让状态变化可以通过适当语义被识别。实现时要控制反馈频率，不能让每一帧进度更新都变成一次打断。

批量、取消与撤销需要对应真实能力

“全选”要说明选择的是当前页还是全部匹配任务。筛选改变、翻页或部分执行失败后，选择范围与反馈数量也需要保持一致。

取消运行通常意味着请求停止后续工作；撤销则涉及恢复已经发生的结果。这两者的实现条件不同。如果后端无法恢复已删除数据或外部副作用，界面上就不能仅靠一个“撤销”按钮承诺恢复。

WCAG 对重要提交错误预防的解释列出了可逆、检查和确认等方式。产品应根据操作后果选择保护方案，而不是对所有动作机械增加确认框，或对所有删除机械取消确认。

手机与键盘路径需要单独检查

窄屏可以调整字段顺序、将辅助信息收进详情，并让主要操作保持可发现。桌面悬停才出现的入口，应有触控与键盘可达的替代路径；表格是否横向滚动、转为列表或提供详情，需要按比较任务决定。

本文示例将重要按钮的触控区域目标设为至少 44×44 CSS 像素，作为作者的项目设计约定。WCAG 2.2 SC 2.5.8描述的是 24×24 CSS 像素的最小目标及其间距等例外，不能把两者当成同一条统一阈值。

弹窗还需要合理的初始焦点、内部键盘顺序和关闭后的焦点去向。WAI-ARIA APG 的模态对话框模式提供了相关交互指导。加上一个 role 属性并不能代替实际焦点管理与测试。

将设计决定整理成项目规范

设计规范要把已作出的决定连接到可复用实现。颜色表之外，还需要布局规则、文字层级、组件用法、状态、文案、响应式行为和例外条件。

设计令牌（Design Tokens）可以为重复使用的设计决定命名，让样式和文档使用共同词汇。DTCG 2025.10 格式模块定义了在工具间交换设计令牌的格式；它是社区组报告，并非 W3C 正式标准。项目可以借鉴令牌方法，不必为了写一份设计说明就引入完整的交换工具链。

下面是作者为教学页面自拟的 CSS 变量片段。它展示语义命名与复用，不是 UX Engine 配置，也不保证覆盖完整主题或无障碍要求：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
:root {
  --surface-page: #f5f7fa;
  --surface-panel: #ffffff;
  --text-primary: #18212f;
  --text-secondary: #526071;
  --action-primary: #245b4a;
  --action-danger: #a52a39;
  --space-1: 0.25rem;
  --space-2: 0.5rem;
  --space-3: 1rem;
  --space-4: 1.5rem;
  --radius-panel: 0.75rem;
}

.task-list {
  display: grid;
  gap: var(--space-3);
}

DESIGN.md 可以承接这些决定，但应先检查项目是否已有相同职责的文档、样式变量和组件库，确定唯一维护入口。以下同样是教学片段，尺寸和约定需要按真实产品调整：

1
2
3
4
5
6
7
8
9
10
11
12
设计对象：导出任务管理网页，面向需要处理异常任务的运营人员。
视觉方向：清晰、克制；任务信息优先，装饰服务于分组和识别。
排版：沿用项目字体；正文16px，辅助信息14px，页面标题28px。
空间：组内8px，组件内16px，区块间24px；例外说明用途。
颜色：使用语义令牌；状态同时提供文字；核对实际对比度。
组件：复用已有按钮、输入和弹窗；主要操作与危险操作区分。
状态：区分首次加载、无数据、无结果、刷新失败和部分成功。
输入：校验失败保留可继续编辑的内容，错误与对应字段关联。
交互：运行中的可用操作由任务状态决定，不虚构进度或撤销能力。
适配：重要触控区域目标44px；窄屏明确字段优先级，允许长文本换行。
键盘：操作有名称，焦点可见，弹窗关闭后回到合理位置。
修改：新页面复用规范；新增令牌或组件先说明理由并更新入口。

规范应允许有依据的例外。例如，数据比较页面可能需要更高密度，营销页面可能需要更强的视觉表现。例外应指出场景和范围，避免同一种组件在不同页面因为多轮生成而逐渐变成不同实现。

自然语言规范是 Agent 的上下文，不是程序层面的强制保证。 关键约束仍需通过组件复用、静态检查、浏览器检查和行为测试验证。

给 Agent 的设计任务要包含输入与验收条件

一个可执行的设计任务，可以同时提供页面目标、现有实现、参考特征和约束。以下是作者建议的任务说明模板，读者需要替换为自己的项目资料：

1
2
3
4
5
6
7
8
目标：让用户发现导出失败的任务，并理解原因和可用的恢复操作。
范围：现有任务列表网页；沿用原接口、权限与任务状态语义。
先阅读：项目说明、现有设计规范、按钮/输入/弹窗组件和相邻页面。
视觉方向：低饱和背景、清晰层级、适度紧凑；说明参考中的具体特征。
交互要求：覆盖加载、无数据、无结果、刷新失败、运行中和部分成功。
实现要求：复用语义令牌和组件，明确窄屏、键盘及长文本方案。
先交付：任务与假设摘要、布局说明、关键状态和准备修改的文件范围。
完成后：提供实现、实际完成的验证、观察结果和仍需人工判断的问题。

对于既有页面的小幅调整，可以只补充本次变化、必须遵守的既有约定与验收条件，不必每次重新定义整套设计系统。对于新页面或目标模糊的任务，则需要在实现前澄清会影响正确性的关键问题。

从设计说明到实现与审查

阶段 给 Agent 的输入 应得到的产物或判断
理解任务 用户、场景、真实内容、平台和约束 任务说明、关键假设、待解决问题
确定方向 已有规范、参考特征和内容优先级 布局与视觉选择及其理由
定义细节 主要路径、异常路径、组件能力 关键组件、状态表、文案和恢复方案
实现 已确认的设计与代码边界 可运行界面、复用组件和必要规范修改
审查 实际内容、视口、输入方式与验收任务 已观察的问题、修复与验证证据

建议先检查少量关键页面与状态，再扩展相同设计语言。只看正常状态的一张截图，容易漏掉长文本、失败反馈、主题切换和窄屏条件下的实际问题。

原创AI Agent设计工作流示意：任务与约束、视觉方向、交互状态、设计规范、实现验证及反馈修改
原创流程示意：每个阶段都有明确输入和产物，审查结果反馈到实现与规范。该图表达作者建议，不表示已经运行的 Agent 或用户研究结果。

UX Engine 如何辅助这套流程

像 UX Engine 这样的技能工具，可以将设计检查组织为重复调用的流程。Agent Skills 的公开说明将技能描述为包含 SKILL.md 和可选资源的目录，Agent 在需要时加载相应指令。这可以解释通用的知识与流程注入方式，不能据此推断某个付费包的内部实现。

截至本文资料核对日期 2026-11-05，designmotionhq 官网展示的 UX Engine 2.4 包含意图、层级、状态、表单、反馈、审查、设计系统、视觉和响应式等技能方向，并列出 /ux-design、/ux-audit、/ux-review、/restyle 四个命令。可以分别关注新页面设计、已有页面问题、代码变化和视觉调整；实际调用与客户端支持应以对应版本说明为准。

这类工具的价值需要通过实际交付判断：是否读到了已有规范，是否保留业务行为，是否补全必要状态，是否让设计选择有据可查。厂商演示与自建项目上的模型评审不等于目标用户研究，本文也没有复现这些结果。

即使不依赖特定插件，明确的任务说明、组件规范、状态表与审查流程仍可以作为 Agent 的工作输入。工具负责帮助执行和组织检查，产品目标、风格取舍与验收结论仍需要项目负责者判断。

将视觉审查与可用性验证分开记录

视觉审查可以检查文字层级、对齐、间距、密度、颜色角色及组件一致性；浏览器检查可以观察窄屏、长文本、主题与焦点状态；行为验证则需要检查操作是否产生正确结果、失败是否保留必要信息，以及恢复路径是否真的有效。

如果声称某次改版改善了实际体验，还需要相应证据。GOV.UK 的可用性测试指南建议让实际或潜在用户尝试明确、可信的任务，并观察他们如何完成。任务说明应提供目标，避免直接告诉参与者按哪个按钮。

在教学页面中，可以设定“找到昨天失败的导出任务，确认原因并尝试恢复”这一目标。观察用户是否理解任务状态、是否找得到入口、哪里需要解释；如果记录耗时、错误或完成情况，还需说明样本、条件、任务差异和限制。

本文没有开展这类用户测试。两张图只能解释设计方法，不能证明任务完成时间缩短或用户更喜欢某种风格。Agent 自查、静态检查和截图比较各有用途，结论应与实际完成的验证对应。

常见问题

AI Agent 能自己决定产品审美吗？

可以让 Agent 根据目标与参考提出方案和理由，再由项目负责人确认方向。对于偏好或品牌取舍，应保留选择依据；对于文字可读性、控件语义和任务行为，则使用相应检查。不能把模型对截图的偏好直接当作目标用户的判断。

写一份 DESIGN.md 就够了吗？

还需要让它与实际令牌、组件和审查流程保持对应。文档写着复用组件，代码却在每个页面另造按钮，规范就没有落实。修改规范时也应检查既有页面是否受影响。

设计规范会让界面失去特色吗？

规范可以保存已经选择的产品特色，包括排版气质、色彩、密度和动效，而不只是限制差异。需要避免的是将某套通用模板的外观直接当作所有产品的目标。

参考资料

以下资料支持相邻段落中的具体机制或设计建议。Carbon、GOV.UK 与 UX Engine 各自的多篇页面属于同源材料；W3C Understanding 与 APG 为解释和实现指导，引用时保留相应范围。本文未进行插件对照实验或用户效果研究。

  1. Carbon：Typography。排版层级与样式复用。
  2. Carbon：Spacing。间距与分组。
  3. W3C：Understanding SC 1.4.3。文本对比度与例外。
  4. Design Tokens Format Module 2025.10。设计令牌交换格式及社区组报告身份。
  5. Carbon：Empty states。空状态分类与下一步。
  6. GOV.UK：Recover from validation errors。输入保留与错误恢复。
  7. W3C：Understanding SC 4.1.3。状态消息。
  8. W3C APG：Dialog (Modal) Pattern。模态焦点与键盘交互。
  9. W3C：Understanding SC 2.5.8。目标尺寸、间距及例外。
  10. W3C：Understanding SC 3.3.4。重要提交的错误预防。
  11. Agent Skills Overview。技能机制。
  12. UX Engine 产品官网。工具案例的公开范围。
  13. GOV.UK：Using moderated usability testing。任务设计与用户观察。