============
前言：
最近准备要换到一段新的旅程，想趁中间过度休息的时间整理一下目前这份工作得到的一
些经验以及心得。除了作为整理自我沉淀的心得之外，也想分享一下顺便和大家交流交流
。
以下说明本文的一些默认前提：
1. 我大部分的职业生涯都是QA，并没有太多完整Dev的经验
2. 此篇文章适用于产品为软件的产业，硬件以及韧体我并没有太多经验不确定是否适合
3. QA的学经历仍然是本科系(STEM)出身
4. Junior QA：CS知识或coding能力是同等学经历的SDE约3成左右
5. Senior QA：CS知识或coding能力是同等学经历的SDE约6成左右
6. 自动化测试的结果不稳定（伪阳性/伪阴性）我觉得是软件工程的问题而不是使不使用
AI的问题，故不特别讨论
============
# QA更应该拥抱AI技术，而不是害怕被其取代
在当前的技术讨论中，“AI 写 Code 的能力越来越强，测试人员（QA）会不会最先被取
代？”似乎是一个最被大众讨论且被接受的共识。
但我的观点恰恰相反。我认为在软件开发中，“QA 才是这波 AI 浪潮下最大的受益者”
。
这听起来可能很反直觉，但如果我们观察软件工程以及品质的本质，从风险与回报的角度
来看，你会发现 QA 处于一个极其特殊的“不对称优势”位置。
这篇文章将探讨什么工程师对 AI 充满顾虑，而 QA 却可以大胆拥抱 AI ，以及各种不同
等级的QA该如何善用这个技术来达成更高的效率。
## 0 与 100 不同的开发方向
首先，我们需要厘清开发（Dev）与测试（QA）在产品生命周期中的不同责任。
软件开发像是一条光谱：
工程师（Dev）是从 0 到 100 的创造者。他们照着规格从无到有构建产品，每一行程式
码都是像层层往上叠的砖块一样将产品建构完成。
测试人员（QA）是从 100 到 0 的解构者。 我们拿到的是已经被构建好的产品（100），
然后层层剥开细节，寻找裂缝与逻辑漏洞，试图将它还原成规格文件并验证。
正是这种出发点的极端差异，决定了两者在使用 AI 时面临的“压力”完全不同。
## 代码的本质：外部产品 vs. 内部产品
为什么工程师即便拥有能够写出复杂Code的AI，依然不敢放心地让 AI “全自动”写 Cod
e？原因在于“风险”。
工程师产出的程式码是“外部产品（External Product）”。它必须面对真实世界中数以
百万计的未知使用者、千奇百怪的网络环境、以及潜在的恶意攻击。这意味着程式码必须
具备极高的通用性与安全性。如果 AI 生成的程式码在百万分之一的场景下发生一次致命
的逻辑错误（注：最近明日方舟的Paypal事件就是一种），对公司来说就是毁灭级的灾难
。这种“对外交付”的沈重责任，导致工师在使用 AI 时必须支付极高的“信任成本”与
Review 时间。
反观 QA，我们产出的自动化程式码，本质上是“只”服务于公司产品的“内部产品（Int
ernal Product）”。
我们的“对象”是明确且单一的——就是眼前的这个产品。
我们不需要让测试脚本相容于全世界所有的软件，只需要它能够测试我们公司的产品就可
以。
“外部产品”追求的是无懈可击的广度；而“内部产品”追求的是解决特定问题的深度。
正因为 QA 的程式码是“受限的”且“目标单一的”，这导致我们使用 AI 生成的Code“
验证是否合法”的成本远低于工程师。只要 AI 写出的 Code 能在这个特定版本、特定环
境下抓出 Bug（或帮助我们工作），它就是有价值的 Code。
这就是 QA 使用AI的“不对称优势”。
所谓不对称优势，是指我们处于一个“下行风险有限，但上行回报无限”的位置：
极低的下行风险：
过去我们常将风险解释为“修复脚本的成本”，但真正的风险应该是“退回手动执行 ”
。当 AI 生成的测试脚本失效或无法执行时，我们最坏的情况仅仅是切换回原本的人工测
试模式。重点在于，无论是由 AI 执行还是由人工执行，最终的测试结果是一样的。这意
味着我们的“风险底线”就是现状。
举个例子：
你有一个test acse，内容是做A、B、C三个操作，之后验证状态是否为预期的，并且你本
来就有一份自动化测试在执行这个case了。
现在你们的软件改版，还是一样做A、B、C三个操作验证状态，但是UI改版了，于是你原
本的自动化测试告诉你某个UI找不到了无法执行。
这时候通常会是两种情况：
1.时间不够来不及修脚本所以这次改为人工执行
2.时间还够把脚本修好继续用自动化测试执行。
在这两个选择中，不论是人工执行或是用程式执行得到的结果都是一样的，从品质的角度
来看这两种方式都提供了一样的品质保证，唯一你有可能承担的风险只有“时间不够”（
例如用程式跑只需要1分钟但是人工需要30分钟），而不是“品质下降”，这就是所谓的
“风险仅是退回手动测试”的意思。
注：当UI改动（或是业务逻辑改动）后本来测试就需要“跟着更新”，这个成本不论是手
动或是自动都要承担的，只是我们都把更新人脑的成本忽略了。但这本质上还是“成本”
而不是“风险”。
极高的上行回报 ：
相对于被锁定的低风险，一旦你接受使用AI来帮助执行测试，获得的却是“指数级的效率
提升”。
我们并非将结果交给 AI来产生，而是将 AI 视为一个“低风险、高回报”的增强外挂：
AI 写的脚本不能用？那就退回手动，品质结果不变。
但只要这个脚本能够成功帮助我们执行测试，通常就是十倍速以上的效率跃进回报。
## 实战落地：AI 赋能的两个层次
理解了优势后，我们该如何落地？许多人对 AI 自动化有个误区，认为必须一步登天，建
立完美的自动化框架。事实上，QA 使用 AI 可以分为至少两个层次：
### 1. 初级使用：繁琐任务
（适合 Junior QA / Manual Testers）
如果你的工作目前依赖大量手动测试，不要一开始就想着“将 Test Case 100% 转为自动
化代码”。你应该关注那些手动测试中“繁琐、重复、低脑力的任务。
举例：
Log抓取：
你需要抓取android手机中你们公司产品app的log。但是你不知道adb logcat以及grep两
个指令，所以你以前只能每次都连线进去手机找到log档案复制出来并且ctrl+f一行一行
寻找。
但是如果你把这个问题拿去问AI后就可以得到一个adb + grep的一行组合指令解决你的问
题并且节省了许多时间。
Log 分析：
以前你需要花 5 分钟肉眼过滤 Device Raw Log 找错误代码，现在你可以花 30 秒让 A
I 写一个 Shell Script 帮你parse raw log并且直接判断是否有Error。
资料生成：
需要许多笔符合特定格式或是规则的测试资料，以前人工执行的话要一直复制贴上资料并
且修改不同的部分（最大值、最小值、中间值、超出边界…等等），现在把这些规则告诉
AI之后，AI能在很短的时间内产出高品质资料。
为什么在这个层次 AI 特别有帮助？
首先是“积少成多的复利效应”。
假设你每天需要分析 20 个失败的 Test Case Log，手动查找原因平均每次耗时 5 分钟
，这意味着你一天有 100 分钟（近 1.7 小时）消耗在单调的肉眼检查上。
若用 AI 生成的脚本辅助，将分析时间压缩至 1分钟，你每天就凭空多出了80分钟的深度
工作时间，这就是微小进步带来的巨大回报。
其次是“极低的验证成本”。
由于这些任务的 Scope 很小，要验证 AI 写出来的程式码或结果是否正确非常简单。相
比于工程师验证产品的高昂成本，QA 在这些繁琐任务上的试错成本几乎为零，是典型的
“低风险、高回报”投资。
对于这些任务，我们甚至可以抱持着“抛弃式代码”的心态。它们是为了取代当下那 100
% 的手动苦工而存在的。
* 如果它能用了，你赚到了时间。
* 如果它过期了或坏了，就丢掉它，让 AI 重新生成一个，或者暂时退回手动。
这些碎片化工具是通往自动化的“鹰架”。它们帮助手动测试者跨越了“不会写 Code”
的恐惧鸿沟，在一次次与 AI 的协作中，逐渐成长为能驾驭程式码的工程师。
### 2. 进阶使用：开发自动化测试架构（适合Senior QAE / SDET）
当你以及团队跨过了初级阶段，进入到系统级自动化测试时，AI 的角色就从“写手”变
成了“副驾驶”。
在这个阶段，我们不能再依赖抛弃式代码，而是要建立稳健的架构。这时候，QA 的职责
是定义架构、制定方向、提供规格、设计接口、规范Pattern，然后让 AI 去填充具体的
实作细节。
有人会挑战：“如果内部产品充满了 AI 写的烂 Code，会变成团队的隐形杀手。”
这正是Senior QA或是SDET 的价值所在。AI 的产出效率越高，Code Review 的重要性就
越高。我们必须确保引入的自动化测试程式码符合软件工程标准。
但即便如此，相比于开发正式产品，QA 在建立自动化测试时的 Scope 依然小得多。
为什么这么说？
工程师的产品程式码必须处理高同步、严格的资安标准、以及各种来自现实世界的攻击…
等等的各种极端情况。
而 QA 的测试程式码通常运行在受控的环境中，面对的是可预测的输入与单一的系统状态
。它不需要服务全世界，只需要服务公司产品。
因此，同样的资深工程师使用 AI，撰写自动化测试面临的技术复杂度指数远低于正式产
品，因此能换取指数级高的效率回报。这不再只是节省几分钟，而是能将原本需要“3 天
的手动回归测试周期，透过 AI 加速构建自动化测试，压缩至 2 小时内完成”。这对产
品发布节奏的影响是革命性的。
## 结语：AI 无法模仿“品味”
最后，可能会有人问：如果 AI 能写 Code 也能写测试，那未来的 QA 价值在哪里？
这是一个哲学问题。在我看来，工程师和 AI 追求的是“逻辑的正确”，但 QA 追求的是
“体验的品质”。
产品的最终使用者是人类，而只有人类能理解人类的痛点与“品味”。AI 可以帮我们写
出完美的 Assert 语句，但它无法告诉我们这个按钮的触感是否“对劲”，或者这个流程
是否让用户感到“挫折”。
如果我们承认了AI可以想出这些含有人类情感的test case，似乎也就承认了AI拥有了跟
人类一样的情感。至少在2026一月的今天，我觉得AI还没拥有这些能力（如果有的话应该
比取代QA还大条XD）。
总结成最后一句话：AI 负责处理逻辑的 0 与 1，QA 负责守护那不可量化的“人类体验
”。

