去年冬天，前同事老周发了一条朋友圈，定位在望京的一个外卖站点。配文是：“以前跑用例，现在跑单，都是跑。”

我私聊他，他说被裁三个月了。面了十几家，手工测试岗要么已经招满，要么面试就问“你会不会调 prompt 做自动化”。

他苦笑着说，写了八年用例，现在连面试机会都拿不到。

这不是个例。2026 年过半，测试行业的淘汰机制正在以一种非常具体的方式运转。被淘汰的人，不是不努力，而是他们的努力方向被系统性地架空。

目录

一、半年没联系，老周已经在送外卖了
二、不是 AI 太强，是测试工作的“可自动化边界”在坍塌
三、一张图看懂：你的哪些日常正在被模型吃掉
四、活下来的那批人，到底做对了什么
五、三个工程化动作，现在做还来得及
六、最后，问你一个问题

一、半年没联系，老周已经在送外卖了
今年脉脉测试区有个帖子很火：“2026 年 Q1，测试招聘量同比下降 41%，但测开岗薪资中位数涨了 18%。”

冰火两重天。

火的这边，企业拼命找能搭 AI 测试流水线的人，JD 里满屏的“大模型应用”“智能体构建”。冰的那边，传统功能测试、兼容性测试、接口手工测试的岗位大规模消失，投出去的简历像扔进黑洞。

很多被优化的测试员想不通：我经验丰富，业务熟练，凭什么不要我？

理由很残酷。不是你不行了，是你手里的技能组合，刚好落在了 AI 的射程之内。

AI 淘汰的不是岗位，而是“可被规则穷举的技能”。

二、不是 AI 太强，是测试工作的“可自动化边界”在坍塌
过去十年，测试自动化的目标一直是把“稳定且可复现”的操作交给脚本。但这段边界相对保守，因为脚本编写成本高，维护成本更高。

大模型出现后，局面变了。它不需要你一行行写死定位器和验证逻辑。它能理解自然语言写的需求，能看懂界面上的按钮叫什么，能从日志堆里找出相关报错。

本质上，大模型把自动化的单位从“脚本”变成了“语义理解”。这让原来那堵墙——那些“规则复杂、难以穷举，但终究还是规则”——被推倒了。

以前你觉得只有人能写的测试用例，现在模型能写个八九不离十。以前你觉得只有人能判断的界面异常，现在视觉模型能挑出 90%。以前你觉得只有人才能分析的性能瓶颈，现在模型关联一下 trace 和 log 就给出了推断。

可自动化的边界，一下子吞掉了手工测试大半的生存空间。

三、一张图看懂：你的哪些日常正在被模型吃掉
别急，我们用工程视角把测试员的日常工作拆开看。下面是一张简化版的传统测试活动流，标注了当前 AI 插件的实际介入位置。

虚线箭头指向的五个环节，现在都有成熟的 AI 插件方案。它们覆盖了从用例生成到回归推荐的全链路。只有两个环节目前还比较依赖人：需求分析和测试策略设计。

这不是说需求分析和策略设计不会被 AI 触及，而是它们对业务上下文、风险判断的依赖更重，现阶段的模型还做不到可靠。但其他环节，模型已经能处理得很好，甚至更好。

核心在于，虚线框住的那些工作，有一个共同特点：它们处理的是“给定清晰输入，产出规范输出”的任务。而这正是大模型最擅长的事——语义到语义、语义到代码、语义到数据的转换。

一个测试员如果 80% 的精力都耗在这些环节，基本就是在和机器正面竞争。竞争结果，不言而喻。

四、活下来的那批人，到底做对了什么
我身边没有被优化的测开，没有一个是靠“更会写用例”活下来的。

他们做的事情，本质上是角色转换：从测试活动的执行者，变成了测试系统的设计者。

具体有三件事做得不一样。

第一，他们把测试资产当产品来做。用例库不是堆积的 Excel，而是有结构的语料。他们会给历史用例打标签、建向量索引、定义相似度标准。这样当 AI 生成用例时，能精确召回团队沉淀下来的领域知识。产出的不是通用模板，而是带着团队经验的、可用的用例。

第二，他们重新定义了“完成”。以前测完了，报告一发就算结束。现在他们在每个测试活动结束后会做一件事：把人工修正的结果回流。比如 AI 生成的用例 review 后被改了哪些地方，为什么改，这些信息会写回提示词示例或知识库里。这让他们自己的测试系统有了迭代能力，越用越准。

第三，他们抢着去填“AI 还做不好”的坑。需求评审时能不能发现逻辑漏洞？探索性测试时能不能找到意料之外的用户路径？质量度量体系怎么设计才能反映真实风险？这些事，模型现在还糊弄不来，却是高级测开核心的护城河。

未来测试开发的核心竞争力，不是“会用什么工具”，而是“能把哪些知识塞进工具里”。

五、三个工程化动作，现在做还来得及
如果你发现自己现在的工作内容大量落在上图的虚线框里，有三件事可以立刻开始做。这些不是速成技巧，而是工程化思维的转变。

动作一：把你手里的隐性知识，变成机器能吃的格式。

问问自己：评审用例时，你脑子里那个“这里容易出 bug”的经验，写成过规则吗？分析缺陷时，你判断“这个 crash 大概率是内存泄漏”的推理链条，梳理过吗？把这些东西结构化，写成判断逻辑、标签体系、prompt 模板。一旦完成这一步，你就从一个经验丰富的执行者，变成了一个能给 AI 系统的认知喂料的人。

动作二：在团队里建立“AI 输出-人工确认-结果回流”的最小闭环。

不需要领导批准，也不用引入新平台。找一个你每天在做的事情，比如生成接口测试数据。先用大模型生成，你检查修正，然后把修正后的数据版本作为好的示例保存下来。下次生成时带上这个示例。跑一个月，你就会看到质变。这个闭环，就是你自己的测试智能体雏形。

动作三：刻意练习“问对问题”的能力。

用 AI 生成用例，结果水不水，很大程度上取决于需求描述得够不够清楚。把“给我写点登录用例”换成“列出用手机号+验证码登录时，考虑到断网、频繁发送、倒计时结束三种异常场景，接口层面应验证的状态码和提示文案”。这不是写提示词，这是在定义测试模型。能做好这件事的人，无论工具怎么变，都稀缺。

六、最后，问你一个问题
老周的故事不是个例，也不可逆。2026 年之后，测试员的生存标准已经被重写。

送外卖只是一个隐喻，它代表的是那些被技术变革挤出原有轨道的人。真正的分界线，不是你会不会用某个 AI 工具，而是你的工作里，到底有多少比例属于“机械执行”，有多少属于“智力构建”。

文章写到这里，我想请你停下来，认真想一个很具体的问题：

如果把你上周做的所有工作列出来，逐条判断它是“规则可描述的执行活动”还是“需要深层判断的质量决策”，那条分界线划下来，你留在右边的东西，还剩多少？

答案不着急。但这个问题，值得你每隔一段时间就问自己一次。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。