（文中三张插图由AI生成）
今天写这篇文章是对上一篇文章回归测试不再“回归”：测试工程师的现状调查的呼应，看看能否帮测试人员在AI时代找到一条职业成长的路径。
5月22日，上海，第9届AI+研发数字峰会。
快手"研发Agent和智能质量平台"负责人苗星上台，讲他们智能UI用例生成的演进。屏幕上出现一个数字：生成率8%。
台下有人小声笑了一下。8%，这成绩也敢拿出来讲？
但故事还没讲完。苗星接着放：15%、35%、70%。
台下没人笑了。
我坐在一个资深QA旁边。她没有反应，只是记下了"70%"后面的一个细节：快手从V1到V4花了两年时间。那个8%不是因为模型不行，而是只喂了PRD；那个70%也不只因为AI变聪明了，而是因为系统背后积累了170+个业务私域知识模板、自动沉淀的历史缺陷规则库、完整的BadCase分类闭环。
她轻声说了句话，我印象很深："所以问题根本不是AI替不替代测试。问题是测试的定义在变。"
一个被误读了的问题
这半年，我和许多测试人员都有过交流。最常见的焦虑是："AI能生成用例、能生成脚本、能跑回归，那测试还有什么活？"
但如果你看快手这个案例，或者看那些正在系统化接入AI工具的大团队，答案很打脸：活儿没有减少，类型改了。
赵婷婷被裁的原因，看起来是"AI可以替她生成用例和跑脚本"；但更准确的原因是——她做的工作本质上是"按测试规范复制验证流程"。这个工作本来就最容易被自动化，AI只是加速了这个必然。
但陈浩没有被裁。他现在做的事反而更忙：
AI生成的脚本在真实环境里跑不稳，他要诊断为什么；
偶发失败该怎么定位，不能简单说"后端不稳定"；
环境差异怎么处理，权限、缓存、灰度状态怎么约束；
什么时候该信任自动化结果，什么时候得人工介入。
这些工作，按老标准叫"测试自动化维护"；按新标准，是智能体驾驭工程（Harness Engineering）设计、troubleshooting方面的工作。
关键的转变在这儿：测试不再是"执行一套验证方案"，而是"定义什么才是有效的验证"。
为什么从8%到70%，本质不是AI学会了更多
这是那篇快手分享里最值得反复看的部分。
V1（8%生成率）的失败，表面原因是"长文档理解衰减，业务知识缺失，生成过程黑盒"。
真实原因更简单：AI只看到了PRD的字面意思。
支付功能的PRD写"余额不足提示充值"。新手QA照着写一条用例：输入金额大于余额，检查弹充值提示。符合要求。
资深QA会想：并发两笔支付会不会重复扣款？充值中途退出后的幂等性怎么保？网络中断重试的状态是什么？
这些问题PRD里一个字没有。它们藏在哪儿？藏在这个团队以前出过的缺陷记录、藏在业务规则文档、藏在资深QA的脑子里。
V2做的是什么？把Review流程独立出来，让人的审核决策变成系统一部分。这样生成率到了15%，但真正解决不了核心问题。
V3的突破，是把"知识工程"系统化了。不是让AI更聪明，而是让AI能检索历史缺陷库、调用业务规则图谱、复用团队用例模板。当系统生成"支付"相关用例时，自动去历史缺陷库检索"支付并发扣款"这条记录，然后把它作为上下文注入——这时候AI才知道要补齐"并发防护"这个测试点。
结果一下子从15%到35%。更关键的指标是："历史缺陷被新用例覆盖的比例从12%跳到76%"——这说的是什么？说的是以前踩过的坑，现在有76%的概率不会再踩第二次，因为系统'知道'了。
V4的"自进化"，本质上是把"人工标注BadCase→系统分析规则→下次生成自动纠正"这个闭环完全自动化了。从天级更新规则，降到5分钟。
你看明白没有？从8%到70%这段路，根本不是"AI越来越聪明"，而是"系统的知识积累越来越丰富、人的判断点被越来越清晰地定义出来了"。
AI没学会"怎么思考"。AI学会的是"在正确的约束条件下，怎么执行人已经定义好的验证策略"。
所以真正发生了什么变化
这是我想讲清楚的核心。
以前测试工程师的工作是"线性的"： PRD→设计用例→手工执行或写脚本→执行→记结果。在这个流程里，"手工执行"最容易被自动化替代。但其实"设计"这一步也很容易被工具化——因为很多情况下，你做的"设计"就是按照规范去列举场景、排列组合。那些最标准化的工作，自然最先被吞掉。
现在测试工程师的工作是"系统性的"：
首先是质量战略的上游：不再是"给我一份需求，我按规范出用例"，而是"这个需求的真实风险在哪儿？这个业务的隐含规则是什么？我们团队历史上在这类功能最容易踩什么坑？"这些判断决定了后续测试智能化的上限。
其次是知识的系统化：不是"记录一个缺陷就完事"，而是"这个缺陷怎么分类、属于什么业务机制失效、下次怎么预防、沉淀成什么规则可以被AI调用"。快手的170+业务私域模板，每一个都代表着一类经验的结构化。没有这个，生成率再高也是"广而不精"。
第三是执行的可信度：AI生成的脚本能跑不等于能交付。能交付不等于证据链完整。能通过不等于真的验证了。陈浩现在做的就是这个："把AI生成的脚本当草稿，真正的工作是：确保这个脚本在真实环境中跑的时候，每一个通过或失败都代表一个真实的业务状态"。
第四是质量决策的权重：当有100条自动生成的用例摆在面前时，哪50条是真正关键的？如果通过率是99%，那1%失败了意味着什么？能不能上线？这个判断越来越值钱。
换句话说，测试工程师正在从"执行者"升级成"测试系统的架构师"——不是"架构系统本身的技术"，而是"架构系统对'什么是正确验证'的理解"。
那些没被替代的人，做对了什么
访谈里那些还被认可的测试工程师，做了这些事：
陈浩把测试自动化当作"真实环境下的质量观测系统"，而不是"脚本跑过=验证完"。所以他关心的是：框架怎么在真实差异下保持稳定、失败怎么快速定位、证据链怎么完整。这些能力越来越值钱，因为AI生成的脚本都容易在这些地方翻车。
周桦在通信设备行业，他非常清楚"可跑（run，运行）离可交付差得远"这一点。所以他在做的是：需求→场景→前置条件→期望行为→证据链→现场可复现性。这整条链的任何一环都不能AI代替，因为一旦链断了，就变成了"看起来做了"而不是"真的验证了"。这个原则正是有经验的测试工程师和工具的根本区别。
姚薇说的"测试品味"，其实指的就是这个：在众多可能的验证方案中，判断哪些是"会救命的"，哪些是"可以先等等的"。这个判断，永远需要对业务的理解，而不仅仅是对测试技术的理解。
他们做对的共同点，用一句话总结：他们把自己定位成了"质量系统的设计者"，而不是"验证流程的执行者"。
这跟快手的演进怎么映射
快手的V1到V4，其实映射的也是这个转变过程。
V1的失败（8%生成率），根本原因是系统没有"质量决策者"。AI只能理解文档字面意思，没人去补齐"真实的风险在哪儿"。
V2改进了（15%），因为引入了人的Review决策。但还不够系统化。
V3的突破（35%），是因为开始把"资深QA的经验"系统化成了知识库。这时候AI才真的有了"懂业务"的参考框架。
V4的自进化（70%），是因为建立了完整的"BadCase→规则→纠正"的闭环。这个闭环本质上是在不断地让系统学会"什么才是真正的风险"。
你看明白了吗？每一步的提升，都不是"AI更聪明"，而是"系统背后的质量决策逻辑更清晰"。
而那些决策逻辑，是由测试工程师定义、维护、不断优化的。
那对你意味着什么
如果你现在做的是"按规范写用例、跑测试、记缺陷"，我不瞒你，这部分工作确实在被压缩，而且压缩力度，未来一定是越来越大。
但如果你想不被替代，路径也很清晰：
第一步，从"怎么验证"升级到"什么该验证"。 看你负责的模块历史上最常见的缺陷是什么？是并发问题、还是状态机错误、还是边界处理不当？每一类缺陷背后映射的都是一条"应该测的场景"。资深QA和新手的根本差别，就在这儿。
第二步，开始维护一个"知识资产"而不是"缺陷记录"。 缺陷库通常缺乏管理，下次同样的问题再出现，还得重新调查。但如果你把缺陷整理成"缺陷类别→触发场景→根本原因→怎么验证→可复现步骤"这样的结构，那就变成了一个真正能被复用、能被AI调用的资产。快手现在在做的，其实就是这件事的系统化。
第三步，开始关心"稳定性和证据链"而不是"覆盖率"。 一个能跑1000条用例，但70%都是"看起来通过了"的系统，价值远不如一个稳定跑200条、但每一条的证据链都清晰的系统。这是陈浩在做的事，也是最难被AI替代的地方。
第四步，不要只会用工具，要学会"驾驭"工具。 AI生成的脚本有问题，不是简单地说"AI不行"，而是理解"为什么这个生成策略在真实环境里失效了"，然后通过调整约束条件、补齐上下文、优化Review流程，让工具给出更靠谱的结果。这是从"使用者"到"系统设计者"的转变。
写在结尾
快手那个"从8%到70%"的故事，如果你只看表面，就是"AI能做的事越来越多，人能做的越来越少"。
但如果你看实质，说的是："要让一个测试自动化系统达到可信度，需要系统背后有多少人的专业判断在支撑。"
那170多个业务私域模板，谁维护的？谁在审核每一个新的缺陷类别是否应该被加入规则库？谁在决定什么时候让系统自动学习，什么时候该人工干预？
都是测试工程师。
所以真正发生的事不是"测试被替代"，而是"测试的定义在升级"。
你不再是"把验证流程跑完的人"，你变成了"定义什么是正确验证、怎么让系统理解这个定义、怎么确保这个定义持续有效"的人。
这个定义的升级，从2007年第一版《全程软件测试》开始，我一直在讲的一个原则成了现实：测试的本质不是"找缺陷"，而是"通过系统地定义和验证，来提升对系统正确性的信心"。
在AI时代，这个原则的重要性反而在上升，而不是下降。
因为当自动化程度越来越高时，"什么是正确的"这个定义，就变成了整个质量系统的最基础一层。定义错了，自动化得越彻底，出错的范围就越大。
所以真的没有什么"AI时代测试的生存指南"
有的只是"测试工程师该怎么升级自己的能力和定位"，这个问题在20年前和20年后，答案其实是一样的：从执行者成长为系统设计者，从"怎么验证"思考到"什么该验证"。
