产品设计与原型总览

产品设计与原型

同样是让 AI 干活，为什么有的产品用起来很爽，有的让人抓狂？差别往往不在模型，而在设计。产品设计是把需求转化为用户可以理解和使用的界面与交互。AI 产品的设计核心是：管理用户对 AI 的预期，并为不确定性设计兜底。

本页是「产品设计与原型」类目总览，聚焦 AI 产品设计本身：从问题定义到体验质量验收的完整设计链路，以及 AI 特有的交互范式与设计原则。通用的设计方法（视觉、交互、设计系统、原型、评审）见下方「本类目导航」各兄弟页面。

在 AI 产品里，设计是一套从问题定义到体验质量验收的决策系统：每一步都产出可评审的工件，每个工件都要回答上一层的追问，最后用可验收的状态与判据收口。

设计过程的完整链路

一个 AI 功能从想法到可验证设计，通常要走过九步。每一步都有明确的输入与产出，且必须能回答「上一步凭什么要我这么做、这一步凭什么支撑下一步」：

flowchart LR
    problem[问题框架] --> mental[用户心智模型]
    mental --> current[当前任务流]
    current --> opportunity[机会点]
    opportunity --> concept[概念方案]
    concept --> ia[信息架构]
    ia --> state[流程与状态机]
    state --> visual[视觉与文案]
    visual --> constraint[实现约束]
    constraint -. 风险最高处回跳 .-> mental
    constraint -. 评审后修订 .-> problem

图示说明：九步链路从问题定义逐层落到约束，风险验证会把设计带回心智模型或问题框架，而不是机械走完瀑布。

互联网产品设计的五个层次

设计行业公认的经典框架来自 Jesse James Garrett 的《用户体验要素》（The Elements of User Experience）：任何产品的用户体验都可以从抽象到具体拆成五层：战略、范围、结构、框架、表现。上层回答「要什么」，下层回答「怎么呈现」；自上而下决策、自下而上支撑。越靠上层越难改：战略层改错了等于产品重做：

flowchart TD
    strategy[战略] --> scope[范围]
    scope --> structure[结构]
    structure --> framework[框架]
    framework --> surface[表现]
    surface -. 体验问题向上追溯 .-> strategy

图示说明：五层从产品目标逐级落到界面表现，体验问题则应沿反向链路追溯到更上游的决策。

用法：设计时从战略层往下逐层落地，每层都要说清「上一层要求我做什么」；上线后从表现层往上查，体验问题几乎都能追到更上层的决策。「用户乱问」往往不是表现层问题，而是战略/范围层没划清能力边界。AI 产品最容易在战略层偷懒（「先做个智能助手」），结果下面四层全在补窟窿。

每层的输入、产出与评审问题

把五层当决策关卡用：每层开工前检查输入是否齐备，完工后回答该层评审问题，再交给下一层；出现问题时沿"向上追溯"列逐层上查：

评审时如果某一层答不出评审问题，不要往下走。带病下传的成本是指数级的：结构层漏掉一个失败状态，表现层要补三套界面，上线后还要补一次事故复盘。

详见 设计哲学与设计思维：设计思维与以用户为中心（UCD）是五层模型的上游方法，先想清楚"为谁设计、怎么思考设计"再进五层。

九步是本页的作业顺序，五层是体验结构。走九步时，产出要能落到某一层，避免两套框架各写各的：

信息架构与流程设计

信息架构（IA）决定"东西放在哪、怎么到达"；流程设计决定"状态怎么变、变了怎么办"。对 AI 产品，这两件事比传统软件多一个维度：系统自己也会"行动"（分类、建议、执行），这些动作也要进状态机。

对象模型：先列核心实体

把产品里的"名词"列出来，每个名词都要回答：谁创建、谁修改、谁删除、存多久、谁能看到。以"AI 客服工单助手"为例：

导航模型与入口密度

• 导航模型：主入口（如"新建工单"）与次级入口（如"我的工单""AI 助手"）分清楚；AI 能力要么放在任务流内部（旁路），要么独立成入口（对话），不要两个都做强入口
• 入口密度：同一屏 AI 入口超过 2~3 个，用户会失去焦点。规则：每屏只给一个"主角 AI 入口"，其余做成上下文相关的微入口
• 可达性：任何状态下用户都要能回答"下一步能干什么"，没有死胡同

状态迁移：每个状态都要有失败分支

