第二部分 — 文献：领域现状

文献综述二：从筛查走向预期用途证据

文献中最新的一个地层——仍然单薄，但推进很快——直攻筛查框架敞开 未合的那个缺口：用一个软件包、或任何流水线组件，适合你的预期 用途这件事，要靠证据来证明，而不是靠分数。本章回顾这场运动， 因为它既是这个领域的去向，也是本书自身研究的落点。

界定缺口的三个问题

近期以规格为驱动的工作(包括本书的姊妹论文 Human-Governed Validation of R Packages for Regulated Statistical Computing) 把这个缺口磨成了三个问题——对于执行路径上的任何东西，一份验证 档案都必须回答：

1. 你要求了什么？ 一份有版本的需求陈述，附验收标准，针对的 是你使用这个组件的具体方式——而不是软件包的通用文档。
2. 你如何知道它满足了这些要求？ 已执行的证据，把每条需求与 具体的测试用例及其结果一一挂钩。
3. 你如何知道你的测试能抓住相关缺陷？ 关于测试套件本身的证据 ——以变异式检查注入已知缺陷，确认套件确实会察觉。

第三个问题，是把验证与"核验表演"区分开来的那一问，而实践中几乎 从没有人问。

测试判官难题，与蜕变测试的解答

让第二个问题长期昂贵的障碍是判官难题(oracle problem)：对任意 输入，若不重新实现软件本身，你无法知道正确的输出是什么。解开它的 研究谱系是蜕变测试——从 Chen 的开创性工作一路贯穿软件测试文献—— 它把"这个输出正确吗？"换成"这一对输出是否满足某个已知关系？"序列 化走一个往返，应当还原出原物；置换行序，一个正确的统计量不应改变； 缩放输入，位置统计量应当相应地平移。

把它施加于 R 软件包，经由一个固定的、可审计的关系库，由确定性的 种子生成器驱动，便能得到期望结果系构造而来、而非猜测而来的测试 设计。姊妹论文的公开复演很能说明问题：一个往返关系揭示出，某序列 化默认设置的文档化精度语义未达到一项已声明的预期用途；一个合成的 时间-事件胶囊复现了预先规定的 Kaplan–Meier 与 Cox 输出，并在五十 项检查中通过了行序不变性；注入纯净软件包的四个预置缺陷变体，各自 恰好只让目标需求失败，而干净的软件包通过了全部用例——这就是对第 三个问题的实证回答。

抗拒篡改的记录

同一场运动同样关注证据栖身何处。已执行的记录进入只可追加、以 哈希链接的审计存储(Merkle 式)，使篡改可被发现，而不仅仅是被禁止 ——这一设计与 Part 11 的审计追踪直觉、与本书的工件寻址原则直接 相通。同一作者的相关工作(CAVE-Onc,PLOS One 2026)把一模一样的 监管链机制用于递交数据验证本身，把每一条验证痕迹写入防篡改存储。

LLM 入场，但在治理之下

最活跃的前沿，是大语言模型与验证相遇之处——而文献已经在警告它自身 的失败模式：从一开始就把 LLM 放进回路的原型，由它起草评估与结论， 人工复核只是事后补记。反设计是默认关闭、由人治理(fail-closed, human-governed)：模型只起草结构；每一个期望值要么来自机器捕获的 表征基线，要么独立推导；权限边界规则由代码强制执行，而非靠提示词； 批准始终是一位具名者的行为。在姊妹论文的公开契约复演中，十五项权限 边界检查全部守住——包括一组提示注入红队用例——恰恰因为边界是机械 的。同样的治理模式贯穿作者的相邻工作：以 LLM 辅助独立代码生成、 消除 QC 编程重复的工作(PharmaSUG 2026,AI-201)，以及一种 AI 辅助 的临床试验数据处理与统计编程方法论(ClinAgent,2026)。

这给领域留下了什么

把这些地层拼起来，图景是：一个成熟的筛查层(第 5 章)，一个正在 成形的预期用途证据层(本章)，一个对两者都明确免责的丰饶组件生态 ——以及，至关重要的是，没有任何已发表的架构把这些绑成一个运行 中的环境。这个绑定，正是第三部分的原则与第四部分的案例所尝试的。

检验。 对任何一个"已验证"的组件，只要一件工件：需求到测试的 可追溯性那一行，以及最可能伤到你的那条需求的故障注入结果。两者 缺一，你手里的不过是礼貌一些的筛查。