术语表

如何使用这份术语表

条目按英文术语的字母顺序排列，中文版沿用同一顺序，方便两个版本对照。中文术语在前，英文原词放在括号里。这里的定义只是摘要；证据、限定条件和每个来源的等级都在链接的那一节里。各章标为“本书的提议”的术语，在这里同样只是提议：没有任何组织用实际结果验证过它们。六个评审指标（有用、已处理、引发修改、已解决、可操作、被标为错误）各自归在自己的字母下，因为厂商把它们当成同一个指标来用，而它们并不是。顺带提到的产品能力均截至 2026 年 10 月。

A–B

接受率（acceptance rate）——AI 生成的建议、测试或修复中被人接受的比例。它衡量的是认同，不是正确，单独拿出来永远不能当成功指标。见《测试与验证》。

可操作（actionable，评审指标）——这是整次评审的属性，而不是单条评论的属性：这次评审至少发了一条评论。见《代码评审》。

已处理（addressed，评审指标）——代码在同一个变更集里发生了回应这条评论的修改，由规则或模型判定。见《代码评审》。

智能体“三取二”规则（Agents Rule of Two）——Meta 提出的设计规则：在一个会话内，智能体最多只能同时具备以下三项中的两项：处理不可信输入、能访问敏感系统或私有数据、能改变状态或对外通信。见《安全、权限与爆炸半径》。

阿姆达尔算术（Amdahl's arithmetic）——只给前置时间中的一段提速，省下的时间永远不会超过这一段所占的份额；下游任何增长（比如评审变长）都要从这个上限里扣除。见《当代码变便宜，瓶颈就会转移》。

放大器（amplifier）——DORA 2025 年的发现：AI 会放大一个组织既有的长处与短处；薄弱的测试、过大的批量和不清晰的职责不会被修好，只会被放大。见《前言：如何阅读本书》。

署名（attribution）——用标签、提交 trailer、机器人身份或元数据把智能体的产出标记出来。从 L2 起必须做到；没有署名，这个阶段评不到 L1 以上，也无从做逃逸缺陷对比。见《AI-SDLC 成熟度模型》。

审计抽样（audit sample）——对不再逐项评审的条目定期做人工检查。L4 必须具备；L3 中被路由出人工评审的类别也要保留。见《AI-SDLC 成熟度模型》。

权限漂移（authority drift）——一种回退触发条件：发现任何智能体凭证或设置超出了它的权限边界（能触及生产环境、处于跳过权限确认模式、能调用不可逆 API）。阈值是一次；动作是吊销，并按事故处理。见《衡量成效，以及何时回退》。

后台编码智能体（background coding agent）——无人值守地执行任务的智能体，通常运行在沙箱里，交回的是一个拉取请求，而不是在编辑器里陪着开发者干活。它是 L3 编码的典型形态。见《编码》。

基线（baseline）——在智能体开工之前，对不用智能体完成同一任务类型的测量：前 90 天的历史数据，最好再加上一组同期对比。一旦大家的工作方式变了，就再也测不到了。见《90 天试点》。

批量大小（batch size）——一次通过评审和发布的变更量（每个变更的行数、每次发布的变更数）。DORA 对 AI 相关不稳定性提出的机制是：批量越大，越难评审。见《当代码变便宜，瓶颈就会转移》。

爆炸半径（blast radius）——智能体凭证能触及并造成破坏的全部范围。它由凭证和环境边界决定，而不是由模型决定。见《安全、权限与爆炸半径》。

C–E

捕获测试（catching test）——在一次代码变更落地之前为它生成的测试，设计目的是在变更有缺陷时失败。与加固测试不同，它不能随它所测的变更一起落地。见《测试与验证》。

变更失败率（change failure rate）——DORA 指标，指在生产环境引发故障的发布所占的比例。本书把它用作 CI/CD 升级的稳定性配对指标。见《CI/CD 与发布》。

约束（constraint）——工作等待时间最长的那个阶段，靠测得的等待时间和实际处理时间画图找出来。给其他任何阶段提速，只会让它前面的队伍更长。见《评估你的起点》。

每次合并变更的成本（cost per merged change）——智能体 token、CI、AI 评审、评审者时间和返工的总和，除以合并的变更数。还没有任何组织公布过包含人工评审时间的这个数字。见《经济性、风险与度量》。