客服工单助手的状态机片段（产品版本 v1 路由 / v2 建议 / v3 自动解决是 CC/CD 生命周期 L0–L4 上的切片，不是另一套等级）：

stateDiagram-v2
    state "新建" as New
    state "分类中" as Classifying
    state "建议中" as Suggesting
    state "待确认" as Confirm
    state "处理中" as Processing
    state "已解决" as Resolved
    state "已转人工" as Human

    [*] --> New
    New --> Classifying: 提交问题
    Classifying --> Suggesting: 分类完成
    Classifying --> Human: 低置信度/需澄清
    Suggesting --> Confirm: 建议生成
    Suggesting --> Human: 检索无命中
    Confirm --> Processing: 用户采纳
    Confirm --> Suggesting: 编辑/重新生成
    Confirm --> Human: 连续拒绝/高风险
    Processing --> Resolved: 动作成功
    Processing --> Processing: 一键重试
    Processing --> Human: 动作失败
    Resolved --> New: 重新打开
    Human --> [*]

图示说明：工单从输入到完成必须显式覆盖澄清、纠正、重试和转人工等失败分支，任何自动动作都保留回退出口。

覆盖"输入、分类、建议、纠正、转人工、完成"六件事后，再检查两个点：纠正要进动作记录（用户改了什么、为什么改，是后续迭代的数据源）；任何自动动作都要预留「做了之后用户反悔」的路径：转人工后想继续和 AI 聊？采纳后想撤销？状态机里预留回退边，比上线后补后悔药便宜得多。

权限与异常路径

• 权限：谁能看 AI 建议、谁能转人工、谁能看动作记录——AI 产品里"谁授权系统执行动作"是最高优先级权限，必须显式设计
• 异常路径清单（每条都要有 UI 呈现）：模型服务不可用、超时、上下文超长、输入违规（触发内容安全）、会话被外部打断（断网 / 杀进程）
• 降级策略：异常时是重试、降级为规则引擎、还是转人工？在设计阶段定好，别等线上出事故再拍脑袋

详见 交互设计基础：导航、表单与状态设计是信息架构与流程设计落地的通用方法。

常见误区

误区一：把 AI 包装成无所不能

入口写着"什么都能帮你做"，用户一上来就提超出能力的问题，AI 答不上来——预期落空，信任崩塌，下次再也不用了。

怎么做：在界面里明确能力边界，写清能做什么、不能做什么，甚至主动给出示例问题，把用户引导到模型擅长的场景。

误区二：只设计成功路径

原型里全是"AI 答对"的界面，答错、超时、中断时一片空白——用户不知道发生了什么，也不知道该怎么办。

怎么做：为每个失败状态设计兜底——重试、编辑、降级为人工，并明确提示"刚才的回答可能不对，你可以……"。

误区三：让用户猜系统在干嘛

点完发送，页面一动不动，用户只能干等——焦虑、反复点击、以为卡死了。

怎么做：状态可见。思考中、生成中、失败都要有明确反馈，流式输出、进度提示都是手段。

AI 产品交互设计原则

1. 明确能力边界：让用户知道"它能做什么、不能做什么"，降低错误预期
2. 可解释：AI 给出结论时，展示依据（引用来源、推理步骤）
3. 可纠错：用户能修改、重试、反馈错误答案
4. 渐进披露：复杂能力分层呈现，避免一开始就吓跑用户
5. 状态可见：思考中、生成中、失败——让用户知道系统在干什么

每条原则都要落到可检查的判据：

交互质量标准

设计稿评审时，按下面这张表逐项打勾。每项是一个「检查问题 + 验收示例」：

详见 设计评审与可用性度量：启发式评估与可用性测试是逐项度量这些标准的通用方法。

文案与解释设计

AI 产品的文案不只是"措辞"，它是能力契约：用户根据文案判断 AI 能干什么、结果多可信。六条规则：

• 动词准确性：分清 AI 到底做了什么。"已生成草稿"≠"已完成"，"已提交"≠"已送达"。动词夸大是幻觉式文案，会让用户做出错误决策
• 能力声明：把"能做什么 / 不能做什么"写进界面，而不是藏在帮助文档里。示例："我能帮你查退款政策、修改地址；我无法办理支付操作。"
• 置信度表达：拿不准就明说，不包装成确定结论。不用假装精确的百分比，用"我比较有把握 / 我不确定 / 仅供参考"分级
• 引用溯源：结论基于资料时就展示来源，用户可以点开核验；没有依据的结论要标注"这是我的推测"
• 拒绝理由：拒绝要给出原因 + 替代方案，而不是一句"无法处理"；被拒绝后用户还有路可走
• 纠错入口：每个回答都带反馈 / 编辑入口，且告诉用户"反馈会用于改进"

