作者：Lei阅读 --

当写代码不再是瓶颈：20 个术语读懂 AI 时代的软件验证

用 scrapling 抓取并深读 Shiplight 的 AI 测试术语表：验证为什么取代编码成为新瓶颈，AI-augmented / AI-native / agentic / agent-native 四个词怎么分，"定位器是缓存"这个值得偷走的心智模型，以及怎么带着防伪眼镜读一份厂商定义的词汇表。

AIAgent上下文工程

一个编码 agent 一周能开 40+ 个 pull request，而一个人一小时只能认真读懂几个 diff。当代码生成的速度提升了 2-5 倍、而测试和验证还停留在人肉速度时，多出来的速度不是生产力——是一队排得越来越长的、没人检查过的变更。

这篇文章深读的对象有点特别：不是论文，不是框架源码，而是一份厂商术语表——AI 测试公司 Shiplight 发布的 AI 测试词汇表，20 个词条。我用 scrapling 把全部词条页面抓下来通读了一遍。

如果你只带走一句话，就带走这个：

AI agent 接管代码编写之后，软件工程的稀缺资源从”写代码的手”变成了”验证代码的注意力”。谁先给这个新瓶颈里的概念命名，谁就拿到了这个品类的定义权——这份术语表就是一次公开的命名行动。

所以这篇文章要做两件事：一是把术语表里真实存在的工程问题和值得偷走的心智模型挖出来（这部分有独立学术研究背书）；二是示范怎么带着防伪眼镜读厂商内容——哪些是真问题，哪些是抢定义权，哪些是营销数字。

先交代读法：一份术语表的三层成分

打开这份术语表的任何一个词条，结构都一样：定义、为什么重要、和相邻概念的区别——然后不出意外地拐到”这正是 Shiplight 解决的问题”。20 个词条，每一个都通向同一个产品。

这不是缺点，是体裁。厂商术语表是一种经典的品类营销：HubSpot 定义了 “inbound marketing”，HashiCorp 定义了 “infrastructure as code” 的一半词汇。创造词汇的人不需要说服你买它的产品，只需要让你用它的词思考问题。 读这类内容的正确姿势是分三层拆：

  1. 真问题层：它描述的工程矛盾是否真实存在？——需要独立来源交叉验证；
  2. 概念层：它铸造的术语和区分是否有认知价值？——好的区分即使脱离产品也站得住；
  3. 数字层：“效率提升 10 倍"" QA 时间从 60% 降到接近零”——这些是客户案例式营销数字，默认不可迁移到你的团队。

下面按这个顺序来。

真问题：速度失衡是结构性的

术语表里最有分量的两个词是 Coverage Decay（覆盖率衰减）和 AI Test Debt（AI 测试债），它们描述同一个失衡的两个侧面。

覆盖率衰减的洞察在于把覆盖率从”状态”改成了”速率”：

覆盖率缺口（gap）是一个状态，衰减（decay）是一个速率。一个团队可以带着 90% 的总覆盖率，同时只有 30% 的”近期变更覆盖率”——前者是虚荣指标，后者才是真信号。

这个区分是有牙齿的。总覆盖率是滞后指标，衡量的是历史上写过多少测试；变更表面覆盖率（changed-surface-area coverage，最近 30 天被修改的代码里有直接测试覆盖的比例）衡量的是你的测试是否跟得上当下的变更速度。当 agent 把代码速度拉高 2-5 倍而测试还靠人写时，衰减速率转正，缺口每个 sprint 复利式扩大。

AI 测试债则把这笔债拆成三种成分，这个分类学值得记下来：

债务成分是什么症状
覆盖债新代码路径没有测试就上线变更覆盖率持续走低
稳定债flaky 测试堆积，被隔离后无人修复隔离名单只增不减
归因债测试靠”选错了元素”侥幸通过，真回归被掩盖测试通过率很高，生产事故却在上升

第三种最阴险：测试全绿和生产事故率同时上升，说明你的测试在测一个已经不存在的应用。

这个失衡有独立研究背书吗？有。关键在于 AI 生成代码的错误形态和人类不同。两项实证研究值得引用：

也就是说，“AI 代码常常语法正确但语义错误”不是厂商发明的恐吓，是实证文献的一致发现。人类写错代码往往错得明显（编译不过、逻辑乱），LLM 写错代码错得体面——这正是”看 diff”式人工审查失效的原因：reviewer 无法在脑子里执行代码，而 AI 的错误恰好只在执行时暴露。

顺带一提，“让 AI 写测试来追上 AI 写代码”这条路也已有工业级证据：Meta 的 TestGen-LLM（arXiv:2402.09171）在 Instagram/Facebook 上部署 LLM 改进单元测试，75% 的生成测试能构建、57% 稳定通过、25% 提升了覆盖率，73% 的推荐被工程师接受进入生产。注意这些数字的诚实之处：远不是全自动，但方向成立。

概念层之一：一根轴分清四个容易混的词

