AI协作01｜测试工程师如何让AI承担一天70%的工作:判断框架+3个真实场景拆解-洪萨配资

系列说明：这是「AI协作工程化」系列的第一篇。系列定位不是"AI怎么写测试用例"这种工具替代视角,而是想回答一个更前置的问题——测试工程师的一天,哪些环节可以交给AI,哪些必须人来做。
开篇文章先抛框架和方法论,后续会按高频场景逐篇展开,每篇带可复用的Prompt模板或SOP产物。

1. 前言:一个反常识的观察

经常在后台收到提问，大概就是:

“测试工程师用AI能干嘛?除了写用例、写报告这些。”

我觉得:关于测试工程师如何用AI,可能很多人还停留在"工具替代"的层级——把AI当成一个更快的搜索引擎、一个更顺手的写作助手。坦白说，一年前，我也是这样。

那么现在我的情况是:搭环境、需求分析、写SOP、写脚本、生成报告、写文档、分析项目源码——这些环节大约70%的工作量是AI在执行,我在做判断。

所以两个问题:

为什么大多数人用AI的方式没法承接这么多工作量?
那些"能让AI承担70%工作"的协作模式,具体长什么样?

2. 判断一:为什么"网页版AI"承接不了多少工作量

普遍现象:

很多人用AI = 打开网页 + 问问题 + 复制答案

这种用法是"问答",不是"执行"。问答模式有几个天花板:

维度	网页问答模式	真正的Agent执行模式
交付物	一段文字,需要人再加工	直接产出可用的文件、脚本、报告
上下文	每次对话从零开始,项目背景要反复贴	持续在你的代码库/项目目录里工作
可复用性	答案散落在聊天记录里	沉淀为可被下次直接调用的产物
工作量承接	信息辅助为主	真正的"代干活"

结论:要让AI承担工作量,必须用能直接在你工作目录里执行动作的形态——比如Claude Code、Codex这一类Agent形态的工具,或者团队内部的WorkBuddy类工具。

这一步不打通,后面所有方法论都是空的。这也是为什么很多人觉得"AI也就那样"——不是AI不行,是使用形态没切换过去。

3. 判断二:人和AI的分工原则

切换到Agent形态之后,问题来了:哪些活该交给AI,哪些活必须自己干?

我自己摸索出的分工原则是一句话:

人做判断,AI执行

展开看:

人做的"判断"包括:

风险识别(这个模块的核心风险点在哪)
优先级排序(先测什么、后测什么、不测什么)
异常归因(一个bug到底是哪一层的问题)
价值取舍(这件事值不值得做、做到什么程度停)
盲区发现(AI产出的东西漏了什么)

AI做的"执行"包括:

信息搜集与整理(读代码、读文档、汇总数据)
格式转换(把口述变成SOP、把笔记变成文章)
代码生成(测试脚本、辅助工具、数据处理)
文档撰写(报告初稿、技术文档、流程图)
批量处理(数据集生成、Case变体扩展)

注意:"判断"和"执行"不是按任务类型切的,而是按任务里的具体动作切的。

举个例子:写测试报告这件事,执行层(数据汇总、图表生成、措辞润色)交给AI,判断层(结论怎么定、风险怎么分级、哪些问题要往上报)留给自己。同一个任务里,两类动作是交错进行的。

这里有个前提,也是需要强调的:

你能让AI帮你干多少,取决于你能不能把自己的工作显性化。

如果你说不清楚自己一天在做什么、每件事的输入输出是什么、判断点在哪里——你就没办法把活拆出来交给AI。所以梳理能力本身,才是AI时代测试工程师的核心能力。

4. 实操:3个真实协作场景的拆解

下面挑3个我自己真实做过的场景,展示"人做判断、AI执行"具体长什么样。

每个场景的拆解方式统一:背景 → AI执行了什么 → 人判断了什么 → 协作产物。

4.1 场景一:多Agent系统源码分析

背景:

接手一个包含20+ Agent、三层意图路由的多Agent系统,需要在短时间内摸清整个架构,为后续的测试策略设计做准备。如果靠人肉读代码,这个量级至少要花两三周。

AI执行了什么:

遍历代码库,按模块梳理调用链
把每一层的关键组件、配置项、依赖关系整理成结构化文档
协助绘制架构图(SVG初稿)
生成每个Agent的输入输出契约说明

人判断了什么:

识别"配置即行为"模式:发现Prompt和路由规则都存在DB/配置中心,不在代码里——这意味着测试不能只看代码,必须把配置一起纳入测试范围
安全层缺失判断:设计上的5层安全防护实际只实现了1层,这个gap是看代码看不出来的,必须对照设计文档判断
编排层无超时保护:这是一个潜在的线上风险点,AI能列出代码,但"这是个风险"是人下的判断
测试账号绕过门禁:这意味着"测试环境通过 ≠ 生产环境通过"——这个判断直接影响测试策略

协作产物:

一份代码库分析文档 + 6张架构+风险标注图,每个风险点对应后续的测试设计输入。

这个场景的精髓:AI解决了"看不完"的问题,人解决了"看完了又怎样"的问题。

4.2 场景二:Agent输出断言方法论

背景:

Agent类系统的输出是开放式自然语言,传统"输入=预期输出"的断言方式根本没法用。需要设计一套可执行、可复用的断言方法论。

AI执行了什么:

协助梳理"代码断言 → LLM Judge → 人工复核"三层断言体系的结构
生成每一层的断言模板和示例
把方法论整理成SOP文档和文章初稿

人判断了什么:

第一个gap:链路级断言点缺失
AI最初产出的断言体系是按"单轮输入-单轮输出"组织的。我review时发现,Agent的真实问题往往出在多轮链路里——前一步的输出污染了后一步的判断、工具调用结果被错误解读、状态在多轮中漂移。这些问题在单轮断言里根本暴露不出来。
这个gap是看着AI产出的文档,突然意识到"它漏了一整个维度"。
第二个gap:遗漏检测需要must-have清单
Agent的另一类典型问题是"该说的没说"——用户问了三个问题,Agent只回答了两个。这种"沉默式错误"用常规断言(检查"说了什么对不对")根本抓不到,必须显式列出must-have清单,反向检查。

补完这两个gap之后,方法论才真正可用。

协作产物:

一份Agent评测断言SOP(三层体系 + 链路级断言点 + must-have清单),已在团队内推广使用。

这个场景的精髓:AI能搭出框架,但框架的盲区只能靠人发现。这也是为什么"人做判断"不可替代——AI不会知道自己漏了什么,人才会。

4.3 场景三:风险驱动的安全测试数据集构建

背景:

要给一个AI系统做安全测试,常规思路是"穷举用户可能问的攻击性问题"。但很快就会发现,这种穷举永远穷举不完,而且大量重复。需要换一种数据集构建思路。

AI执行了什么:

按给定的风险类目,批量生成攻击Prompt
对每一类攻击做变体扩展(不同表达、不同语境、不同伪装方式)
整理成结构化的Case库

人判断了什么:

风险类目的分层设计
我把安全风险拆成了7类:Prompt注入、系统提示泄露、业务请求嵌入攻击、隐私越权、多轮渐进攻击,以及另外两类。这个分层是"判断"——决定了整个数据集的骨架。类目设计错了,后面生成再多Case也是白搭。
这一步的核心理念:数据集要覆盖的是风险类目,不是用户问题。前者有限可枚举,后者无限不可枚举。
攻击场景的真实性判断
AI生成的攻击Prompt里,有相当一部分是"看起来像攻击但实际不会发生"的——比如过于直白的越狱话术、明显不符合业务上下文的隐私索取。这些Case放进数据集只会污染评测结果。判断哪些保留、哪些剔除,只能靠人。
Bug的有效性确认
数据集跑出来一批"疑似失败"的Case,但其中一部分是模型回答得过于谨慎(不是bug),一部分是模型确实越界了(是bug)。区分这两种,需要对业务场景的判断。

协作产物:

7类风险类目的安全测试数据集,实际帮助发现了多个真实安全问题。

这个场景的精髓:"风险驱动"是判断,"批量生成"是执行。两者顺序不能反——先有判断框架,再让AI执行扩展;不能让AI先生成一堆Case,再让人来归类,那样效率反而更低。