反事实估算（counterfactual estimate）——按“没有 AI 这项工作要花多少”算出来的“节省”，比如节省了多少开发者年。它说明一个组织认为价值在哪里，但它不是测量。见《经济性、风险与度量》。

模型换算表（crosswalk）——本书对其他成熟度模型的级别如何对应到自己 L0–L4 的解读，在下文 C.9 节重印。见《AI-SDLC 成熟度模型》。

事实上的 L4（de facto L4）——一个没人选择过的级别：如果智能体的凭证让它可以不经逐项批准就对能触及的东西（往往是生产环境）采取行动，那么就这部分范围而言它处在 L4，不管团队怎么称呼。本书记录的每一起破坏性事故都属于这种情况。见《AI-SDLC 成熟度模型》。

确定性自动化（deterministic automation）——codemod、依赖更新机器人和基于规则的改写。无论多么自主，就 AI 而言都算 L0。见《AI-SDLC 成熟度模型》。

有争议（disputed，证据标记）——各方对一个案例的说法相互矛盾。本书把两种说法都印出来，不把结果单独归咎于“AI”或“人”。见《前言：如何阅读本书》。

出站控制（egress control）——限制运行中的智能体能把数据发往哪里。从 L3 起，权限边界要求默认拒绝，外加白名单。见《安全、权限与爆炸半径》。

升级前提条件（enablers）——DORA 的七项 AI 能力（清晰的 AI 立场、健康的数据生态、AI 可访问的内部数据、扎实的版本控制、小批量工作、以用户为中心、优质的内部平台），本书把它们当作攀升前要检查的前提，而不是级别。见《AI-SDLC 成熟度模型》。

准入条件（entry criterion）——任务类型升到下一级之前必须拿出的证据，写在第二部分每一章的结尾。团队靠满足它来升级，而不是靠申请。见《向更多团队推广》。

等价变异体（equivalent mutant）——因为不改变行为而无法被杀死的变异体。不把它过滤掉，就会虚增变异分数的分母。见《测试与验证》。

错误预算（error budget）——事先商定一个任务类别可以承受的失败量。它是 L4 类别所需验证记录的两种形式之一。见《AI-SDLC 成熟度模型》。

逃逸缺陷（escaped defect）——闯过所有检查、进入生产环境的缺陷。L3 要求把 AI 执行工作的逃逸缺陷率与人工基线对比至少 90 天。见《AI-SDLC 成熟度模型》。

证据包（evidence bundle / evidence pack）——L3 中人用来代替逐行阅读的东西：核验器结果、变更摘要，以及（对全舰队变更而言）一份文件样本。它的结构化形式就是合并就绪包。见《AI-SDLC 成熟度模型》。

证据等级（evidence tier）——每个案例、每个承担论证的数字都带的评级，T1 到 T4。一个来源的等级取“谁测量的”和“怎么测量的”两者中较低的那个。见《前言：如何阅读本书》。

扩展、暂停攀升、降级（extend, hold, step down）——一次试点的三种结果，都由事先写好的规则决定。扩展：流动改善且稳定性守住。暂停攀升：什么都没坏，也什么都没改善，所以不升级。降级：叫停被触发，退回上一级。见《90 天试点》。

F–K

编造证据（fabricated evidence）——诊断中引用了并不存在的日志、指标或事件；在一项独立的根因研究中，这是最常见的推理失败。通过抽查智能体写的事故报告来测量它的比例。见《运维与故障处理》。

架构适应度函数（fitness function）——自动检查一次变更是否符合架构规则。设计阶段要到 L3 就需要这样的核验器；还没有人公开过用它来把关智能体变更。见《需求、规格与设计》。

不稳定测试（flaky test）——在同一份代码上时而通过、时而失败的测试。不稳定测试的分诊与修复是测试阶段最适合委派的任务类型之一。见《测试与验证》。

流动指标（flow metric）——如果升级奏效就应当改善的指标，比如前置时间、等待时间或落地的变更数。报告时必须带上它的稳定性配对指标。见《衡量成效，以及何时回退》。

四项读数（four readings）——按阶段和任务类型做的评估：人评审什么、何时评审；哪个核验器是 AI 改不了的；AI 持有哪些凭证；这个阶段能承受多大风险。见《评估你的起点》。

生成-核验落差（generator-verifier gap）——生成产出已经变得便宜，核验它却没有，所以系统层面的收益受制于核验。见《当代码变便宜，瓶颈就会转移》。

