AI 时代还需要 QA 吗？比“取消测试”更重要的，是重新发明质量团队
QA 这门“老手艺”，怎么突然成了争议焦点
在软件行业，QA——也就是质量保证——曾经是个再正常不过的岗位。很多传统企业的软件上线流程里，开发写完代码，丢给测试，测试提 bug，开发修，测试再验。这个流程运行了很多年，像极了一条工业时代的装配线：环环相扣，也环环相等着别人。
但这几年，越来越多工程负责人开始公开表达一种近乎“去 QA 化”的态度：质量不该由一个单独团队兜底，而应该由工程师自己负责。Jade Rubick 这篇文章讨论的，正是这个在工程管理圈越来越火的尖锐问题——“QA 还该存在吗？”他的结论并不极端，却足够刺耳：大多数软件团队，不应该从 QA 开始搭组织；即便有 QA，也最好不要把它做成一道流程关卡。
这话听起来有点狠，但并不新鲜。过去十年里，DevOps 的兴起已经把“开发写代码、运维上线背锅”的分工模式冲击得七七八八。今天，类似的反思轮到了 QA。原因也很现实：只要团队里存在“我先做完，再交给别人检查”的心态，责任就会被稀释，速度也会被来回扯慢。很多人嘴上说追求敏捷，身体却还活在瀑布式流程里。
真正尴尬的是，一些公司一边保留庞大的 QA 流程，一边又没有像样的单元测试和集成测试，最后形成一种奇怪的心理依赖：反正后面还有测试兜底。结果不是质量更高，而是工程师对质量更不敏感，测试团队也被迫陷入永无止境的人工回归。这样的 QA，确实容易沦为“减速带”。
反对 QA 的人，和支持 QA 的人，其实都没完全错
Rubick 提到，工程管理者反对 QA 的理由大致有三类：它拖慢交付；它制造“把问题扔过墙”的坏习惯；它的激励机制也容易跑偏——如果一个岗位的价值来自“找问题”，那它天然会不断找问题，至于问题是否值得阻塞上线，反而未必是第一位。
这个逻辑听上去冷酷，却击中了很多互联网团队的现实。尤其在创业公司里，速度就是命。产品一天一个版本，靠人工测试逐项验收，很快就会跟不上开发节奏。更不用说现在不少团队已经把 CI/CD、灰度发布、线上监控、回滚机制做成了基础设施，很多过去由 QA 在发布前做的事，如今已经被流水线、自动化脚本和线上可观测性工具接手了。
但支持 QA 的人也不是守旧。测试本身确实是一门技能，而且是那种常常被开发低估的技能。好的测试人员并不只是“按按钮找 bug”，他们擅长用用户视角、异常路径、边界条件去挑战产品，能在一堆“理论上没问题”的功能里，闻到哪里可能翻车。这种能力，不是每个工程师都天然具备。
更何况，一些高风险场景里，质量从来不是可选项。金融、医疗、车载、航天、企业级基础软件，这些领域的 bug 不只是“页面错了一个按钮颜色”，而可能意味着资金损失、合规风险，甚至人身安全问题。到了这种地方，“工程师自己注意点就行”听起来就像一句危险的安慰。也正因为如此，传统行业往往比互联网公司更坚定地保留 QA 职能。
所以问题从来不是“QA 有没有价值”，而是“QA 以什么方式存在才有价值”。这也是我觉得这篇文章最有意思的地方：它不是简单喊裁员口号，而是在追问质量工作如何摆脱旧流程，真正成为工程效率的一部分。
真正该被淘汰的，不是 QA，而是流水线式 QA
Rubick 提出一个很重要的判断：如果从零组建软件团队，他不会先招 QA，而是先建立一个默认前提——工程团队自己拥有质量。单元测试、集成测试、UI 测试、CI/CD，这些都应该从第一天就进入工程日常，而不是等到后面“补一个测试部门”。
这背后有个软件工程里很经典的概念，叫“测试金字塔”。底层是数量最多、速度最快、最稳定的单元测试；往上是集成测试；最顶层才是更慢、更脆弱、维护成本也更高的端到端 UI 测试。行业里其实早就有共识：底层测试必须由工程师承担。争议主要集中在最上层——尤其是站在用户视角的端到端测试，到底该归谁。
我的看法是，很多公司并不是“有 QA 所以效率低”，而是它们把 QA 设计成了一个流程终点。开发做完，QA 接手，发现问题，再退回去，这就像快递到了中转站才拆箱检查，自然慢得让人抓狂。相反，如果测试人员从需求评审就介入，和工程师一起设计测试方案、一起定义验收标准、一起把自动化测试接进 PR 流程，那 QA 就不再是最后一道门，而更像是质量教练。
这和今天 SRE 在很多公司里的位置有点像。SRE 并不是替全公司“负责稳定性”的那群人，而是稳定性领域的专家，他们推动团队自己把系统做稳。照这个思路，QA 也应该是质量专家，而不是质量代工厂。
说得再直白一点：凡是以“交接”为核心的 QA 模式，都会越来越难受；凡是以“嵌入”和“自动化”为核心的质量角色，反而可能迎来新机会。
AI 写代码之后，测试反而比以前更重要了
这篇文章最有前瞻性的部分，是 Rubick 提出的一个新称呼：AVE，Automated Verification Engineer，也就是“自动化验证工程师”。他建议质量团队别再死守传统 QA 这块牌子，而是主动把自己定义为帮助开发流程获得更快反馈、帮助 AI 代码代理识别错误的人。
这个判断，我认为非常值得行业认真想一想。
过去几年，生成式 AI 最先改变的是“写代码”这件事。Copilot、Cursor、Claude Code、GPT 类 coding agent，让写代码的成本快速下降。可一个老问题也随之被放大：代码写得更快了，怎么证明它是对的？AI 最擅长的是“看起来会了”，最危险的也是“看起来差不多”。它可以几秒钟写出一段逻辑完整、风格统一、甚至注释工整的代码，但只要验证体系不够强，团队就会迎来一种新型灾难——产出暴增，错误也暴增。
这就是为什么“自动化验证”突然变成了一个战略岗位。AI 时代最稀缺的，不再只是能写代码的人，而是能快速、稳定、低成本地判断代码对不对的系统。如果一个团队能把验证反馈做得足够早、足够快、足够可信，AI 产能才能真正释放。否则，开发像踩了油门，测试像没装刹车，最后谁都不敢开快。
Rubick 设想的 AVE，更像是 QA、开发者体验工程师和测试基础设施工程师的混合体。他们关注的不是手工点点点，而是怎么让流水线在最早阶段就发现用户层面的风险，怎么让测试更确定、不抖动、更快，怎么把 flaky test 这种“假警报制造机”清理掉，怎么让 PR 阶段就拿到足够多的质量信号。
这一点和今天很多大厂的实际演化方向很接近。Meta、Google、Netflix 这些公司，早就不是靠庞大人工测试团队来守质量了，而是把质量能力沉到工程平台、自动化测试、发布系统和可观测性基础设施里。中国互联网公司这两年也在走类似路径，只是很多团队还处在半自动化、半人肉兜底的过渡阶段。
质量团队下一站：消失，还是进化？
对不少 QA 从业者来说，这类讨论听上去难免刺耳，甚至像一种职业威胁。Rubick 在文中也很小心地强调，他批评的不是从业者，而是岗位被组织设计成了低效模式。这个区分很重要。很多时候，不是 QA 不优秀，而是企业让他们只能在一个低杠杆的位置上反复劳动。
如果站在管理者视角，我觉得接下来最现实的路不是简单裁掉 QA，也不是原封不动保留旧体系，而是问几个更尖锐的问题：你的质量工作到底是在创造反馈，还是在制造等待？你的测试是在帮助开发和 AI 更快地确认正确性，还是在上线前集中爆雷？你的团队是把质量当作一种能力建设，还是当作一道审批手续？
这背后其实还有一个更大的行业争议：当 AI 让写代码越来越廉价，软件组织未来的核心竞争力，会不会从“谁能写得快”转向“谁能验证得准”？如果答案是会，那测试、质量、验证这条线，不但不会消失，反而会变成更靠近战略中枢的位置。
我个人的判断是，传统 QA 岗位会继续收缩，尤其是那种严重依赖手工回归、通过流程卡点体现存在感的团队，未来几年会越来越难。但质量职能本身不会消失，它会更工程化、更平台化，也更贴近 AI 工具链。届时，能活下来的质量角色，不是“最后检查的人”，而是“提前建立验证系统的人”。
说到底，软件行业每隔几年就会重写一次分工关系。运维如此，测试也是如此。旧岗位名称也许会变，岗位说明书也许会重写，但那个最朴素的问题从没变过：代码跑起来之前，谁来证明它不会把世界搞砸？在 AI 写代码越来越像流水线的今天，这个问题只会比以前更贵，也更重要。