AI 会点击、会截图了，为什么产品经理和高级测试反而更关键

AI 会点击、会滑动、会截图、会录屏，会自己写 E2E 用例并跑通整条链路——这些能力在今天已经不是新闻。但我们在团队里实践下来，一个结论反而越来越清晰：高级测试和产品经理在这个流程里的关键性不但没有下降，反而提高了。

这不是客套话。执行能力越普及，判断的价值就越凸显。这篇文章想讲清楚的是：AI 已经能做的部分，不值得再当作卖点宣传；真正稀缺的，是人的判断准则、深层次漏洞的设计，以及最终拍板的那个人。AI 和人不是替代关系，是互相协作的关系。

AI 的执行能力，已经不是门槛

先承认一个事实：AI 做测试的执行能力已经相当成熟。它会编写 E2E 测试用例，通过 OCR、模拟点击、滑动、截图、录屏等方式看清界面、操作界面；它能把一个迭代的代码 diff 拉出来，理解核心改动，然后自己执行测试、根据失败不断修正用例，直到链路跑通。

这些能力在过去很惊人，但现在它们只是入场券。点击、截图、跑用例——AI 做得又快又好，人在这部分确实比不过它。

所以问题从来不是"AI 会不会执行"，而是"AI 执行完之后，怎么判断结果对不对"。而这，恰恰是人的战场。

AI 做不好验收的真正原因：缺判断准则

很多人觉得 AI 做不好验收工作，这个判断在现阶段是成立的。原因不在它不会点击、不会截图，而在于它缺少判断的准则。

验收的本质是回答"这次改动到底算不算完成"。要回答这个问题，需要一套明确的标准：需求的目标是什么、用户应该获得什么结果、什么情况算达成、什么情况算缺陷。人可以教 AI 这些准则，但无法穷尽所有情况——业务场景的组合是无限的，这正是验收工作最困难的部分。

所以验收的瓶颈不在执行端，而在判断端。AI 能把测试跑到最广，但"什么是对的、什么算完成"，需要人来定义。

AI 真正能贡献的：边界思考的广度

那 AI 在验收里到底有没有价值？有，而且很大，只是价值点不在执行，而在边界思考。

AI 在边界思考上往往比人更全面、更多维。它可以把一个需求的所有边界条件、异常路径、组合场景都枚举出来，而人类受限于经验和注意力，很容易漏掉那些"没想到"的角落。理论上，在进行测试的时候，AI 完全有机会测得比人更完善——但前提是，它得先理解目标，再按目标去设计验证。

这正是未来测试方法演进的方向：更偏向 BDD 而不是 TDD，甚至演进到 Goal Driven Verification——从目标倒推验证，而不是从代码倒推验证。

一句话总结：AI 负责把测试面铺到最广，但"该测什么、为什么测、什么算达标"，由人来定。

人的价值点：判断准则、深层次漏洞、最终拍板

如果 AI 负责广度，人的价值在哪里？我们实践下来的答案是三个具体的地方。

产品经理：判断准则的唯一来源

AI 做验收的第一个瓶颈是"缺少判断准则"，而这个准则只能由产品定义。需求的目标是什么、用户应该获得什么结果、什么情况算达成、什么情况算缺陷——这些问题 AI 回答不了，也不应该由 AI 回答。

换句话说：AI 的能力边界，取决于需求定义的清晰度。 需求写得模糊，AI 测得再全面，也是在错误的基准上穷尽边界。我们团队的实践是：产品把需求和验收标准定义得越清楚，AI 的验收结果就越可信——这一环没有任何工具可以替代产品经理。

高级测试：深层次漏洞的设计师

AI 的优势是边界思考的广度——它能枚举出人类容易忽略的边界条件、异常路径和组合场景。但"哪些边界真正致命、哪些组合会导致真实的业务损失"，需要高级测试来判断。

