过去两年，生成式 AI 把研发效率拉到了一个新水平：在 IDE 里输入一句自然语言，几秒钟就能得到一段业务代码，一个接口、一个组件，甚至一个微服务都能被快速拼装出来。但开发提速的同时，测试却越来越像新的瓶颈。不少团队已经感受到这种反差：代码生成变快了，测试没有同步提速，甚至在用 AI 生成测试用例之后，测试数量迅速膨胀、噪音明显增加、维护成本一路走高。很多团队最后都得出同一个判断：不是测试不够，而是测试方式错了。行业正在从 Generate Test Cases 转向一个更本质的方向，也就是意图驱动测试（Test Intent）。这不是简单的工具升级，而是一场测试思维的范式转变。
AI 泛滥后测试更难
先看一个常见场景：你把登录接口交给 AI，让它生成 20 个测试用例，它很快会给出一份看起来很完整的结果，比如正确用户名和密码、错误用户名、错误密码、空输入、特殊字符、超长输入、SQL 注入尝试等。乍一看没什么问题，但认真审查就会发现，这些测试大多只是教科书式覆盖，集中在参数组合、边界值和基础异常路径上，不一定对应你的真实业务风险。登录失败是否触发风控、多设备登录状态是否一致、Token 刷新是否存在竞态问题，这些更关键的点，往往不会自然出现在生成结果里。
更麻烦的是，AI 很容易把测试变成噪音堆积。当它一次生成几十甚至上百个用例时，重复逻辑只是换个数据，低价值路径大量堆叠，关键场景反而被淹没，测试评审也从判断质量变成了过滤垃圾。与此同时，维护成本会被迅速放大。UI 按钮 ID 一改，一批 E2E 测试全挂；接口字段稍作调整，多个测试一起失效；页面结构一微调，Selector 基本报废。说到底，这些测试绑定的是实现细节，而不是业务语义。以前测试写得慢，但至少是精挑细选；现在测试生成得快，却很容易变成海量低质资产。换句话说，你不是在减少工作，而是在管理更多问题。
问题本质：重步骤轻目的
传统测试以及多数 AI 生成测试有一个共同特点：它们强调的是怎么测，而不是为什么测。比如一段典型步骤通常是打开登录页、输入用户名、输入密码、点击登录、验证返回结果。这种写法告诉了你操作顺序，却没有告诉你这个测试真正要保护的价值是什么、它在防止什么业务风险、成功或失败分别意味着什么业务后果。也正因为如此，测试失去了语义层。一旦缺乏语义，AI 就只能在形式层面批量生成，却无法在价值层面主动优化。
什么是意图测试
意图驱动测试的核心并不复杂：先表达测试意图，再由 AI 推导测试路径。一个完整的测试意图通常包含三部分：Intent 说明要验证什么业务规则，Risk 说明一旦出问题会造成什么后果，Acceptance 界定什么结果才算通过。也就是说，意图不是一句模糊的测试目标，而是一段带有业务背景、风险判断和验收边界的完整表达。
举几个更真实的例子就很容易理解。支付场景里，你真正想验证的不是某个按钮有没有点成功，而是扣款成功但库存不足时系统必须回滚，用户余额不能不一致，这背后牵涉的是分布式事务、补偿机制和数据一致性。UI 场景里，弱网下重复点击提交不能导致重复订单，且用户要获得明确反馈，这背后对应的是幂等性、用户体验和状态提示。并发场景里，秒杀高并发下库存不能超卖、订单状态最终一致，对应的则是并发控制、数据锁和最终一致性。这些例子虽然场景不同，但共同点很明确：它们描述的是业务层的真相，而不是技术层的操作。
这也是它和传统方式的本质区别。传统测试更像写剧本，意图测试更像定义规则；以前 AI 的角色是帮你写步骤，现在它更适合帮你推理测试策略。人的工作开始更多落在给出判断标准和风险模型上，AI 则负责把这些高层意图展开成可以执行、可以验证、可以维护的测试路径。
为何在 2026 年发生
一个关键原因是 AI 的能力刚刚够用。在 2023 年，模型的主要能力还停留在补全；到了 2025 年之后，模型开始逐步具备更稳定的语义理解、多步推理和规划能力，这才让 AI 有可能从意图出发构建测试，而不只是生成零散代码片段。与此同时，工具生态也在变化：一些 AI 测试工具开始强调 Intent-first，Playwright等框架支持更高层的语义封装，社区也开始讨论 Intent Library，也就是意图库。越来越多团队因此看到一些现实收益：用例数量下降了，测试稳定性提升了，审查成本也显著降低。更重要的是，测试重新回到了理解业务的本质。
如何落地意图测试
真正的变化不是换一个工具，而是调整工作方式。一个可行的闭环很简单：第一步先由人写 Test Intent，例如：
Intent: 验证用户在支付成功但库存不足时系统必须回滚
Risk: 出现资金扣除但订单失败
Acceptance: 用户余额恢复，订单状态为失败
第二步再让 AI 扩展测试场景，补充边界条件、异常场景和并发情况，比如库存只剩1、请求过程中网络中断、多个请求同时进入等；第三步根据意图生成不同层级的测试，包括单元测试、API 测试和 UI 测试；第四步执行并反馈，测试失败就修正实现或修正意图，测试通过就固化为意图库资产。把这几步串起来后，你会发现测试的源头不再是用例，而是意图。
如果想让 AI 输出更稳定，一个很实用的 Prompt 结构是：先交代 Intent、Risk、Acceptance，再补充四个要求，分别是优先覆盖高风险路径、避免冗余测试、给出关键断言、标注每个测试的价值点。这个模板的重点不是让 AI 生成更多测试，而是让它围绕价值工作，而不是围绕数量工作。只要输入里先把目标、风险和验收标准交代清楚，输出质量通常都会比简单要求生成 20 个用例高得多。
进一步往前走，团队最好建立自己的意图库。更实用的做法是按业务模块组织，比如支付、登录、订单，让每个意图都具备可复用性，并做版本化管理。长期来看，这些内容会成为团队最重要的测试资产，因为代码会改、页面会改、接口也会改，但高价值风险点通常不会频繁消失，真正值得长期保存的，恰恰是这些经过验证的意图本身。从这个角度看，TDD 是先写测试代码，BDD 是先写行为描述，而 Intent 是先写业务意图，本质上是一条不断向语义层上移的演进路径。
意图没有那么简单
方向是对的，但真正落地并不轻松。首先，意图写不好，结果可能比写一堆用例更糟。如果你的意图只有一句系统正常工作，那 AI 最后大概率只会生成一堆没有区分度的测试。一个可用的意图，至少要具备清晰目标、明确风险和可验证标准，少了任何一项，输出都很容易重新退化成大而空的测试清单。换句话说，意图驱动测试并不会天然减少思考，它只是把思考前置到了更关键的位置。
其次，复杂业务通常很难一次描述清楚，大型系统往往需要多个意图组合，也需要多轮迭代完善；再加上当前大模型仍然存在调用成本和响应延迟问题，团队仍然需要在效率、成本和收益之间找到平衡点。所以它不是一套拿来即用的银弹，而是一种更值得长期投入的方法。
测试转向意图工程
未来 1 到 2 年，测试领域大概率会出现三个明显变化。第一，意图会成为第一等公民。代码可以被重写、生成、替换，但意图代表的是系统的业务理解，它比某一版实现更稳定，也更接近测试真正要守护的东西。第二，多 Agent 协作测试会越来越常见，比如 Agent A 生成测试意图，Agent B 生成测试，Agent C 分析失败并自愈，测试本身会更像一个自动化系统。但无论 Agent 再多，最上游仍然需要有人定义什么是值得守护的风险，什么是必须达成的验收结果。第三，测试工程师的角色会继续升级，你不再只是写用例的人，而会越来越像一个设计系统风险模型的人。
竞争回到理解力
为什么 AI 让开发更快，却让测试更难？因为开发在自动化实现，而测试本质上是在理解意图。当生成越来越廉价，真正稀缺的能力反而变成了对业务的理解、对风险的洞察和对系统行为的建模。所以，测试的竞争不再是谁生成的用例更多，而是谁定义的意图更准确。如果你只想用一件小事启动这次转变，我建议你从下一个需求开始，不要先写测试用例，先写 Test Intent。你会很快发现，测试不再只是验证，而是设计的一部分。