去年冬天，前同事老周发了一条朋友圈，定位在望京的一处外卖站点。配文只有一句话：“以前跑测试用例，现在跑单，都是跑。”
我问他近况。他说被裁三个月了，面试了十几家公司，手工测试岗位要么早就招满了，要么上来就问“你会不会调 prompt 做自动化测试”。
他苦笑，写了八年测试用例，如今连面试机会都拿不到。
这不是个别现象。2026年过半，软件测试行业的淘汰机制正在以一种非常具体的方式运转。被淘汰的人，并非不够努力，而是他们的努力方向被系统性地架空了。
一、半年没联系，老周已经在送外卖了
今年脉脉测试板块有条帖子特别火：“2026年Q1，测试岗位招聘量同比下降41%，但测试开发岗位薪资中位数上涨了18%”。
一边是火焰，一边是海水。火的那头，企业疯狂寻找能搭建AI测试流水线的人，职位描述里满屏都是“大模型应用”“智能体构建”。冰的那头，传统功能测试、兼容性测试、接口手工测试的岗位正在大规模消失，投出去的简历像扔进了黑洞。
很多被优化的测试工程师想不通：我经验丰富，业务熟练，凭什么不要我？
理由很残酷。不是你不行了，而是你手里的技能组合，刚好落在了AI的射程之内。AI淘汰的不是岗位，而是“可被规则穷举的技能”。
二、不是AI太强，而是测试工作的“可自动化边界”正在坍塌
过去十年，测试自动化一直盯着那些“稳定且可复现”的操作，交给脚本去执行。但这堵墙一直很稳——脚本编写成本高，维护更是门槛。大模型一来，直接把这堵墙推倒了：它不需要你一行行写死定位器和验证逻辑，它能理解自然语言描述的需求，能看懂界面上的按钮叫什么，能从日志堆里找出相关报错。
本质上，大模型把自动化的单位从“脚本”变成了“语义理解”。原来那堵墙——那些“规则复杂、难以穷举，但终究还是规则”——被彻底推倒了。以前你觉得只有人能写的测试用例，现在模型能写出八九不离十；以前你觉得只有人能判的界面异常，现在视觉模型能挑出90%；以前你觉得只有人才能分析的性能瓶颈，现在模型关联一下 trace 和 log 就能给出推断。
可自动化的边界，一下子吞掉了手工测试大半个生存空间。
三、一张图看懂：你的哪些日常正在被模型吞噬
别急，我们用工程视角把测试工程师的日常工作拆开来看。下面是一张简化版的传统测试活动流，标注了当前AI插件的实际介入位置。
虚线箭头指向的五个环节，现在都有成熟的AI插件方案，覆盖了从用例生成到回归推荐的全链路。只有两个环节目前还比较依赖人：需求分析和测试策略设计。这不是说它们不会被AI触及，而是它们对业务上下文、风险判断的依赖更重，现阶段的模型还做不到可靠。但其他环节，模型已经能处理得很好，甚至更好。
核心在于，虚线框住的那些工作有一个共同特点：它们处理的是“给定清晰输入，产出规范输出”的任务。而这正是大模型最擅长的事——语义到语义、语义到代码、语义到数据的转换。一个测试工程师如果80%的精力都耗在这些环节，基本就是在和机器正面竞争。结果不言而喻。
四、活下来的那批人，到底做对了什么
那些没有被优化的测试开发，没有一个是靠“更会写用例”活下来的。他们做的事情，本质上是一次角色转换：从测试活动的执行者，变成测试系统的设计者。具体来说，有三件事做得特别不一样。
第一，他们把测试资产当产品来做。用例库不再是堆积的Excel，而是有结构的语料。他们会给历史用例打标签、建向量索引、定义相似度标准。这样AI生成用例时，能精确召回团队沉淀下来的领域知识。产出的不是通用模板，而是带着团队经验的、可用的测试用例。
第二，他们重新定义了“完成”。以前测完了，报告一发就算结束。现在他们在每个测试活动结束后会做一件事：把人工修正的结果回流。比如AI生成的用例 review 后改了哪些地方、为什么改，这些信息会写回提示词示例或知识库里。这样的系统就有了自己迭代的能力，越用越准。
第三，他们抢着去填“AI还做不好”的坑。需求评审时能不能发现逻辑漏洞？探索性测试时能不能找到意料之外的用户路径？质量度量体系怎么设计才能反映真实风险？这些事，模型现在还糊弄不来，却是高级测试开发最核心的护城河。
未来测试开发的核心竞争力，不是“会用什么工具”，而是“能把哪些知识塞进工具里”。
五、三个工程化动作，现在做还来得及
如果你发现自己每天的工作大量落在上图的虚线框里，以下三件事可以立刻开干。它们不是速成技巧，而是工程化思维的转变。
动作一：把你手里的隐性知识，变成机器能吃的格式。问问自己：评审用例时，你脑子里那个“这里容易出bug”的经验，写过规则吗？分析缺陷时，你判断“这个 crash 大概率是内存泄漏”的推理链条，梳理过吗？把这些东西结构化，写成判断逻辑、标签体系、prompt 模板。一旦完成这一步，你就从一个经验丰富的执行者，变成了一个能给AI系统认知喂料的人。
动作二：在团队里建立“AI输出-人工确认-结果回流”的最小闭环。不需要领导批准，也不用引入新平台。找一个你每天在做的事情，比如生成接口测试数据。先用大模型生成，你检查修正，然后把修正后的数据版本作为好的示例保存下来。下次生成时带上这个示例。跑一个月，你就能看到质变。这个闭环，就是你自己的测试智能体雏形。
动作三：刻意练习“问对问题”的能力。用AI生成用例，结果水不水，很大程度上取决于需求描述得够不够清楚。把“给我写点登录用例”换成“列出用手机号+验证码登录时，考虑到断网、频繁发送、倒计时结束三种异常场景，接口层面应验证的状态码和提示文案”。这不是写提示词，这是在定义测试模型。能做好这件事的人，无论工具怎么变，都稀缺。
六、最后，问你一个问题
老周的故事不是个例，也不可逆。2026年之后，测试工程师的生存标准已经被重写。送外卖只是一个隐喻，它代表那些被技术变革挤出原有轨道的人。真正的分界线，不是你会不会用某个AI工具，而是你的工作里，到底有多少比例属于“机械执行”，有多少属于“智力构建”。
文章写到这里，请你停下来，认真想一个很具体的问题：如果把你上周做的所有工作列出来，逐条判断它是“规则可描述的执行活动”还是“需要深层判断的质量决策”，那条分界线划下来，你留在右边的东西，还剩多少？
答案不着急。但这个问题，值得你每隔一段时间就问自己一次。