术语表里最有认知价值的部分，是它花了四个词条去区分四个市场上被用烂的标签：AI-augmented、AI-native、agentic、agent-native。拆开来其实是两个独立的问题：

  1. 谁在操作测试循环？——人操作、AI 辅助（augmented）；还是 AI 操作、人审结果（native / agentic）；
  2. 谁能调用这个工具？——只有人能点 dashboard（human-only）；还是编码 agent 能通过 MCP 之类的协议直接调用（agent-native）。
术语回答的问题一句话判据
AI-augmented谁操作循环人开车，AI 是副驾：智能定位器、用例建议、脚本补全
AI-native / agentic谁操作循环AI 开车：从意图生成测试、执行、解读结果、自愈，人定政策审结果
Agent-native谁能调用工具把核心能力暴露成 agent 可调用的接口（典型是 MCP），编码 agent 是一等用户

这两个维度是正交的：一个系统可以内部跑满 agent（agentic）但不对外暴露任何 agent 可调用接口（非 agent-native）；也可以只是暴露了 API 但自身毫无自主行为。术语表给出的防伪测试很实用——“一个编码 agent 能不能在任务中间自主调用这个工具？还是必须由人切换到另一个界面去操作？” 如果是后者，无论营销文案怎么写 “AI-native”，它都是 augmented。

这个区分对读者的价值超出测试领域：2026 年几乎所有开发工具都在做同样的架构转身——从”给人用的产品里加 AI 功能”到”把产品能力暴露给别人的 agent 调用”。MCP（Anthropic 于 2024 年 11 月发布）之所以重要，就是因为它把第二个问题标准化了。

概念层之二：值得偷走的心智模型——定位器是缓存

20 个词条里最漂亮的一个想法藏在 Intent-Cache-Heal 模式里，可以概括成一句话：

测试的真值（ground truth）是”用户想操作的那个元素”，CSS 选择器只是上一次解析这个真值得到的缓存。UI 变了，不是测试坏了，是缓存失效了。

传统 E2E 测试的脆弱性由此有了一个干净的解释：脚本把缓存（选择器）当成了真值本身，所以每次 UI 重构——类名改了、DOM 挪了、A/B 测试换了布局——缓存失效就等于测试失败，尽管用户可见的行为一点没变。而纯 AI 解析（每一步都让模型看页面找元素）等于永远不走缓存：能扛住 UI 变化，但慢、贵、不确定。

Intent-cache-heal 就是给这个缓存补上标准的缓存语义：

flowchart LR
    A[测试步骤<br/>记录的是意图] --> B{缓存的定位器<br/>还能命中吗?}
    B -->|命中| C[确定性执行<br/>脚本级速度]
    B -->|失效| D[AI 从意图重新解析元素]
    D --> E{元素是移动了<br/>还是消失了?}
    E -->|移动了| F[更新缓存 + 产出可审查的 diff]
    E -->|消失了| G[报告真实 bug<br/>而不是把测试改到通过]

日常运行走缓存（确定、快），UI 真变了才触发 AI 重解析（heal），且每次 heal 都产出一个人能审的 diff。AI 的成本被限制在缓存失效路径上，而不是每步每次运行都花。

这个模型同时照亮了 Self-Healing Test（自愈测试）的危险面——术语表自己也承认这一点，这是它比较诚实的地方：

如果 “Submit” 按钮被删掉了，而自愈层找到了一个 “Save” 按钮凑数，测试会错误地通过。

静默的自愈等于把归因债自动化。所以生产级自愈必须满足：每次 heal 以 diff 形式浮出水面供人审查；区分”元素移动了”和”元素没了”——前者修缓存，后者报 bug。判断一个自愈方案靠不靠谱，就问这两条。

概念层之三：验证是反馈闭环的缺失半环

把视角拉高一层，这份术语表真正在讲的是 agent 时代的反馈闭环问题。

术语表里 Context Engineering 词条对来龙去脉的记述是准确的（我交叉核实过）：2025 年 6 月 18 日 Shopify CEO Tobi Lütke 发推提出”上下文工程是为任务提供全部上下文、使之对 LLM 可解的艺术”，一周后 Karpathy 转发背书，同年 9 月 Anthropic 的工程博客将其系统化，学术界随后跟进——中科院团队的综述 《A Survey of Context Engineering for LLMs》（arXiv:2507.13334）梳理了 1400+ 篇相关论文。这个词的走红轨迹本身就是”命名即定义权”的又一例证。

而术语表在这个公共概念上做了一个有意思的私货嫁接：验证结果是最高信号的上下文。规格说明描述的是意图，测试通过/失败报告的是现实，截图展示的是渲染真相——把这些喂回 agent 的循环，才能”把猜测变成有依据的下一步”。这个说法我认为站得住：在上一篇讲 Claude 5 上下文工程的文章里我们看到 Anthropic 在删规则、留判断依据，而运行时反馈正是模型无法靠判断力凭空获得的那类依据。

沿着闭环视角，另外两个词条也就位了：

