Agent Product 101｜08｜Trust UX：让用户敢于委托

Trust UX 不是把界面做得像安全产品，而是在关键时刻让用户看懂 Agent 的计划、证据、风险、权限、恢复路径和责任边界。

核心结论

Trust UX 的目标不是让用户“相信 AI 很聪明”，而是让用户敢于委托。用户敢不敢委托，取决于他是否能在关键时刻看懂：Agent 准备怎么做、依据是什么、风险在哪里、哪些动作会影响外部世界、出错后能不能恢复、责任由谁承担。

对产品经理来说，Trust UX 是 Agent 产品的转化层。模型能力决定 Agent 能不能做，信任体验决定用户敢不敢让它做。很多 Agent 产品看起来功能强，但用户只把它当搜索框或草稿工具，原因往往不是模型不够强，而是用户看不到控制感和恢复路径。

Trust UX 要解决的是三类心理问题：

用户心理问题	产品需要回答	典型设计
它懂我吗？	Agent 如何理解任务和约束	任务复述、计划、目标确认
它靠谱吗？	依据、来源、验证和不确定性是什么	引用、证据、测试、preview、diff
我还掌控吗？	我何时能暂停、修改、拒绝或接管	approval gate、undo、rollback、takeover

从真实产品看 Trust UX

ChatGPT Agent 的个人任务体验强调暂停、接管和敏感动作确认。用户并不只关心 Agent 能不能浏览网页，更关心它会不会在不知情的情况下提交表单、购买商品或发送信息。

Claude Code、Cursor、Codex、GitHub Copilot coding agent 的信任来自工程协作对象：plan、diff、test、branch、PR、review。开发者不一定相信 Agent 的口头解释，但会相信可审查的修改、可运行的测试和可回滚的分支。

Replit Agent、v0、Lovable 的信任来自预览和迭代。非工程师用户不想阅读代码，但需要看到页面长什么样、哪里变了、能不能一键调整、发布前是否可确认。

Slack、Copilot Studio、Agentforce 的信任来自组织语境：谁触发了 Agent、它访问了哪些系统、更新了哪些业务对象、谁审批、谁能查看记录。团队和企业场景中，信任不是个人感觉，而是协作和治理机制。

产品模型：Trust UX 的六个组件

1. Intent Check：先确认理解

Agent 在执行高成本或高风险任务前，应先把自己理解的目标、范围、约束和产物说清楚。对 PM 来说，这不是“多一步确认”，而是减少返工和误操作的关键。

2. Plan Preview：展示计划，不展示幻觉

计划要足够具体，让用户知道 Agent 会先做什么、后做什么、哪些节点需要用户参与。但计划也不能伪装成确定承诺。好的计划会标明假设、依赖和可能调整的地方。

3. Evidence：让结果有依据

总结类任务需要来源；代码类任务需要 diff 和测试；业务流程需要记录和对象变更；创作类任务需要版本和参考材料。证据不是给用户增加负担，而是让用户能快速判断是否可信。

4. Risk Signal：把风险提前说出来

风险提示不应该只在失败后出现。Agent 准备发送邮件、删除数据、部署生产、修改客户记录、触发审批前，都应让用户看到影响范围和不可逆程度。

5. Control Point：关键节点让用户掌控

信任不是全程人工确认，也不是完全自动化。PM 要设计哪些节点自动通过，哪些节点需要确认，哪些节点需要审批，哪些节点允许用户接管。

6. Recovery：出错后能回来

用户真正信任一个系统，往往不是因为它从不出错，而是因为出错后能解释、能恢复、能回滚。Trust UX 必须包含失败状态、补救路径和人工接管。

产品判断表：不同场景的信任抓手

场景	用户最担心	关键 Trust UX
写邮件/消息	发错对象、语气不当、泄露信息	收件人预览、草稿模式、发送前确认
总结文档/会议	编造结论、遗漏重点	来源引用、原文定位、置信提示
改代码	破坏现有功能、难以回滚	diff、测试结果、分支、PR review
生成应用	页面不可用、发布风险	live preview、checkpoint、发布确认
更新 CRM	改错客户、影响销售流程	对象确认、字段差异、审计记录
执行企业流程	越权、审批缺失	policy、approval、role visibility

反例与误区

误区一：把“拟人化”当信任

友好的语气、头像和动画可以提升亲近感，但不能替代证据、控制和恢复。Agent 说“放心交给我”没有意义，用户需要看到它为什么值得放心。

误区二：把所有细节都展示出来

透明不等于倾倒日志。过多技术细节会让用户更焦虑。Trust UX 应该分层：默认展示用户决策需要的信息，需要时再展开日志和证据。

误区三：只在高风险时突然弹窗

如果用户平时看不到 Agent 的计划和状态，到了高风险节点突然弹出确认，会显得突兀。信任应该在整个任务过程中逐步建立。

误区四：用免责声明代替产品设计

“AI 可能出错，请自行判断”不是 Trust UX。它把责任推给用户，却没有提供判断所需的证据、控制点和恢复路径。

设计原则

1. 让用户先理解，再授权

用户授权前要知道 Agent 为什么需要权限、会访问哪些对象、会执行什么动作、结果会在哪里出现。没有理解的授权不是信任，只是被迫点击。

2. 用 artifact 建立信任

对 PM 来说，最可靠的信任载体不是解释，而是可审查产物：diff、preview、引用、报告、审批单、变更记录。让用户看结果，而不是只听 Agent 讲过程。

3. 控制点要少而准

每一步都确认会毁掉效率；完全不确认会毁掉信任。PM 应根据风险、可逆性和用户意愿设计控制点。

4. 把不确定性说成可操作信息

不要只说“我不确定”。更好的表达是：缺少什么信息、有哪些假设、用户可以如何补充、继续执行的风险是什么。

5. 把恢复路径放在用户看得见的地方

撤销、回滚、重试、修改、接管、升级支持，都应该在任务界面中可见。用户知道能恢复，才敢让 Agent 迈出下一步。

Trust UX 检查清单

Agent 执行前是否复述了任务目标、范围和关键假设？
用户能否看到计划，以及哪些步骤会需要人类决策？
结果是否有证据：引用、diff、测试、预览、日志或业务记录？
高风险动作是否展示影响范围、不可逆性和替代方案？
用户是否能暂停、修改、拒绝、接管或回滚？
信息展示是否分层，避免默认暴露过多技术细节？
失败状态是否清楚说明原因和下一步？
团队场景下，其他人能否理解 Agent 的动作和责任边界？

小结

Trust UX 的本质是把 Agent 的黑箱工作变成用户可理解、可控制、可验证、可恢复的过程。它不是装饰层，而是 Agent 产品能否从“试试看”进入“正式委托”的关键。

下一篇进入 Product Metrics：信任不能只靠主观感受，PM 需要用指标衡量任务是否被正确接收、推进、恢复和验收。