产品设计与原型总览
产品设计与原型
同样是让 AI 干活，为什么有的产品用起来很爽，有的让人抓狂？差别往往不在模型，而在设计。产品设计是把需求转化为用户可以理解和使用的界面与交互。AI 产品的设计核心是：管理用户对 AI 的预期，并为不确定性设计兜底。
本页是「产品设计与原型」类目总览，聚焦 AI 产品设计本身——从问题定义到体验质量验收的完整设计链路，以及 AI 特有的交互范式与设计原则；通用的设计方法（视觉、交互、设计系统、原型、评审）见下方「本类目导航」各兄弟页面。
在 AI 产品里，设计不是"画界面"，而是一套从问题定义到体验质量验收的决策系统：每一步都产出可评审的工件，每个工件都要回答上一层的追问，最后用可验收的状态与判据收口。
本类目导航
本类目共 8 页：本页（总览）+ 7 个兄弟页面，覆盖 AI 产品设计从方法到交付的完整链路。本页负责 AI 产品设计的完整链路与 AI 特有原则；各兄弟页面负责通用设计方法，按需深入：
- 设计哲学与设计思维：设计思维、以用户为中心、Norman 设计心理学、Dieter Rams、设计伦理
- 视觉设计基础：格式塔、视觉层级、色彩、排版、栅格与间距
- 交互设计基础：心智模型、反馈、设计定律、导航、表单、动效、可访问性
- 设计系统与规范：Material Design / HIG / Ant Design、design tokens、组件库与治理
- 原型与设计交付：保真度、原型工具、可点击原型、设计交付（handoff）
- 设计评审与可用性度量：启发式评估、可用性测试、SUS / HEART、A/B 实验
- 设计师黑话速查：UX / UI / FAB / bottom sheet / design token 等术语速查
设计过程的完整链路
一个 AI 功能从想法到可验证设计，通常要走过九步。每一步都有明确的输入与产出，且必须能回答"上一步凭什么要我这么做、这一步凭什么支撑下一步"：
| 步骤 | 要回答的问题 | 产出工件 | AI 产品的特别之处 |
|---|---|---|---|
| 1 问题框架 | 用户在什么场景下、有什么任务没做好？ | 问题陈述（POV） | 先写价值假设，警惕"为 AI 而 AI" |
| 2 用户心智模型 | 用户以为 AI 是什么、能做什么？ | 心智模型草图 | 多数用户会高估或低估 AI，能力声明必须与心智对齐 |
| 3 当前任务流 | 用户现在是怎么完成任务的？ | 任务流现状图 | 标注每一步的人、工具、耗时与出错点 |
| 4 机会点 | 哪些环节值得用 AI 改进？ | 机会点清单（按价值/成本排序） | 优先替换高重复、低容错成本的环节 |
| 5 概念方案 | AI 以什么形态介入？ | 概念草图、交互范式选择 | 对话框 / 画布 / 向导 / 旁路 / 流水线（见下文范式） |
| 6 信息架构 | 对象、入口、导航怎么组织？ | 信息架构图 | 新增"会话 / 记忆 / 动作记录"等 AI 特有对象 |
| 7 流程与状态机 | 每个状态怎么迁移、失败怎么兜底？ | 状态机图 + 失败路径表 | 每个状态都要画"模型不可用 / 答错 / 超时"分支 |
| 8 视觉与文案 | 用户看到什么、读到什么？ | 视觉稿、文案规范 | 状态可见性、不确定性的文案表达 |
| 9 实现约束 | 模型、成本、延迟允许什么？ | 技术约束清单 | 首 token 延迟、token 成本、评测门槛先于开发确认 |
提示
不要把这九步当成必须顺序执行的瀑布：真实项目里是粗走一遍 → 挑风险最高的环节深挖 → 回来修订。比如第 5 步发现交互范式选错，往往要回到第 2 步重新确认用户心智模型。
互联网产品设计的五个层次
设计行业公认的经典框架来自 Jesse James Garrett 的《用户体验要素》（The Elements of User Experience）：任何产品的用户体验都可以从抽象到具体拆成五层——战略、范围、结构、框架、表现。上层回答"要什么"，下层回答"怎么呈现"；自上而下决策、自下而上支撑，越靠上层越难改——战略层改错了等于产品重做：
| 层次 | 回答的问题 | 典型产出物 | AI 产品示例 |
|---|---|---|---|
| 战略层 | 产品目标 × 用户需求：我们为什么做、为用户解决什么 | 商业目标、用户研究结论 | 把运营的客服响应时间从 2 小时降到 5 分钟 |
| 范围层 | 做什么、不做什么：功能规格与内容范围 | 功能清单、PRD | 只做"知识库问答"，不做"全自动客服" |
| 结构层 | 用户怎么到达功能、信息怎么组织：交互设计 + 信息架构 | 流程图、信息架构图 | 对话流程还是工作流编排？FAQ 入口放哪 |
| 框架层 | 页面元素怎么摆：界面、导航、信息设计 | 线框图、原型 | 对话框 / 生成式画布 / 旁路助手等交互范式（见下文） |
| 表现层 | 用户最终看到什么：视觉设计与品牌感 | 视觉稿、设计规范 | 生成中状态、引用来源的视觉呈现 |
用法：设计时从战略层往下逐层落地，每层都要说清"上一层要求我做什么"；上线后从表现层往上查，体验问题几乎都能追到更上层的决策——"用户乱问"往往不是表现层问题，而是战略/范围层没划清能力边界。AI 产品最容易在战略层偷懒（"先做个智能助手"），结果下面四层全在补窟窿。
每层的输入、产出与评审问题
把五层当决策关卡用：每层开工前检查输入是否齐备，完工后回答该层评审问题，再交给下一层；出现问题时沿"向上追溯"列逐层上查：
| 层次 | 输入 | 产出 | 该层评审问题 | 向上追溯 |
|---|---|---|---|---|
| 战略层 | 用户研究结论、商业目标、机会点清单 | 产品目标、能力边界声明 | 用户凭什么选我们？成功指标是什么？ | — |
| 范围层 | 战略层目标 | 功能清单、明确的"不做清单" | 每个功能对应哪个用户任务？哪些明确不做？ | 每个功能必须能指出它服务哪个战略目标 |
| 结构层 | 范围层功能清单 | 信息架构、状态机、导航模型 | 用户能说出"我在哪、能去哪"吗？失败路径全覆盖了吗？ | 每个入口与状态都必须有范围层功能背书 |
| 框架层 | 结构层架构 | 线框图、可点击原型 | 主任务几步完成？默认值与空状态设计了吗？ | 每个组件都能指出它实现哪个结构层节点 |
| 表现层 | 框架层原型 | 视觉稿、文案与动效规范 | 关键状态（加载 / 错误 / 生成中）可感知吗？ | 每个视觉元素都能对应一个框架层组件 |
评审时如果某一层答不出评审问题，不要往下走——带病下传的成本是指数级的：结构层漏掉一个失败状态，表现层要补三套界面，上线后还要补一次事故复盘。
详见 设计哲学与设计思维：设计思维与以用户为中心（UCD）是五层模型的上游方法，先想清楚"为谁设计、怎么思考设计"再进五层。
信息架构与流程设计
信息架构（IA）决定"东西放在哪、怎么到达"；流程设计决定"状态怎么变、变了怎么办"。对 AI 产品，这两件事比传统软件多一个维度：系统自己也会"行动"（分类、建议、执行），这些动作也要进状态机。
对象模型：先列核心实体
把产品里的"名词"列出来，每个名词都要回答：谁创建、谁修改、谁删除、存多久、谁能看到。以"AI 客服工单助手"为例：
| 实体 | 创建者 | 关键属性 | 生命周期 |
|---|---|---|---|
| 工单 | 用户 / 系统 | 描述、分类、优先级、状态 | 创建 → 解决 → 关闭（可重开） |
| 会话 | 用户 + AI | 消息序列、上下文摘要 | 创建 → 结束（可重开 / 清空） |
| 建议 | AI | 内容、置信度、引用来源 | 生成 → 采纳 / 拒绝 / 编辑 |
| 动作记录 | 系统 | 动作类型、参数、审批人、结果 | 只追加，不可改（审计用） |
导航模型与入口密度
- 导航模型：主入口（如"新建工单"）与次级入口（如"我的工单""AI 助手"）分清楚；AI 能力要么放在任务流内部（旁路），要么独立成入口（对话），不要两个都做强入口
- 入口密度：同一屏 AI 入口超过 2~3 个，用户会失去焦点。规则：每屏只给一个"主角 AI 入口"，其余做成上下文相关的微入口
- 可达性：任何状态下用户都要能回答"下一步能干什么"，没有死胡同
状态迁移：每个状态都要有失败分支
客服工单助手的状态机片段（与 CC/CD 生命周期 的代理权阶梯对齐：v1 路由 → v2 建议 → v3 自动解决）：
| 状态 | 进入条件 | 状态内动作 | 失败 / 异常路径 |
|---|---|---|---|
| 新建 | 用户提交问题 | 生成会话、展示空状态示例 | 空输入 → 提示示例问题；超长输入 → 截断提示 |
| 分类中 | 提交成功 | 意图识别、知识检索 | 低置信度 → 追问澄清，不硬猜 |
| 建议中 | 分类完成 | 生成解决方案建议（带引用） | 检索无命中 → 明示"未找到匹配知识" + 转人工入口 |
| 待确认 | 建议生成 | 展示建议、来源、采纳 / 编辑 / 重新生成 | 用户连续两次拒绝 → 主动建议转人工 |
| 处理中 | 用户采纳 | 执行动作、写入动作记录 | 动作失败 → 展示错误 + 一键重试 |
| 已解决 | 用户确认 | 收集满意度 | 用户改口 → 允许重新打开工单 |
| 已转人工 | 用户点击 / 两次失败 / 高风险分类 | 生成人工工单、携带完整上下文 | 人工接管后 AI 降级为旁路助手 |
覆盖"输入、分类、建议、纠正、转人工、完成"六件事后，再检查两个点：纠正要进动作记录（用户改了什么、为什么改，是后续迭代的数据源）；任何自动动作都要预留"做了之后用户反悔"的路径——转人工后想继续和 AI 聊？采纳后想撤销？状态机里预留回退边，比上线后补后悔药便宜得多。
权限与异常路径
- 权限：谁能看 AI 建议、谁能转人工、谁能看动作记录——AI 产品里"谁授权系统执行动作"是最高优先级权限，必须显式设计
- 异常路径清单（每条都要有 UI 呈现）：模型服务不可用、超时、上下文超长、输入违规（触发内容安全）、会话被外部打断（断网 / 杀进程）
- 降级策略：异常时是重试、降级为规则引擎、还是转人工？在设计阶段定好，别等线上出事故再拍脑袋
详见 交互设计基础：导航、表单与状态设计是信息架构与流程设计落地的通用方法。
常见误区
误区一：把 AI 包装成无所不能
入口写着"什么都能帮你做"，用户一上来就提超出能力的问题，AI 答不上来——预期落空，信任崩塌，下次再也不用了。
怎么做：在界面里明确能力边界，写清能做什么、不能做什么，甚至主动给出示例问题，把用户引导到模型擅长的场景。
误区二：只设计成功路径
原型里全是"AI 答对"的界面，答错、超时、中断时一片空白——用户不知道发生了什么，也不知道该怎么办。
怎么做：为每个失败状态设计兜底——重试、编辑、降级为人工，并明确提示"刚才的回答可能不对，你可以……"。
误区三：让用户猜系统在干嘛
点完发送，页面一动不动，用户只能干等——焦虑、反复点击、以为卡死了。
怎么做：状态可见——思考中、生成中、失败都要有明确反馈，流式输出、进度提示都是手段。
AI 产品交互设计原则
- 明确能力边界：让用户知道"它能做什么、不能做什么"，降低错误预期
- 可解释：AI 给出结论时，展示依据（引用来源、推理步骤）
- 可纠错：用户能修改、重试、反馈错误答案
- 渐进披露：复杂能力分层呈现，避免一开始就吓跑用户
- 状态可见：思考中、生成中、失败——让用户知道系统在干什么
每条原则都要落到可检查的判据，而不是停在口号：
| 原则 | 检查问题 | 验收示例 |
|---|---|---|
| 明确能力边界 | 新用户 30 秒内能说出"它能做什么"吗？ | 空状态给出 3 个示例问题 + "我不能做"清单 |
| 可解释 | 每个结论都能追溯到依据吗？ | 每条建议带引用来源，点击可看原文 |
| 可纠错 | 每个回答都有纠错入口吗？ | 回答尾部固定"反馈 / 重新生成 / 编辑"三个动作 |
| 渐进披露 | 高级能力是否藏起来了？ | 默认只显示基础模式，"高级设置"折叠 |
| 状态可见 | 任何等待都有反馈吗？ | 生成中显示流式光标 + "正在检索 3 篇资料" |
交互质量标准
设计稿评审时，按下面这张表逐项打勾。每项都不是名词，而是"检查问题 + 验收示例"：
| 标准 | 检查问题 | 验收示例 |
|---|---|---|
| 可见性 | 系统现在处于什么状态，用户看得出来吗？ | 生成中显示流式输出光标，不是静止页面 |
| 反馈 | 每一次操作都有回应吗？ | 点击发送 → 0.3 秒内出现"已收到"回显 |
| 映射 | 控件与结果的关系符合直觉吗？ | "重写"按钮只重写当前段落，不碰全文 |
| 约束 | 非法输入被阻止了吗？ | 输入框限制 4000 字并提示，超出不允许发送 |
| 一致性 | 同类操作全站同款吗？ | "重新生成"的位置、文案、图标全局统一 |
| 容错 | 错误可以被挽回吗？ | 误删草稿 → 5 秒内可撤销 |
| 渐进披露 | 复杂度被分层了吗？ | 参数面板默认折叠，只有高级用户展开 |
| 默认值 | 默认配置是安全且合理的吗？ | 默认低风险模式，自动执行默认关闭 |
| 空状态 | 空白页面会引导用户吗？ | 空会话展示 3 个示例问题 + 能力说明 |
| 加载态 | 等待时间可预期吗？ | 长任务显示进度条与预计剩余时间 |
| 错误态 | 失败时可理解、可恢复吗？ | "网络超时，内容未发送" + 一键重试 |
| 权限态 | 无权操作时说明原因和出路吗？ | 未登录：置灰 + "登录后可保存对话" |
| 离线 / 弱网 | 弱网下体验可接受吗？ | 先本地回显用户消息，断网显示缓存内容与离线提示 |
详见 设计评审与可用性度量：启发式评估与可用性测试是逐项度量这些标准的通用方法。
文案与解释设计
AI 产品的文案不只是"措辞"，它是能力契约：用户根据文案判断 AI 能干什么、结果多可信。六条规则：
- 动词准确性：分清 AI 到底做了什么。"已生成草稿"≠"已完成"，"已提交"≠"已送达"。动词夸大是幻觉式文案，会让用户做出错误决策
- 能力声明：把"能做什么 / 不能做什么"写进界面，而不是藏在帮助文档里。示例："我能帮你查退款政策、修改地址；我无法办理支付操作。"
- 置信度表达：拿不准就明说，不包装成确定结论。不用假装精确的百分比，用"我比较有把握 / 我不确定 / 仅供参考"分级
- 引用溯源：结论基于资料时就展示来源，用户可以点开核验；没有依据的结论要标注"这是我的推测"
- 拒绝理由：拒绝要给出原因 + 替代方案，而不是一句"无法处理"；被拒绝后用户还有路可走
- 纠错入口：每个回答都带反馈 / 编辑入口，且告诉用户"反馈会用于改进"
不确定输出不能包装成确定结论
同样一个问题，两种文案的信任差异是决定性的：
| 场景 | 错误示范（包装成确定） | 正确示范（诚实表达） |
|---|---|---|
| AI 我不知道 | "您的订单将在 3 天内送达" | "我查不到您的订单信息（可能是下单渠道不同）。您可以提供订单号，或点这里转人工。" |
| AI 拿不准 | "根据我的分析，您的账户被风控了" | "我看到了几条不一致的记录，无法确定原因。建议人工核实，我可以先帮你生成情况说明。" |
提示
判据：把文案里的结论动词圈出来（送达 / 风控 / 完成……），如果 AI 没有能力保证它，就降级为"建议 / 可能 / 请核实"。
常见交互范式
| 范式 | 代表产品 | 适用场景 |
|---|---|---|
| 对话框 | ChatGPT、Claude | 开放任务、探索式使用 |
| 生成式画布 | 文档/设计协作 | 内容创作、迭代式修改 |
| 填空式向导 | 表单 + AI 增强 | 结构化任务、高准确性要求 |
| 旁路助手 | Copilot | 嵌入既有工作流、低频打断 |
| 自动化流水线 | Agent 工作流 | 确定流程、批量任务 |
范式可以混合：同一个产品里"向导收集信息 → AI 生成草稿 → 画布上编辑"是常见组合。关键是每个范式要有明确的控制权声明——这一范式下最终决定权在谁手里，界面就要把对应的确认 / 编辑能力放在显眼位置：
| 范式 | 控制权在谁 | 界面必须给出 |
|---|---|---|
| 对话框 | 用户 + AI 共同 | 追问、重新生成、结束对话 |
| 生成式画布 | 用户 | 编辑、版本对比、撤销 |
| 填空式向导 | 用户（AI 只填空） | 校验提示、修改入口 |
| 旁路助手 | 用户（AI 建议） | 采纳 / 忽略、低频打扰 |
| 自动化流水线 | 系统（用户授权） | 执行记录、停止 / 撤销、审批点 |
范式选择决策链
选范式不用背表格，先回答两个问题：
- 任务是否结构化？ 有固定步骤、强格式要求 → 填空式向导 / 自动化流水线；开放探索、没有标准答案 → 对话框 / 生成式画布
- 用户是否需要过程可见？ 需要边看边改、掌控过程 → 生成式画布 / 旁路助手；只要最终结果 → 对话框 / 自动化流水线
一句话总结：用户更在意"过程可控"还是"结果省事"——在意过程，就把 AI 放在用户旁边；只要结果，就让 AI 替用户跑。
再加两个问题可以进一步收敛：
| 追加问题 | 是 → | 否 → |
|---|---|---|
| 错误代价高吗？ | 填空式向导（结构化 + 强校验），AI 只填空不自由发挥 | 对话框（用户可自行判断） |
| 用户是新手还是专家？ | 向导 / 对话框 + 示例引导 | 画布 / 旁路，少打扰 |
AI 设计专章：自主性、失败与透明度
自主性阶梯：建议 → 草稿 → 确认执行 → 自动执行 → 审计
系统的"代理权"必须分级，每级对应不同的界面表达。代理权要靠表现赚取，不要一次性授予（详见 CC/CD 生命周期）：
| 等级 | 系统行为 | 界面表达 | 客服工单助手示例 |
|---|---|---|---|
| 1 建议 | 只给建议，用户决定 | 建议卡片 + 采纳 / 忽略 | 回复话术建议 |
| 2 草稿 | 生成草稿供编辑 | 草稿模式 + 编辑框 | 工单回复草稿 |
| 3 需确认执行 | 执行前必须确认 | 确认对话框 + 动作预览 | 发送前展示"将发送给客户" |
| 4 自动执行 | 按规则自动执行 | 执行记录 + 可撤销 | 自动把低风险工单路由给对应部门 |
| 5 自动执行后审计 | 执行并留痕 | 审计面板 + 一键回滚 | 自动解决"改密码"类工单，48 小时内可回滚 |
失败分级与 UI 兜底
不是所有失败都同等对待。按风险分级设计兜底，避免"一刀切"：
| 风险级别 | 失败示例 | UI 兜底要求 |
|---|---|---|
| 低风险 | 摘要措辞不佳 | 重新生成 + 编辑，无需人工 |
| 中风险 | 工单分类错误 | 显示置信度，用户可改；记录修正 |
| 高风险 | 医疗 / 法律 / 财务建议错误 | 显著警示 + 一键转人工 + 不自动执行 |
| 不可逆 | 删除、发送、支付、改价 | 二次确认 + 动作预览 + 撤销窗口（如 5 秒） |
设计评审时给每个自动动作打分：它属于哪级风险？失败后用户能不能自己走出来？ 答不出第二问的功能不发布。
流式输出、进度、取消与编辑
- 流式输出：逐字显示让用户感知"正在干活"，但流式内容仍在变化，关键数字 / 结论要等完整后再强调，防止用户截取中间态做决定
- 进度：长任务（>10 秒）要有阶段进度："正在检索 → 正在分析 → 正在生成"，不是转圈
- 取消：任何长任务都要能取消；取消后明确"已停止，之前的输出保留"
- 编辑：AI 输出的任何结果都应可编辑，且编辑后要重算依赖它的下游内容（版本一致性）
- 版本对比：多版本生成时提供对比视图（diff），用户才能做选择
- 历史回放：会话 / 动作记录支持回放——用户能看到"AI 当时为什么这么做"，也是事后审计的基础
工具调用透明度
Agent 替用户调用工具时，界面要展示：步骤摘要、工具名、输入输出、审批点。长任务给"看板"而不是一句话状态：
| 透明度要素 | 界面呈现 | 验收示例 |
|---|---|---|
| 步骤摘要 | 步骤列表（已完 / 进行中 / 待定） | "①搜索航班 ②比价 ③待你确认预订" |
| 工具名 | 每个动作标注调用的工具 | "正在调用 flight-search 查询航班" |
| 输入输出 | 工具的入参和返回可展开查看 | 点开看到"上海 → 北京 3 月 1 日，返回 3 班" |
| 审批点 | 高风险动作前停下等确认 | 下单前弹确认框，不自动支付 |
| 长任务看板 | 多步骤任务用看板跟踪 | 每步有状态与结果，失败步可单独重试 |
官方规范都强调同一件事：工具调用要有护栏与人工审批。可对照阅读 Anthropic Building Effective Agents、OpenAI Agents Guide 与 OpenAI Agents SDK Guardrails。
个性化与记忆的用户控制
AI 记住用户偏好能提升体验，但记忆是敏感资产，用户必须拥有控制权：
- 可查看：设置页列出"AI 记得关于你的信息"，逐条展示
- 可修改：用户能编辑记忆条目（如"我不喜欢电话沟通"改成"我可以接电话"）
- 可删除：单条删除 + 一键清空全部记忆，删除立即生效
- 可关闭：提供"本次会话不使用记忆"的开关，或彻底关闭个性化
- 透明提示：AI 说"我记得你上次……"时，展示它记得的具体内容
这条在实践上与 Claude Code Best Practices 和 Claude Code Security 的建议一致：最小权限、用户可审计可撤销，是构建信任的基础。
原型工具
- Figma：界面设计、交互原型、AI 插件生态成熟
- 墨刀 / MasterGo：国内协作与演示
- 低代码原型：用于快速验证 AI 交互（如 Flowise、Dify 搭出可点的 demo）
- 真实模型演示：直接用 Claude/ChatGPT 调好的 Prompt 给用户"演"一遍，比静态原型更有说服力
工具选型原则：原型工具的取舍由验证目标决定——验证流程用可点击原型，验证模型行为用真实模型演示，两者不能互相替代。
详见 原型与设计交付：保真度选择、原型工具与可点击原型的通用方法论。
AI 特有的原型验证
原型策略：成本与信度矩阵
四种原型方式的成本与信度差异很大，按验证目标选择：
| 原型方式 | 成本 | 信度 | 适合验证 | 不适合 |
|---|---|---|---|---|
| Prompt 原型 | 极低（小时级） | 低 ~ 中 | 模型能不能做到、输出形态长什么样 | 交互流程、真实性能 |
| 绿野仙踪（人工冒充 AI） | 中 | 高 | 价值假设、转人工流程、用户是否愿意用 | 规模化结论 |
| 可点击原型 | 低 ~ 中 | 中 | 信息架构、导航、状态覆盖 | 模型能力本身 |
| 生产 spike（真数据小范围跑通） | 高 | 极高 | 真实数据下的效果、延迟、成本 | 快速试错 |
提示
顺序建议：先用 Prompt 原型确认"模型干得了这活"，再用绿野仙踪确认"用户愿意这么干活"，最后用生产 spike 确认"真实数据下成本与效果都成立"。绿野仙踪在 AI 产品里特别有效——人肉客服顶一个月，比写三个月自动化划算（《精益创业》的 Aardvark 案例：8 名真人模拟 AI 后端 9 个月）。
错误注入与压力测试
原型阶段就要"故意让产品出丑"：
- 答错：换低质量提示词，或直接 mock 错误输出，验证用户能否识别并纠正
- 超时：mock 慢响应（如 15 秒无返回），验证进度提示与取消路径
- 拒答：输入敏感 / 越界内容，验证拒绝理由文案与替代方案
- 模型不可用：直接断掉 API，验证降级界面（提示、缓存、转人工）
- 上下文超长：塞满上下文再提问，验证截断策略与提示
每条注入都对应一个验收标准："用户在不求助任何人的情况下，能否靠自己走出这个状态？"
详见 原型与设计交付：本页的验证策略之外，通用原型方法论（保真度、可点击原型）与设计交付（handoff）见该页。
对话式 UI 的可用性测试要点
- 开场引导：用户知道"能问什么、怎么问"吗？重点测第一句话和空状态
- 追问路径：回答不满意时，用户能不能自然地问下去（追问、澄清、修改）
- 错误恢复：答错后，用户能否靠自己找回正确路径，还是只能放弃
- 过程感知：等待时用户知道系统在干什么吗？长任务有没有进度预期
测试执行建议：任务式测试（给用户真实任务而非"随便聊聊"）+ 录屏回放 + 5~8 名用户即可发现主要问题（与 用户研究 的访谈样本量一致）。观察重点不是"AI 答得对不对"，而是答错之后用户的行为——重试？换说法？放弃？直接差评？这决定了兜底设计是否及格。
多轮对话的上下文管理（UI 层）
- 上下文可见：让用户看到"AI 记得什么"——展示引用来源、提供可编辑的上下文摘要
- 上下文可控：给"重开对话 / 清除上下文"留入口，防止旧话题污染新问题
- 上下文一致：UI 上显示的会话摘要、历史记录，要和模型真正用到的上下文保持一致
实现层注意：上下文可见不是"把 prompt 给用户看"，而是翻译成用户语言——"AI 参考了：你上周的工单 #1234、本月的退款政策"。上下文一致要求产品埋点记录"模型实际收到的上下文"，否则用户以为 AI 记得、实际模型早已忘记，是最伤信任的隐性不一致。上下文超长时（长对话、长文档），要显式提示"已省略较早内容"，而不是静默截断。
可访问性、国际化与性能
可访问性（WCAG 基本原则）
- 对比度：正文与背景对比度 ≥ 4.5:1（WCAG AA），AI 输出区常被忽略，同样适用
- 键盘可达：所有操作可键盘完成；流式输出区域用 aria-live 向读屏软件播报更新
- 非文本替代：图表、截图要有文字说明；AI 生成的图片要带 alt
- 时间与动效：闪烁 / 自动滚动提供关闭开关，避免诱发不适
跨端适配
- 移动端：单手操作、对话为主；流式输出注意省电与流量（弱网下自动降低输出速度或提示）
- 桌面端：画布、多列对比、长文档编辑更合适
- 规则：设计评审时明确"主场景端"，另一端的体验降级策略写清楚，不做"两端都要 100 分"的无效内耗
性能预算：延迟与吞吐是体验变量
AI 的"加载"是模型推理，延迟直接由成本与模型选择决定——所以性能预算必须在设计评审阶段定下来，而不是上线后才发现：
| 交互 | 建议预算 | 超出预算的兜底 |
|---|---|---|
| 发送消息 → 首 token | < 1.5 秒 | 显示"正在思考"；1 秒后仍在等待则给进度 |
| 完整回答（短问答） | < 10 秒 | 改流式输出，边生成边显示 |
| 端到端（含工具调用） | 每步标注进度，总长任务给看板 | 长任务转异步 + 完成通知 |
| 弱网（移动端） | 首 token < 3 秒 | 本地回显 + 断线提示 + 自动重试 |
预算一旦写入设计，就变成模型选型、缓存策略、流式协议的输入——评审时问一句"这个交互的延迟预算是多少"，比上线后优化十倍都有效。同样的逻辑适用于吞吐：并发峰值时的排队策略（降速、降级模型、限流提示）也应在设计里预留。
详见 交互设计基础 的「可访问性（WCAG）」部分：完整的可访问性准则、ARIA 与无障碍审计方法。
设计评审与验收
评审角色与节奏
| 角色 | 评审中负责什么 |
|---|---|
| 设计负责人 | 交互质量、一致性、可访问性 |
| 产品经理 | 能力边界、需求覆盖、成功指标可测量性 |
| 工程代表 | 实现约束：延迟、成本、模型能力 |
| 数据 / 评测 | 评测集是否覆盖设计的状态与失败路径 |
| 法务 / 合规（按需） | 文案声明、数据使用、内容安全 |
评审建议每次设计走查都留决策记录：日期、决策、理由、备选方案、owner——一个月后回看"当时为什么这么设计"，决策记录比记忆可靠得多。
AI 交互设计评审检查表
评审时逐项打勾，任何一项不通过都不得进入开发：
- 能力边界：新用户能说出"它能做什么 / 不能做什么"
- 成功路径：主任务在 3 步内可达
- 失败路径：答错 / 超时 / 拒答 / 模型不可用都有兜底 UI
- 状态可见：所有等待都有反馈，长任务有进度
- 可解释：关键结论都有引用或依据
- 可纠错：每个回答都有编辑 / 反馈入口
- 自主性分级：自动执行前有审批点，不可逆动作有二次确认
- 工具透明度：动作有步骤摘要，可展开查看输入输出
- 记忆控制：用户可查看、修改、删除、关闭记忆
- 文案契约：无夸大动词、不确定性如实表达、拒绝给替代方案
- 交互质量：空 / 加载 / 错误 / 权限 / 离线五态齐全
- 性能预算：每类交互的延迟预算已定且可实现
- 可访问性：对比度、键盘、读屏通过
- 评测覆盖：评测集包含主要失败路径与边界输入
- 决策记录：本次评审的决策与理由已写入决策日志
验收方式
验收不是"看设计稿满意"，而是四件事：走查（对照检查表逐项过）、可用性测试（5 名以上用户完成任务）、错误注入演练（见上文压力测试）、性能预算核验（真实环境测延迟）。全部通过才进入开发——AI 功能上线前的"最后一公里"，靠的是这套验收而不是感觉。
详见 设计评审与可用性度量：启发式评估、可用性测试与 SUS / HEART 等度量的通用方法论。
一张表收束
| 设计原则 | 对应误区 | 验证方法 |
|---|---|---|
| 明确能力边界 | 把 AI 包装成无所不能 | 让新用户试用后说出"它能做什么"，再与真实能力对比 |
| 状态可见 | 让用户猜系统在干嘛 | 录屏观察用户等待时的动作与表情 |
| 可解释 / 可纠错 | 只设计成功路径 | 错误注入测试，检查兜底界面是否可用 |
| 渐进披露 | 一上来堆满全部能力 | 可用性测试，观察前 30 秒用户是否迷失 |
| 自主性分级 | 直接上全自动 | 按代理权阶梯逐级上线，每级有审批与审计 |
| 失败兜底 | 答错就死路 | 每个失败状态有重试 / 编辑 / 转人工路径 |
下次画原型之前，先问自己：如果 AI 这次答错了，我的界面还能带用户走完这条路吗？
来源说明
以下来源均于 2026-08-23 验证可达；页面可能随时更新。
官方文档与博客
- Anthropic Building Effective Agents（Agent 设计与工具护栏）
- Claude Code Best Practices（人工审批与最小权限实践）
- Claude Code Security（可审计可撤销的安全基线）
- OpenAI Agents Guide（Agent 与 Guardrails）
- OpenAI Agents SDK Guardrails（护栏机制）
经典著作与论文
- Jesse James Garrett, The Elements of User Experience（用户体验五层模型，2010/2011）
- Don Norman, The Design of Everyday Things（设计心理学：映射、约束、反馈，2013）
- Nielsen, 10 Usability Heuristics（1994）
- Eric Ries, The Lean Startup（精益创业：绿野仙踪、MVP 是实验，2011）
- Marty Cagan, INSPIRED（启示录：MVP 应是原型，2018）
- Kano et al., "Attractive quality and must-be quality"（1984）
仓库原创读书笔记
- 《启示录》精读笔记
- 《精益创业》精读笔记
- AI 产品开发生命周期（CC/CD）（自主性阶梯与控制交接）
类目内页面
发现错误？想一起完善？ 在 GitHub 上编辑此页！
本页面贡献者：AI-PM Wiki Team
本页面的全部内容在 CC BY-SA 4.0 和 SATA 协议之条款下提供，附加条款亦可能应用