等 agent 能更容易访问 app/web 后就轻松了

一切都看老板怎么想

老板会叫你用ai产测试计画 不准去打扰工程师客户和pm

当AI程式码贡献越来越多的同时，QA只会越来越重要

我觉得重要跟需求可能是两回事譬如说柏油其实很重要 但是柏油路工人不会有稀缺价值

那就表示柏油工人和QA都很重要

根据经验 QA写的烂code会让人抓狂

柏油工人www

不管问AI还是看JD都会告诉你柏油工人薪水还满高的喔...无经验都能保日薪2400了，老师傅月薪可以近十万，而且还找不太到人……

写的像ai slop。重点是？

如果这是你的人类体验，那还真不如用AI 总结重点

柏油工人没有稀缺价值你要确耶 搞不好比五年前软件人还缺

给个堆，一堆人看到AI就PTSD

给推

推

真心觉得文字工作者，或分享文，别再用AI 来生文章了，原Po 可以看看后来你自己回复的内容，有温度多了。重要的是你的经验你的感觉，不是这篇文章看起来多厉害

给箭头，回文的原 po 自己的写法好多了，太多 AI slop

AI不能模拟user 行为 ,QA主管肯定这样说

就跟电脑出现后变成多数工作更强的辅具以及取代ㄧ部分的工作而已

dev端ai产出越多qa需求目前看起来越多，不过老板不一定懂

AI Tools只是麻疯狂压榨产能用的 上头和PM不会管你要review多久 AI一秒扫万行 人类还要再review 你人类效率要跟上啊。 现在风气很搞笑，与其当打工仔不如离开写和学自己有兴趣的