AI 产品设计边界

传统软件是确定的：点同一个按钮，得到同一个结果。AI 功能不是：同样的输入，结果可能不同，也可能是错的。很多 AI 产品体验不好，问题不在模型，而在产品设计没有正视这种不确定性：

• 用户照着 AI 给出的错误信息操作，造成了损失，因为界面让它看起来非常权威；
• 点击“智能生成”后，页面白屏十几秒，用户以为卡死了；
• AI 改写的内容直接覆盖了原文，用户想恢复却找不到原来的版本；
• 用户切换到另一篇文档后，上一篇的生成结果被插入了当前文档。

读完这篇你会

• 按“错了的代价”决定 AI 在功能中的角色
• 设计“预览 → 采纳 → 可撤销”的交互
• 处理好等待、失败、过期结果和用户反馈

1. 原理：一位能干但偶尔犯错的新同事

可以把 AI 想成一位能干、速度很快、但偶尔会犯错的新同事。你会让他起草邮件，但发给重要客户之前，你会自己看一遍；你会让他整理资料，但关键数字你会核对。

设计 AI 功能的核心问题不是“模型能不能做到”，而是：它做错了，代价我承受得起吗？

错误的代价	AI 的角色	例子
很高（健康、法律、资金）	只提供参考，必须由人确认	医疗建议、合同审核、财务判断
中等	生成草稿，用户编辑后采纳	写作助手、邮件起草、摘要
很低，可以随时撤销	可以自动执行	灵感推荐、标签建议、草稿整理

2. 人和 AI 怎样分工

模式	适合	特点
全自动	错误代价低、可以撤销、批量处理	快，但用户没有机会拦截错误
AI 草稿 + 人编辑	内容创作、文档整理	平衡，人保留最终决定权
人审核后执行	高风险、不可逆的操作	稳，但有等待和人力成本
辅助（Copilot）	专业工具：写代码、做表格、写报告	人主导，AI 加速，可控性最高

经验是：默认选择人机协作。让 AI 做“费时但不致命”的工作（起草、提取、初筛），让人做“判断和拍板”的工作。

3. 坑一：假装 AI 永远正确

现象：AI 生成的回答和人工编辑的内容使用相同的样式、相同的权威语气，没有任何标识。用户完全相信了一个错误的答案。

修复：

做法	作用
标注“AI 生成，请核对”	降低用户对绝对正确的预期
展示引用和来源	让用户能自己核实，建立信任
结果可以编辑	用户发现问题能直接修改
不确定时如实说明	“没有找到相关信息”比编造一个答案好得多
展示能力边界的示例	让用户知道它能做什么、不能做什么

用户对 AI 的信任是一种消耗品：一次自信的错误回答，可能抵消十次正确回答积累的信任。宁可保守，不要夸大。

4. 坑二：点击生成后，白屏等十几秒

现象：普通接口几百毫秒就返回，AI 生成要 5～20 秒。用户盯着没有任何变化的页面，以为卡住了，反复点击按钮或者直接离开。

修复：

• 流式输出：边生成边显示，用户在不到一秒内就能看到内容开始出现；
• 分阶段反馈：“正在检索资料…… 已找到 3 篇…… 正在生成……”，让用户知道进展；
• 可以取消：生成方向不对时，用户能随时停止，不用干等；
• 防止重复触发：生成期间按钮变成“停止生成”，避免连点导致多次请求；
• 很长的任务转为后台处理：生成报告、处理大文件，完成后通知用户。

5. 坑三：AI 的结果直接覆盖了原内容

现象：用户点击“润色全文”，AI 的结果直接替换了原文。用户发现改得不好，想恢复，却找不到原来的版本。

修复：采用 “预览 → 采纳 → 可撤销” 的流程：

AI 生成候选结果
  → 和原内容对比展示（哪些地方改了）
  → 用户选择：采纳全部 / 采纳部分 / 重新生成 / 放弃
  → 采纳后可以撤销，或者保留采纳前的历史版本

生成完成不等于修改生效，修改只在用户明确采纳后才发生。笔记应用里的具体做法，见 AI 编辑的可靠性边界。

6. 坑四：旧的结果被应用到了新内容上

现象：用户在文档 A 中选中一段话点击“改写”，在等待结果时切换到了文档 B。结果返回后，改写的内容被插入到了文档 B 中。

原因：异步结果返回时，界面没有核对“当时发起请求的上下文”和“现在的上下文”是否还是同一个。

修复：发起请求时记录上下文（哪篇文档、哪段选区、原文的快照），结果返回和用户采纳时，都检查上下文是否仍然一致；不一致就提示“内容已变化，结果可能已过期”，让用户决定是否继续。这和前端开发中的 竞态问题 是同一类问题。

7. 坑五：失败时给用户看报错

现象：模型服务超时时，界面显示 Error: 504 Gateway Timeout，或者只有一句“出错了”。

修复：失败也是产品体验的一部分：

模型超时或出错
  → 自动重试有限次数
  → 仍然失败：显示能理解的说明和下一步
     “生成服务暂时繁忙，你的内容已保存。可以稍后重试，或者先手动编辑。”
  → 用户已经输入的内容不能丢失

8. 坑六：反馈按钮只是摆设

现象：每个回答下面都有“👍 / 👎”按钮，数据每天都在增长，但从来没有人看过，产品也没有因此改进。

修复：建立闭环：

用户点击“没帮助”（可以选择原因：不准确 / 不相关 / 太长……）
  → 记录这次的输入、输出和上下文（注意脱敏）
  → 定期分析，归类问题
  → 加入评测集，修改提示词、检索或护栏
  → 用评测验证改进效果

用户的负面反馈是最有价值的改进信号，具体做法见 LLM 评测与 Guardrails。

9. 坑七：在不该用 AI 的地方用了 AI

现象：订单金额计算、库存判断、权限校验也交给了模型，偶尔出错，而且没法解释为什么。

判断标准：如果一个确定的规则或传统算法能解决，就先用它；只有问题本质上是模糊的、需要理解语义的，才考虑 AI。

不适合用 AI	原因
规则明确、必须 100% 准确（计价、库存、权限）	错了就是事故，规则代码又快又准
流量巨大、成本敏感	每次调用都要花钱
需要在几百毫秒内响应	模型生成太慢
每个决策都必须可解释、可审计	模型的判断过程难以说明
用户期待同样的操作得到同样的结果	模型的输出会波动

10. 怎样衡量 AI 功能好不好用

除了模型本身的准确率，还要看用户的实际行为：

指标	说明什么
采纳率	生成的结果有多少被用户采纳
采纳后的修改程度	采纳后用户改了多少，改得越多说明质量越不够
重新生成率	用户对结果不满意的频率
中途取消率	等待太久或者方向不对
负面反馈率	用户明确表示不满意

检查清单

• [ ] 按“错了的代价”决定 AI 在功能中的角色
• [ ] AI 生成的内容有明确标识，展示来源，可以编辑
• [ ] 使用流式输出或分阶段反馈，可以取消生成
• [ ] 生成结果先预览，用户明确采纳后才生效，并且可以撤销
• [ ] 结果返回和采纳时核对上下文是否已经变化
• [ ] 失败时有能理解的说明，用户的输入不会丢失
• [ ] 用户反馈形成改进闭环
• [ ] 规则明确、必须准确的部分用传统代码实现

延伸阅读

• AI 编辑的可靠性边界：笔记应用中的预览与采纳
• LLM 评测与 Guardrails：用数据改进 AI 功能
• 可访问性实战：动态内容的播报与焦点