高后果场景不应把核查完全交给用户

概念解释

夜班里一条剂量建议生成完毕，旁边写「请自行核对药品说明书」。核对的人同时看着三台监护仪，没有第二条被维护的确定性路径。后果一旦发生，系统把「你没核」当成已经完成的分配。高后果核验不可转嫁（non-delegable checking）指的是：错误代价超过用户当场能支付的注意时，核验必须由系统侧的约束、校验或拒绝来承担，不能只作为用户的课后作业。

免责声明把责任写在纸上，是另一件事。这里管的是核验劳动在事故发生前有没有被真正执行。

机制

高后果任务里，人已经把注意预算花在情景本身：病人、金额、法律时限。生成把一道新的核验任务叠上去，而这道任务的难度与生成器的流畅程度成反比。界面用「请核对」完成了程序上的交接，没有提供执行核对所需的时间窗口、对照物和失败时的停机。

责任分配若只写在文案里，实际执行仍按最小费力走：看起来正常的输出被采用。高后果与「看起来正常」叠在一起时，转嫁核验等于把事故概率留给现场。

怎么研究

在有真实代价的任务里（模拟用药、模拟转账、模拟法律提交）比较三种：仅免责、免责加核对清单、系统侧硬校验（剂量范围、账户白名单、条款模板）。因变量：未核验采用率、被拦住的错误数、任务完成时间。自变量：时间压力、核对入口是否打断主路径。

「被试事后说自己会核」不能当证据。要看提交前是否真的打开了对照物。时间压力条件必须有，否则实验室会高估核验执行率。

边界

后果低且可逆（草稿标题、内部头脑风暴）可以把核验留给用户。用户是该领域的核验专职（编辑、药剂师在自己的工作台上）且系统提供对照物时，核验可以是其工作的一部分，但仍不能只靠一句「请核对」。系统做不到校验的领域，正确降级是拒绝生成事实输出，而不是生成再转嫁。这条不讨论页脚声明对传播的影响，只讨论事故前核验是否被执行。

怎么落地

• 对剂量、金额、法律后果、身份识别这类输出，先走约束与校验；校验失败则不给出可复制的事实句。
• 核对若仍需要人，必须打断主路径：对照物并排、确认控件在提交之前、默认不可一键采用。
• 不要把「请自行核对」当作高后果场景的完整设计。它不提供时间，也不提供对照。
• 验证：在时间压力下跑一次目标任务，统计有多少人在提交前打开了对照物。接近零而错误仍能被提交，核验已经被转嫁且未被执行。

延伸

• 同组：L3.03.1 流畅表述不等于正确 · L3.03.2 核查成本可能高于自行完成 · L3.03.4 错误分散在正确内容之中时，核查必须逐句进行，成本接近自己重写 · L3.03.5 用户越不熟悉某领域越难核查，而这正是最可能求助系统的场景 · L3.03.6 表述的确定语气与内容的可靠程度之间没有关系 · L3.03.7 数字、日期与人名一类具体细节的错误最难察觉且后果最大 · L3.03.8 把核查责任写进免责声明并不减少错误的实际传播
• 相邻：L1.05 人在回路 · L4.11 行动前确认与不可逆操作
• 站内检索：non-delegable checking · high-stakes verification · offloaded fact-check