一位客户的总法律顾问给你发来一封只有一行的邮件：“如果下周模型在我们的合规工作流中捏造了事实，谁的保险来赔付？”你把邮件转发给工程副总裁，他转发给法务，法务又转回给你。等这条转发链结束时，三个人都分别假设其他人已经仔细阅读过模型提供商的条款。但实际上没人读过。合同之间并没有真正的衔接——而你，作为中间层，是第一个发现这一点的人。
这就是 AI 赔偿缺口。它的存在是因为每个企业级 AI 产品都处于一个由三环组成的责任链中——终端客户、你的产品、模型提供商——每一环都默默假设下层在承担责任。模型提供商的条款将赔偿限额设定在过去 12 个月的费用总额左右，并明确排除对输出准确性的责任。你的 MSA（主服务协议）通过客户律师未仔细阅读的下游转嫁条款继承了这些排除项。而你的客户与他们的下游用户（当输出出错时真正的链尾受害者）签署的合同却将你的产品列为责任方，且没有明确的上游追索权。
第一次索赔发生时，大家才会发现这个缺口。在此之前，责任链上的每一个人都在抱着侥幸心理得过且过。
你的 AI 功能通过了压力测试。达到了延迟 SLA。回滚程序运行正常。成本估算在预算之内。你的 post-mortem 模板每一行旁边都有一个绿色的对勾。
上线两个月后，该产品出现在一篇关于歧视性结果的调查文章中。你花了六周时间进行法律审查。
这就是双重报纸测试旨在弥补的差距。大多数工程团队为技术故障构建了完善的发布前流程——可靠性退化、API 不稳定、基础设施成本飙升。他们阅读有关停机的 post-mortem 并进行相应优化。但第二类 AI 故障能直接穿透这些流程，因为它们看起来不像 bug：功能完全按设计运行，但伤害仍然发生了。
演示总是成功的。这是 AI 产品开发中最昂贵的一句话。产品经理看到模型处理好了理想路径（happy path），工程师发布了该功能的直观版本，六周后，支持队列里塞满了指标未能预见的投诉。模型本身没有退化。提示词（prompt）也没有变糟。只是该功能的形态并非模型所擅长的，而团队在工作开始前没有办法指出这一点。
相当大一部分已发布的 AI 功能都是以这种方式失败的——不是因为模型不好，而是因为任务错了。产品需要的输出是确定性的，而引擎是随机性的。用户对长尾误差的容忍度是千分之一的错误率，而模型的失败分布比这更厚。单位经济效益（unit economics）要求的延迟预算只有你在可负担范围内模型所能提供的一半。评估质量所需的地面真值（ground truth）并不存在，也无法低成本创建。这些都不是模型问题。它们是任务形态（task-shape）问题，应该在写下第一条提示词之前就被筛选出来。
在43%的测试提示中，GPT-4会在被要求续写给定段落时逐字复现书中原文。2025年的一项研究中，研究人员仅通过持续的前缀喂入循环——无需任何越狱操作——就从一个生产级LLM中近乎完整地提取了一本书的内容。如果你的产品使用语言模型生成内容，版权风险已不是未来的隐患，而是正在你的用户会话中实时发生，而你可能完全没有监测手段。
这不是一篇法律文章，而是一篇关于法律问题的工程文章——工程决策要么制造这个问题，要么遏制它。律师会告诉你什么构成侵权；这套框架告诉你系统在哪里泄漏、如何度量，以及哪些措施真正能降低风险，而不只是看起来有效。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
