九月，字节Data部门开始把QA往RD序列里并。爆料说截止时间卡在2027年12月，到那时纯QA岗位就没有了。差不多同一周，蚂蚁国际也在推研发测试合并。
这事传出来以后，我看了一圈讨论。有点意外的是，反应最大的不是测试，是开发。有人把截图转到群里，配一句"终于等到这一天"，底下一排点赞。
我当时没觉得有什么可高兴的。
因为几乎在同一个时间，还有两条消息，转的人不多。
一条是得物把独立的前端部门解散了，并进服务端。另一条是个数字：前端岗位的全球招聘需求，今年同比掉了将近一成。
这两条和字节那条搁在一起看，说的其实是同一件事——这一轮被重新排位置的，不只是测试。
一、我理解的"合并"，不是"砍掉"
很多人看到"QA转RD"，第一反应是"测试被开发吞了"。我一开始也这么想，后来觉得不太对。
更准确的说法可能是：岗位的颗粒度被调粗了。
以前做一个功能，要拆成好几道工。写页面的、写接口的、找bug的，各干一段。现在AI把每一段的工作都能干掉70～80%左右，公司自然想把这些段并成一个岗位，让一个人从头管到尾管起来，中间多用AI agents补上。
注意，是"并成一个"，不是"减掉几个"。这两者区别很大，但落到个人头上，感受可能差不多——因为确实有人要走。
所以我不想说"测试没事，别慌"这种话。有的人是真的要没有位置的。问题只在于：哪些人？
二、先说实话：确实有一类测试要没了
我在这个圈子待了二十多年，见过的测试大概能分两类。
一类是拿着需求文档，照着把场景列出来，然后写出一批测试用例，跑一遍，填结果，报 bug。这类工作有个特点——它可以被"标准化"。而标准化的东西，迟早能交给机器。AI 接手这类活，比人快得多，也便宜得多。
另一类，是那种你（特别是开发）遇到麻烦会想去问他的人。他会告诉你这个功能历史上在哪儿翻过车、这次改动的风险大概在哪、线上真出事了怎么定位。
第一类正在被吃掉，这是事实，而且只会越来越快。第二类暂时没事，甚至更抢手。
行业里过去有个做法，把手工测试往SDET（测试开发）转。过去有过一个统计，国内头部企业过半都已完成了这种转换。数据准不准，我不敢打包票，但方向是对的：被压缩的是"纯执行"的测试人，被争抢的是"既懂技术又懂业务、还能担事"的那批人。
三、那开发就安全吗？
这是我想多说两句的地方，因为它跟不少人的直觉相反。
现在有一种情绪，觉得"AI会写代码了，测试这个环节多余了"。这话放在五年前也许还站得住。但放在今年，你会发现它同时也在说另一件事——
如果"会写代码"本身正在变得不值钱，那靠"会写代码"立身的程序员，才是最危险的。
有个数字我印象比较深：某大厂今年九月的内部统计，新增代码里92%是AI参与生成的；而去年的数字是50%。从50%到92%，仅仅过去一年。
我不觉得这是在渲染末日。我只是觉得，当一个能力从"稀缺"变成"人人都有"，它就不太值钱了。会打字的人，曾经也是稀缺的。
有人做过统计，前后端那些纯编码的岗位，今年需求同比降了四到五成，同期AI相关研发岗的招聘量涨了将近八倍。一减一增。
所以真实的情况不是"测试被开发取代"，而是"写代码这一段，无论谁做，都在被重新定价"。
四、有个坑，比岗位之争更值得警惕
前阵子看到一个案例，印象挺深。
有个小团队，把写测试这件事整个交给了AI。代码覆盖率从47%一路涨到 98%，每一次合并请求都是绿的。大家挺高兴。
然而上线后出事了。用户注册的竞态条件导致邮箱重复，优惠码接口返回了null不是 0，支付算错。最后赔了四万多美元，还搭进去六十多个工时。
问题出在哪？出在代码和测试是同一个AI生成的，用的是同一套逻辑。代码里假设"输入都是正常的"，测试里也这么假设。所以代码错了，测试会用同样错的方式，告诉你"没问题"。
这个坑有个名字，叫覆盖率幻觉。98%的覆盖率看着很安全，实际上什么都没保证。
我不想把这事说成"AI不行"。AI挺好的，只是我们工程师用错了。我是想说：当写和验这两件事交给同一个AI做的时候，中间就少了一个人。而少的那个人，恰恰是唯一会说"等一下，这样不对"的人。
五、两种脑子
这事在网上吵的时候，反方有个说法挺典型："测试没什么技术含量，开发顺手就做了。"
我不同意，但我想好好说为什么不同意。
举个特别小的例子。
有个导出报表的功能。开发写测试，写了三条：能导出、空数据能处理、没权限会报错。全过。看着挺完整。
后来测试的人接手，问了几个问题：导十万行浏览器会不会卡死？手抖连点三次会不会出三个文件？导到一半断网，服务器上会不会留一堆垃圾？报表里有客户手机号，别人能不能拿到？
这几个问题，开发的测试里一个都没有。
你不能说开发不上心。他的脑子在"构建模式"里——想的是怎么把东西做出来，默认输入是对的。测试的脑子在"破坏模式"里——想的是这东西会在哪儿坏。
这跟聪明不聪明没关系，是脑子的默认设置（长期的思维习惯）不一样。而思维习惯这东西，改起来很慢。有人三个月能学会写用例，但要习惯性地往"它会在哪儿坏"上想，得好几年。
六、现实中的数据，表面上看起来挺残酷的
说实话，现实中有几组数据挺硬，让测试人感到残酷。
一个是薪资，开发的薪资长期是测试的一点五到两倍。一个是岗位，统计说 QA 岗位这两年降了将近三成。还有一份报告，直接把 QA 排进了"最容易被AI替代的职业"前几名，开发排在二十名开外。
这些可能是真的。
但我一直觉得，市场给的是"昨天的价"。能力结构的供需变了，价格滞后好几年才跟得上。拿现在的薪资去算未来的价值，有点像拿去年的地图找今年的路。
还有一组数据，开发人员特别喜欢用，说新增的高端质量岗位里，六到七成是开发背景的人。他们的结论是"这证明测试没价值，得开发来干"。
我看到的是另一层意思。这些岗位之所以倾向找开发背景的人，是因为它要的是"懂系统、能设计质量方案"的人，而过去几年里最容易长出这种能力的人，恰好是开发。这不叫"测试没价值"，这叫门槛被抬高了——抬到了“光会点点点的人” 进不来的高度。
再补一个开发人员不太提的角度。不管用什么方法（AI、自动化、手工），最终还是要保证业务不出问题，面向业务的端到端测试（验证）不能少，而且是挺复杂的，而仅仅靠单元测试、功能测试是无法保证的，况且像性能测试、安全方面的渗透测试，目前AI的能力也比较弱。所以，如果你的公司重视质量、懂质量，也不会把所有的测试并进开发，会保留一个小的团队来做业务端端验收测试——E2E测试。
七、到底谁取代谁？
写了这么多，回到最开始那个问题。
我的答案是：谁也没取代谁，但位置在重新划分、岗位会在不断的融合。
把"测试"这两个字拆开看，它其实能站在两个很不一样的地方。
一个地方叫执行：照着规范跑一遍，把结果记下来，报出 bug。这个地方正在被AI吃掉，快慢而已。
另一个地方叫判断：判断这个功能的风险在哪、哪几道关卡不能省、AI 生成的东西能不能信、这一版能不能发。这个地方在变值钱。
这两个地方，跟你的工牌没关系。你工牌上写RD还是QA，不重要；重要的是你每天站在哪一边。
这也就能解释，为什么"QA并进RD"这事，慌的不是所有测试，只是一部分；"前端并进后端"，慌的也只是一部分前端。焦虑从来不属于某个岗位，它属于某个位置。
八、几句实在的建议
第一，把 OpenSpec、OpenCode这类工具用起来。这不是加分项，是现在的门槛。不会用，路会越走越窄。
第二，找一个你真正懂的业务方向，往深里钻。AI眼下最拿不下的，是"这行里踩过的坑"——而这些坑只活在具体的人和具体的业务里。你在哪个行业待得久，你的价值就在哪儿。
第三，试着把脑子里的经验写下来。不是写"我踩过这个坑"，而是写清楚：什么情况下会踩、为什么踩、怎么验证能抓到、下次怎么防。写得多了你会发现，这些东西是你最不容易被替代的部分——因为没法从别处学来。
回到开头。字节把QA并进RD，我不觉得这是"测试完了"的信号。它更像一句提醒：工种之间的墙在拆，以前靠"我干的是这摊活"活着的人，会有点难受。
真正稳的，是那种既能把活干完、又能对结果负责的人。这种人，哪个工牌都需要。至于叫什么名字，其实没那么重要。
测试人，如何在AI时代活下来？
新书速递：《大模型驱动软件测试》
新书速递《软件工程3.0：大模型驱动的研发新范式》