测试开发之路 当裁到你头上的时候,你还要反对 AI 么?

孙高飞 · 2026年08月29日 · 最后由 晴空万里总有芬芳 回复于 2026年09月02日 · 5460 次阅读

前言

前几天接到通知,大老板开始统计每个测试团队的智能体数量,智能体调用次数,智能体发现 bug 数,需求吞吐量,平均需求测试时长,平均需求开发时长等各项指标。AI 提效,已经从探索阶段正式转变为可量化的指标,目标直指量化各个测试团队的 AI 产出能力和效率提升能力。虽然明面上没有说, 但大家都知道这也是为后续的裁员提供数据基础。效率提升不上去的,大概率要被纳入裁员名单里。

我询问了一些在其他大厂做测试的朋友,发现他们那边也差不多。在当前的大环境下,降本是主流趋势,AI 是降本的主流手段。很残酷,也很现实。起码在大厂是这样的,我自己所在的测试团队里,已经离开了 5,6 个人,其中不乏集团正式员工。而这个裁员动作是仍然没有结束的。

在大厂,不拥抱 AI 是生存不下去的

效率,是目前行业中最重要的话题。上半年 AI 编程刚火起来的时候,我们大老板就提出了一个所有同行都要面对的问题:开发人员用 AI 提高了效率,那测试人员呢?

可能很多同学还想要讲道理,比如开发人员用 AI 后效率虽然大幅度提高了,但写出来的功能 bug 很多。比如 AI 用来写代码很强,但用来做测试有很多局限性。 这些话没错,错的是你想跟老板讲道理。这世上有几个老板是跟员工讲道理的?跟员工讲道理的人大多都是当不了老板的。起码在大厂,我们是没的选的,要么离开,要么满足老板的需求。

所以各种测试智能体,AI 用例生成,AI 自动化脚本生成等手段该上就是要上的。AI 测试就是我们这里的主流质量保证手段。可能有些同学会很鄙夷,觉得 AI 生成的用例能完善么?能保证好质量么?能有我古法操作质量好么?也许人工操作确实更好。但不好意思,你没有时间。200 个需求,拆分到 5,6 个人身上,一周内必须测完。人均 30~40 个新需求,有的需求大到光需求文档就上万字,并且还要跑回归测试,搞的完么?

我有一个被裁的同事,所有人公认的测试很细,他负责的需求一定测的明明白白的。 但为什么还裁他?因为他只能负责一个模块,而其他人负责了两三个模块,我巅峰的时候负责了 5 个模块。他测的是细致,质量是好。 但老板的视角是我把你裁了,换 5 个外包来也不一定比你差,而且 5 个外包能负责更多的工作。

可能还有些同学会质疑,人家质量保证做的好啊,难道公司不要质量了么? 可现在公司的逻辑不是这样的,现在的主要矛盾是成本,是使用更少的人力支撑起更多的项目。 谁的成本更低, 谁的效率更高, 谁能用最短的时间把用户需要的功能迭代出来,谁就能活下去。这些才是当下行业中的主要矛盾。

所以,当老板面对这样的选择:保证业务质量到 95 分且只能保证一个模块的同学 A,以及使用了 AI 可以同时保证 5 个模块质量到 85 分的同学 B。 大家猜,现在的老板选哪个? 我们心里想的是工匠精神打磨产品,老板心里想的只有冷冰冰的数字。尤其是质量这个东西,是很难量化度量的,在老板视角里,同学 A 的质量真不一定比同学 B 强。并且大多数老板的理念是:测试把质量做好是应该的,是份内之事,这不是什么加分项。所以现实中很多老板眼里只看的到同学 A 的效率低下。

所以我们这些使用 AI 做测试的人,有些时候是在探索一条边界:如何用最快的方式达到产品质量的 85 分线(假设 85 分是用户和老板都可以接受的线),而不是在追求达到优秀的那条线。然后快速用 AI 覆盖到其他业务线上达到一个人可以负责的事情更多的效果。

