---
title: "AI Agent UI/UX 设计指南：视觉审美、交互体验与设计规范"
source: https://www.iowill.com/blog/2026/11/ai-agent-ui-ux-design/
date: 2026-11-05
updated: 2026-11-05
tags: [AI Agent, UI设计, UX设计, 交互设计, 设计系统]
categories: [编程开发]
---

# AI Agent UI/UX 设计指南：视觉审美、交互体验与设计规范

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

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

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

## 明确用户任务与界面范围

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

![原创任务页面设计示意：排版层级、间距分组、语义色彩与任务操作分别对应可检查的设计决定](https://img.iowill.com/file/编程开发/AiAgentUiUxDesign/body1.png)

原创设计示意：把审美要求对应到排版、空间、色彩与操作。图中内容为虚构教学样张，不是 UX Engine 的生成结果或产品实测截图。

## 让交互体验覆盖完整任务

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

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

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

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

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

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

动态反馈还要考虑辅助技术能否感知。[WCAG 状态消息解释](https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html)讨论了不转移焦点时，怎样让状态变化可以通过适当语义被识别。实现时要控制反馈频率，不能让每一帧进度更新都变成一次打断。

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

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

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

[WCAG 对重要提交错误预防的解释](https://www.w3.org/WAI/WCAG22/Understanding/error-prevention-legal-financial-data.html)列出了可逆、检查和确认等方式。产品应根据操作后果选择保护方案，而不是对所有动作机械增加确认框，或对所有删除机械取消确认。

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

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

本文示例将重要按钮的触控区域目标设为至少 44×44 CSS 像素，作为作者的项目设计约定。[WCAG 2.2 SC 2.5.8](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html)描述的是 24×24 CSS 像素的最小目标及其间距等例外，不能把两者当成同一条统一阈值。

弹窗还需要合理的初始焦点、内部键盘顺序和关闭后的焦点去向。[WAI-ARIA APG 的模态对话框模式](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)提供了相关交互指导。加上一个 `role` 属性并不能代替实际焦点管理与测试。

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

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

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

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

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

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

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

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

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

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

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

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

## 从设计说明到实现与审查

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

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

![原创AI Agent设计工作流示意：任务与约束、视觉方向、交互状态、设计规范、实现验证及反馈修改](https://img.iowill.com/file/编程开发/AiAgentUiUxDesign/body2.png)

原创流程示意：每个阶段都有明确输入和产物，审查结果反馈到实现与规范。该图表达作者建议，不表示已经运行的 Agent 或用户研究结果。

## UX Engine 如何辅助这套流程

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

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

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

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

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

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

如果声称某次改版改善了实际体验，还需要相应证据。[GOV.UK 的可用性测试指南](https://www.gov.uk/service-manual/user-research/using-moderated-usability-testing)建议让实际或潜在用户尝试明确、可信的任务，并观察他们如何完成。任务说明应提供目标，避免直接告诉参与者按哪个按钮。

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

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

## 常见问题

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

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

### 写一份 DESIGN.md 就够了吗？

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

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

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

## 参考资料

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

1.  [Carbon：Typography](https://carbondesignsystem.com/guidelines/typography/overview/)。排版层级与样式复用。
2.  [Carbon：Spacing](https://carbondesignsystem.com/guidelines/spacing/overview/)。间距与分组。
3.  [W3C：Understanding SC 1.4.3](https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html)。文本对比度与例外。
4.  [Design Tokens Format Module 2025.10](https://www.designtokens.org/TR/2025.10/format/)。设计令牌交换格式及社区组报告身份。
5.  [Carbon：Empty states](https://carbondesignsystem.com/patterns/empty-states-pattern/)。空状态分类与下一步。
6.  [GOV.UK：Recover from validation errors](https://design-system.service.gov.uk/patterns/validation/)。输入保留与错误恢复。
7.  [W3C：Understanding SC 4.1.3](https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html)。状态消息。
8.  [W3C APG：Dialog (Modal) Pattern](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)。模态焦点与键盘交互。
9.  [W3C：Understanding SC 2.5.8](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html)。目标尺寸、间距及例外。
10.  [W3C：Understanding SC 3.3.4](https://www.w3.org/WAI/WCAG22/Understanding/error-prevention-legal-financial-data.html)。重要提交的错误预防。
11.  [Agent Skills Overview](https://agentskills.io/home)。技能机制。
12.  [UX Engine 产品官网](https://designmotionhq.com/)。工具案例的公开范围。
13.  [GOV.UK：Using moderated usability testing](https://www.gov.uk/service-manual/user-research/using-moderated-usability-testing)。任务设计与用户观察。