夜雨聆风
一、十八个月前，我们有九个人
十八个月前，我所在的测试团队有九个人。
团队结构很典型：两名测试开发负责框架搭建和工具维护，四名功能测试工程师负责用例设计和手工测试，两名自动化工程师负责脚本编写和CI对接，一名测试负责人负责策略制定和跨团队协调。
这个配置，在行业里属于中规中矩的水平。覆盖了一个中型电商平台的完整测试工作，不算富裕，但够用。
然后，十八个月前，我们开始引入AI辅助测试工具。
今天，这个团队还有七个人。
但如果你以为这篇文章是在写"AI裁掉了两个人"，那你只看到了数字，没看到数字背后发生的事。
二、第一阶段：工具引入，没有任何人员变化
引入的第一件事，不是裁员，甚至不是转岗——是混乱。
我们引入了两类工具：一类是AI辅助用例生成工具，用来基于需求文档快速输出用例草稿；另一类是智能接口测试Agent，能自主执行接口回归并生成分析报告。
前两个月，这两类工具的主要贡献是制造了大量需要人工清理的垃圾。
AI生成的用例草稿，覆盖面确实更广，但充斥着和业务逻辑对不上的预期结果，以及对于"用户"和"已登录用户"不加区分的场景混用。功能测试工程师花在审核和修改草稿上的时间，比直接自己写还多。
智能接口Agent的误报率在初期超过了20%——每五条"缺陷告警"里，就有一条是环境波动或测试数据问题造成的假阳性。自动化工程师每天要花大量时间甄别真假告警。
第一到第四个月，工具引入带来的净效果是：工作量没有减少，团队的挫败感在增加。
这个阶段，没有一个人离开，也没有一个人的岗位职责发生变化。
但有一件事悄悄开始了：团队开始区分"哪类工作AI能帮上忙""哪类工作AI会帮倒忙"。这个认知的积累，是后来一切变化的基础。
三、第二阶段：工作方式开始分化
到第五个月，团队的工作方式开始出现分化——不是因为有人下令，而是因为每个人在和AI工具的日常接触中，自然地找到了自己的使用节奏。
功能测试工程师这边：
四个人里，有两个人开始把AI用得很顺。她们的做法是：不让AI生成完整用例，而是用AI做"覆盖点盘查"——先自己写出主要场景，然后让AI找她们可能遗漏的边界条件和异常路径，再决定哪些值得补充。这种"AI审查人，而不是AI替代人"的用法，让她们的用例质量明显提升，设计速度也快了大约30%。
另外两个人，一个习惯了原有的工作方式，AI生成的内容对她来说更像干扰，她选择不用；另一个尝试了几个月，感觉自己在"给AI擦屁股"，工作量反而增加了，开始对这套工具产生抵触情绪。
自动化工程师这边：
误报率经过四个月的调优，降到了8%左右。这个数字意味着：每天的告警里，大多数是真实问题，自动化工程师不再需要大量时间甄别假阳性，可以把精力放在真正的问题分析上。
其中一名自动化工程师，开始把大量时间投入到一件以前"想做但没时间做的事"：建立测试数据的分层管理体系。她一直知道团队的测试数据是混乱的——测试脚本跑完留下的脏数据会干扰下次执行，但数据清理工作太费时间，没人有精力认真做。AI接管了大部分脚本的执行和初步分析，她终于有时间把数据管理这件事做起来了。
测试开发这边：
两名测试开发的工作重心发生了显著转移。他们花在"写自动化脚本"上的时间减少了——因为Agent能生成和维护大量标准接口用例的脚本；他们花在"设计AI工具的提示词和调度逻辑"上的时间大幅增加。
他们的工作从"编写测试代码"，变成了"设计让AI更有效地完成测试工作的系统"。这是一个明显的工作重心上移。
这个阶段结束时，九个人都还在，但每个人的日常工作内容已经不同于十八个月前。
四、第三阶段：第一次真实的人员变化
第十一个月，发生了第一次真实的人员变化——但不是裁员。
那名对AI工具始终抵触的功能测试工程师，提出了转岗申请。不是因为她被要求离开，而是因为她自己意识到：团队工作方式的整体变化，让她越来越不适应。
她最擅长的，是深度的手工探索测试——凭借对产品的长期理解，找到那些脚本和Agent发现不了的边缘问题。这个能力是真实有价值的，但在这个团队里，这类工作的占比正在减少，而她不想花时间学习和AI协作的那套工作方式。
她转去了公司另一个业务线的测试团队，那个团队的工具化程度更低，更接近她熟悉的工作方式。
这不是一个悲剧，这是一个人在自己的职业路径上做的选择。她的离开，没有让团队出现能力空白——因为她离开时，她所承担的核心探索测试工作，已经在过去半年里被逐渐拆解：常规部分由Agent承担，需要深度业务理解的部分由其他工程师兼顾。
离开之后，团队没有补招这个岗位。
五、第四阶段：第二次变化，更复杂
第十五个月，团队负责人宣布了一个决定：不再续签一名合同制自动化工程师的合同。
这是团队里最接近"因AI而失去工作"的一次，值得说清楚它的真实原因。
这位工程师的主要工作，是维护UI自动化脚本。他非常熟练——发布前的UI回归，他能在两小时内跑完并给出报告。这项工作，他做了三年，做得很好。
但AI工具引入之后，这项工作发生了两个变化：第一，UI回归的执行被智能Agent接管，速度更快，也不再需要专人盯着跑；第二，脚本维护的工作量显著下降，因为新一代UI测试Agent具备一定的自愈能力，元素定位的小变更不再需要人工逐一修复。
他的核心工作量减少了大约60%，而他在这段时间里没有向新的工作方向迁移——他继续做着剩下的40%，效率很高，但没有扩展新的能力。
合同到期不续签，不是因为他能力差，而是因为他的工作领域收缩了，而他没有及时扩展到新的领域。
这件事之后，团队内部有了一次坦诚的讨论。测试负责人明确说：AI工具不会让团队规模无限缩减，但它会改变每个人工作价值的来源。如果一个人的价值来源，是执行已经被AI接管的任务，那这个人需要找到新的价值来源——或者在这个团队内，或者在其他地方。
六、现在：每个人都在做十八个月前做不了的事
今天，团队七个人。
两名测试开发，现在的头衔叫"质量工程平台工程师"——他们搭建和维护整个AI测试工具链，设计Agent的调度逻辑，管理MCP集成，分析工具的误报率并持续优化。这件事在十八个月前根本不存在。
三名功能测试工程师，每个人每天处理的被测系统范围比十八个月前更广——因为常规场景的测试被Agent覆盖了，她们的精力集中在探索性测试、需求阶段的风险识别、以及AI功能的专项评估上。其中一位正在主导公司AI客服功能的质量体系建设，这个岗位六个月前还不存在。
一名自动化工程师，现在主要做两件事：测试数据管理体系的持续完善，以及生产环境的质量监控设计——两件事在引入AI之前都没有时间做，现在成了她主要的工作内容。
测试负责人，工作重心从"管理测试执行过程"转向了"定义质量标准和影响产品决策"——因为执行层的工作被AI和工具承担了，她有了时间和空间在更上游的环节发挥影响力。
七、结尾
回到文章开头的问题：引入AI测试工具后，人员变化是裁员、转岗还是能力升级？
答案是：三者都有，但比例不同于大多数人的预期。
一次主动转岗（她选择了更适合自己的环境），一次合同不续签（工作价值来源的收缩未被及时扩展），五次真实的能力升级（工作内容发生了显著变化，且方向是向上的）。
从九人到七人，表面上是人员减少，实质上是工作结构的重新配置——更少的人，在覆盖同等测试范围的同时，在做更多十八个月前没有条件做的事。
这不是一个让所有人都满意的结果，有人因为这次变化失去了熟悉的岗位。但它也不是一个"AI取代人类"的故事——七个人里，没有一个人的工作被完整复制进AI工具里。他们都在做AI做不了的那部分：判断、设计、协商、承担责任。
有一件事，这十八个月让我看得越来越清楚：
AI改变的不是团队需不需要人，而是需要什么样的人。
需要能够设计AI工作系统的人，需要能够判断AI结论的人，需要能够在AI覆盖不到的地方发挥洞察力的人。
这些人，在这个团队里都找到了自己的位置。
那些没有找到的，离开了——有人是主动的，有人是被动的。
这是我们经历的真实故事，没有刻意美化，也没有刻意渲染。
