翻 2027 届的招聘需求，你会撞见一个有点割裂的画面：一边是字节这样的公司在研发侧新增『AI 全栈』『AI Agent 开发』岗位，技术和产品类岗位需求占比超过七成；另一边，是招聘平台上纯手工、纯业务执行的测试岗肉眼可见地变少了。很多测试方向的新人卡在同一个问题上——第一份工作，到底该投『业务测试』还是『测试开发』？
先给结论：这不是一道「哪个更好找工作」的选择题，而是一道「你未来三年想往哪个能力方向长」的方向题。今天先把招聘信号按原口径摆清楚，再给你一张能力—岗位对照表，最后落到第一年无论选哪条都该校准的三个能力信号。
一、先看几条招聘信号，别被标题带偏
不贩卖焦虑，先把事实照口径摆出来，这一步比什么都重要——因为很多焦虑都来自被简化过的标题。
第一条，字节跳动 2027 届研发侧新增了『AI 全栈』『AI Agent 开发』等岗位，同时有梳理称其技术和产品类岗位需求占比超过七成。这里必须说清口径：这个「超过七成」指的是技术和产品岗在整体岗位需求里的结构占比，并不是「七成都是 AI 岗」，两回事，别混；而且它是单届口径，不要拿去和别的届数相加。
第二条，据教育在线（eol.cn）2026-09-07 的复核梳理，11 家科技大厂 2027 届里，AI 相关岗位合计约占四成。这说明 AI 岗在头部公司的分量确实在加重。
第三条，据新京报、经济观察报，前程无忧方面称近三成企业已在校招里布局 AI 人才，超三成应届生已经感知到 AI 带来的就业替代效应。
把这几条放一起，能得到一个定性判断：AI 相关岗位在扩，而纯手工、纯业务的执行类测试岗在收。至于今年的毕业生规模，媒体普遍的说法是再创新高、竞争更激烈——本篇不引具体的绝对人数，也没必要用一个吓人的数字来给你制造恐慌。趋势是真的，但趋势的另一面从来不是「岗位被简单取消」，而是「岗位被重新定义」。
二、AI 岗在扩、手工测试岗在收，对新人到底意味着什么
很多人看到「手工测试岗在收」，第一反应是「那我是不是必须会写代码、必须去搞 AI」。这是个误会，得先把话说清楚。
对绝大多数测试岗来说，AI 带来的变化不是让你去训练模型、写算法，而是让「测试这件事的价值锚点」发生了迁移。过去，一个测试新人的日常里，有很大一块是重复性的执行——照着用例一条条点、把结果记进表格。这类「按既定步骤执行、判定标准明确」的工作，恰恰是 AI 一键生成用例、自动化脚本最容易替代的部分。
但测试的价值不止于执行。真正难被替代的，是另外两件事：一是定义什么才算对——把一份模糊的需求翻译成可判定的验收条件，这需要业务理解和判断力；二是把验证沉淀成能反复重跑的资产——写脚本、搭框架、把用例接进流水线，让每次改动都能自动回归，这需要工程能力。前者偏「业务测试里更值钱的那部分」，后者正是「测试开发」的核心。
所以「手工测试岗在收」收的是纯执行的那一层，而不是整个测试职业。你要做的，是让自己尽快站到「定义标准」和「造可回归资产」这两层上去。想明白这一点，再看业务测试和测试开发的差别，就不会只盯着「哪个门槛低」了。
三、业务测试 vs 测试开发：一张能力—岗位对照表
把两条路摆到「日常做什么、需要什么硬技能、被 AI 冲击的程度、三年后的天花板、适合什么样的人」这五个维度上，差别就很清楚了：
对照维度
业务测试
测试开发
日常做什么
理解业务、设计并执行用例、提缺陷、盯上线，围绕具体功能做验证
写测试脚本/框架、搭自动化、造测试工具与数据、把用例接进 CI，围绕「怎么让验证自动跑」做建设
需要的硬技能
需求理解、用例设计、缺陷定位、抓包看接口，业务sense重于代码
一门编程语言、自动化框架（如 pytest/selenium）、接口与数据库、一点 CI/CD 与工程化能力
被 AI 冲击的程度
纯执行、纯手工点点的部分冲击最大；用例设计、业务判断这类仍难替代
写代码的活 AI 也在提效，但「设计测试策略、造工具、守回归」这类反而更需要人来定义
三年后的天花板
若停在执行层，成长容易见顶；若往业务专家/测试策略走，则越老越吃香
起点门槛高，但更靠近「AI 时代测试价值往定义标准、建可回归资产迁移」的方向，上限更高
适合什么样的人
对业务感兴趣、沟通和理解需求强、暂时不排斥但也不擅长写代码的人
喜欢写代码、愿意折腾工具和框架、能坐得住调试的人
看这张表要抓住一个关键：它不是「好 vs 坏」，而是「两种能力重心」。业务测试的核心资产是业务理解和判断力，测试开发的核心资产是工程和自动化能力。真正危险的位置只有一个——停在业务测试里最纯执行的那一层，既不往业务深处走，也不肯碰代码，那才是被 AI 冲击最直接的地方。
四、别急着二选一：第一年该校准的三个能力信号
新人常犯的一个错，是把「选方向」当成投简历那一刻的一次性决定。其实第一份工作给你的是什么岗位，你未必完全能选；但无论你落到业务测试还是测试开发，第一年都该主动校准下面这三个能力信号——它们是两条路共用、且都指向「难被替代」的地基。
第一个信号：会写断言，也懂用例设计。别把测试理解成「点一下看有没有报错」。你要能针对一个功能说清「什么情况算通过、什么情况算失败」，会用等价类、边界值、异常分支去系统地设计用例，而不是只测那条最顺的主流程。这个能力在业务测试里是立身之本，在测试开发里则是你写自动化断言时的判断依据。
第二个信号：能把模糊需求翻译成可判定的验收条件。产品丢给你一句「用户下单后要能查到订单」，你要能追问并定义出：什么状态算下单成功？查不到时该返回什么？并发下会不会查串？——把一句含糊的话，变成一组能明确判定对错的验收条件。这恰恰是 AI 最难替你做的部分，因为它需要对业务和风险的判断。
第三个信号：懂一点自动化和脚本。哪怕你的岗位是业务测试，也要主动去学一门语言、学 pytest 这类框架，把自己重复点的那些步骤写成能自动跑的脚本。这不只是「测试开发才需要的技能」，而是任何一个想往「造可回归资产」那层走的新人，都该在第一年就迈出去的门槛。
这三个信号合起来，其实就是把你从「只会按步骤执行的验证者」，慢慢养成「能定义对错、能把验证沉淀成资产」的人。方向可以慢慢定，但这三块地基，越早打越好。
五、给新人的落地行动建议
方向说清了，落到行动上不必一上来就啃大部头，也不需要什么昂贵投入。给三条现在就能走、成本很低的路径。
第一，别急着给自己贴标签，先各做一次小练习。挑一个你熟悉的小功能，先按业务测试的方式，认真设计一份覆盖主流程、异常、边界的用例清单；再用 pytest 把其中最重复的那几条写成能自动跑的脚本。两种都亲手做一次，你对「自己更适合、更愿意往哪走」的判断，会比看十篇分析都准。
第二，把「定义验收条件」当成刻意练习。每接到一个需求，都逼自己先写一句「这个功能怎样才算做对了」，再去测。这个习惯练的是前面说的第二个信号，也是你和「只会点点点」的人拉开差距的地方。
第三，给「被 AI 冲击」这件事一个正确的应对姿势：不是回避工具，而是站到工具够不着的那两层去。AI 能帮你生成用例草稿，你要做的是判断这些用例有没有覆盖到真正有风险的地方；AI 能帮你写脚本，你要做的是设计这套自动化该测什么、怎么接进流水线守住回归。你越往「定义标准」和「造资产」这两层走，AI 对你就越像是放大器，而不是替代者。
招聘需求还会一直变，今天扩的是 AI 岗，明天可能又是新的名词。但把测试当成「定义什么才算对、并让它能被反复验证」的这套底层能力，不会因为下一个热词出现就过时。
新人第一份测试工作选业务测试还是测试开发，真正决定你三年后能走多远的，从来不是这两个岗位名称，而是你有没有从第一年就开始往「定义验收标准」和「造可回归资产」这两层加厚自己。
你现在是卡在「不知道该投哪类岗」，还是已经入职却在纠结「要不要往测试开发转」？评论区说说你的处境，也想把这三个能力信号系统练扎实的话，来软件测试就业联盟，我们陪你把第一份工作的方向走清楚。