不确定输出不能包装成确定结论

同样一个问题，两种文案的信任差异是决定性的：

常见交互范式

范式可以混合：同一个产品里"向导收集信息 → AI 生成草稿 → 画布上编辑"是常见组合。关键是每个范式要有明确的控制权声明：这一范式下最终决定权在谁手里，界面就要把对应的确认 / 编辑能力放在显眼位置：

范式选择决策链

选范式不用背表格，先回答两个问题：

1. 任务是否结构化？ 有固定步骤、强格式要求 → 填空式向导 / 自动化流水线；开放探索、没有标准答案 → 对话框 / 生成式画布
2. 用户是否需要过程可见？ 需要边看边改、掌控过程 → 生成式画布 / 旁路助手；只要最终结果 → 对话框 / 自动化流水线

用户更在意「过程可控」还是「结果省事」：在意过程，就把 AI 放在用户旁边；只要结果，就让 AI 替用户跑。

再加两个问题可以进一步收敛：

AI 设计专章：自主性、失败与透明度

代理权阶梯：L0–L4（界面表达）

系统的代理权必须分级，每级对应不同的界面表达。代理权要靠表现赚取，不要一次性授予。等级定义以 CC/CD 生命周期 的 L0–L4 为准；本表只补界面。审计是 L4 的界面要求，不是独立于自动执行的第六级。

失败分级与 UI 兜底

失败按风险分级设计兜底：

设计评审时给每个自动动作打分：它属于哪级风险？失败后用户能不能自己走出来？ 答不出第二问的功能不发布。

流式输出、进度、取消与编辑

• 流式输出：逐字显示让用户感知"正在干活"，但流式内容仍在变化，关键数字 / 结论要等完整后再强调，防止用户截取中间态做决定
• 进度：长任务（>10 秒）要有阶段进度："正在检索 → 正在分析 → 正在生成"，不是转圈
• 取消：任何长任务都要能取消；取消后明确"已停止，之前的输出保留"
• 编辑：AI 输出的任何结果都应可编辑，且编辑后要重算依赖它的下游内容（版本一致性）
• 版本对比：多版本生成时提供对比视图（diff），用户才能做选择
• 历史回放：会话 / 动作记录支持回放——用户能看到"AI 当时为什么这么做"，也是事后审计的基础

工具调用透明度

Agent 替用户调用工具时，界面要展示：步骤摘要、工具名、输入输出、审批点。长任务给"看板"而不是一句话状态：

官方规范都强调同一件事：工具调用要有护栏与人工审批。可对照阅读 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 特有的原型验证

原型策略：成本与信度矩阵

四种原型方式的成本与信度差异很大，按验证目标选择：

错误注入与压力测试

原型阶段就要"故意让产品出丑"：

• 答错：换低质量提示词，或直接 mock 错误输出，验证用户能否识别并纠正
• 超时：mock 慢响应（如 15 秒无返回），验证进度提示与取消路径
• 拒答：输入敏感 / 越界内容，验证拒绝理由文案与替代方案
• 模型不可用：直接断掉 API，验证降级界面（提示、缓存、转人工）
• 上下文超长：塞满上下文再提问，验证截断策略与提示

每条注入都对应一个验收标准："用户在不求助任何人的情况下，能否靠自己走出这个状态？"

详见 原型与设计交付：本页的验证策略之外，通用原型方法论（保真度、可点击原型）与设计交付（handoff）见该页。

对话式 UI 的可用性测试要点

• 开场引导：用户知道"能问什么、怎么问"吗？重点测第一句话和空状态
• 追问路径：回答不满意时，用户能不能自然地问下去（追问、澄清、修改）
• 错误恢复：答错后，用户能否靠自己找回正确路径，还是只能放弃
• 过程感知：等待时用户知道系统在干什么吗？长任务有没有进度预期

测试执行建议：任务式测试（给用户真实任务而非「随便聊聊」）+ 录屏回放 + 5~8 名用户即可发现主要问题（与 用户研究 的访谈样本量一致）。观察重点是答错之后用户的行为：重试？换说法？放弃？直接差评？这决定了兜底设计是否及格。

多轮对话的上下文管理（UI 层）

