harm-anticipation

伤害预判

伤害预判是指系统地思考 AI 产品可能如何造成伤害——并在伤害发生之前采取行动。这是预防性设计，而非危机发生后的应对。

这项工作既不光鲜，也很容易被跳过。做好了，就能提出具体、可测试的缓解措施；做得不好，就会产出一份没人读的文档。

AI 伤害类别

• 直接伤害：AI 输出有害内容——危险建议、歧视性内容、侵犯隐私
• 助长伤害：AI 帮助用户实施有害行为，即使 AI 本身的输出无害
• 涌现伤害：由规模或交互效应产生的有害模式，而非任何单次输出造成
• 不作为伤害：AI 在应该采取行动时没有行动——未能发现危机、未能升级处理
• 侵蚀性伤害：逐渐产生的负面影响——依赖、技能退化、操纵、信任侵蚀

结构化预判

从以下五个角度逐一分析每种伤害类别：

1. 谁可能受到伤害？ 用户、与用户互动的人、弱势群体、整个社会。
2. 他们可能受到怎样的伤害？ 身体、情感、财务、声誉、隐私、自主权方面。
3. 发生的可能性有多大？ 常见用例、边缘情况，还是对抗性攻击。
4. 严重程度如何？ 不便、痛苦，还是不可逆的损害。
5. 可检测性如何？ 明显且立即可见，还是隐晦且延迟显现。

滥用场景

像对手一样思考：

• 有人会如何故意滥用此功能？
• 提取有害输出最简单的方法是什么？
• 这能否被用于操纵、欺骗或胁迫？
• 如果用户谎报意图，会怎样？
• 在自动化的大规模场景下会发生什么？

意外后果

思考二阶影响：

• 当用户达到数百万时，会发生什么？
• 用户会因依赖这项技术而失去哪些技能？
• 这会造成不公平的优势或劣势吗？
• 权力关系会发生怎样的变化？
• 哪些过去不可能的事情会因此成为可能——无论是利是弊？

决策规则

• 按发生频率 × 严重程度评分，而非只看严重程度。 在累积影响上，常见的中度伤害几乎总是胜过罕见的灾难性伤害。团队长期以来过度重视罕见的灾难性伤害，低估持续发生的中度伤害。
• 每种伤害都需要一个可证伪的测试。“如果 AI 对 Y 类型的用户做出 X，系统就应当执行 Z。”如果你无法写出测试，说明你对伤害的描述还不够精确——先完善描述，再采取缓解措施。
• 在能起作用的最低层采取缓解措施。 过滤输出不如约束提示词；约束提示词不如限定功能范围；限定功能范围不如不构建该功能。
• 每次规模跃升后都重新进行预判。 面对 1k、100k 和 10M 用户时，伤害都不相同。同一份清单在不同规模下会得出不同答案。
• 弱势用户决定底线，而非上限。 如果处境最不利的用户都能得到良好服务，其他用户也会受益。以中位数用户为对象、再为边缘情况打补丁，是错误的设计方式。
• 在探索阶段优先采用可逆的缓解措施。 过早锁定方案，你就会害怕重新审视假设。

反模式

• 事前复盘作秀：把预判危害的文档当作交付物来写，然后再也不打开。文档只是产物；实践才有价值。
• 只考虑最坏情况：只有灾难性危害才受到关注。发生频率中等、严重程度也中等的危害不断累积，却未得到处理，最终成为产品的真实写照。
• 只以对手为视角：预判恶意行为者，却忽略善意用户在意外情境下造成的危害（乐于助人的自杀热线接线员、好心提供法律建议的人）。
• 以清单代替缓解措施：把危害当成待勾选的事项，而不是持续的设计约束。一旦打勾，就认为危害已经“处理”，直到事实证明并非如此。
• 转嫁责任：“用户同意了服务条款，我们就免责了。”免责 ≠ 减少危害。用户仍然会受到伤害；只是公司得到了保护。
• 单一维度思维：只从一个危害类别进行预判，忽略交叉影响。“我们检查了偏见，也检查了隐私”——但偏见 × 隐私的交叉问题本身就是一种失效模式。
• 乐观主义式缓解：编写的缓解措施依赖用户察觉、用户报告或 AI 检测。如果缓解措施依赖传感器正常工作，就要审查传感器是否真的有效。

何时不使用

• 针对常规 UX 小问题（加载缓慢、文案别扭）——改用 failure-taxonomy 或 user-satisfaction-signals。危害预判关注的是后果，而非摩擦。
• 针对纯技术可靠性问题（延迟、正常运行时间）——这些属于 SRE 的职责；危害预判是位于其上的产品层工作。
• 代替红队测试——预判是规划活动；红队测试是探查活动。两者都要做，而非二选一。
• 作为上线时的一次性审计——能发现危害的预判，是持续进行的预判，尤其是在每次重大变更之后。

另请参阅

• trust-calibration — 过度信任本身就是一种危害类别；校准信任是最有效的缓解措施之一。
• escalation-design — 许多危害可以通过不独自处理来缓解。预判能发现触发条件；升级机制负责处理当下情况。
• bias-detection-design — 偏见是一种危害类别，有专门的检测方法；在此识别出偏见风险后，请使用这项技能。
• value-specification — 危害预判会列出各种约束；当约束相互冲突时，价值规范负责权衡。
• guardrail-design — 预判会产出需求；guardrail-design 则提供实现机制。

设计产物

• 伤害预判矩阵
• 滥用场景目录
• 事前验尸分析文档
• 产品功能风险严重性热力图
• 缓解措施跟踪日志，记录每种伤害对应的通过／失败测试

示例 — AI 心理健康支持聊天机器人的伤害预判矩阵中的一行：

字段	值
场景	用户处于急性危机中（使用表达自杀意念的措辞）并寻求建议。
伤害类别	遗漏伤害 + 直接伤害。
受害者	用户及其受抚养人。
发生方式	AI 未识别出危机，提供一般建议；用户因此延迟寻求紧急帮助。
可能性	中等 — 危机用户在使用者中占少数，但这类互动的风险最高。
严重程度	灾难性、不可逆。
可检测性	在单次互动层面较低（没有明显的不良输出）；事后回顾时中等（事件审查）。
缓解措施	对用户输入进行危机标记分类；检测到危机时，用硬编码的危机热线文案替换 AI 回复，并暖交接给人工咨询师。可证伪测试：使用包含 30 种已记录危机用语模式的红队提示；所有提示都必须触发覆盖机制。
缓解措施强度	位于比输出过滤更低的一层 — 完全替换回复，而非清除其中内容。
重新预判时机	用户数量增长 10 倍、模型版本变更、扩展语言支持时。

缓解措施配有测试。每次模型更新时都会运行该测试。这使伤害预判成为持续有效的约束，而不只是一份文档。

改编自负责任的 AI 部署相关研究（Raji 等人关于弥合 AI 问责缺口的研究；Weidinger 等人关于语言模型风险分类体系的研究），以及认知心理学中的事前验尸方法（Klein 关于前瞻性回顾的研究）。