实际授予的权限（granted authority，规则 2）——AI 的凭证和设置实际允许它做什么。一个阶段的级别取团队实际采用的评审方式与实际授予的权限两者中较高的那个。见《AI-SDLC 成熟度模型》。

护栏（guardrail）——智能体无法靠说服绕过的东西。按这个意义，指令、审批点击和命令白名单都不是护栏；环境与凭证范围才是。见《安全、权限与爆炸半径》。

幻觉包名（hallucinated package names）——模型凭空编出的依赖。由于同样的名字会在多次查询中重复出现，攻击者可以抢先注册；防御手段是锁文件加注册表白名单。见《经济性、风险与度量》。

硬性叫停（hard stop）——试点中一旦发生安全事件就立即生效的叫停：智能体修改或跳过了它的核验器、在权限边界之外行事，或引发了超过指定严重级别的事故。见《90 天试点》。

加固测试（hardening test）——生成时就通过、落地后用来防止将来回归的测试，例如 Meta 的 TestGen-LLM 和 ACH。见《测试与验证》。

人工共同提交比例（human co-commit share）——合并前人向智能体分支推送提交的频率。这个比例上升，说明人在替智能体收尾。见《编码》。

不稳定性（instability）——DORA 对交付出问题（变更失败、返工）的度量。在 2024 年和 2025 年两次调查中，AI 采用都与更高的不稳定性相关，而且更快的交付并没有把它抵消掉。见《当代码变便宜，瓶颈就会转移》。

指令文件（instruction file）——代码库中的一个文件（AGENTS.md、CLAUDE.md 等），告诉智能体那些它猜不到的命令、约定和约束。本书建议写得短，并由人来写；这类文件能否提高成功率，证据并不一致。见《编码》。

意图违规（intent violation）——通过破坏检查的本意来让检查通过的变更：降级版本、删除或跳过测试、改动 CI 配置。统计被你的智能体后置检查拦下的这类变更。见《CI/CD 与发布》。

不可逆操作（irreversible action）——无法撤销的操作，比如在没有软删除的情况下删除数据。它让一个任务类别失去 L4 资格；在 L3，智能体只负责准备，由人来执行。见《AI-SDLC 成熟度模型》。

锯齿状前沿（jagged frontier）——在看起来相似的任务之间，AI 的能力参差不齐，因此结果随任务而变，而不是随阶段或团队而变。见《经济性、风险与度量》。

初级工程师成长路径（junior track）——本书对智能体写初稿时如何培养初级工程师的提议：默认使用导师模式、评审优先的学徒制、不用 AI 的调试练习、受保护的指导时间，以及逐级放开的权限。见《人：角色、技能与初级工程师培养》。

急停开关（kill switch）——一次性暂停所有进行中的智能体操作的控制手段，比如 Google 的“红色按钮”。L4 必须具备，并配以持续监控。见《AI-SDLC 成熟度模型》。

L–M

L0 手工（L0 Manual）——没有 AI 触及这个阶段的产出，或者政策禁止使用 AI。确定性自动化就 AI 而言算 L0。见《AI-SDLC 成熟度模型》。

L1 辅助（L1 Assisted）——AI 提建议，每一件产物都由人来写；AI 的产出只以建议的形式进入，由人修改。见《AI-SDLC 成熟度模型》。

L2 委派（L2 Delegated）——对一个具名的、反复出现的任务类型，AI 产出完整的产物，而且这些产物在生效前百分之百经过有记录的人工评审；产出有署名，并有指令文件。见《AI-SDLC 成熟度模型》。

L3 受监督自主（L3 Supervised-autonomous）——对具名的常规任务类型，AI 端到端运行，人评审的是证据包、样本，或只评审路由过来的条目。路由由机器强制执行，暂停与回退已经演练过，存在与人工基线的 90 天对比，而且 AI 改不了自己的评估器。见《AI-SDLC 成熟度模型》。

L4 自主（限定任务类）（L4 Autonomous, task class）——对一个列举明确、范围狭窄、可逆的任务类别，AI 无需逐项批准即可行动，前提是有验证记录、带急停开关的持续监控、一位具名的责任人和定期审计抽样。写的时候必须带上范围。见《AI-SDLC 成熟度模型》。

