#如何设计用户可信任的 AI 输出

用户不需要无条件相信 AI。

他们真正需要的是：能够判断这次输出是否可以使用。可信任的 AI 输出，不是看起来更自信、更完整、更像专家，而是让用户看见依据、边界、风险和可操作入口。

很多 AI 产品的问题不是回答太短，而是回答太像“最终结论”。模型把事实、推理、猜测和建议混在一起，用流畅语气包装出来。用户如果没有证据和控制手段，就只能在“相信它”和“完全不用它”之间摇摆。

AI 输出设计的目标，是把这种二选一变成可判断、可编辑、可追溯、可恢复的工作流。

#信任不是文案问题，而是产品结构问题

在传统软件里，用户信任系统，通常是因为系统规则稳定。订单金额来自数据库，审批状态来自流程引擎，报表指标来自计算逻辑。用户可以不理解全部实现，但他们知道结果不是凭空生成的。

AI 输出不同。它可能来自模型常识、用户输入、检索片段、工具调用、历史对话、系统 prompt 和中间推理。不同来源的可信度不同，但如果界面只展示一段答案，用户无法区分。

所以，可信任输出至少要拆成四层：

• Answer：AI 给出的结果。
• Evidence：支撑结果的来源、引用和工具结果。
• Uncertainty：哪些地方不确定、缺证据或可能需要人工判断。
• Action：用户可以如何采纳、编辑、重试、追问或提交。

如果只有 Answer，没有 Evidence、Uncertainty 和 Action，输出越流畅，风险可能越高。

#先区分输出类型

不同输出类型需要不同的信任设计。

AI 输出大致可以分成五类：

事实回答需要 citation。摘要整理需要覆盖范围和原文定位。创作草稿需要可编辑和版本对比。决策建议需要指标、解释和人工确认。执行动作需要结构化确认和审计。

不要用同一种答案卡片承载所有输出。信任设计必须和输出类型匹配。

#Citation 不是把链接贴上去

引用来源是 Trust UX 里最常见的设计，但也是最容易做浅的设计。

一个好的 citation 应该回答：

• 这句话依据哪一段资料？
• 来源属于哪个文档、网页、数据库记录或工具结果？
• 原文片段是什么？
• 来源是否在当前用户权限范围内？
• 来源是否过期？
• AI 是否正确使用了这段来源？

只在答案末尾列几个链接，帮助有限。用户需要的是答案中的具体断言和证据之间有对应关系。

更好的做法是：

• 在关键句旁边标 citation。
• 点击 citation 显示原文片段。
• 显示文档名、页码、段落、时间或记录 ID。
• 区分检索来源和模型生成内容。
• 当证据不足时明确说明。

例如：

客户合同可在提前 30 天书面通知后终止。[1]

[1] 合同_v3.pdf，第 8 页，终止条款：……

在产品工程上，citation 不应该只是 Markdown 链接，而应该是结构化对象：

type Citation = {
  id: string;
  sourceType: 'document' | 'web' | 'database' | 'tool_result';
  sourceId: string;
  title: string;
  locator?: {
    page?: number;
    paragraph?: number;
    rowId?: string;
    url?: string;
  };
  excerpt: string;
  usedFor: string;
};

结构化 citation 才能支持权限校验、点击定位、审计和 Eval。

#不确定性要具体表达

很多产品会用“AI 可能出错，请谨慎核对”作为免责声明。

这句话法律上可能有用，但 UX 上帮助很小。因为它没有告诉用户哪里可能错、为什么可能错、应该怎么核对。

更好的不确定性表达应该具体：

• “未找到 2025 年之后的数据。”
• “这份回答只基于你上传的 3 个文件，不包含外部网页。”
• “第 4 点缺少直接证据，是根据上下文推断。”
• “工具调用失败，以下结果来自缓存。”
• “检测到多个可能的客户记录，请先确认对象。”

不要把不确定性伪装成置信度百分比。很多场景里，83% confidence 对用户没有意义，甚至会制造虚假的精确感。

更实用的是把不确定性分成可理解的状态：

用户不需要模型装得全知，他们需要系统诚实地说明边界。

#让输出可编辑、可比较、可回滚

可信任不等于用户必须接受全部输出。

AI 结果最好以可操作对象出现，而不是一段不可分割的文本。尤其是写作、代码、配置、文档和业务记录场景，用户需要局部采纳。

常见设计包括：

