本文整理自QCon北京《蔡明哲 - 透过Agent Skill、MCP再到Pre 的全链路智能化流程与实践方案》，通过AI音视频总结工具Ai好记视频转文字转录整理，以下为精炼整理后的会议笔记内容。
先抛一个和每个测试团队都相关的问题：AI 对 QA 来说，帮助更多还是威胁更多？
作者用 Shopify 的 CTO 在 GitHub 上的 commit 数量做了个对比，团队开发速度被 AI 明显拉快了，如果 QA 跟不上开发的节奏，整个迭代就会卡在测试这个环节。
这篇文章讲的就是一个 QA 团队如何透过 Agent Skills、MCP 和 Playwright 这些技术，把从需求分析到测试执行的整个链路智能化，让 QA 从执行者转向架构师。
用 AI 的几类典型问题
团队在日常中发现，大家用 AI 很容易踩几个坑。
一是不知道工具怎么用，把 AI 该做的重复工作留给人做，把需要人判断的留给 AI。
二是对 AI 过度信任或不信任，有人坚信自己写的代码比 AI 强，有人则 AI 出什么就发什么。
三是工具孤岛，测试管理平台、缺陷平台、AI 工具、文档平台各自独立，数据没法串接。
四是用错工具，典型例子是打开通用的 AI 网页，说「你是一位资深测试工程师，请帮我写测试用例」，结果是通用模型不懂业务领域知识，生成出一堆不可用的用例，于是得出 AI 不可靠的结论。五是工具效能没释放，会用的藏着掖着，大家重复造轮子。
从日常流程切入找 AI 能介入的点
作者强调不要为了做而做，而是先梳理日常测试流程（STLC 环节、每个 sprint 怎么跟其他团队协作），找出耗时最长、最值得改进的地方，再针对性地让 AI 介入。
最终确定了四个方向：测试用例生成、测试脚本生成、产品业务知识提取、用户反馈 log 分析。
Agent Skills 的核心实践
测试用例生成
新需求的用例生成主要通过 Agent Skills 来做，好处是渐进式披露、结构化输出和执行步骤。流程是理解需求文档、识别测试场景、按定义结构产生输出。作者分享了几个经验：
- QA 的基础认知决定了 Skill 质量，负责创建 Skill 的人如果对业务逻辑和 QA 方法论不清晰，生成结果会有遗漏，边界值过宽松、用户路径输出不好。
- 拆分测试类型，不要指望一个 Skill 同时做压测和普通用例，每个 Skill 专注一件事。
- 规范结构，清楚定义输出格式。
- 一个策略调整：由于通用大模型不懂业务逻辑，且产品迭代快（两周可能改一次页面），他们不生成完整测试案例，而是先生成测试点（test point），即什么时间点做什么事、预期结果是什么，采纳率比生成完整案例高很多。
成对组合测试（Pairwise）
系统测试步骤参数很多时，比如交易系统的交易类型、卡片类型、账户类型排列组合能到 1 万 9 千多种组合。
Pairwise 的目标是用最少的用例达到最高覆盖，作者发现两两成对的组合是中最高效的，能把整体用例压缩到 30 个以内。
过去靠跑脚本生成，现在封装成 Skill，Agent 可以自动提取关键参数、执行脚本并生成用例。
基于代码变更的智能化测试
有几千上万个测试用例，回归时不可能全部执行。
这个流程会先给大模型 GitHub 的 PR 或 tag，通过 GitHub 的 MCP 抓取代码变更、提交人、PR 评论，定位文件改动和相关点，再抓取关联的 Jira 需求文档理解改动背景，同时补充产品知识后做分析，判断影响哪个板块、风险最高，再通过 MCP 把相关测试用例抓回来挑选输出，最后在测试管理平台自动创建 test plan。
这里有个处理产品大文本的踩坑经历：
code 里的 RAG 方式先提取关键字再全文检索，但文档中英混合时效率结果不理想；
换更大 token 的模型让多 agent 各读档案再总结，token 消耗大又慢；
最终改成先把技术文档做语义相似度提取（去重、精简），既省 token 又快。
产品业务知识提取：不用传统 RAG
团队最早尝试建传统的 RAG 系统，用向量化工具或向量库，结果遇到三个问题：
技术落地门槛高（QA 工程师需要背景知识，图片、表格、长文本文档脏数据清洗和向量化是大工程，做不好匹配率低）；
知识更新成本高（产品迭代快，要不停清理向量库）。
最终改用新的思路：做意图分层，先判断问题属于哪个业务场景，再动态加载对应技术文档，按长短文本分别处理。
这样维护的只是背后的知识文档，不用跑整套 RAG pipeline。
MCP 打通工具孤岛
团队大量的工具底层打通都靠 MCP。当开源或官方 MCP 不符合使用情境时，会借助 AI 力量做一个贴近自己使用场景的 MCP。MCP 和 Agent Skills 是可混搭的，很多 Skill 在运行时会再去调用别的 MCP。
Playwright Agent 生成测试脚本
Playwright Agent 内部有三个 Agent：
- Planner Agent 像资深 QA 一样起一个浏览器判断测试意图
- Generator Agent 针对测试案例生成脚本代码
- Repair Agent 做自动修复
基于无障碍（accessibility tree）的方式读取页面，比传统 DOM 解析效率更高、意图识别更准。
一个很实用的能力是同时生成 UI 和 API 测试：在 Agent 执行 UI 操作时，通过 hook 记录下触发的所有网络请求，最终把 UI 操作步骤和捕获的 API 请求一起输出，同一个测试用例下同时产出 UI 自动化和 API 自动化脚本。
当 Playwright Agent 只支持 JavaScript 时，可以创建一个 Skill 把 JS 脚本转成 pytest，告诉它 JS 用法映射到 pytest 哪个 API、项目架构、编码规范。
构建好 Agent Skills 的四个准则
- 逻辑确定性：能用 Python 或脚本执行的尽量用代码执行，降模型幻觉，输出更可控。
- 显性激励约束：在 prompt 里明确品质优先，同时告诉模型不该做什么，限定边界。
- 权重分配：最不希望或最希望做的放 markdown 文本上方，用强调方式保证模型注意力。
- 避免超大 Skill：拆成多个小 Skill 互相调用。
几个使用技巧：善用 IDE 的 prompt 功能（艾特文件、斜杠命令）先把意图定义清楚；
搭配 agent 模式和 bug 模式增强输出；处理弹窗、下拉这类影响 AI 执行的特殊交互，先在页面初始化时剔除；最后模型能力直接决定成效，差一点的模型输出确实不行，能直上就直上。
用户反馈 log 分析
研发排查问题时不断和 AI 对话，定位后让 AI 把整个排查过程压缩成一个 Skill 上传到平台，其他团队上传 log 时自动匹配这些 Skill 做分析并反馈。这样让大家一起参与 Skill 维护，更快地分析问题。
未来展望
一是通过代码知识图谱实现更精准的测试用例筛选，解析代码、抽象语法树，知道每个函数、变量之间的关联，某个函数改动时能拉出上下游调用链路的函数一起分析，回归测试更准。
二是预先冒烟机制，在 PR 阶段让 AI 作为公正的第三方，针对本次新功能变更生成测试用例、用 Playwright 自动执行，输出 pass 或 fail，生成的脚本沉淀回自动化仓库提交 PR，实现「新功能提交时已经让 AI 做过冒烟测试」的闭环。
回到开头的问题，作者认为现阶段 AI 对 QA 是帮助更多。真正受威胁的是还不太会用 AI 的人。
就像汽车问世后养马人、车夫消失，但出现的是修车人和汽车工人，QA 的价值会从专注执行测试转向测试架构师，回归本质，把产品品质做好。衡量的标准是测得更深、更广、更快。
以上内容由 Ai好记 转录整理。
Ai好记是一款支持音视频转图文笔记的AI知识库工具，支持B站、小红书、抖音、小宇宙等平台链接及本地音视频文件，视频转文字后自动生成精华速览、思维导图和结构化图文笔记，帮助你把几小时的视频内容变成可搜索、可复习的图文笔记。