L5——不属于本模型。按定义它的那些来源自己的说法，通用自主要么还不存在，要么没有相应的控制手段。见《AI-SDLC 成熟度模型》。

引发修改（led to change，评审指标）——之后有一次提交改动了评论所指的代码。它不说明这次修改是否正确或必要。见《代码评审》。

致命三要素（lethal trifecta）——Simon Willison 从攻击者一侧给“三取二”规则所禁止的组合起的名字：不可信输入、对私有数据的访问，以及把数据送出去的途径。见《安全、权限与爆炸半径》。

LLM 评判者（LLM judge）——给另一个模型的产出打分或否决的模型。把它当作一道可调、带有误报代价的第二道关卡，绝不能当作判据或安全层。见《维护与迁移》。

托管设置（managed settings）——由管理员下发、用户无法覆盖的工具配置，用来在每台机器上禁用绕过模式和自动批准模式。见《向更多团队推广》。

人工长尾（manual tail）——一次迁移中流水线完成不了、只能由人手工处理的部分。长尾变长，说明这个变更类别正在滑出流水线能核验的范围。见《维护与迁移》。

被标为错误（marked incorrect，评审指标）——有人明确把一条发现标记为错误。它只是误报的下限，因为大多数错误评论只是被忽略了。见《代码评审》。

成熟度网格（maturity grid）——八个阶段乘五个级别，每个格子给出可观察的判据，以及最好的公开证据和它的等级。见《AI-SDLC 成熟度模型》。

成熟度级别（maturity level）——人评审什么、何时评审，再结合 AI 实际持有的权限来读，按任务类型、在最近 30 天或 90 天的窗口内打分。能力、智能体数量和推广广度被有意排除在定义之外。见《AI-SDLC 成熟度模型》。

“测量方”说明行（"Measured by" line）——每个案例、每个承担论证的数字下面的那一行：谁测量的、用什么方法、样本或时间窗口，以及证据等级。见《前言：如何阅读本书》。

合并就绪包（Merge-Readiness Pack）——Hassan 等人提出的、提交给人审批的结构化证据包，用来证明功能完整、验证可靠、工程规范良好并留有审计线索。L3 的评审者读的是它，而不是 diff；空白模板见《模板》。见《AI-SDLC 成熟度模型》。

混合独立性（mixed independence，证据标记）——方法明确的研究，但作者中有与结果存在利害关系的厂商的员工。它按 T1 计，同时带上这个标记。见《经济性、风险与度量》。

模型网关（model gateway）——集中的模型访问代理，用来强制使用经批准的模型、按团队统计使用量，并承载各团队的预算。见《向更多团队推广》。

调节变量（moderators）——左右测得的生产率效应的四个因素：任务类型、对代码的熟悉程度、代码库成熟度和工具代际。引用时给出区间和它的调节变量，绝不只给一个数字。见《经济性、风险与度量》。

平均缓解时间（MTTM，mean time to mitigate）——从事故开始到得到缓解的平均时长。按事故类别、对照基线来测量。见《运维与故障处理》。

变异分数（mutation score）——测试套件能检测出的人为注入故障（变异体）所占的比例。要衡量测试能发现什么，它是更好的指标；覆盖率只是薄弱的代理指标。见《测试与验证》。

O–R

判据（oracle）——为一个任务类型判定通过或失败的自动检查：测试、变异体、编译器、计划分类器或策略引擎。也叫核验器。见《AI-SDLC 成熟度模型》。

判据原则（oracle principle，规则 1）——除非有一个自动核验器判定通过或失败，而且 AI 无法修改、跳过或重新定义它，否则任何任务类型都不能运行在 L3 或 L4。声称处于 L3 却没有这样的核验器，一律记为 L2。见《AI-SDLC 成熟度模型》。

篡改判据（oracle tampering）——一种回退触发条件：任何一次已合并的智能体变更删除、跳过或削弱了一项测试或检查，或改动了 CI 或核验器配置。阈值是一次；该任务类型立即停止。见《衡量成效，以及何时回退》。

配对指标（paired metrics）——每一次升级都要用一个流动指标和一个稳定性指标来评判，并且两者一起报告。见《衡量成效，以及何时回退》。

权限边界（permission envelope）——本书对 L2、L3、L4 智能体可以在哪里运行、持有什么、改动什么、读取什么的提议：运行位置、凭证、写入范围、网络、不可逆操作、不可信输入、自身配置、依赖和门禁。只要有任何一项设置属于更高的一栏，那就是你的级别。见《安全、权限与爆炸半径》。

