
去年冬天前同事老周发了一条朋友圈定位在望京的一个外卖站点。配文是“以前跑用例现在跑单都是跑。”我私聊他他说被裁三个月了。面了十几家手工测试岗要么已经招满要么面试就问“你会不会调 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 测试等内容侧重测试实践、工具应用与工程经验整理。