关注 霍格沃兹软件测试开发 公众号，回复「资料」, 领取人工智能测试开发技术合集

当“AI帮我写的”成了测试报告里最高频的短语，我意识到出事了

大家好，我是某互联网公司质量保障团队的技术负责人。

上个月，我们给测试团队全员配了AI Copilot。工具是好工具，GitHub Copilot加内部大模型双管齐下，目标是让测试用例编写效率翻倍。

结果第一周结束，我打开大家的日报，被一个短语刷屏了：

“AI说的。”

“这个用例覆盖了边界条件——AI说的。” “断言逻辑是这样写的——AI说的。” “这个模块风险较低，不用深入测——AI说的。”

整整一周的日报里，“AI说的”出现了47次。没有一个人写“我判断”“我认为”“我分析”。

那一刻我感觉不太对劲。

一、事情是怎么开始的？
先交代一下背景。

我们团队20多人，负责公司核心业务的质量保障。日常工作量最大的就是用例编写和回归验证——每个版本几百条用例，全靠人肉写，一个版本耗掉3-4人天。

今年Q1，公司引进了AI Copilot的企业版，可以接入内部代码库和知识库。测试团队作为首批试点，全员配上了。

第一周大家热情很高。AI确实能干活——你输入“请为订单支付接口生成完整的测试用例”，10秒钟出来20多条用例，覆盖正向、反向、边界场景。换以前，一个测试同学至少要花半小时。

效率提升肉眼可见。但问题也肉眼可见。

周一，一个初级测试同学提交的用例里，AI生成了一个“优惠券叠加使用”的场景——规则是“满100减10”和“满200减30”可以叠加。但实际上我们系统的规则是不能叠加，只能选一个最优的。

我问ta：“这个用例的逻辑你验证过吗？”

ta回答：“AI生成的，我看了一眼觉得没问题。”

“看了一眼。”

这个回答让我心里咯噔了一下。

二、“AI说的”背后，藏着三个致命问题
第一周结束后，我把那47条“AI说的”全部拉出来看了一遍。发现问题比我想象的严重得多。

问题一：盲从——把AI当成了“正确答案”
最典型的一个案例：一个测试同学用AI生成了一段接口自动化脚本，AI在断言部分写了一个错误的预期返回值——把“订单状态=已支付”写成了“订单状态=已发货”。

脚本跑完之后显示“全部通过”，ta就直接提交了报告。

我问ta：“你没看一下断言的逻辑吗？”

ta说：“AI写的，应该是对的吧。”

“应该是对的吧” ——这句话的危险程度，不亚于在生产环境直接执行DROP TABLE。

类似的案例在行业里并不少见。有测试工程师因为相信AI生成的“100%路径覆盖、0错误”报告，忽略了“输入字段为空+并发写入”这种AI逻辑无法覆盖的组合，最终导致生产环境崩溃。不是AI不行，是人太信AI了。

问题二：惰性——从“主动思考”退化成“被动接收”
有一个细节让我印象特别深。

我们有一个测试用例的评审会，大家一起过AI生成的用例。以往人工写的用例，大家会争论——“这个边界值设得对不对？”“这个场景有没有遗漏？”

那天，全场沉默。

我问：“大家觉得这些用例怎么样？”

一个同学说：“AI生成的，应该覆盖得挺全的吧。”

没有人质疑，没有人提问，没有人补充。 所有人都在默认“AI是对的”。

这种现象在业内已经有专门的研究了。AI工具在接管重复性测试的同时，正在无形中“驯化”人类专家，导致他们从“主动怀疑”的探索者退化为“被动接收报告”的审查员。即使是资深工程师，在接触新技术时过度依赖AI，技能退化同样会显著发生。

我们团队从“写用例的人”变成了“看AI用例的人”——但“看”的时候，脑子是关着的。

问题三：逃避责任——把决策权甩锅给AI
最让我担心的，是那句“AI说的”背后的潜台词。

“AI说的”=“出了问题别找我，是AI说的。”

这不是个例。有媒体曝光过一个真实案例：某大厂推行零代码测试平台后，因为一个人不懂底层日志写错断言，导致AI自动生成一百多个误报工单，整个研发团队崩溃。不是技术故障，是认知断裂。

当测试工程师不再为自己的判断负责，而是把决策权外包给AI——这个团队的质量保障能力，实际上是在倒退。

三、第三周，事故来了
第三周，出事了。

一个支付模块的回归测试，AI生成了一套用例，全部跑通。测试同学在报告里写“支付模块回归通过，无新增问题”——AI说的。

