AI 溯源 UI：可信交互设计

AI 信号与现实校验（2026 年 2 月 19 日）

今日信号

“它为什么这么做？”正在变成一等产品表面——而不是一个支持工单。

当 AI 系统从“回答问题”升级为执行动作（预约、路由、编辑、审批、发送）时，很多团队正在悄悄形成一种新的 UI 原语：

决策溯源（decision provenance）： 用简洁、结构化的方式，展示系统用了什么、做了什么决定。

这不是长篇解释。 也不是带情绪的“故事”。 它更像是一张可读的“回执（receipt）”。

在实践中，做得最好的产品，通常会收敛到一组用户真正关心的溯源字段：

• **输入（Inputs）：**查阅了哪些数据源（邮件线程、日历事件、CRM 记录、文档段落）。
• **约束（Constraints）：**应用了哪些规则/政策（“不要给外部域名发邮件”“报销上限 $X”）。
• **工具调用（Tool calls）：**尝试了哪些动作（起草邮件、创建事件、开工单），以及使用了哪些参数。
• **不确定性（Uncertainty）：**系统在哪里不确定（缺少参与人、账户歧义、日期冲突）。
• **差异（Diffs）：**在编辑内容时做了哪些改动（前后对比）。

这相当于把产品从“相信我”推进到 “这是痕迹/轨迹（trace）”。

现实校验

*只有当溯源是可审计（auditable）的，它才会建立信任；否则它只是一个装饰性的“因为 AI 这么说”层。*

很多团队低估了一个事实：做出“看起来很好”的溯源很容易，但要让它在真实运营中可靠却很难。

常见坑包括：

1）溯源必须能穿过重试与部分失败。 当 agent 因为网络抖动、工具超时、或用户改了一个参数而重跑任务时，“回执”不能在没有记录的情况下悄悄变样。 用户会注意到：同一个任务，昨天写“用了来源 A”，今天又写“用了来源 B”。

2）溯源必须绑定到真实工件（artifact）。 如果溯源写着“查阅了 CRM”，却无法深链到具体记录/版本，它就会变成表演。 一条溯源只有在“可落地”时才有价值：记录 id、时间戳、查询条件、或者快照 hash。

3）溯源必须包含“政策决策”，而不仅是“模型决策”。 在 agent 系统里，很多失败并不是“模型胡编乱造”，而是“策略层允许了它”或“路由层选错了工具”。 如果溯源把这些层隐藏起来，你依然会在黑箱里排障。

4）过度解释会破坏信任。 用户不想看作文。 他们真正想要的是：

• 选择这个动作的一个关键理由，
• 检测到的一个关键风险，
• 以及一个可以修正它的入口。

如果溯源变成啰嗦的“合理化”，用户会被训练成不再阅读——而这恰恰发生在他们最需要阅读的时刻。

二阶推演

“回执”会变成竞争壁垒——也可能变成合规要求。

一旦溯源存在，它会迅速扩散到更多人群：

• 支持团队想用它来更快定位事故。
• 安全团队想把它当成审计轨迹。
• 产品团队想用它来做自治阈值的 A/B。
• 用户会用它来决定是否授予更大权限。

两个非常现实的转变会随之发生：

• **溯源优先的架构（provenance-first design）：**你会把 agent 设计成：每一个关键决策都必须产生结构化事件。
  • 没有输出事件，就当它没发生。
  • 发生了，就必须可链接、可追溯。
• **为“纠正”而不是“解释”的 UX：*溯源要变成可交互对象*。
  • “换一个线程做依据。”
  • “排除这个联系人。”
  • “下次设定更严格的策略。”

这时，溯源就不再是透明度表演，而是控制能力。

未来 24–72 小时观察点

• agent 产品是否会标准化一种可移植的“回执 schema”（输入、工具、政策、diff），并能跨厂商使用？
• 团队是否把溯源放进和可靠性遥测同一条管线里（从而把故障与具体的 tool-call 模式关联起来）？
• 是否会出现“可扫一眼的一行溯源”，并且只有在需要时才展开更多细节？

参考

• W3C PROV（描述溯源与可追踪性的成熟模型）：https://www.w3.org/TR/prov-overview/
• OpenTelemetry（跨系统可观测性的标准化 trace/span 基础设施）：https://opentelemetry.io/
• NIST AI 风险管理框架（推动可审计系统的治理与透明性预期）：https://www.nist.gov/itl/ai-risk-management-framework

Read in English →