AI 底层逻辑 / 经典论文
Sociotechnical AI / Resilience：工作系统
一句话:
329 行ai-foundations/papers/66-sociotechnical-ai-resilience-work-as-done.md
Sociotechnical AI / Resilience / Work-as-Done 解读
面向对象: AI Product Lead / AI Architect / Senior BA / Operations Lead / Governance Lead / Change Lead。 核心问题: 很多 AI 项目把系统边界画到模型、RAG、API 和 UI 为止, 但真实成败取决于人、流程、例外、工作负载、信任、反馈、组织职责和持续改进。AI 上线后, 工作会被重新分配, 责任会被重新解释, 例外会被放大或隐藏。 学习目标: 用社会技术系统和韧性工程视角, 把 AI 产品从“功能上线”升级为“可运营、可学习、可恢复、可治理的工作系统”。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| NIST AI Risk Management Framework | https://www.nist.gov/itl/ai-risk-management-framework | 将 AI 系统放入组织治理、风险、测量和持续管理循环 |
| Microsoft Guidelines for Human-AI Interaction | https://www.microsoft.com/en-us/research/publication/guidelines-for-human-ai-interaction/ | 参考 AI 交互中的期望校准、反馈、错误处理、人工控制 |
| Google PAIR Guidebook | https://pair.withgoogle.com/guidebook/ | 参考以用户任务、数据、反馈和人机协作为中心的 AI 产品设计 |
| Team Topologies | https://teamtopologies.com/ | 借鉴 team boundaries、cognitive load、interaction modes 对组织架构和平台能力的影响 |
一句话:
Sociotechnical AI 把 AI 看成由人、模型、数据、流程、工具、政策和反馈共同构成的工作系统; 产品成功来自整体适配, 不是模型能力单点领先。
1. Work-as-Imagined vs Work-as-Done
AI PRD 常描述 work-as-imagined:
用户提出问题 -> AI 给出建议 -> 用户确认 -> 系统执行 -> 流程完成
真实 work-as-done 往往是:
用户问题不完整
政策有例外
系统数据缺字段
客户情绪影响表达
一线员工有 SLA 压力
二线团队有 backlog
AI 引用看似正确但不适合这个客户
人工为了赶时间直接采纳
错误在下游投诉或审计中才暴露
如果只按 work-as-imagined 设计, AI 会在真实工作流中制造新风险:
- 把判断压力转移给一线。
- 增加二线复核负载。
- 让异常 case 更难被发现。
- 让用户误以为 AI 输出就是最终结论。
- 让组织把责任推给“模型”或“人工确认”。
2. AI 工作系统的组成
| 组成 | 关键问题 |
|---|---|
| Human Actors | 谁使用 AI? 谁审核? 谁承担责任? 谁有权 override? |
| AI Capability | AI 是检索、总结、分类、建议、决策还是执行? |
| Data / Knowledge | 数据来源是否权威、及时、可访问、可删除? |
| Workflow | AI 插入哪一步? 改变哪些 handoff? |
| Tools / APIs | AI 能读写哪些系统? 权限和限额是什么? |
| Policies | 合规、业务、风险、品牌、客户权益约束是什么? |
| Feedback | 用户如何纠错? 错误如何进入改进循环? |
| Monitoring | 谁看 dashboard? 什么信号触发行动? |
| Governance | 谁批准上线、扩展、暂停、下线? |
| Organization | 哪个团队拥有平台、知识、模型、运营、风险? |
高级 AI 产品设计要同时设计这些元素。
3. Human-AI Collaboration Patterns
| 模式 | AI 角色 | 人类角色 | 适用场景 | 风险 |
|---|---|---|---|---|
| Drafting | 生成草稿 | 编辑、批准 | 客服回复、报告初稿 | 人工过度信任 |
| Retrieval | 找依据 | 判断适用性 | 政策、知识库查询 | 引用正确但上下文不适用 |
| Triage | 排序、分类 | 复核高风险 | AML alert、投诉队列 | 低估长尾风险 |
| Recommendation | 给建议 | 接受、拒绝、override | 财富建议、下一步动作 | 责任边界模糊 |
| Decision Support | 给评分和理由 | 做最终决策 | 信贷、欺诈调查 | 解释不足、偏差 |
| Execution Agent | 调用工具执行 | 批准、监控、接管 | 退款、case update | 过度自动化 |
| Coach | 引导用户学习 | 用户自我决策 | 理财教育、员工培训 | 用户误解为正式建议 |
每种模式都需要不同的 UI、control、eval 和 operating model。
4. Handoff / Exception / Load
4.1 Handoff
handoff 不只是“转人工”。需要定义:
- 谁接手？
- 接手时看到什么 evidence bundle？
- AI 的不确定性和失败原因是否可见？
- 当前 SLA 是否重新计算？
- 客户是否知道状态变化？
- handoff 是否进入监控指标？
4.2 Exception
AI 系统的真实价值常被 exception 决定:
- 数据缺失。
- 政策冲突。
- 客户身份异常。
- 监管敏感话术。
- 多系统记录不一致。
- 用户请求超出授权范围。
- 模型置信低但语气肯定。
产品要把 exception 当一等公民, 而不是边角备注。
4.3 Load
AI 可能降低一个团队的负载, 同时增加另一个团队的负载:
| 表面收益 | 隐藏负载 |
|---|---|
| 一线客服更快回复 | 二线复核增加 |
| AML 初筛更快 | 高风险 case 积压 |
| 自动生成报告 | 审核人员需要检查更多文本 |
| agent 自动更新 CRM | 数据治理团队处理更多异常 |
要测量 total system load, 不是只测单点效率。
5. Resilience Metrics
韧性不是“永不出错”, 而是系统能发现、吸收、恢复和学习。
| 韧性能力 | 指标 |
|---|---|
| Detect | incident detection time、unsafe output discovery rate、drift alert coverage |
| Absorb | fallback success rate、manual queue capacity、graceful degradation rate |
| Recover | MTTR、rollback time、customer remediation time |
| Learn | error-to-fix cycle time、eval set update rate、policy update propagation time |
| Adapt | new scenario onboarding time、workflow change lead time |
| Coordinate | handoff completion rate、ownership clarity、cross-team review SLA |
这些指标比单纯 AI adoption 更能说明系统是否健康。
6. AI Operating Model
一个成熟的 AI operating model 至少包含:
| Capability | Owner | 关键职责 |
|---|---|---|
| Product Outcome | PM / Business Owner | 业务价值、用户体验、优先级、pilot |
| Requirement & Eval Contract | Senior BA / PM / QA | GQM、acceptance、golden set、UAT |
| Architecture | Architect | pattern、integration、quality attributes、ADR |
| Model / Prompt / RAG | AI Engineering | 模型、prompt、retrieval、版本管理 |
| Data / Knowledge | Data Owner / Knowledge Owner | source authority、lineage、freshness、权限 |
| Risk & Compliance | Risk / Compliance / Legal | policy, residual risk, review, evidence |
| Security & Privacy | Security / Privacy | threat model、DLP、access、logging |
| Operations | Ops Lead | review workload、handoff、SOP、incident response |
| Monitoring | Platform / SRE / Model Ops | dashboard、alert、drift、rollback |
| Continuous Improvement | Cross-functional AI Review Board | 错误复盘、eval 更新、策略调整 |
RACI 必须明确到真实动作:
- 谁能批准模型升级？
- 谁能修改知识库？
- 谁能放宽 guardrail？
- 谁能暂停 agent 写权限？
- 谁负责客户补救？
- 谁拥有 eval set 的代表性？
7. 金融零售案例
7.1 分行财富顾问 Copilot
Work-as-imagined:
顾问输入客户情况 -> AI 生成资产配置建议 -> 顾问确认 -> 客户接受
Work-as-done:
- 客户信息分散在 CRM、交易、风险测评和线下沟通。
- 顾问有销售压力和合规责任。
- 客户可能把教育性解释理解成正式建议。
- 市场信息和产品适配性快速变化。
- AI 生成内容需要 disclosure、suitability 和记录留痕。
设计重点:
- 把 AI 限定为 education / preparation / explanation, 高风险建议必须顾问确认。
- 显示资料缺口和不适用假设。
- 自动生成 evidence bundle, 而不是只生成漂亮话术。
- 监控 override、客户投诉、销售偏差和产品集中度。
7.2 AML Analyst 工作系统
AI summary 可能让 analyst 更快, 但也可能:
- 降低对原始交易的检查。
- 把模型总结当事实。
- 让二线复核只看 AI 生成 rationale。
需要:
- fact / inference / recommendation 分离。
- evidence trace。
- sampled review。
- high-risk mandatory escalation。
- analyst feedback 进入 eval set。
7.3 客服 Copilot
真正的成功不是回答更长, 而是:
- 客服更快理解政策。
- 客户得到一致但不误导的答复。
- 异常和投诉被及时升级。
- 错误输出能被发现并修复。
- 客服不会因为 AI 增加认知负担。
8. 反模式
| 反模式 | 表现 | 后果 |
|---|---|---|
| Model-centric delivery | 只汇报模型指标 | 真实工作流问题被忽略 |
| Fake HITL | UI 上有人工确认, 但人没有时间和证据判断 | 责任转移而非风险控制 |
| Adoption theater | 只看使用次数和采纳率 | 过度信任被误当成功 |
| Hidden work shift | 一个团队效率提升, 另一个团队负载增加 | 系统总效率下降 |
| Exception blindness | 只优化 happy path | 事故集中在长尾场景 |
| No learning loop | 用户反馈没有进入 eval 和产品改进 | 同类错误重复发生 |
| Governance by meeting | 靠会议决定上线和放宽限制 | 缺少可追溯证据 |
9. 设计模板
# Sociotechnical AI Design Brief
## 1. Work-as-Imagined
- Target workflow:
- AI inserted step:
- Expected value:
## 2. Work-as-Done Discovery
- Real exceptions:
- Informal workarounds:
- Data gaps:
- Handoff pain:
- Load constraints:
## 3. Human-AI Collaboration Model
- AI role:
- Human role:
- Automation level:
- Trust calibration:
- Override and feedback:
## 4. Operating Model
- Owners:
- Review cadence:
- Escalation path:
- Incident response:
- Change control:
## 5. Resilience Metrics
- Detect:
- Absorb:
- Recover:
- Learn:
- Adapt:
## 6. Governance Evidence
- Eval contract:
- ADR:
- Risk acceptance:
- Monitoring dashboard:
10. 面试回答
Q1: 为什么很多 AI 项目上线后效果不好？
30 秒版本:
因为它们把 AI 当模型功能, 没把它当社会技术工作系统。真实成败取决于工作流、例外、人工负载、信任校准、数据质量、反馈循环和治理责任。如果只优化 demo 和 adoption, 很容易把风险和负载转移到下游团队。
Q2: 你会如何设计 AI Copilot 的上线运营模型？
30 秒版本:
我会先对比 work-as-imagined 和 work-as-done, 找出真实例外和 handoff; 再定义 AI 与人的协作模式、HITL 控制点、反馈机制、monitoring 和 incident response。上线不是结束, 还要有 eval 更新、知识更新、模型版本管理和跨团队 review cadence。
追问准备:
| 追问 | 回答要点 |
|---|---|
| 怎么避免人工审核流于形式? | 给 reviewer evidence、时间、权限和抽检机制 |
| 怎么衡量 AI 是否真的减负? | 测 total system load, 不只测一线处理时长 |
| 怎么处理用户过度信任? | UI 信任校准、引用、不确定性、升级和教育 |
11. 作品集交付物
- Work-as-Imagined vs Work-as-Done Map。
- Human-AI Collaboration Model。
- Handoff / Exception Matrix。
- Total System Load Analysis。
- AI Operating Model RACI。
- Resilience Metrics Dashboard。
- Feedback-to-Eval Loop Design。
- Incident and Rollback Playbook。
- Sociotechnical AI ADR。
这套作品能体现你对 AI 产品的理解已经超出“功能 + 模型”, 进入组织、架构、风险和运营一体化设计。