范式跃迁
软件测试自动化大致走过了三个阶段。第一阶段是脚本时代，工程师用 Selenium、WebDriver 在 IDE 里一行行写操作：找到按钮、点击、输入文本、断言元素出现。第二阶段是录制回放时代，工具捕获人的操作并固化为脚本，门槛确实降低了，但脆弱性也更高。一次 UI 调整、一次组件重构，都可能让回归套件大面积失效。
到了 2026 年，第三阶段正在成熟：意图驱动编写（Intent-Based Authoring）。它不再要求人描述怎么操作，而是让人描述应该成立什么，剩下的路径查找、元素定位、断言推导交给 AI 在运行时实时解析。
这看似只是换了一种写法，本质上却是角色分工的变化：人负责定义业务正确性，AI 负责把正确性翻译成可执行行为。对软件测试团队而言，这不是简单的工具升级，而是测试工作流、用例资产和团队协作方式的一次重排。
意图驱动的本质
传统脚本里，一条登录用例通常会写得很细：打开 URL，等待输入框可见，输入用户名，输入密码，点击提交按钮（CSS 选择器 #login-btn-v2），等待跳转，断言 .welcome-banner 文本包含欢迎。每一步都在描述 DOM 结构和页面动作，任何一个 class 改名、按钮位置移动、组件抽象调整，都可能让用例失败。
意图驱动写的是另一回事：
步骤：登录已注册用户
期望：进入首页且看到欢迎信息
短短两行，表达的是业务意图，而不是页面操作。AI 在执行时读取当前页面的 accessibility tree，理解登录入口在哪里、哪个输入框该填什么、点击哪个按钮会触发提交、成功后的视觉信号是什么。它做的不是字符串匹配，而是基于页面语义和上下文的推理。
Mabl 把这种写法描述为：入口是意图（intent），出口才是实现（implementation）。Functionize 的总结更直接：你只需要描述产品必须成立的事实，系统自己去验证如何成立。Harness 则把这种思路扩展到断言层面：你不需要写断言文本等于 X，而是写用户应该清楚地看到订单已支付，AI 会自动推导一组断言线索，覆盖文本、图标、状态码、URL 跳转、副作用等多个维度。
这里的关键变化是，测试用例从操作脚本变成了可执行的业务约束。脚本关心页面现在怎么长，意图关心业务结果是否成立。
成熟时机
意图驱动的想法并不新。BDD（行为驱动开发）十几年前就提出过用自然语言写用例。但 Cucumber 这类工具有一个根本问题：写完 Given/When/Then 之后，还要有人编写 Step Definition，把用户登录映射到具体的 click、fill 和 wait。这层映射本质上仍然是脚本，所以依旧会被页面结构变化拖住。
意图驱动真正不同的地方在于，它把这层映射放到了运行时：LLM 在运行时就是 Step Definition。
让这件事真正能跑起来的，是 2026 年三个技术拼图同时到位。
第一是 accessibility tree 的工业化使用。Playwright MCP 把页面以 2~5KB 的结构化数据暴露给 AI，而不是 500KB~2MB 的截图，让模型在更低成本下理解页面语义，性能也比传统截图方案更可控。
第二是开源 LLM 的本地化能力。Qwen 3、GLM-5.1 等模型已经具备企业内网部署条件，意图解析不必天然依赖外部 API。对金融、电商、企业后台这类页面内容敏感的系统来说，这是能不能进入生产流程的关键门槛。
第三是 MCP（Model Context Protocol）协议的标准化。测试工具暴露的能力可以被不同 Coding Agent 调用，意图驱动不再只是某一家商业工具的封闭能力，而开始变成生态层面的共同接口。
生产落地架构
如果每次执行都让 LLM 重新解析每一个元素，速度和成本都不可接受。生产环境更现实的做法，是把意图、缓存和自愈拆成三层，也就是常见的 Intent-Cache-Heal 模式。
第一层是意图（Intent），它是权威定义，也是用例真正的源代码。意图描述业务必须成立的结果，原则上不应该跟着页面实现细节频繁变化。
第二层是缓存（Cache）。第一次运行时，AI 解析得到的 selector、定位路径、断言策略会被持久化下来。后续执行优先复用缓存，只有缓存失效时才重新解析。这样稳定状态下的执行速度可以接近传统脚本。
第三层是自愈（Heal）。当按钮 ID 改了、布局调整了、组件库升级了，缓存命中失败，AI 再基于当前页面和原始意图重新解析正确元素，并刷新缓存。CI 流水线不应该因为按钮从左边挪到右边就失败，它应该只在业务意图真的不成立时失败。
这套机制同时回应了 AI 测试最常见的两个质疑：执行慢、成本高。在稳定状态下，意图驱动用例的资源消耗与传统脚本接近；只有页面变化发生时，才付出 AI 解析的额外成本。
测试角色变化
意图驱动最具颠覆性的影响，不是写得更快，而是谁能写。
过去，测试自动化的入门门槛是编程能力。即使是低代码工具，要写出可维护的脚本，仍然需要理解 DOM、选择器、等待策略、断言机制。这意味着自动化能力长期被锁在 SDET 或测试开发角色里，业务 QA 和产品同学很难直接参与用例资产建设。
意图驱动把入口前移到自然语言。Mabl 文档明确写道：产品经理可以基于需求直接定义测试场景，开发者可以在写功能的同时写意图，不需要切换到框架语法。QA 工程师则从实现细节里抽身出来，把更多精力放在测试策略、边界条件设计、探索性测试和风险审计上。
这会改变团队协作方式。一种正在出现的新模式是：每个用户故事在 PRD 完成时就自带 5~10 条意图用例，PM、开发、QA 三方在 PR 阶段共同评审这些意图是否覆盖了需求。需求文档与测试用例不再是两份互相追赶的文件，而是同一份业务规则的两种视图。
用例资产的形态也会变化。它不再只是测试仓库里的 .spec.ts 文件，而会越来越像业务领域里的可执行需求规范。更理想的状态是，意图仓库与代码仓库平级维护，与 PRD 双向引用，由产品和工程共同治理。
意图资产治理
完全自由的自然语言虽然门槛低，但难以代码评审、难以版本管理，也难以构建稳定的测试套件。更适合工程团队的方式，是把意图写成半结构化的 YAML：
suite: 跨境支付核心流程
context:
# 明确运行上下文，避免 AI 在用户状态上自由猜测
user: 已认证 KYC Level 2 用户
device: web
steps:
# 每一步同时写清 intent 和 expect，方便评审和追溯
- intent: 登录账户并进入支付页面
expect: 看到完整的支付方式列表
- intent: 使用默认 USDT 余额支付 100 USDT
expect:
- 订单状态变为已确认
- 余额减少 100 USDT
- 看到成功提示
- intent: 返回订单详情页查询本次交易
expect: 该交易记录可见且状态正确
这种写法保留了人类可读性，同时具备代码资产的基本能力：Git 版本控制、PR 评审、套件组织、依赖管理、CI 集成。它也让审计可追溯。在监管合规场景下，每一个意图、每一次 AI 解析结果、每一条断言路径，都可以被日志化为结构化数据。
换句话说，意图不是随手写给 AI 看的提示词，而是需要被治理的质量资产。它要有命名规范、粒度标准、评审机制和变更记录。
典型局限
意图驱动不是银弹。越接近生产落地，越要正视它的边界。
复杂业务规则的验证仍然脆弱。涉及多条件组合、长链路状态机、跨系统副作用的断言，AI 可能给出看起来正确但实际错位的判断。这类场景下，团队必须用结构化断言显式锁定关键不变量，而不是依赖 AI 自由推导。
渲染层穿透问题也无法回避。Canvas、WebGL、复杂 SVG 渲染的内容无法被 accessibility tree 完整表达，意图解析准确率会显著下降。K 线图、交易撮合可视化、复杂图表等典型金融场景，仍需要传统视觉验证或专用 SDK 测试。
意图歧义会放大不确定性。页面应该正常工作这类描述会让 AI 自由发挥，结果不可预测。团队必须建立意图编写规范：每条意图都要包含明确的主语、动作、可验证结果三要素，避免把模糊需求直接丢给模型解释。
冷启动成本与首次解析延迟也要纳入预算。Cache 未命中时，AI 调用通常比传统脚本慢 5~20 倍。对数千条用例级别的回归套件，冷启动时间需要专门优化，包括预热缓存、并行解析、按页面聚类调度。
这些局限并不否定意图驱动的价值，反而说明它需要和传统自动化测试、结构化断言、视觉验证一起组成混合体系。
团队落地路径
意图驱动适合从有限的甜区切入，再逐步扩散。
第一步是场景选择。最适合的甜区是业务流程稳定、UI 经常变化的场景，比如登录、注册、表单提交、列表搜索、个人中心。这些用例传统脚本维护成本高，意图驱动收益更明显。最不适合的是核心交易撮合、价格图表渲染、复杂动效，这些仍然应该走传统路径。
第二步是规范先行。在写第一条意图之前，团队应该用一两个工作日制定意图编写规范，明确粒度，也就是一条意图覆盖多大行为，同时明确断言写法、命名约定、与 PRD 的对应关系。没有规范的意图库，很快会退化成 AI 看心情决定怎么验证。
第三步是双轨运行。建议先安排 6~8 周并行期：传统脚本和意图脚本同时跑，统计两者的一致率、误报率、维护工时。等意图脚本的通过率稳定在 95% 以上、误报低于 5%，再讨论局部切换。
第四步是 CI 集成。把意图用例接入 PR Quality Gate，让每一次代码变更触发相关意图集执行。这一步很关键，因为它决定意图是实验性工具，还是日常基础设施。
第五步是组织协同。当 PM 开始写意图、开发开始读意图、QA 开始审计意图，原本散落在三个角色之间的什么叫做完成，才有机会在文档层面统一。这一步的价值远超工具本身。
结语
意图驱动编写的真正意义，不在于让测试写得更快，而在于让什么是正确这个问题在团队内部有了可执行、可版本化、可评审、可追溯的答案。当一条业务规则被写成意图、被 CI 验证、被 PR 评审、被审计追溯，软件质量就不再只是 QA 一个角色的责任，而会变成整个团队共享的契约。
2026 年，这个范式还在快速演化，但方向已经清晰：未来的测试用例库会越来越像一份会自己跑的产品规范文档。早一步建立意图资产的团队，得到的不只是更便宜的回归测试，而是一种新的产品 - 工程对齐方式。