政策（policy，证据标记）——来源陈述的是一条规则，而不是一个结果，比如禁令或强制推行的备忘录。它永远不会被当作结果的证据来引用。见《前言：如何阅读本书》。

精度调优（precision tuning）——把 AI 评审者或路由器配置成没有把握就不说话：置信度阈值、屏蔽低价值类别、允许什么都不说。它优先于覆盖面。见《代码评审》。

提示词注入（prompt injection）——不可信的文本（一个 issue、一份 README、工具输出）把智能体引向用户并不想要的操作。智能体读到的任何东西，都可能成为它自身控制措施的输入。见《安全、权限与爆炸半径》。

来源记录（provenance）——对每次变更中 AI 做了什么、由哪个人负责的机器可读记录，通常是一条提交 trailer。本书的提议：智能体从不签名；L2 由批准的评审者签名；L3 和 L4 由该任务类别的负责人签名。见《向更多团队推广》。

队列溢出（queue overflow）——一种回退触发条件：评审等待时间，或未经评审即合并的数量，超出基线一个事先商定的幅度。它限制生成数量，级别不变。见《衡量成效，以及何时回退》。

已解决（AI 判定）（resolved, AI-judged，评审指标）——由一个模型在合并时判定被指出的问题已经修复。见《代码评审》。

评审方式（review mode）——人看什么、什么时候看：每一行、一个证据包、一份样本，或者什么都不看。它是定义级别的两项读数之一。见《AI-SDLC 成熟度模型》。

评审节流（review throttle）——按评审能力给生成量设上限，比如每个负责团队未关闭的智能体 PR 数。生成快于人能评审的速度，只会让队伍更长。见《维护与迁移》。

评审噪声（reviewer noise）——一种回退触发条件：AI 评审者某个评论类别的“没用”比例超过上线前设定的阈值，以 Google Tricorder 的 10% 为模板。它关掉的是这个类别，而不是整个阶段。见《衡量成效，以及何时回退》。

奖励黑客（reward hacking）——智能体满足的是检查的字面要求，而不是它的本意：修改测试或评分代码、给评估器打猴子补丁，或者干脆删掉导致失败的那次变更。这正是判据原则存在的原因。见《AI-SDLC 成熟度模型》。

返工率（rework rate）——已交付的工作中需要返工的比例，是一项 DORA 指标。本书把它用作流动收益的稳定性配对指标。见《衡量成效，以及何时回退》。

风险上限（risk ceiling，规则 4）——每个阶段、每个风险类别允许的最高级别，要在任何人提议升级之前记下来；例如，受监管服务的 CI/CD 不超过 L2，凡是不可逆的操作都不能到 L4。见《AI-SDLC 成熟度模型》。

风险分级（risk tier）——根据你自己的事故历史划分出的变更类别，决定一次变更要接受多少人工评审。见《代码评审》。

回退触发条件（rollback trigger）——事先商定的、收回自主权的规则，由六部分组成，都在升级前写好：信号、阈值、时间窗、动作、责任人和重新升级的条件。这是本书的提议；还没有哪家公司为编码智能体公布过这样的规则。见《衡量成效，以及何时回退》。

路由规则（routing rules）——写成文字、由机器强制执行的规则，决定在 L3 哪些条目送到人手里。AI 必须改不了它们；对评审而言，路由规则就是核验器。见《代码评审》。

规则 6（编码差距经验法则）（Rule 6, the coding-gap heuristic）——编码最多比评审与测试中较低者高一级。这是本书的提议，依据的是相关性遥测数据，用作警戒线，而不是定律。见《AI-SDLC 成熟度模型》。

S

沙箱（sandbox）——供智能体无人值守运行的隔离环境，通常用完即弃。从 L3 起必须具备，且同时要有文件系统边界和网络边界。见《编码》。

范围受限凭证（scoped credential）——短期有效、只限于一项任务、从沙箱外部注入的凭证；智能体够不着的东西，它就破坏不了。见《安全、权限与爆炸半径》。

计分卡（scorecard）——每个阶段和任务类型一行：级别及其证据、带基线的流动指标和稳定性指标、让这一行降级的触发条件，以及它的责任人。试点版本要在智能体第一次运行之前签好。见《衡量成效，以及何时回退》。