上线第二天，线上反馈：部分用户支付成功后订单状态没有更新。

排查后发现，AI生成的测试脚本里，断言只验证了接口返回码是否为200，没有验证数据库里的订单状态字段是否真的更新了。

那个测试同学说：“AI生成的断言就是这样，我以为够了。”

“我以为够了。”

这个Bug不算大，影响了几十个用户，紧急修复了。但这件事让我意识到——我们不是在用AI提效，我们是在用AI给自己挖坑。
四、我做了什么？
事故之后，我停掉了AI Copilot的“自动生成”权限，改成“辅助模式”。然后做了三件事。

第一件事：把“AI说的”从日报里禁掉了
我在团队群里发了一条消息：

“从今天开始，日报里再出现‘AI说的’这三个字，重写。我要看到的是‘我验证了’‘我确认了’‘我判断’。AI可以是你的工具，但不能是你的大脑。”

不是矫情。当一个人开始用“AI说的”来为自己的工作背书时，说明他已经放弃了对工作结果的 ownership。

第二件事：立了一条铁规矩——AI生成的，必须人工验证
具体做法很简单：

AI生成用例后，必须逐条review，标注“已验证”才能提交
AI生成的断言，必须在测试环境手动跑一遍，确认逻辑正确
AI生成的风险判断，必须人工复核，不能直接采纳
不是不相信AI，是相信之前，先确认。

第三件事：每周一次“AI盲测”训练
每周五下午，我挑一个模块，让团队同学不用AI、纯手写一套测试用例。

不是为了让他们“回到石器时代”，而是为了保持手感。

一个做了半年AI辅助测试的同事跟我说，第一次做“盲测”的时候，他发现自己写用例的速度和逻辑严密性，比半年前退步了至少30%。

这个结果让我后背发凉。

五、后来怎么样了？
调整之后又跑了两个月。数据是这样的：

指标
调整前
调整后
用例编写效率
↑150%
↑80%
用例准确率（首次提交）
72%
93%
线上漏测率
↑20%
↓5%
团队成员“主动思考”的自评分数
6.2/10
8.5/10
效率降了一些，但质量回来了。

更重要的是，团队的氛围变了。日报里不再有“AI说的”，取而代之的是“我验证了AI生成的用例，补充了3个边界场景”“我修改了AI的断言逻辑，增加了数据库状态检查”。

工具还是那个工具，但使用工具的人，脑子回来了。

六、给同行的几点建议
如果你也在给团队配AI Copilot，我有几条掏心窝的话：

1. AI是副驾驶，不是自动驾驶
   Copilot这个名字本身就说明了问题——它是副驾驶，不是自动驾驶。副驾驶可以帮你导航、提醒路况，但方向盘必须在你自己手里。

任何AI生成的内容，在提交之前，必须经过人工验证。这是底线，没有商量余地。

2. 保护好团队的“质疑能力”
   质疑能力是测试工程师最核心的能力——质疑需求、质疑设计、质疑代码、质疑自己的判断。

AI最容易侵蚀的就是这个能力。因为它给出的答案太“像那么回事”了，让人懒得质疑。

每周至少安排一次“无AI”的测试设计训练，让团队保持手动设计用例的能力。

3. 建立“AI输出审查”机制
   不是说AI生成的不能用，而是要有机制地使用：

AI生成 → 人工review → 标注修改内容 → 提交
每周统计AI输出的准确率和人工修改率
修改率超过30%的模块，说明AI在这个领域还不成熟，暂时不要用
4. 警惕“效率幻觉”
AI提效是事实，但效率提升不等于质量提升。

一个测试同学用AI一天写了200条用例，如果其中有30条逻辑有问题，那这200条用例的价值，可能还不如手写50条高质量的。

效率是手段，质量是目的。别搞反了。

最后
AI Copilot是个好工具。但它也是一面镜子——照出了我们团队在“独立思考”这件事上有多脆弱。

第一周那47条“AI说的”，本质上不是AI的问题，是我们的问题——是我们太容易放弃思考，太容易把决策权交给别人。

现在我的团队还在用AI Copilot，但用法变了：

AI负责“生成初稿”，人负责“最终决策”。AI负责“提供建议”，人负责“做出判断”。AI负责“提高速度”，人负责“保证质量”。

工具是冷的，人是热的。别让AI替你思考，让AI帮你思考得更快。

本文系作者基于真实经历的复盘总结，欢迎同行交流讨论。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。