• 上下文可见：让用户看到"AI 记得什么"——展示引用来源、提供可编辑的上下文摘要
• 上下文可控：给"重开对话 / 清除上下文"留入口，防止旧话题污染新问题
• 上下文一致：UI 上显示的会话摘要、历史记录，要和模型真正用到的上下文保持一致

实现层：上下文可见把模型实际用的内容翻译成用户语言：「AI 参考了：你上周的工单 #1234、本月的退款政策」。上下文一致要求产品埋点记录「模型实际收到的上下文」，否则用户以为 AI 记得、实际模型早已忘记，是最伤信任的隐性不一致。上下文超长时（长对话、长文档），要显式提示「已省略较早内容」，而不是静默截断。

可访问性、国际化与性能

可访问性（WCAG 基本原则）

• 对比度：正文与背景对比度 ≥ 4.5:1（WCAG AA），AI 输出区常被忽略，同样适用
• 键盘可达：所有操作可键盘完成；流式输出区域用 aria-live 向读屏软件播报更新
• 非文本替代：图表、截图要有文字说明；AI 生成的图片要带 alt
• 时间与动效：闪烁 / 自动滚动提供关闭开关，避免诱发不适

跨端适配

• 移动端：单手操作、对话为主；流式输出注意省电与流量（弱网下自动降低输出速度或提示）
• 桌面端：画布、多列对比、长文档编辑更合适
• 规则：设计评审时明确"主场景端"，另一端的体验降级策略写清楚，不做"两端都要 100 分"的无效内耗

性能预算：延迟与吞吐是体验变量

AI 的「加载」是模型推理，延迟直接由成本与模型选择决定。性能预算必须在设计评审阶段定下来，而不是上线后才发现：

预算一旦写入设计，就变成模型选型、缓存策略、流式协议的输入。评审时问一句「这个交互的延迟预算是多少」，比上线后优化十倍都有效。同样的逻辑适用于吞吐：并发峰值时的排队策略（降速、降级模型、限流提示）也应在设计里预留。

详见 交互设计基础 的「可访问性（WCAG）」部分：完整的可访问性准则、ARIA 与无障碍审计方法。

设计评审与验收

评审角色与节奏

评审建议每次设计走查都留决策记录：日期、决策、理由、备选方案、owner。一个月后回看「当时为什么这么设计」，决策记录比记忆可靠得多。

AI 交互设计评审检查表

评审时逐项打勾，任何一项不通过都不得进入开发：

• 能力边界：新用户能说出"它能做什么 / 不能做什么"
• 成功路径：主任务在 3 步内可达
• 失败路径：答错 / 超时 / 拒答 / 模型不可用都有兜底 UI
• 状态可见：所有等待都有反馈，长任务有进度
• 可解释：关键结论都有引用或依据
• 可纠错：每个回答都有编辑 / 反馈入口
• 自主性分级：自动执行前有审批点，不可逆动作有二次确认
• 工具透明度：动作有步骤摘要，可展开查看输入输出
• 记忆控制：用户可查看、修改、删除、关闭记忆
• 文案契约：无夸大动词、不确定性如实表达、拒绝给替代方案
• 交互质量：空 / 加载 / 错误 / 权限 / 离线五态齐全
• 性能预算：每类交互的延迟预算已定且可实现
• 可访问性：对比度、键盘、读屏通过
• 评测覆盖：评测集包含主要失败路径与边界输入
• 决策记录：本次评审的决策与理由已写入决策日志

验收方式

验收做四件事：走查（对照检查表逐项过）、可用性测试（5 名以上用户完成任务）、错误注入演练（见上文压力测试）、性能预算核验（真实环境测延迟）。全部通过才进入开发：AI 功能上线前的「最后一公里」，靠的是这套验收而不是感觉。

详见 设计评审与可用性度量：启发式评估、可用性测试与 SUS / HEART 等度量的通用方法论。

一张表收束

下次画原型之前，先问自己：如果 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）（L0–L4 代理权阶梯与控制交接）

类目内页面

• 设计哲学与设计思维
• 视觉设计基础
• 交互设计基础
• 设计系统与规范
• 原型与设计交付
• 设计评审与可用性度量
• 设计师黑话速查

发现错误？想一起完善？ 在 GitHub 上编辑此页！
本页面贡献者：AI-PM Wiki Team
本页面的全部内容在 CC BY-SA 4.0 和 SATA 协议之条款下提供，附加条款亦可能应用