S73：Evidence-first 与 Recommendation-first Review：交互顺序如何改变风险
Evidence-first 与 recommendation-first 的差异不是界面排版偏好，而是用户在形成初始判断前先看到证据还是 AI 结论，从而影响 anchoring、automation bias、复核时间与错误发现。
内容类型：预习教材（不代表已完成）
日期：2027-02-03
阶段：P2 · AI Systems Engineering 90
总路线：Day 163
周次节奏：W11 · 周三引导练习
状态：教材已备；学习未完成
一句话定义
Evidence-first 与 recommendation-first 的差异不是界面排版偏好，而是用户在形成初始判断前先看到证据还是 AI 结论，从而影响 anchoring、automation bias、复核时间与错误发现。
学习目标
- 设计两条内容相同、呈现顺序不同的审核流程。
- 从 decision quality、time、override、evidence inspection、confidence calibration 与认知负担观察取舍。
- 识别不同 review tier 为何可能需要不同的信息顺序，而不追求唯一最佳界面。
核心知识
Recommendation-first 可快速定向注意力，在低风险、任务熟悉、证据简单时降低处理成本。但它会产生 anchoring：reviewer 可能只搜索支持建议的证据，忽略冲突或缺失。高 confidence、绿色标识、拟人语气与一键接受会放大这种效应。
Evidence-first 先呈现来源、事实、冲突、缺失与时间戳，让 reviewer 先形成初步判断，再显示 AI recommendation 与理由。它可改善独立性，但当证据多、噪声大、界面不支持分组时，会提高 cognitive load 与 time-to-decision。“先证据”不等于把所有原始数据倾倒给人，而需结构化 provenance、relevance、freshness 和 uncertainty。
两种路线的比较要控制内容。若 evidence-first 给了更多证据，而recommendation-first 只给摘要，便无法将差异归因于顺序。不宜用真实用户或敏感决定做本日实验；可用自己对合成案例的 walkthrough，只产生设计观察。
机制与推导
复核质量可拆为：decision correctness + evidence coverage + calibrated uncertainty + procedural fairness，不应只看 acceptance rate。可观察：
- 首次决定前打开的证据数与冲突证据是否被查看；
- 接受/修改/拒绝的理由是否引用来源；
- time-to-decision、返工、appeal 与事后错误；
- reviewer 自信与实际正确性的差距。
这些指标仍受学习效应、案例难度和个人差异影响，小样本 walkthrough 不能得出通用人因结论。
最小练习或观察
- 写一个合成案例，包含 3 条支持证据、1 条冲突证据和 1 个缺失信息。
- 画两个低保真流程：A 先显示 recommendation，B 先显示 evidence；信息总量保持一致。
- 为两条路径各走一次，只记自己观察到的注意顺序、漏看点与决策时间，不声称用户研究。
- 把冲突证据放在不同位置，预测什么顺序最容易被忽略。
- 产出一张体验与风险观察表，不设优劣冠军。
常见误区与边界
- evidence-first 显示更多或更好内容，使顺序与信息量混杂。
- 用接受率高表示 recommendation-first 更有效，却不知道决定是否正确。
- 为反对 automation bias 而隐藏所有 AI 建议，损失低风险场景的效率价值。
- 将 confidence 当成准确概率，不检查校准、分布和生成方式。
- 个人 walkthrough 只是设计学习，不是真实用户行为或人因因果证据。
系统 / 金融 / Web3 连接
调查员复核高风险案件时，可先看来源、交易、时间线与冲突，再看 AI 叙述；普通格式检查则可先显示建议。Web3 签名界面应先展示可验证交易字段与 simulation warning，不应让 AI 的“看起来安全”结论在最前面成为锚点。
自检问题
- evidence-first 降低什么风险，又增加什么成本？
- 为什么两条路径必须保持信息总量一致？
- acceptance rate 为什么不是决策质量指标？
- 哪些 review tier 更适合先显示证据？
专业课程对齐
- Google PAIR Guidebook：精读 mental models、explainability、feedback、errors 与 user control，映射界面顺序与认知负担。
- NIST AIRC / AI RMF：精读 human oversight、transparency 和 context，检查高风险任务所需证据与决定权。
- DORA：选读 developer experience 和流程衡量，用来防止只增加审核步骤却不观察工作负担与反馈速度。
深入学习提示
以 PAIR 为主读材料，NIST 用于风险边界，DORA 用于工作系统取舍。对每个界面元素问三件事：它在什么时间出现，它引导注意力去哪里，它是否保留了查看原始来源和拒绝建议的能力。
学后填写区
- 合成案例与冲突证据：
- 两条 review 路径：
- 体验/风险观察：
- 未运行或不能外推的结论：
- 下一个最小设计问题：