Spec-Driven Development（规格驱动开发）：GitHub 在 2025 年 9 月开源了 Spec Kit，把”先写规格再让 agent 实现”固化成 Specify → Plan → Tasks → Implement 四步。术语表对它的补充批评很到位：只生成不验证的规格是愿望，不是契约——你把真值源从代码挪到了文档，但没有任何东西强制代码继续服从文档。规格驱动开发供给闭环的前半段，验证供给后半段，缺了后者，规格会腐烂成一厢情愿的文档。

Verification Agent（验证 agent）：写代码的 agent 验证自己的工作有利益冲突——它倾向于确认自己的假设，写出”针对刚才那个实现恰好通过”的测试。所以验证 agent 应该是结构上独立的第二个角色：只接收意图（不接收实现），打开真实浏览器操作变更，对照意图判断行为。这是把人类 QA 独立评审的组织学原理，搬进了多 agent 流水线。作者和审计者分离——这条原理比任何具体产品都古老，也大概率比它们都长寿。

从 SRE 抄来的运维纪律

还有一组词条的思路是把 SRE 的纪律移植到测试层，移植得相当整齐：

  • Test Flakiness Budget（不稳定预算）：照抄 SRE 的 error budget——团队约定一个最大 flake 率（术语表建议：合并前冒烟套件 <0.5%，合并后全量 <2%，定时回归 <5%），预算烧穿就停新功能、先修 flake。“修 flake”从此不再是”人人都想做、没人排优先级”的事，而是和发版速度直接挂钩；
  • Quarantine Test（隔离测试）：flaky 测试不删除（丢历史）、不 skip（永久失明），而是移到不阻塞合并的独立泳道继续跑，配明确的回归标准（如连续 30 次绿灯才能回主套件）。为防止用隔离刷预算，隔离中的测试按 0.5 倍折扣继续计入 flake 预算——这个防钻空子的细节设计很见功力。

flaky 测试本身的严重性同样有独立文献支撑：对 Python 生态 22,352 个开源项目的实证研究（arXiv:2101.09077）发现 flakiness 的普遍程度与 Java 相当，且 59% 源于测试顺序依赖；JavaScript 项目的对应研究（arXiv:2207.01047）则发现并发问题（async 等待、竞态）是头号原因。这些根因没有一个会因为”测试是 AI 写的”而自动消失——事实上 agent 高速产出测试时，flake 的绝对数量只会更大，这正是预算和隔离机制在 AI 时代反而更重要的原因。

灰度：这套词汇什么时候不适用

按惯例，给这套叙事画边界。

如果你的团队代码速度仍然是人肉瓶颈——大多数团队在 2026 年依然如此——那么 augmented 工具就是合理选择，术语表自己也承认这一点（“对很多团队，augmented 是正确的一步”）。为一个还没出现的失衡提前重构测试架构，是过度设计。

营销数字要打折。“QA 维护时间从每周 60% 降到接近零"" 10 倍速建立覆盖""80% 核心回归流程数周内自动化”——这些是精选客户案例，样本量为个位数，且都出自卖方之口。对比 Meta 论文里 57% 的稳定通过率，你就知道诚实的工业数字长什么样。

最硬的开放问题术语表轻轻带过了：意图解析层本身的可靠性。整套 intent-based 叙事的地基是”AI 能从意图可靠地找到正确元素”。如果解析层不可靠，intent-based 测试只是把不确定性从选择器搬到了模型——从一种 flake 换成另一种 flake。缓存机制缓解了成本和速度，但缓存失效路径上的解析质量依然是信任链的最薄弱环节，而这恰恰是没有公开基准可查的部分。

还有一个词术语表没有收录：谁来验证验证者？当 heal 的 diff 也由 agent 生成、PR 里的验证证据也由 agent 出具时，人类审查的对象从代码变成了证据链。证据链造假（reward hacking 的测试版）在激励上完全可能——一个被”让测试变绿”驱动的 agent，和一个被”让指标变好”驱动的模型，是同一个对齐问题的两张面孔。

带走的三个模型

  1. 覆盖率是速率不是状态：盯变更表面覆盖率，别盯总覆盖率。这个指标切换在任何 CI 体系里今天就能做，不需要买任何产品；
  2. 定位器是缓存：意图是真值，选择器是缓存，UI 变化是缓存失效。凡是”自愈”方案，先问它 heal 时产不产出可审查的 diff、区不区分”元素移动”和”元素消失”；
  3. 作者与验证者分离：不管是人与人、人与 agent 还是 agent 与 agent，验证者只拿意图、不拿实现。这条组织学原理在多 agent 时代只会更值钱。

至于这 20 个词本身会不会成为行业标准词汇——那要看这家公司活不活得到那一天。但词汇背后的瓶颈转移是真的：代码不再稀缺之后，被验证过的代码依然稀缺。这个差价，就是接下来几年测试工具、agent 框架和对齐研究共同争夺的地盘。

参考来源

一手来源与工程实践

arXiv 论文