S74 · 总 Day 164教材已备 ≠ 学习已完成

S74：人机运营案例：Backlog、Fatigue、冲突证据、Active Learning 与 Code-agent Review

人机运营失效往往不是某一个模型答错，而是工单流入超过人类容量、证据编排放大偏差、反馈被错误采样，最终让系统在 backlog 和 fatigue 中逐步退化。

2027-02-04

内容类型：预习教材（不代表已完成）
日期：2027-02-04
阶段：P2 · AI Systems Engineering 90
总路线：Day 164
周次节奏：W11 · 周四案例与连接
状态：教材已备；学习未完成

一句话定义

学习目标

从 arrival、triage、review、decision、appeal、feedback 到 model/process change 走通一个人机运营案例。
识别 backlog age、fatigue、conflicting evidence、feedback selection bias 与代码审查负担的相互作用。
将 active learning 看成受预算、标注品质与数据治理约束的采样流程，不是“选最不确定的样本”一个公式。

核心知识

案例设定：一个文档 agent 将工单升级给 reviewer，但新版本降低了自信阈值，arrival rate 增加 60%。队列变长后，reviewer 优先完成简单工单，高风险复杂案例更老；为清 backlog，界面默认选中 AI recommendation，override 下降，但 appeal 延迟上升。这个链条说明“低 override”可能是疲劳和默认值的产物，不是模型质量提升。

Conflicting evidence 不应被摘要器强行合并成单一结论。应展示 source、time、authority、freshness 与冲突类型，并让 reviewer 能选择 request-more-evidence 而非只有 accept/reject。冲突多的工单可实现独立 priority boost，但也要防止被噪声攻击导致队列阻塞。

Active learning 的采样目标可包含不确定性、业务影响、多样性、新颖性、公平性覆盖和标注成本。只选最不确定的样本可导致大量噪声或分布外垃圾；只选 override 样本则忽略 reviewer 与 AI 同时错误的情况。反馈还需 provenance：谁在什么界面、看到什么证据后给出什么标签。

Code-agent review 是同类问题。生成更多 PR 可能让 merge throughput 上升，也可能让 reviewer 处于高频、低信号的 diff 中。应限制 diff size、标明 generated regions、提供设计理由和证据，并将高风险代码与普通重构分层；否则 AI 提速可被人工审核瓶颈抵消。

机制与推导

系统可用存量流量思考：backlog(t+1)=backlog(t)+arrivals-completions-expired。当 completion 靠降低审核深度提高时，短期 backlog 改善可能换来更多 rework/appeal。因此有效吞吐更接近：

effective_throughput = completed - rework - avoidable_appeals - escaped_errors

这些项的时间延迟不同，不能用一天的完成量证明改进。案例分析应同时保留 leading signals（queue age、inspection depth）和 lagging signals（appeal、escaped error）。

最小练习或观察

将上述案例画成 causal loop：升级率→backlog→fatigue→review depth→escaped error/appeal→rework→backlog。
为每个节点写一个可观察信号与一个可能替代解释。
设计一个只改变 queue priority 或 evidence presentation 的小调整，预测它对质量和容量的两面影响。
为 active learning 写一个多目标采样表，不实际收集真实用户数据。
将 code-agent review 作为迁移对照，写两个相同机制和两个不同风险。

常见误区与边界

backlog 下降就声称运营改善，没有看 expired、rework 与 appeal。
把 reviewer 当作稳定无限的资源，不观察疲劳和技能分层。
active learning 只采最不确定样本，或将 override 直接当作 ground truth。
AI 生成 PR 数量上升就声称工程效率提升，忽略 review/rework 与维护。
这是系统案例推演，不是真实员工生产力或人因研究结果。

系统 / 金融 / Web3 连接

金融调查队列中，法定时限、潜在损失、客户影响与证据冲突都可影响优先级，不能只按 confidence。Web3 安全审核中，代码 agent 可以生成修复，但涉及资金路径、权限与 upgradeability 的 diff 应有专业 reviewer，且不能因自动测试通过就降级人工审查。

自检问题

override 下降为什么可能是负面信号？
active learning 除不确定性外还应考虑什么？
effective throughput 为什么要减去返工与逸出错误？
code-agent review 与业务 HITL 的共同系统约束是什么？

专业课程对齐

Google PAIR Guidebook：精读 errors、feedback、explainability 与 user control，映射证据冲突、反馈与 automation bias。
DORA：精读 software delivery performance、developer experience 与 AI-assisted development 相关研究，用于审视 code-agent throughput 与系统效果。
Google SRE Book：选读 handling overload、monitoring 和 eliminating toil，将 reviewer backlog 看成容量、可靠性和工作设计问题。

深入学习提示

先用 SRE 解释 backlog 与 overload，再用 PAIR 审视界面和反馈，最后用 DORA 看交付系统。分析任何单一指标时，必须补一个“这个数字变好可能通过什么坏路径实现”的反例。

学后填写区

案例与 causal loop：
leading / lagging signals：
一个队列或界面调整：
active-learning 采样边界：
迁移到 code-agent review 的结论：