p305. 信任架构：从黑盒到可审计的合作伙伴

信任问题是 AI 产品的核心 HCI 挑战。与传统软件不同，AI 产品的底层输出本身就是概率性的（c13 §13.2），这意味着不存在”100% 可信”的 AI 系统——产品设计的任务是在”用户实际信任程度”与”AI 真实准确程度”之间建立校准良好的映射关系。

3.5.1 信任的本质：校准，而非最大化

一个常见的产品设计错误：把”建立信任”等同于”让用户更信任 AI”。实际上，正确目标是校准信任（Calibrated Trust）——用户对 AI 的信任程度应与 AI 在该任务上的实际可靠性相匹配。

信任的累积曲线：信任建立缓慢（每次正确表现带来微小正向积累），信任崩塌迅速（一次重大失误可以清空数周的积累）。这意味着防守性的产品设计——避免高危的置信表现——比激进地展示 AI 能力更有利于长期留存。

展示 AI 是”怎么想”的，而非只展示最终结论：

折叠式推理面板：默认收起，用户感兴趣时展开查看完整推理链。对大多数用户，他们只需要结论；对专业用户和审核场景，推理链是验证质量的工具。

步骤摘要：将复杂推理压缩为 3–5 步关键节点：

1. 搜索了"XX 法规最新版本" → 找到 2024 年修订版
2. 发现条款 A 和条款 B 有矛盾 → 优先采用更新版的条款 B
3. 对比了 3 个案例 → 结论是...

工具调用日志：当 Agent 调用了外部工具时，展示调用了什么、得到了什么结果（与 m207 §2.4.5 Agent 评估的审计日志需求一致）。

Perplexity 的设计范例：搜索结果不只是一个回答，而是”来源 → 综合推理 → 结论”的完整链条，用户可以在任何一个环节点击深入。这是当前可解释性设计的最佳实践标杆。

模型不确定时，产品应诚实。这在短期内可能降低用户的”满意度评分”，但在长期内建立信任。

反面案例：模型对所有回答都表现出同等的自信语气（即使内部置信度很低）→ 用户几次被误导后彻底丧失信任 → 用户流失。这与 c13 §13.3 RLHF 对齐税直接相关——RLHF 训练的模型天然倾向于自信表达。

正面案例：模型在不确定时主动标注”我不确定这个信息是否最新，建议核实” → 用户偶尔被不确定的标注打断 → 但在关键时刻避免了被误导 → 长期信任建立。

透明度的悖论：过度的透明度（展示每一步推理、每一个不确定性）会造成信息过载，反而降低用户对 AI 的信任感（因为暴露了太多内部不确定性）。正确的做法是”分层透明”——默认展示结论和高确定性的关键步骤，进阶用户按需查看完整推理链。

用户不是 AI 的监考老师——HITL 的设计不应该让用户感觉”我在给 AI 改作业”，而应该让用户感觉”我在和 AI 协作”。

确认断点的设计原则（与 m207 §2.4.4 HITL 断点设计框架联动）：

新用户 vs 老用户的差异设计：

技术支撑：这种分阶段的信任设计需要后端系统追踪用户的”信任积累”数据——使用频率、采纳率、撤销率——作为动态调整 AI 主动性的依据（见 p307 §3.7.3 动态升降级）。