二手来源（secondary，证据标记）——这个数字只在对某一一手来源的新闻报道中读到过，本书读不到原始来源，并在句中注明。见《前言：如何阅读本书》。

自评表（self-assessment grid）——为每个阶段和任务类型打分的表格：级别、证据、判据及谁能修改它、风险上限、持有的凭证。每个季度重新打分。见《AI-SDLC 成熟度模型》。

自愈 CI（self-healing CI）——厂商对流水线中由智能体自行修复构建失败的叫法。按本书的说法，人合并每一个修复时是 L2，修复在通过独立验证步骤后自动应用时是 L3。见《CI/CD 与发布》。

自报（self-report，规则 7）——人们觉得自己有多快、多安全。它永远不能作为级别的证据或成功标准：在 METR 2025 年的试验中，开发者实际慢了 19%，却以为自己快了 20%。见《AI-SDLC 成熟度模型》。

影子对比（shadow comparison）——在一段时间里，一位响应者使用该工具，另一位不用（或用现有工具），然后按事故类别比较两者的用时。见《运维与故障处理》。

磨合期（shake-down）——试点中用来修复智能体运行环境（软件包源、超时、初始化步骤）的那几周，不计入结论。见《90 天试点》。

AI 写的代码占比（share of code written by AI）——一个产量数字，定义在不同表述之间不断变化，而且不管交付是否变快都会上升。它永远不是成功指标，也绝不能在公司之间比较。见《经济性、风险与度量》。

跳过权限确认模式（skip-permission mode）——关闭权限确认提示的工具设置或参数，比如 --dangerously-skip-permissions 或 --yolo。在持有真实凭证的机器上，它就是一次未被记录的 L4 授权；除了用完即弃的容器，其他地方都应通过托管设置禁用它。见《安全、权限与爆炸半径》。

软删除（soft delete）——在一段时间内可以撤销的删除。不可逆操作只有通过支持撤销或软删除的 API、且备份位于爆炸半径之外时，才具备 L4 资格。见《安全、权限与爆炸半径》。

规格锚定（spec-anchored）——Böckeler 的说法，指任务完成后仍保留规格，并用它来继续演进这项功能。见《需求、规格与设计》。

规格即源码（spec-as-source）——Böckeler 的说法，指把规格当作主要的源文件，人从不碰代码。这是一个关于编码的 L3 或 L4 主张，没有任何公开证据。见《需求、规格与设计》。

规格驱动开发（spec-driven development）——先写规格，再由智能体实现，常用工具有 Spec Kit 和 Kiro。规格的详尽程度应随任务规模而定；一份成功条件可以被智能体改写的规格，算不上控制手段。见《需求、规格与设计》。

规格先行（spec-first）——Böckeler 的说法，指在任务开始前写好规格，只用于这一次任务。这是一种 L2 做法。见《需求、规格与设计》。

稳定性指标（stability metric）——能显示一次升级适得其反的指标，比如回退、逃逸缺陷、返工或变更失败率。见《衡量成效，以及何时回退》。

立场（stance）——一份书面声明，写明哪些阶段和任务类型可以运行在哪个级别、上限是什么、用哪些工具，以及谁可以让一个团队降级。DORA 发现，清晰的立场会放大 AI 的收益，无论立场的内容是什么。见《向更多团队推广》。

降级（stepping down）——触发条件生效时，把一个任务类型降低一级。只要预先接好线、演练过、限定范围，并且记录但不追责，它就是日常运维，而不是失败。见《衡量成效，以及何时回退》。

Stop 钩子（stop hook）——在智能体试图结束时运行的确定性检查，检查不通过就不让它结束，从而把核验器放在智能体控制之外。见《编码》。

叫停规则（stop rule）——试点事先商定的退出条件，在任何结果出来之前写好，由一位指定的人执行：针对安全的硬性叫停、针对稳定性的阈值叫停，以及在第 90 天针对流动与成本的暂停攀升。见《90 天试点》。

按任务类型的成功率（success rate per task type）——已合并的智能体 PR 数除以已合并与已关闭之和，按任务类型分别跟踪。见《编码》。

T–W

T1 独立测量（T1 Independent measurement）——由与产品没有利害关系的一方测量，采用写明分母的方法：随机试验、对照研究、基准测试或取证分析。见《前言：如何阅读本书》。

