系列说明这是「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,再让人来归类,那样效率反而更低。5. 阶段性结论:让AI干活的前置动作是梳理回到开头那个问题——“测试工程师用AI能干嘛?”我的回答不是给一份AI能做的事情清单,而是想说:这个问题问反了。真正该问的是:“我每天在做的事情里,哪些是判断,哪些是执行?”把这件事想清楚之后,AI能帮你的部分自然就浮出来了。所以让AI承担70%工作量的前置动作,不是学Prompt技巧,不是装更多工具,而是:把你一天的工作显性化——每个任务的输入、输出、关键判断点写出来识别每个任务里的执行动作——可以交给AI的部分识别每个任务里的判断动作——必须自己做的部分选对工具形态——能在你工作目录里直接执行的Agent,而不是网页问答跑起来,在过程中迭代分工——哪些AI做得好、哪些做得差,边做边调整第1步是最容易被忽略的,但也是最关键的。很多人觉得AI帮不上忙,本质上是自己没把活拆清楚。6. 下一篇预告这是「AI协作工程化」系列的开篇,主要立框架。后续会按高频场景逐篇展开,每篇带一个可复用的产物(Prompt模板/SOP/脚本/Case库)。计划中的下几篇:AI协作02:用Agent模式做项目源码分析的完整SOP(含Prompt模板)AI协作03:从PRD到测试用例:AI辅助需求分析的4步流程AI协作04:测试报告生成:哪些AI写、哪些必须人写如果你也是测试工程师,欢迎在评论区告诉我:你最想看哪个场景的展开?我会按反馈调整后续顺序。写在最后:本文的所有方法论和场景都来自我自己的真实工作。系列后续每一篇也都会以真实做过 可复用产物为标准,不写空洞的方法论。
)
