事情是这样的。

圈子里一位三十五岁的女测试同学，没有去卷「每天一百条 Prompt」，而是用四套工具，把日常测试里那些重复得要命的活，拆成了将近二十个可复用的 AI Agent。

不是玄学。是工程。

我自己也还在摸索，但把她那套路径摊开看，骨架其实很清楚，工具负责「能跑」，Skill 负责「跑得稳」。

一、她到底用了哪4个工具

四条路，各管一段。

Coze，偏可视化搭智能体。适合先把「对话式测试助手」跑起来，团队里不写代码的同学也能先摸到反馈。

Dify，偏工作流。课程里那条链路很典型，上传需求文档，提炼测试点，生成用例，再导出 Excel。像把测试流水线拖成节点，而不是把一切赌在一次对话上。

LangChain / AutoGen，偏多智能体协作。用例生成、评审、Playwright 智能测试、BDD 生成、脚本生成器、知识库问答，全在这条线上扩。一个人不够用，就让多个角色互相挑刺。

Claude Code Skills，偏工程化沉淀。把 SOP 写进 SKILL.md，让 AI 按你们团队的规矩干活，而不是每次抽卡。

四套工具不是互斥。你可以把它们想成，能跑的原型、能编排的流水线、能协作的多 Agent、能固化的规范层。

很多朋友可能一开始会纠结「到底学哪一个」。坦率的讲，顺序比选择重要。先可视化吃到甜头，再用工作流稳住输入输出，再上多智能体，最后用 Skills 把规范钉死。

二、19个Agent，其实是一张测试能力地图

把课程树摊开数一数，大概是这样铺开的。

多智能体与自动化这一侧，有用例生成 Agent、用例生成加评审多智能体、Playwright 智能测试 Agent、GenAI Multi-Agent BDD、可视化 BDD 用例系统，再加上 AutoGen 的脚本生成器、企业知识库问答、用例生成器重构版。

工作流这一侧，有「需求文档 → 测试点 → 详细用例 → Excel」这条 Dify Chatflow。

Skills 这一侧，有 explain-code、codebase-visualizer、skill-creator、自定义测试 Skill、/spec、/plan、frontend-design，以及接口用例生成、Bug 报告整理、日志分析这类 QA 向 Skill。

加起来，就是标题里那个「19」。

重点不是数字唬人。重点是，测试人终于可以把能力拆成一块块可插拔的模块。今天缺评审，就挂评审 Agent。明天缺日志归类，就补一个 Log Skill。产能变成积木，而不是一次性灵感。

三、Skill到底长什么样（结构比口号重要）

很多技术文把 Skills 写得特别玄。站在测试视角，其实就一句话。

你把测试 SOP 写进一个 Markdown 文件，AI 就按 SOP 工作。

最小目录长这样。

SKILL.md 才是心脏。上面 YAML 管「叫什么、什么时候触发」，下面正文管「怎么干、输出长什么样」。

接口用例生成 Skill，核心可以短到这样。

调用时你只要说，使用接口测试用例生成器，根据下面接口文档生成测试用例。它就按覆盖矩阵吐表，而不是天马行空写散文。

再看 explain-code。目录同样极简。

正文强制输出结构，类比 → ASCII 流程图 → 分步拆解 → 常见坑。读自动化框架、带新人 Walkthrough，终于不用每次重写提示词。

写好 Skill 有三条经验。

description 要写清触发场景，AI 靠它决定要不要加载你。

给模板示例，尤其是表格头，AI 会死死咬住格式。

SKILL.md 别膨胀到五百行以上，复杂材料丢进 references/。

还有一个很测试的架构点，渐进式披露。会话启动只加载名称和简介，任务匹配上了才加载全文。这很像用例库，不是一上来把全量回归用例灌进脑子。

说到触发方式，也别混。模型自动触发适合「后台按规范干活」，你手动斜杠触发适合「步骤必须可控」。同一条能力可以两边都留入口，但仓库里最好目录分清楚，别让自己半年后看不懂。

四、对测试人到底有什么好处

坦率的讲，测试工作天然吃「流程 + 模板 + 规范」。

计划 → 用例 → 执行 → 提 Bug → 回归 → 出报告。

没有规范，就会出现覆盖残缺、Bug 字段缺一半、报告格式每次换皮。

Skills 和 Agent 把这套规范固化下来之后，好处很具体。

同一接口，用例结构终于稳定。

Bug 描述从「登录报错了」能补成可提交的完整单。

日志分析能先抽出错误类型和排查建议，再由你做判断。

回归里那些机械活，开始变成可复用产能。

你想想看，一个接口手动抠十到二十分钟，Skill 几秒给出正常、异常、边界、鉴权四类覆盖。这不是取代测试，是把你从「打字员」里捞出来。

我也理解另一种担心。你不是全职开发，不需要天天写框架。你就是一个要赶迭代的测试，时间本来就碎。所以这套东西真正爽的地方，是它允许你「先小后大」。先吃到一个接口 Skill 的甜头，再慢慢扩到十九个。

五、怎么嵌进自己的测试项目

别一上来就想造十九个。先造一个，能每周用三次的那种。

第一周，选你们最高频的痛点。接口用例、Bug 整理、日志归类，三选一。按上面的目录建 Skill，把团队真实表格头写进输出格式。一开始可能会有点笨拙，花的时间比手动做还长。挺正常，第二次第三次才会开始赚回来。

第二周，把触发词和 description 写成人话。「当用户需要根据 Swagger 生成接口用例时使用」，比空泛的「帮助测试」强一百倍。顺便用 /skills 清掉重叠能力，别让模型在两个相似入口之间摇摆。

第三周，接到真实迭代。需求文档走 Dify 或用例 Agent 出第一稿，你只做风险补洞和准出判断。自动化仓库里挂 explain-code 与 codebase-visualizer，新人熟悉仓库成本会掉一截。

第四周，才考虑多智能体。比如生成 Agent 出用例，评审 Agent 按检查清单找缺口，Playwright Agent 把冒烟路径落成脚本。这时候你已经有规范层了，多 Agent 才不会变成多处抽卡。

映射到传统测试能力也很自然。

接口测试，对应模型 API 与 RAG 链路断言。

自动化，对应 Prompt 批测与回归流水线。

性能测试，对应推理延迟与稳定性门槛。

安全测试，对应越权、注入、越狱类红队用例。

对象从确定性程序，变成带概率的模型输出。计划、指标、准出门槛都要升级，但方法可以迁移，不是推倒重来。

比较骚的事是，你一旦把「覆盖矩阵」和「准出标准」写进 Skill，团队新人第二天就能按同一套规矩出活。这比你口头带教稳多了。

六、结尾那句狠话

真正会被替代的，往往是重复、机械、没有流程沉淀的工作。

会把经验沉成 Skill，会把流水线沉成 Agent，会把四个工具链成自己测试系统的人，反而更香。

35岁不是天花板。对那位女测试同学来说，它更像一个分水岭，从「会用聊天框」跨到「会搭测试产能」。

屏幕前的你如果也卡在「AI挺能聊，但一进项目就飘」，不妨今天就建第一个最小 Skill。别追求完美，先追求可复用。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～

资料自取

完整 Skills ,MD文档，完整流程，以及四工具对应的课程目录整，文末留言「666」自取。

谢谢你看我的文章，我们，下次再见。