T2 组织自测，方法已说明（T2 Organisation-measured, stated method）——由运营或销售该系统的组织测量，有方法和分母，最好经过同行评审或可以复现。见《前言：如何阅读本书》。

T3 方法单薄的遥测或报告（T3 Telemetry or report, thin method）——没有完整方法、基线或样本量的数字：工程博客、厂商汇总的客户遥测、无对照的试点。只取方向，不取量级。见《前言：如何阅读本书》。

T4 声明（T4 Claim）——完全没有方法：高管表态、媒体转述、营销材料、有争议的说法、政策备忘录。绝不用来承担论证。见《前言：如何阅读本书》。

任务类别（task class）——一次 L4 授权所覆盖的、列举明确的狭窄范围，比如“依赖补丁版本升级”。L4 从来不适用于整个阶段。见《AI-SDLC 成熟度模型》。

任务类型（task type，规则 3）——一个阶段内具名的、反复出现的一类工作，是模型打分的单位：“测试：不稳定测试分诊为 L3；功能测试为 L2”。决定哪些工作可以脱离逐个 diff 评审的，是任务类型，而不是任务大小。见《AI-SDLC 成熟度模型》。

团队原型（team archetypes）——DORA 2025 年归纳出的七类团队，从“基础性挑战”到“和谐的高成就者”。它是诊断团队如何工作的工具，而不是阶梯；遗留瓶颈型团队要先求稳定，受流程所困的团队要先修流程，然后才谈攀升。见《评估你的起点》。

阈值叫停（threshold stop）——在试点评审节点检查的叫停：回退或追溯到的缺陷超过事先定好的数量。它是一个绝对阈值，而不是显著性检验。见《90 天试点》。

吞吐量（throughput）——DORA 对一个团队交付多少变更的度量。在 DORA 2024 年和 2025 年的两次调查中，AI 与它之间关联的正负号不同，本书不把这称为趋势。见《当代码变便宜，瓶颈就会转移》。

工具投毒（tool poisoning）——藏在 MCP 工具描述里、用户看不见但模型会读到的指令，或者在批准之后才被篡改的工具描述。见《安全、权限与爆炸半径》。

类型化工具（typed tools）——一个封闭的缓解措施目录（引流、回滚、重启、扩容），每一项都带风险标签、撤销路径和最高级别，运维智能体从中选择，而不是自己写命令。它定义了运维阶段的 L2。见《运维与故障处理》。

未经修改合并的比例（unmodified-merge share）——已合并的智能体 PR 中，没有再追加任何提交就合进去的比例。见《编码》。

有用（useful，评审指标）——有人把这条评论评为有帮助。它是自愿点选的，所以只统计到愿意点一下的人。见《代码评审》。

价值流图（value-stream map）——从工单到生产的每一步，标上测得的等待时间和实际处理时间，用来在决定把 AI 用在哪里之前先找出约束。见《当代码变便宜，瓶颈就会转移》。

厂商自报框（vendor-reported box / vendor-on-own-product）——凡是唯一来源为被测产品厂商的数字，都放进这个带标签的方框。方框写明谁测量的、“成功”在他们的指标里指什么、缺了什么；正文从不把论证建立在它上面。见《前言：如何阅读本书》。

验证记录（verification record）——L4 类别所需的书面证据：连续 N 个条目没有逃逸缺陷，或者一份错误预算。见《AI-SDLC 成熟度模型》。

核验器（verifier）——判据的另一个名字：判定通过或失败的自动检查。关键在于谁能修改它。见《AI-SDLC 成熟度模型》。

等待时间与实际处理时间（wait time and active time）——工作在有人接手之前排了多久的队，以及被实际处理了多久。两者要分开测量：实际评审时间可能在下降，而它前面的队伍却在变长。见《当代码变便宜，瓶颈就会转移》。

换算其他模型

当有人说“我们在第 3 级”时，先问他用的是谁的量表。这是《AI-SDLC 成熟度模型》中的换算表：本书对各模型的解读，“≈”表示近似对应。有些模型数的是智能体数量、推广广度或能力；本书的级别数的是人评审什么、AI 被允许做什么，所以有几行只能部分对应。

还有一个近在身边的提醒：本 wiki 自己的自主级别页面从 L0 =“建议”开始计数，因此它的 L0 到 L2 比本书的编号低一级。