AI 时代,守门员该不该参与进攻:关于「QA 转研发」的五种立场

上一篇《别急着给 QA 开追悼会》的评论区来了五条留言。

一条说，质量的真源头在产品设计和研发代码，「研发代码几乎没人管，只看结果」。

一条说，分久必合，AI 提效要靠监控兜底，监控做多了效能降、做少了质量降。

一条说，这是让守门员去参与进攻。

一条说，一个锅里吃饭香。

还有一条说，拭目以待。

本文是我对评论的评论。双方的证据都摆出来，包括反对我上一篇的。

1

质量该谁负责

Google 的制度是开发测自己的代码，测试者去做工具和平台。

而 Hacker News 上一位老 QA（ID 是 salawat）反对这个安排：不设 QA，就失去了那支唯一有权要求开发在乎质量的执法力量。

还有一位说得更狠：QA 该像警局的内务部，不该和产品团队向同一个经理汇报。

责任人人有份，那它到底挂在谁的绩效上？

2

守门员参与进攻

制衡派的论据是冗余：FAA 要求飞机上永远有两个飞行员，审计行业也没有自己出终稿的财报。

融合派手里有实证。微软 2014 年取消 SDET、把测试并进研发，一位当事人后来回顾：一年过渡期结束，交付速度并没有下降。

但有个数字两派都很少提。

尘埃落定之后，原来的测试人员仍做约 70% 的测试加 30% 的开发，开发人员反过来也一样。

岗位合并了，工作结构几乎没动——边界是被行政抹掉的，不是被能力抹掉的。

微软如今又在招纯测试岗，同时把大量测试外包出去。

3

账单寄到了验证端

「监控多了效能降，少了质量降」说的其实是成本转移。

DORA 2025报告指出：90% 的人在用 AI，八成以上说生产力提升，但 AI 采用率和交付稳定性负相关。

GitLab 的调研里，85% 的人认为瓶颈已经从写代码移到了审代码。

Sonar 那份调查里还有个更刺眼的数字：42% 的已提交代码由 AI 产出，而 61% 的人说它「看着对，但不可靠」。

反方也有两条。

一条说：瓶颈其实是部署频率，批次拆小就缓解。

另一条说：  AI 让验证也变便宜，

Hacker News 上看有人做 TDD， 只问两句：「能看着它失败吗」「失败的原因对吗」。

最麻烦的反方指向逻辑：

用 AI 验证 AI 是循环论证。代码和测试来自同一套理解，预期结果也是 AI 写的，真实的 bug 会安静地穿过去。

4

这本账算了三十年

微软在90 年代，角色配比是 1 个开发 ， 配 1 个测试，再配 0.5 个 PM。

2000 年砍掉其中一个序列，2014 年把剩下的全并进研发，现在又在重新招纯测试岗。

Google 的测试者从 SET 改叫 SETI，再归入 Engineering Productivity，名字换了三轮，人还在。

Reddit 上有人提醒：二十多年前就说自动化会取代手工测试，结果没发生。

与其继续争论「QA 岗位会不会消失」，不如看两件能用数字表达的事：

1. 转岗过去的人三个月后在写业务代码，还是测试和工具代码；

2. 质量指标挂在谁的绩效上、AI 产出的验证证据由谁生产。

最后，我想问的更具体：

1. 你们公司的 QA 和研发，向同一个经理汇报吗？

2. AI 写的代码，最后是谁替它签字？

欢迎在评论区留言。