总结

我以前总说,不要对抗大势,那是螳臂挡车。如果 AI 是大势,我们就去拥抱它,如果未来 AI 不行了,回归人工变成了大势,我们也去拥抱它。这无关对错,只是普通人对抗风险,挣扎求生的职场哲学。职场,总要优先保证自己能活下来,再说其他的。

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 10 条回复 时间 点赞

AI 出来最大的问题是消费的的死亡螺旋坠落,裁的越多越没人敢消费,需求进一步收缩,这边也确实不需要更多人去测需求了。块也就 2,3 年吧大萧条就要来了,现在最大的问题是吉祥三宝,铁人三项都开始不要人了

dun 回复

我看下来, 感觉咱们两个说的是一件事情,只是细节有出入。 拥抱 AI 肯定是以产生价值为导向,而不是为了 AI 而 AI。 最终都是以效率为度量。

和 DB 讨论下,总结的结论:

  1. 团队的业务价值 = 根基(你有没有存在的意义)
  2. 你在团队位置 = 杠杆(你的工作角色重不重要)
  3. 沟通协作 = 助推器(你的价值能不能被看见、落地)
  4. 薪资性价比 = 天平(公司衡量要不要保留你的成本标尺)
  5. AI 能力 = 加速器(放大前面四项带来的结果)
孙高飞 回复

观点一致的,会与不会 AI 不是裁员硬性指标,但是用错了 AI 与完全拒绝 AI 结果一样会被裁,还是要把 AI 正确的放在解决公司的问题上,能解决公司看得见的问题,能带来领导看得见的效率提升,怎么会裁你,裁了不就裁到大动脉了?很多说 AI 无用论的,估计大部分都是用来写文档、写用例、写平台。这完全是用杀猪刀杀蚊子蟑螂呀

dun 回复

请教下你现在 AI 主要用在哪方面,为公司带来了什么量化价值?

赵又廷 回复

我们现在也没有量化出价值,所以我们没免费的 AI 用。目前也在摸索着,自费 tokens 我不提倡,所以一直是自己偷偷用。但是会告诉领导,有无限 token 且能拿到开发源码,可以干很多事情。
目前能摸索的也有限:
测试左移:我们没有需求评审、用例评审、技术评审流程,测试左移只能到编码阶段,只要拿到开发源码,隐藏风险和潜在崩溃问题可以在编码阶段开始排除,测试阶段压力会小一些;
性能测试分析以及性能调优:以前只出报告,分析的也不那么准确,现在用 AI 能准确分析原因和期望调优方向;
项目知识库、工业、工程施工规范 RAG:当时喂了几个 G 的数据,包含工业工程施工规范的相关专业知识。写工业软件、工程施工相关的测试用例时会首先找这些专业知识,然后生成实际施工、运行需要的测试场景,还能提供给项目实施团队验收用例;
业务场景的接口自动化:只跑业务流转相关的接口,在回归阶段挺好用;
各种提效工具:结合自身公司痛点针对性的做的一些工具,用着还行、且自费不多,所以公网部署了一版,其他人在用着,目前公司 4 个测试,文档生成类调用数据有 100 多次,文档转换类调用有 70 多次,SQL 生成类调用有 40 多次;
提效工具这个是目前唯一落地了的(维护便宜、免费用且确实省时间),以前人工时总是会占 2 天左右的测试时间去写各种文档、材料,现在在前置条件满足的情况下 20~30 分钟搞定,现在同样的任务排期,测试可以多 2 天摸鱼时间。

dun 回复

请教下是哪方面的提效工具,我现在是测试,也用 ai 进行测试,感觉测试过程并没有提效多少,虽然 ai 可以很快完成测试,但是人工核对的时间很长。。

当人力成本低到一定程度,且是短期任务的时候,可以适当外包。
持续产出太难。
越快越卷死自己,无解。

两条路子:
爱学习的孩子 不怕裁
跟着我们 5 年规划走 不会裁

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册