• draft：先生成草稿，不直接发布。
• diff：展示修改前后差异。
• partial accept：逐段、逐句、逐文件接受。
• version compare：比较多次生成结果。
• inline feedback：对局部内容提出修改意见。
• undo：提交后可撤销或恢复上一版。

这些功能的本质，是让 AI 输出进入人的编辑流程，而不是绕过人的判断。

一旦输出会影响真实业务，版本和审计就很重要。系统应该记录用户采纳了哪一版、改了什么、提交到哪里，而不只是保存最终文本。

#可信输出要展示过程，但不要暴露噪音

AI 产品常常纠结：要不要展示模型思考过程？

用户需要的是可验证过程，不是模型内部碎碎念。可信输出应该展示对用户有用的过程信息：

• 检索了哪些来源。
• 调用了哪些工具。
• 使用了哪些过滤条件。
• 哪一步失败或被跳过。
• 哪些结果来自缓存。
• 哪些动作等待确认。

这些信息可以用 step timeline、source panel、tool trace 或 activity log 表达。它们比展示一大段“推理过程”更适合生产环境，也更容易审计。

对复杂任务来说，过程展示可以分层：

• 默认层：当前步骤和结果。
• 展开层：引用、工具参数、来源片段。
• 审计层：完整 run log、版本、权限和执行记录。

这样既不打扰普通用户，也能给专业用户足够的判断依据。

#产品工程视角：可信输出来自数据模型

Trust UX 不能只靠前端临时拼装。

如果后端返回的只是一个字符串，前端很难做 citation、版本对比、不确定性标记和工具追踪。可信输出需要结构化响应。

一个更实用的输出模型可能是：

type AIOutput = {
  id: string;
  runId: string;
  type: 'answer' | 'summary' | 'draft' | 'recommendation' | 'action_proposal';
  content: string;
  citations: Citation[];
  warnings: Array<{
    code: 'insufficient_evidence' | 'tool_failed' | 'permission_limited' | 'stale_data';
    message: string;
    recoverable: boolean;
  }>;
  actions: Array<{
    type: 'edit' | 'retry' | 'accept' | 'reject' | 'ask_followup' | 'request_approval';
    label: string;
  }>;
  version: number;
  createdAt: string;
};

这类结构可以支撑多端 UI，也能进入日志、Eval 和审计系统。

Eval 也应该覆盖 Trust UX。不要只评估答案是否正确，还要评估引用是否命中、是否遗漏风险、是否错误标注置信、是否在证据不足时主动说明。

#前端视角：把判断权还给用户

前端是用户判断 AI 是否可信的主战场。

它需要把模型输出变成一个可审阅的界面：

• 重要结论旁边显示来源。
• 风险提示靠近相关内容，而不是藏在底部。
• 用户能展开原文，而不必离开页面。
• 重试和反馈入口明确。
• 草稿和已提交状态有明显区别。
• 高风险动作进入确认面板。
• AI 修改有 diff，而不是静默覆盖。

视觉上也要避免过度权威感。AI 输出不应该被设计成不可质疑的系统公告。它应该更像“有依据的建议”或“待确认的草稿”。

#常见坑

第一个坑，是用流畅度伪装可信度。

回答越自然，不代表越准确。界面不能因为模型语气自信，就省略证据和边界。

第二个坑，是 citation 只做链接列表。

链接列表无法说明哪句话由哪个证据支撑。可信 citation 应该和具体断言绑定。

第三个坑，是滥用置信度百分比。

没有校准过的 confidence 分数会误导用户。很多时候，证据状态和风险提示比百分比更有用。

第四个坑，是把免责声明放在所有回答下面。

泛泛的“AI 可能出错”会很快被用户忽略。提示应该针对具体缺口、具体风险和具体补救动作。

第五个坑，是让 AI 直接覆盖用户内容。

没有 diff、没有版本、没有撤销的 AI 修改，会破坏用户信任。越接近真实工作流，越需要审阅和回滚。

#小结

可信任的 AI 输出，不是让用户相信 AI 永远正确，而是让用户有能力判断这次输出能不能用。

它需要证据、来源、边界、不确定性、可编辑性、版本和审计。对产品工程来说，这意味着输出不能只是字符串，而应该是带 citation、warning、action 和 version 的结构化对象。

当 AI 输出从“漂亮答案”变成“可审阅、可追溯、可采纳的工作对象”，用户才会真正愿意把它放进重要流程。