# 术语表：对抗性代码审查与 AI 代码保障

> 每个术语一句话，单独引用时依然成立。市场所指的是什么，我们所指的是什么，以及在采购时这种差别在哪里起作用。

Source: https://counterproof.io/zh/glossary/ · Published 14 September 2026 · CounterProof 是 Clavestra Capital Limited（马耳他，C 113987）旗下的一项业务。


下面每条定义都是为了单独引用时依然成立而写的，因为定义正是这样流传的。限定条件写在句子之内，而不是放在后面的段落里。凡我们所指比市场所指更窄之处，写下的就是那个更窄的含义。方法类术语链接到详细阐述它的文章。标有“（英文）”的链接指向目前只有英文版的页面。

## 索引 {#index}

按汉语拼音排序；以拉丁字母开头的术语按其首字母归类。

**A**：[AI 代码保障](#ai-code-assurance) · [AI 代码尽职调查](#ai-code-due-diligence) · [AI 代码审查](#ai-code-review) · [AI 辅助带来的技术债务](#technical-debt-from-ai-assistance) · [安全代码审查](#secure-code-review)

**B**：[本真性](#authenticity) · [编译证明](#compile-proof)

**C**：[裁定](#adjudication) · [测试](#test) · [撤回记录](#withdrawal-log) · [传承](#transmission) · [CPR 报告](#cpr-report) · [CRA 测试报告](#cra-test-report)

**D**：[独立性](#independence) · [对抗性代码审查](#adversarial-code-review) · [对位](#counterpoint)

**F**：[发现项](#finding) · [范围](#scope)

**H**：[候选发现项与已确认发现项](#candidate-finding-vs-confirmed-finding)

**J**：[基准测试分数](#benchmark-score) · [见证者与证词](#witness-and-testimony) · [校勘](#collation) · [仅看似成立](#plausible-only) · [拒绝事项](#refusal)

**K**：[可判定问题与判断问题](#decidable-question-vs-judgement-question)

**L**：[类型化决策模型](#typed-decision-model)

**P**：[判定器](#oracle) · [谱系](#lineage)

**S**：[实际复现](#live-reproduction) · [Siglum](#siglum) · [锁定版本](#pinned-revision)

**X**：[席位](#seat) · [相关性错误](#correlated-errors) · [修复验证](#fix-verification)

**Y**：[严重程度与证据强度](#severity-vs-evidence-strength) · [阳性对照与阴性对照](#positive-and-negative-control) · [以共识为判定器](#consensus-as-oracle) · [已记录的阴性结果](#recorded-negative) · [源码追踪](#source-trace)

**Z**：[证据梯级](#evidence-rung)

---
## 对抗性代码审查（Adversarial code review） {#adversarial-code-review}

**带着攻击者的问题（怎样才能让这段代码做它不该做的事）去审查源代码，有别于为正确性或可维护性而进行的审查**。一些工具现在用这个词指这样一种安排：由一个模型审查另一个模型的输出；我们取的是它更早、更宽的含义，我们在此之上补充的内容见下文“判定器”“裁定”和“独立性”各条。详细阐述见[《对抗性代码审查：这个术语遗漏了什么》](https://counterproof.io/zh/adversarial-code-review/)。

## AI 代码保障（AI code assurance） {#ai-code-assurance}

**一个描述性的总称，涵盖旨在确立 AI 辅助编写的代码实际做了什么的各种实践；它不是标准、认证，也不是产品名称**。这是一个总称，本页用它来涵盖这一类别，而不是指称某项标准。

## AI 代码审查（AI code review） {#ai-code-review}

**由语言模型对一个差异（diff）或代码库进行的自动化审查，产出候选发现项，通常附有严重程度**。这类工具是有用的检测手段，我们也在使用；它们产出的是一次审查的输入，而不是一份经过裁定的审查记录。见[《发现项不是裁决》](https://counterproof.io/notes/a-finding-is-not-a-verdict/)（英文）。[《对抗性代码审查：这个术语遗漏了什么》](https://counterproof.io/zh/adversarial-code-review/)阐述了这类工具能提供什么、不能提供什么。

## AI 代码尽职调查（AI code due diligence） {#ai-code-due-diligence}

**由构建团队之外的一方对 AI 辅助编写的代码库进行的评估，在收购、投资或重大集成之前委托开展**。与常规的技术审查相比，它增加的问题是：构建团队之外，是否有人在一个指明的版本上确立了代码做了什么，并把证据写了下来。

## 安全代码审查（Secure code review） {#secure-code-review}

**在指明的版本上阅读源代码以查找安全缺陷，有别于测试一个正在运行的系统**。渗透测试针对的是已部署的实例；两者回答的是不同的问题，一个严肃的安全计划会两者并用。

## 发现项（Finding） {#finding}

**一位审查者关于某个缺陷存在的报告：一项有待对照代码加以确立的主张，而不是一个可以拿来计数的结论**。除了你的代码库中确实存在的情况，它还带着审查者的习惯和所用的提示词。见[《发现项不是裁决》](https://counterproof.io/notes/a-finding-is-not-a-verdict/)（英文）。

## 候选发现项与已确认发现项（Candidate finding vs confirmed finding） {#candidate-finding-vs-confirmed-finding}

**候选发现项是审查者提出的内容；已确认发现项是对照你的源代码、以确切的文件和行号、一条复现路径和一项影响分级加以确立的发现项；其余一律定级为“仅看似成立”**。每个候选发现项都会得到一个处置结果：已确认、定级为“仅看似成立”或被舍弃；无论结果如何，处置都会被记录下来。见[《发现项不是裁决》](https://counterproof.io/notes/a-finding-is-not-a-verdict/)（英文）。

## 证据梯级（Evidence rung） {#evidence-rung}

**记录一项已确认发现项实际取得了何种证据的标签；它从不暗示更高的梯级，描述的是该发现项的主张，而不是整个代码库**。共有四个梯级，从弱到强依次为：**源码追踪**、**编译证明**、**测试**、**实际复现**，各自的定义见下文；对于任何概率性的主张，还有第五个梯级：一个附有区间的比率，来自足够多次的试验，并保留每次试验的日志，因为一个测得的数字如果没有留存的原始记录，就是一个可撤回的数字。一个发现项如果一个梯级也没有达到，就不会被授予梯级，而是定级为**仅看似成立**，这是另一种处置结果。见[《什么能判定一项发现》](https://counterproof.io/notes/what-settles-a-finding/)（英文）。

## 仅看似成立（Plausible-only） {#plausible-only}

**未达到任何证据梯级的发现项所得的定级：这并非声称该问题无法回答，只是表明在本次委托中没有任何检查判定了它；这一定级会公开标出，而不是被埋没**。有些“仅看似成立”的发现项可以通过本次委托中未开展的工作来判定；另一些则取决于判断。报告会说明属于哪一种。见[《什么能判定一项发现》](https://counterproof.io/notes/what-settles-a-finding/)（英文）。

## 源码追踪（Source trace） {#source-trace}

**记录发现项所描述的代码路径已在锁定版本上被阅读、并引用了文件和行号的梯级；它确立的是源代码写了什么，而不是该行为在你的构建中可达**。

## 编译证明（Compile-proof） {#compile-proof}

**记录已按发现项的预测使构建先失败、再通过的梯级；它确立的是它所检验的编译期主张，对运行时行为则什么也没有确立**。

## 测试（Test） {#test}

**记录这样一项测试的梯级：该测试能把缺陷存在与不存在区分开来，在植入缺陷后运行并观察到失败，在移除缺陷后运行并观察到通过**。一项只通过过、从未失败过的测试，尚未被证明具有区分能力，达不到这一梯级。

## 实际复现（Live reproduction） {#live-reproduction}

**记录缺陷已在明确说明的条件下、针对锁定版本被复现的梯级**。它确立的是这些条件下的行为；换一种配置，就是另一项主张。

## 判定器（Oracle） {#oracle}

**一种能在明确说明的条件下判定某项具体主张的检查：一项已被证明能够给出相反答案的测试、编译或复现，或者为弄清一份规范性文本说了什么而对该文本的阅读**。只要存在这样的检查并且已经运行，它在该主张上的分量就高于任何审查者的意见，包括我们自己的。仅仅执行是不够的：一项不可能失败的测试什么也判定不了。见[《什么能判定一项发现》](https://counterproof.io/notes/what-settles-a-finding/)（英文）。

## 可判定问题与判断问题（Decidable question vs judgement question） {#decidable-question-vs-judgement-question}

**可判定问题存在一种能在明确说明的条件下判定它的检查；判断问题则没有**。“在给定这些输入时，这条路径是否会执行”是可判定的。“这有多严重，攻击者会不会费这个劲，这个信任假设能否接受”属于判断，再多的模型输出也无法把判断变成事实。见[《什么能判定一项发现》](https://counterproof.io/notes/what-settles-a-finding/)（英文）。

## 独立性（Independence） {#independence}

**三种不同的属性，我们只主张其中一种：独立于代码的作者。我们不主张审查者的错误之间存在经过测量的统计独立性，也不主张在商业上独立于你所在的市场：我们的集团在支付和数字资产托管领域进行开发，这一点会在任何委托开始之前以书面形式披露**。我们主张第一种：我们不评估由我们或我们集团内任何公司编写的代码。另外两种之中，审查者之间的错误相关性通过程序性措施加以约束，尚未针对代码审查进行测量；我们的商业立场即定义中所披露的那样。第二个模型在这里能提供什么、不能提供什么，是[《对抗性代码审查：这个术语遗漏了什么》](https://counterproof.io/zh/adversarial-code-review/)的主题。

## 拒绝事项（Refusal） {#refusal}

**我们不会代表客户作出的一项主张，事先公布，以便人们据此对我们进行追究**。我们公布的五项见[《我们不会主张的内容》](https://counterproof.io/zh/refusals/)。

## 谱系（Lineage） {#lineage}

**一个模型家族：同一开发者的一系列模型，被视为单一的见证者。它会被反复抽样，每个回答都是从中抽取的一次样本。来自不同谱系的审查者并不因此就相互独立；见[相关性错误](#correlated-errors)**。

## 席位（Seat） {#seat}

**审查小组中的一个审查位置：一个 AI 模型，来自一个[谱系](#lineage)，以其自己的任务说明和工具运行。没有返回任何可用内容的席位记为缺席，绝不记为同意；被发现与另一个席位共享上下文的席位不予计数**。

## 范围（Scope） {#scope}

**委托约定审查的内容，在报告中与未审查的内容一并列明**。一项评估中没有某个发现项，只有在范围表明该区域已被审查时，才具有信息价值。

## 阳性对照与阴性对照（Positive and negative control） {#positive-and-negative-control}

**阳性对照检查一种检测手段能否检测出它要寻找的东西；阴性对照检查当该东西不存在时它不会报警**。一种从未被证明能报告命中的检测手段，它报告的“未命中”也不能作为依据。见[《什么能判定一项发现》](https://counterproof.io/notes/what-settles-a-finding/)（英文），我们自己的一种检测手段在那里没有通过这项检验。

## 已记录的阴性结果（Recorded negative） {#recorded-negative}

**在说明的范围内运行、未检测到其所寻找的缺陷的一项检查，连同其条件写入报告；它弱于“代码是健全的”这一陈述**。它告诉读者找的是什么、是怎么找的，让不在场的人也能判断覆盖面。见[《攻击者可以运行任何模型》](https://counterproof.io/notes/the-attacker-can-run-any-model/)（英文）。

## 严重程度与证据强度（Severity vs evidence strength） {#severity-vs-evidence-strength}

**严重程度是对影响的判断；证据强度是对检查了什么的记录；一个发现项所带的严重程度，绝不超出其证据所能支持的范围**。这里的报告把两者分开陈述，因为单一的混合评级会掩盖究竟是哪一半在起作用。严重程度是没有源码依据的那个字段，也是会被夸大的那个：见[《发现项不是裁决》](https://counterproof.io/notes/a-finding-is-not-a-verdict/)（英文）。

## 修复验证（Fix verification） {#fix-verification}

**在关闭某个发现项的版本上，针对该发现项重新检查所打的补丁，并单独记录为一项结果；除非委托另有约定，由提出该发现项的同一审查团队进行**。一个已关闭的发现项会写明关闭它的版本，以便后来的读者能分辨哪些经过了验证、哪些只是被断言。

## 裁定（Adjudication） {#adjudication}

**为每个候选发现项决定处置结果（已确认、仅看似成立或舍弃）：有检查可用时交由检查，没有检查可用时交由一位具名的人员，而不是交由票数**。它同样适用于全体一致的发现项和仅由一位审查者提出的发现项，因为彼此具有相关性的审查者之间的一致并不构成确认。

## 撤回记录（Withdrawal log） {#withdrawal-log}

**我们在同一委托编号下撤回的发现项的书面记录，附有理由，并主动发给每一位收到原件的人**。见[《我们撤回了自己的数字》](https://counterproof.io/notes/we-withdrew-our-own-number/)（英文）。

## 锁定版本（Pinned revision） {#pinned-revision}

**一次审查所针对的确切提交，在报告中写明**。一个不写明其版本的发现项，无法对照它所描述的代码加以核查，无论它有何其他长处。

## CPR 报告（CPR report） {#cpr-report}

**以持久标识符 `CPR-YYYY-NNN` 发布的 CounterProof 评估，载有发现项、证据梯级、已记录的阴性结果以及任何撤回，并按委托所设定的保存条款保存**。你的维护者、你的收购方或你的修复提交所引用的，正是这个标识符。

## 相关性错误（Correlated errors） {#correlated-errors}

**不同模型倾向于犯同样的错误，而不是相互独立的错误；这一现象在某些领域已有测量，在漏洞审查领域尚未得到确立**。一项涵盖 350 多个模型的研究发现，当两个模型都答错时，它们给出**同一个**错误答案的频率远高于随机水平（Kim 等，ICML 2025，[arXiv:2506.07962](https://arxiv.org/abs/2506.07962)），研究对象是多项选择基准测试和一项简历筛选任务。认为这应当改变你看待两位审查者在你的代码上达成一致的方式，是我们的推论，而不是该研究的发现。见[《攻击者可以运行任何模型》](https://counterproof.io/notes/the-attacker-can-run-any-model/)（英文）。

## 见证者与证词（Witness and testimony） {#witness-and-testimony}

**把模型的输出当作证词，加以权衡并注明出处，而不是因其表述方式而信任它；因为流畅并不能确立真实，错误的答案与正确的答案以同样的口吻出现**。见[《分数的错觉》](https://counterproof.io/notes/the-illusion-of-the-score/)（英文）。

## 本真性（Authenticity） {#authenticity}

**一项读法或发现项的这样一种属性：见证者是通过自己对证据的接触得出它的，而不是抄袭另一个见证者、复述交给它的任务说明或附和既有的共识；它说明的是一项读法从何而来，而不是它是否真实，而且很少能被完整地证明：一个可能的来源所具有、而该见证者没有的错误，有时可以排除从该来源抄袭的可能；一项读法表述得多么自信，对其来源则说明不了任何问题**。这里的本真性属于一项读法，而不属于一个模型：模型没有可以忠于的自我，但人们可以追问，一个回答是来自证据，还是来自它看到的另一个回答、它的任务说明的措辞，或训练中固定下来的模式。只有在本真的读法之间，一致才算作佐证；一项照抄而来的读法无论多么准确，都不增加任何东西。正因如此，校勘者对抄自现存抄本的抄本不予采用；也正因如此，我们在任何人进行比较之前记录每位审查者的回答，并且不计入被发现与另一位审查者共享上下文的审查者。本真判断的反面不是错误的判断，而是承袭来的判断：之所以持有它，是因为它被继承了下来，而不是因为它经过了检验。随笔[《挣得，而非继承》](https://research.counterproof.io/essay/earned-not-inherited.html)（英文）对此有详细阐述。见[独立性](#independence)、[见证者与证词](#witness-and-testimony)和[对位](#counterpoint)。

## 校勘（Collation） {#collation}

**将多个见证者相互比对，以弄清哪些内容可靠；这是一个抽样和交叉核对的过程，无法找回任何审查者都没有提出的缺陷**。见[《发现项不是裁决》](https://counterproof.io/notes/a-finding-is-not-a-verdict/)（英文）。

## 传承（Transmission） {#transmission}

**信息通过复制从一个来源传到下一个来源：在抄本中，是从母本传到它的抄本；在 AI 模型之间，是一个模型的输出进入另一个模型的训练数据或工作上下文**。抄本传统和 AI 模型群体都可以作为信息传承系统来研究。错误和习惯会随被复制的内容一起传递。正因如此，一个共同的错误可以揭示一个共同的来源，前提是它不太可能是各自独立产生的；也正因如此，AI 审查者之间的一致可能只是在重复同一个源头，而不是对一个发现项的两次确认。研究论文列出了模型输出到达后来模型的四种途径：直接蒸馏、未加标注地混入所采集的文本、有意生产合成数据，以及受模型影响的人类写作；第 10 节又补充了工作上下文，作为尚未纳入该分类的另一个候选途径。传承是一个关乎承袭关系的问题；[对位](#counterpoint)则不是，因为对位的各个声部在同一部作品中同时鸣响，它们共享一位作曲者和一个构思，而不是彼此承袭。见[谱系](#lineage)、[校勘](#collation)以及[研究论文](https://research.counterproof.io/agentic-stemmatics.html)（英文）第 6 节和第 10 节。

## Siglum（抄本代号） {#siglum}

**校勘者给一个文本的每份现存或经重构的抄本所取的简短标签，例如一个字母，以便引用和比较其读法；在 CounterProof，它也是一个研究项目的名称：该项目仍在开发之中，其实际价值尚待证明，正在建设一个证据库和评估工具，用于研究 AI 审查者在什么情况下会漏掉同样的问题**。对每个受测的 AI 模型，该库将记录关于模型之间关系的已知信息、每次测试所用的确切设置以及给出的每一个回答。如果测试表明 Siglum 有效，CounterProof 打算基于它提供付费评估，因此我们对这些测试的结果有商业利益。见[《Siglum》](https://counterproof.io/zh/siglum/)。

## 对位（Counterpoint） {#counterpoint}

**几条旋律线同时鸣响，每条都保持自己的特性；在 CounterProof，用作审查小组的意象：关键在于每位审查者是否贡献了属于自己的东西，而这一点是意象本身无法显示的**。在严格对位中，禁止平行五度和平行八度的规则，阻止两个声部以这些音程平行进行，因为在这些音程上，两个声部听起来可能融为一体。我们的随笔把这条规则与文献学家关于共同错误的规则放在一起，读作一条关于何时可以信任 AI 审查者之间一致的规则，并说明了这一类比止于何处：声部可以各不相同，却仍然共享一位作曲者和一个构思。见[《音乐中的对位，方法中的 CounterProof》](https://research.counterproof.io/essay/counterpoint-and-counterproof.html)（英文）。

## 基准测试分数（Benchmark score） {#benchmark-score}

**在该基准测试上、按该基准测试的条件所测得的表现；能否迁移到你的代码库，是这个分数无法回答的另一个问题**。数据污染、具有相关性的评判者和 best-of-N 提交，都可能就一个你并没有问的问题给出正确的算术。见[《分数的错觉》](https://counterproof.io/notes/the-illusion-of-the-score/)（英文）和[《干净的基准测试不等于干净的代码库》](https://counterproof.io/notes/a-clean-benchmark-is-not-a-clean-codebase/)（英文）。

## 以共识为判定器（Consensus-as-oracle） {#consensus-as-oracle}

**一种基准测试设计，其参考标签是其他模型回答的平均值，而不是一个独立的结果；于是，参考模型共同犯下的错误被当作真实来计分**。对两位评判者取平均，可以减弱它们各自单独犯下的错误，却对它们共同犯下的错误毫无作用；相关性错误方面的文献发现，能力越强的模型，彼此共享错误的倾向越强。我们研究过的第一个公开披露的实例，是 TypeSafe AI 为其模型 Jev 发布的工作流评估，其参考是 GPT-6 Astra 与 Claude Fable 5.1 的平均值；在该供应商公布的 20 个案例中，有 19 个同时给出了两个参考模型的回答，其中 8 个案例里两者对最终操作意见不一。见[《TypeSafe Jev，以共识评分》](https://counterproof.io/notes/typesafe-jev-benchmark-consensus-labels/)（英文）和[《田野笔记 1》](https://research.counterproof.io/note/field-note-1-typesafe-jev-consensus-as-oracle.html)（英文）。

## 类型化决策模型（Typed-decision model） {#typed-decision-model}

**一种只返回选择、分数或针对提问者所提供选项的是/否概率，而从不返回文本的模型；它无法说出提问者遗漏的选项**。供应商的术语是“System One 模型”。它可以通过把概率分散到各个选项上，来表明没有一个给定选项合适，但问题集所遗漏的东西，对每一个回答它的此类见证者来说都始终处于遗漏状态。据其供应商的描述，2026 年 9 月发布的 TypeSafe AI 的 Jev 是这类模型中第一个公开的模型。这并非对该设计的批评，该设计适合路由和分诊；这是在说明其输出能作为什么的证据、不能作为什么的证据。见[《TypeSafe Jev，以共识评分》](https://counterproof.io/notes/typesafe-jev-benchmark-consensus-labels/)（英文）。

## CRA 测试报告（CRA test report） {#cra-test-report}

**为支持制造商依欧盟《网络弹性法案》编制的技术文档而准备的安全测试证据：它是支持性文件，不是符合性认证，也不是一种正式指定的文件类型**。该条例要求提供所开展测试的报告（附件七第 6 点），作为履行测试义务的证明（附件一第二部分第 3 点），并在产品投放市场后至少十年内，或在支持期内（以较长者为准），供市场监督管理机构随时调阅（第 13 条第 13 款）。我们不是公告机构。见[《标准可能推迟，报告日期不会》](https://counterproof.io/notes/the-standards-slipped-the-deadline-did-not/)（英文）。

## AI 辅助带来的技术债务（Technical debt from AI assistance） {#technical-debt-from-ai-assistance}

**AI 辅助工作中遗留未解决的不足之处所造成的未来成本；不是泛指一般的维护，也不是声称每个 AI 辅助项目都会产生它**。它是否出现，取决于任务、模型以及围绕它们的工作流程。见[《速度会消退，复杂性不会》](https://counterproof.io/notes/the-speed-fades-the-complexity-doesnt/)（英文）。

---

本页不主张的内容：运用这一方法即可确立某个代码库是健全的。我们尚未证明多审查者审查比单一审查者审查能发现更多真实缺陷；为检验这一点而设计的实验在开展之前即已撤销；任何审查都无法确立无人发现的缺陷不存在。更完整的论证及其局限见我们的工作论文，这是一份尚未经过同行评审的预印本草稿（英文）：[research.counterproof.io](https://research.counterproof.io/)（[doi:10.5281/zenodo.22030516](https://doi.org/10.5281/zenodo.22030516)）。如果本页内容有误，我们会在本页以书面形式更正。