当效率工具变成裁员加速器，我经历了最纠结的三周
大家好，我是某互联网公司质量保障团队的负责人，手下管理着20多人的测试团队。
今天聊一个让我至今都不太舒服的经历——我们上线了一套AI测试排期系统，它“理性”地把两个老员工的工作内容判了死刑。
不是标题党。这件事发生在去年年底，整个过程只有三周。
一、故事的起点：提效，还是提效
2024年Q4，公司开始大谈“降本增效”。我们测试团队也不例外——老板的目标很明确：在不降低质量的前提下，把人效提升30%。
我们梳理了一下测试流程，发现最耗时的环节是“测试排期”。
每次版本迭代，测试经理都要花1-2天手动排期：评估每个模块的变更影响范围、判断风险等级、分配测试资源、排定执行顺序。涉及十几个开发团队的代码变更、几十个业务模块、几百条用例，全靠人工判断和经验积累。
于是我们立项做了一个AI测试排期系统：
输入：本次迭代的代码变更、历史Bug数据、业务调用链路
AI分析：每个模块的变更风险、受影响范围、历史故障概率
输出：自动生成测试优先级排期——高风险的先测、多测，低风险的后测、少测
原理不复杂，但效果确实好。系统上线后，排期时间从2天压缩到了15分钟，高风险场景的测试覆盖率提升了25%。
老板很高兴。
但问题也来了。
二、转折：AI说“这两个人的活可以砍掉”
系统跑了三周，我们开始用它来做测试资源分配优化——把AI的排期结果和实际的测试人力投入做对比，找出“投入产出比低”的工作内容。
结果AI给了一份让所有人都尴尬的报告。
报告显示，测试团队里有两类工作被标记为“低业务风险-高时间投入”：
第一类：老张的“全量回归”
老张，38岁，入职8年，是团队里最资深的测试工程师。他的核心工作就是每个版本跑全量回归——所有用例从头到尾过一遍，确保没有历史功能被破坏。
AI的分析结果是：过去6个月，老张负责的回归测试模块零故障。不是他测得好，而是这些模块已经18个月没有代码变更了。
AI的结论：“这部分回归测试的边际收益趋近于零，建议调整为按需执行，释放70%的人力。”
第二类：老李的“手工兼容性”
老李，42岁，入职10年。他最擅长的是手工兼容性测试——在不同品牌手机、不同系统版本上人工验证UI适配。
AI的分析结果是：这部分工作已经被自动化兼容性测试工具覆盖了92%。而且自动化工具的执行速度是手工的15倍，覆盖设备数量是手工的8倍。
AI的结论：“建议将剩余8%的边缘场景纳入自动化，该岗位工作内容可被完全替代。”
报告里没有写“建议裁员”，但字里行间的意思谁都看得懂。
三、尴尬的沉默
我拿到报告的时候，是周五晚上10点。
我一个人在办公室坐了很久。数据摆在那里，AI的推理逻辑没毛病——从纯理性的角度看，老张和老李的工作确实存在“优化空间”。
但他们是跟着我干了这么多年的人。
老张是我入职那年就在的老员工。当年App上线前夜发现了一个严重的内存泄漏，是他通宵排查定位的。
老李是全团队最懂Android碎片化的人。哪款国产手机的WebView有坑、哪个系统版本有兼容性问题，他脑子里有一张活地图。
这些价值，AI的报告里一个字都没有写。
我不知道该怎么跟老板开口，更不知道该怎么跟老张和老李开口。
四、硬着头皮推进的结果
周一，老板找我开会：“那份报告看了吧？说说你的想法。”
我说了我的顾虑。
老板说了一句让我很难反驳的话：“公司要活下去，每个人都要证明自己的价值。AI只是把问题提前暴露了，不是制造了问题。”
这句话站在管理者的角度没有错，但我还是争取到了两个缓冲方案：
给老张和老李3个月转型期，从执行岗转向“测试策略设计+AI工具训练”
在此期间，薪资和职级维持不变，由团队提供系统的AI测试技能培训
然后我分别找老张和老李聊了。
老张沉默了很久，最后说了一句：“我知道这一天迟早会来。 ”
老李的反馈更直接：“我来公司10年，你让我从头学AI？你觉得我学得动吗？ ”
那场对话是我职业生涯里最艰难的一次。
三个月后，老李还是走了。老张留了下来，现在在负责AI测试用例的训练数据标注，做得还不错——他的业务经验在这里派上了用场。
但这三个月的过程，对所有人都是一种消耗。
五、复盘：问题到底出在哪？
事情过去半年了，我一直在想这个问题。
AI的判断确实“理性”，团队也确实“提效”了——测试人效提升了28%，版本发布周期缩短了2天。老板满意，数据好看。
但我心里始终觉得，这个过程中我们做错了一些事。
错误一：把“测试排期系统”扩展成了“资源优化系统”
初衷是做“排期提效”，跑着跑着变成了“人力优化”。
这两个目标的性质完全不同。前者是用AI解放生产力，后者是用AI替代人。当工具的边界被悄然扩大，风险就不是技术问题了。
错误二：忽略了隐性知识的价值
老张和老李的价值，不在他们“做了什么”，而在他们“知道什么”。
老张知道哪个模块历史上出过什么诡异问题
老李知道哪款手机的某个特定系统版本有特殊行为
这些知识不在代码里、不在文档里，在他们的脑子里。AI可以替代他们的“操作”，但替代不了他们的“经验”。
等这些人走了，这些隐性知识也就跟着走了。
错误三：没有提前做技能规划
我们上线AI系统的时候，没有同步规划团队成员的技能转型路径。
老张这样的老测试员，未来应该做什么？
手工测试的同学，怎么转成AI测试工程师？
哪些岗位会被替代，哪些岗位会新增？
这些问题的答案，系统上线两个月后才开始想——已经太晚了。
错误四：数据指标过于简化
AI判定老张的工作“低风险”，依据是“过去6个月零故障”。
但这个“零故障”本身，正是因为他每个版本都在做全量回归——他查得那么细，才没让问题漏到线上。把“没发现问题”等同于“工作没价值”，在逻辑上是一个致命的谬误。
用结果倒推行为的价值，尤其在质量保障这个领域，是非常危险的思维。
六、这件事之后的三个改变
经历这件事之后，我对“AI+测试管理”有了新的思考。我做了三个改变：
改变一：明确AI的边界——它做“排期”，人做“决策”
AI的输出不再是“指令”，而是“参考”。
现在的流程是：
AI生成排期建议 → 测试经理review → 根据实际情况调整 → 最终确认
AI可以告诉你“哪个模块风险高”，但“谁来测、测多久、能不能砍掉”——这些决策必须由人来做。
改变二：建立“技能转型通道”
在推动AI工具落地的同时，同步规划人员转型路径：
手工测试 → AI测试训练师（教AI怎么测）
脚本维护 → 测试工具开发（帮AI搭平台）
用例编写 → 测试策略设计（告诉AI测什么、为什么测）
每个人都有一个明确的转型方向和时间表。
改变三：重新定义“老员工的价值”
老员工的经验不能被AI替代。我们的做法是让他们转型成“AI训练师”：
标注高质量数据
定义“什么是好用例”
验证AI生成结果的准确性
补充AI覆盖不到的边缘场景
这些工作AI干不了，但老员工干得很好。
七、给同行的一些话
如果你正在测试团队引入AI，我有几点实在的建议：
- 不要用AI来做“对人的判断”
AI可以判断“这段代码的风险”，但不要让它去判断“这个人的价值”。
数据和指标是冰冷的，人的价值是多维的——经验、判断力、团队协作、隐性知识——这些AI看不到。
- 在系统上线之前，先想好“人往哪里去”
技术落地之前，先做好人力规划。
如果某些岗位会被AI替代，这些人应该转去哪里？需要什么培训？转型周期多久？这些问题应该在项目启动时就回答，而不是上线之后。
- 保护好团队的信任感
用AI“优化掉”同事的消息一旦传开，整个团队的士气会崩塌。
大家会觉得：“下一个是不是我？”然后人心涣散，能跑的都会跑。
宁可慢一点，也不要把效率工具变成恐慌制造机。
- 把“隐性知识”记录下来
在老同事转型之前，花时间把他们脑子里的经验系统性地沉淀下来：
业务的坑点清单
历史故障的完整复盘
边缘场景的手工测试手册
这些不是“老员工应该做”的事，而是“管理者应该组织做”的事。
最后
AI不会让测试这个岗位消失，但会让某些工作方式消失。
作为一个管理者，我的责任不是“用AI省钱”，而是“带着团队走过这场变革”。让留下的人有成长，让走的人有尊严——这是我在这场经历之后给自己的要求。
工具是冷的，人是热的。效率是硬的，信任是软的。
做一个好的管理者，就是要在这两者之间找到平衡。
本文系作者基于真实经历的复盘总结。文中人名已做脱敏处理，欢迎同行交流讨论。
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
