S75：W11 小结：Human Capacity、Trust Calibration、Feedback Provenance、DORA 与 DevEx

内容类型：预习教材（不代表已完成）
日期：2027-02-05
阶段：P2 · AI Systems Engineering 90
总路线：Day 165
周次节奏：W11 · 周五知识整理
状态：教材已备；学习未完成

一句话定义

W11 的结论是：人不是 AI 流程末端的无限 fallback，而是有决定权、信息需求、认知偏差、容量与反馈质量的系统组件，DevEx 与风险控制必须共同优化。

学习目标

1. 把 decision rights、queue capacity、evidence presentation、override/appeal 和 feedback provenance 画成一条运营链。
2. 区分 trust、reliance 和 calibration：目标不是让人更信 AI，而是在不同条件下适当使用。
3. 用 DORA/DevEx 视角观察速度、质量、恢复、认知负担与反馈，而不将 AI 产出数量当成生产力。

核心知识

Human capacity 要同时看人数、技能、时区、工单复杂度、上下文切换和情绪负担。增加 reviewer 不一定线性增加服务率，因为需要培训、协调和复杂案例匹配。最有用的运营问题不是“人够不够”，而是哪类工单正在什么优先级下消耗哪类专业容量。

Trust calibration 要求 reliance 与系统在当前分布和任务上的实际可靠性相匹配。一味强调“AI 会犯错”可造成 under-reliance；拟人化、高自信和一键接受可造成 over-reliance。校准需通过明确能力边界、evidence provenance、冲突显示、可退出与持续结果反馈建立。

Feedback provenance 是让反馈可解释的必要条件。一条“修改了 AI 结果”需知道 actor role、task context、原始建议、evidence seen、reason、new evidence、outcome 和 UI version。否则无法区分模型错误、规则例外、界面误导、reviewer error 或后续情况变化。

DORA/DevEx 提醒不要以 code suggestions、PR count 或 story points 作为 AI 价值的唯一代理。应观察 lead time、deployment frequency、change failure/recovery，同时保留开发者心流、认知负担、工具可靠性、反馈速度和安全感。AI 提高生成速度但增加 review/rework，系统净效果可能为零或负。

机制与推导

可用简化流程算账：

net_value = useful_outcome - review_cost - rework - incidents - delay - cognitive_load

这些项不需强行换成货币。关键是不把 useful outcome 与 output volume 混淆。信任校准可观察 conditional reliance：当有冲突证据、超出分布或高风险 action 时，人是否更多检查/升级；当低风险且证据充足时，是否避免无意义重复工作。

最小练习或观察

1. 把 S71～S74 四张图合为 input→AI evidence/recommendation→tier/queue→review→decision→appeal/outcome→feedback 链。
2. 每个节点写 owner、容量、可观测信号、常见偏差与 safe fallback。
3. 建一棵改进问题树：是流入问题、队列问题、证据呈现问题、权限问题还是反馈问题？
4. 为每个改进想一个反作用，例如提高升级会增加 backlog。
5. 输出 W11 小结即可，不设人机能力评分或考试。

常见误区与边界

• 把“人工复核”当成一个控制名称，不管容量、证据和真实决定权。
• 目标设为提高 AI trust，而不是改善适当 reliance。
• override 和用户反馈无 provenance 就直接进入训练数据。
• 用代码量、PR 数或建议接受率代替可用结果与系统可靠性。
• 本周是学习性运营模型，不是对真实员工、绩效或劳动安排的评价。

系统 / 金融 / Web3 连接

金融机构的 reviewer 可能同时承担案件决策、合规时限和客户沟通，AI 提高案件流入却不增加专业容量会制造新风险。Web3 工程中，code agent 快速生成合约变更时，应用 diff risk tier、变更理由、测试证据与人工审核容量限制流量。

自检问题

1. trust 与 calibrated reliance 的目标有何不同？
2. 一条可用 feedback provenance 需要哪些上下文？
3. AI output volume 为什么不能直接映射为 productivity？
4. 你的改进问题树是否同时包含人、界面、队列和技术？

专业课程对齐

• DORA：精读 software delivery performance、developer experience 与 AI-assisted development 相关研究，建立输出与系统结果的边界。
• Google PAIR Guidebook：精读 trust、mental models、feedback、errors 和 control，用于校准 reliance 与 feedback provenance。
• NIST AIRC / AI RMF：选读 human oversight、roles、transparency 和 measurement，把人机运营接到治理与 residual risk。

深入学习提示

先用 PAIR 复盘个体交互，再用 DORA 看工作系统，最后用 NIST 标出责任和风险。深入时优先追踪一条 feedback 从界面产生、进入队列、被采样到影响新版本的全链，找出语义和 provenance 在哪里丢失。

学后填写区

• W11 人机运营链：
• human capacity / trust calibration：
• feedback provenance 缺口：
• DevEx 与可靠性取舍：
• 下周保留的问题：