我们的实践是：AI 负责把测试面铺到最广，高级测试负责把最有价值的深层次漏洞挖到最深。 高级测试基于业务理解和历史缺陷模式，设计那些 AI 可能想不到的刁钻场景，再交给 AI 去执行和验证。AI 越强，高级测试设计的问题就越能发挥价值。

人掌握最终判断

最后也是最容易被忽略的一点：无论 AI 的报告多完整，"这次改动到底达没达成目标"的最终判断，必须由人来拍板。AI 可以回读自己的测试文档、复盘执行过程，但验收的结论不是技术问题，是业务和责任的判断——这一环永远在人手里。

协作，而不是替代：AI 与人的分工

把上面的结论放到一起，就是一套清晰的协作分工：

AI：读懂需求、编写并修正 E2E 用例、穷尽边界、执行到极致、保留截图录屏与完整留证
产品经理：定义需求和验收标准，给 AI 判断的准则
高级测试：设计深层次的问题和漏洞，让 AI 的执行更有价值
人：对照验收标准，做出最终判断

AI 不是在削弱测试团队，而是在放大判断准则的价值。准则越清晰，AI 的边界思考越有用；问题设计得越深，AI 的执行能力越有产出。两边是互相成就的关系，缺了任何一边，验收都不完整。

我们团队的实践：一次迭代的验收闭环

每一次迭代发版，我们的流程是这样的：

产品经理先给出这次迭代的需求和验收标准——这是 AI 判断的基准；
高级测试列出深层次的怀疑点——这些是要重点验证的刁钻场景；
AI 拿到这个迭代所有的代码 diff，理解核心改动的功能点到底是什么；
AI 编写对应的 E2E 测试用例，围绕需求和目标设计，而不是只测功能；
刚开始写出来的时候，大部分测试其实都跑不过——这不重要，AI 会自己执行，再根据执行过程不断修正测试用例里的问题，直到整条链路真正跑通；
在整个验收过程中，它所有的点击、滑动、输入等操作都会被记录下来，同时保留截图和录屏，最终产生一篇完整的 E2E 测试用例文档和测试报告。

这套闭环的关键在于：AI 不是在"跑别人写好的用例"，而是从理解目标出发，自己生成、执行、修正、留证、复盘，全程围绕目标运转。而贯穿始终的，是产品经理给出的验收标准和高级测试设计的深层次场景——AI 执行得越好，这些"人的输入"就越关键。

一份信息量远超"通过/失败"的验收报告

这份测试报告的信息其实非常丰富，远不止一个测试结果：

测试目标：这次迭代想解决什么问题
操作路径：从进入到验证的完整路径
操作截图：每一步界面的真实呈现
操作录屏：完整过程可回放、可复核
操作反馈：系统对每一步操作的响应结果
真实结果：每一步执行之后软件真实呈现出来的状态

然后，AI 会再回过头去理解这篇文档，重新判断整个过程是否真的达到了最开始的目标。没有达成，就继续修正用例和链路。而"目标是否真的达成"这个最终判断，仍然需要产品经理对照当初定义的验收标准来拍板。

写在最后：AI 做执行，人做判断

测试不应该只是验证代码有没有跑通，也不应该只是验证某个按钮能不能点。它最终验证的是：这次改动有没有真正完成需求、有没有达到目标。

沿着这个方向，AI 和人各归其位：AI 负责用更全面的边界思考把执行做到极致，产品负责把需求和验收标准定义清楚，高级测试负责设计深层次的问题和漏洞，人负责最终的判断。 这不是谁取代谁，而是互相协作。

如果你想在自己的团队里落地，建议从下一次迭代开始：让产品经理先把这次改动的需求和验收标准写清楚，让高级测试列出深层次的怀疑点，再让 AI 读一遍代码 diff、说清楚目标、写 E2E 用例、跑起来、修正、留证。你会发现，验收报告第一次能同时回答"功能通不通"和"目标达没达成"两个问题，而产品经理和高级测试的价值，也在其中被真正放大。