Russ Little 提出 ZTHR 模式，用零信任机制替代 AI 代码评审

Zero Trust – High Reliability。一种面向 AI 构建软件的 pattern language。 Russ Little · v1.0 · © 2026 Russ Little, CC BY 4.0 · DOI: 10.5281/zenodo.23826734

AI 让写代码变得廉价，但判断代码是否正确并没有变得更便宜。大多数团队把 AI 作者硬塞进一个由人工 code review（代码审查）控制节奏的流程里，而在真实体量下，这个流程会以两种方式之一失效：要么审查者成为拖住交付的瓶颈，要么他们变成橡皮图章，批准没人有时间读的东西。用同一模型的另一份副本来替代人类审查者并无帮助。共享训练数据的模型也共享盲点。

等待一个足够可信的模型，是在重复那个旧假设：质量存在于作者身上。更好的作者仍然需要证据来证明某个具体改动是正确的，而证据必须来自作者无法控制的地方。

让 AI 写代码，并构建一座无法被欺骗的工厂，来判断代码是否可用。

对称零信任。任何作者、审查者、模型、操作员或报告，都不能通过声称成功来获得权威。一个主张只有在基于主张者无法控制的证据时才成立。这条规则适用于所有方向：对写代码的 AI、对产品内部运行的 AI、对自动化检查本身，以及对操作流水线的自动化。一个从未被证明会失败的测试，不值得信任它能通过。

夹具反转（Fixture Inversion）。质量从作者的技能转移到作者所处的工作环境中。这正是制造业两个世纪前完成的转变：夹具、固定装置和通过/不通过量规让普通操作员也能生产出工匠无法达到的公差。在软件中，夹具是受治理的基础和合格部件目录，它们限制了可以构建什么。量规则是那些已被证明会在其旨在捕获的缺陷上失败的检查。基准——一切测量的参照——是用户意图：人们来做什么，被写下来，且作者无法更改。

AI 生成候选。夹具评判它们。被拒绝的候选会返回重试，需要多少次就多少次；重试很便宜，而发布缺陷不便宜。只有通过所有夹具的候选才会被准入、部署，并被验证为确实在提供服务。

每次改动在提交前至少由来自不同模型家族的三个模型审查：一个获得上下文，一个只获得 diff，一个独立检查代码。第四个模型在完全晋级前在原位审查。最强的检查以不同形式读取系统（源代码、数据库、构建产物、渲染出的屏幕和正在运行的服务），因为不同表示形式的读取者不可能全部共享同一个盲点。

当缺陷漏过时，修复不仅针对代码。还会新增一个夹具，使这类缺陷永远无法再次通过。变异测试、每晚尝试破坏系统、外部服务的校准孪生体，以及每一代新模型的重新审查，持续发现没人想到要测试的东西。工厂每周都变得更严格，它构建的一切也是如此。

人们不再阅读 diff，而是开始做能产生复利的工作：与掌握意图的用户一起定义意图，构建和治理夹具，并判断重大风险。可审计、可一步回滚的确定性改动自行推进。破坏性或多步骤改动、对 AI 本身的任何改动，以及任何 agent 请求更宽权限，都需要人工签字批准。

质量与规模不是取舍关系。每个夹具都替代了一个原本必须盯着那种失败的人，因此一个构建者或一个小团队就能以传统团队需要更多人才达到的水平运作。

首要指标是意图完成率：软件让人们完成他们来此要做的事情的频率。它衡量做对了什么，而不仅仅是做错了什么。有意义的比较是同等条件下、按体量归一化后，与今天的工作方式对比。AI 永远不会完美，也不需要完美；问题是它是否比当前流程更好，而夹具让这一点可以衡量。

最大的风险是系统构建它被告知的东西。坏的规格会被和好的规格一样忠实地执行，因此 ZTHR 在生成任何代码之前，会对照现有部件目录并从第一性原理审查规格。有夹具的软件，其正确性取决于其夹具的忠实程度。这不是完美的主张；而是说忠实地执行是可见的、可衡量的并且在上升。

ZTHR 已在一个受监管行业的绿地系统开发中投入生产使用，并被证明非常有效。它的三十三个模式描述的是如何做与为什么，而不是一套工具，因此它们可以迁移到大多数软件工程工作中。

进一步阅读：五页简报更深入地介绍每一条原则、六个模式家族和治理。完整论文列出了全部三十三个模式及其作用力与后果，并在 zthr.ai 公开出版。