AI 编码 Agent 可以连接需求单、查看设计、编写测试用例和自动化代码、运行测试，最后准备好拉取请求。听起来很高效，直到它开始自行补全缺失需求，或一次生成几十个质量一般的场景。
分享页面列出的日常测试工作包括处理缺陷报告和测试数据、探索新功能、查看日志。
在 Ministry of Testing 的分享《测试人员工作流中的日常 AI 编码：Skills 与插件》中，测试领域首席软件工程师 Maneesh Maddala 提出了更稳妥的做法：把 Agent 的职责拆小、明确，谨慎开放工具权限，并在关键审批点保留人工判断。分享由 Ministry of Testing AI Chapter 的 Rahul Parwal 主持，于 2026 年 7 月 31 日举行。下文把其中的案例整理成团队可以检查和调整的工作流。
Skill 为 Agent 提供可复用的路线
可复用的 Skill 像一张路线图，能把完成任务所需的指引、上下文和方法整理出来，帮助团队复用做法。它可以提升一致性，却不能保证 Agent 会遵守每条规则，也不能替它补上缺失的信息。
在测试任务中，Skill 可以要求先取得证据再创建测试；Agent 仍需要权限边界、有代表性的评估样本，以及在需求不清楚时安全停止的方式。Skill 是工程工作流的一部分，不能替代整个工作流。
命令、Skill、插件、MCP 和 Agent 有什么区别
分享用厨房做比喻，帮助听众区分这些概念。这个比喻有助于理解，但不是技术规范。
| 概念 | 厨房比喻 | 实际作用 |
|---|---|---|
| 斜杠命令 | 主动选用的菜谱卡 | 显式启动一项指定操作 |
| Skill | 受过某种工作方法训练的厨师 | 提供任务所需的指引和上下文；任务符合其描述时也可能被自动选用 |
| 插件 | 包含设备和食材的整间厨房 | 在特定宿主中打包或提供 Skill 与工具 |
| MCP 服务器 | 连接外部供应商 | 通过约定接口让模型访问外部数据或执行操作 |
| Agent | 负责调度的主厨 | 规划工作、使用工具、处理失败，并在满足完成条件时停止 |
Skill 不会取代 MCP。Skill 可以说明怎样使用已经连接的系统，MCP 则可以提供这条连接。工作流是否需要 MCP，取决于是否必须读取外部数据或执行外部操作。
分享者还用工具箱作比喻：Skill 是为一项具体工作准备的工具，插件则像包含多种能力、脚本和钩子的工具箱。斜杠命令被比作显式调用一个函数，Skill 则像在相关任务中加载的工具库——例如处理日期时带入 moment.js 这样的日期库。这些是帮助理解的比喻，不代表每种宿主的具体实现。演示中，grill-me 被作为单个 Skill 介绍；Superpowers 则被描述为一个包含 14 个 Skill、脚本和配套材料的插件。这些数量和打包方式是演示当时的介绍，不是长期不变的规范。
为什么一个超长提示词效果不好
分享中回顾了一次早期的端到端尝试：一个提示词要串起 Asana 需求、Jira 工单、Figma 设计、TestRail、Playwright 和拉取请求评审。团队通过 MCP 把它接入需求和测试管理系统。原计划是读完这些材料、提出场景，等人批准后再创建测试用例、Playwright 页面对象和测试文件。Agent 最后生成了大约 50 至 60 个场景，但其中不少质量薄弱，甚至虚构了行为；即便可以使用浏览器，它也编造了定位器。
问题不只是提示词太长。一个任务同时包含太多决策、系统、权限和输出类型，却没有足够的项目上下文和检查机制。当时团队没有为生成的场景设置权限护栏或评估；对话上下文不断累积后，输出质量也开始下滑。团队把场景数量误当成覆盖率；用例增多，评审负担也可能随之上升。
按职责拆分工作流
给每个 Skill 一个范围明确的任务和交接条件。规划 Skill 可以只读需求并提出场景，不获得创建测试用例或代码的权限。场景编写 Skill 在获批后创建用例。编码 Skill 实现页面对象和测试。执行 Skill 运行并汇报。评审 Skill 可以准备拉取请求，但除非负责人明确授权，否则应在合并之前停止。团队是经过反复试错才逐渐划清这些边界的；接通工具或把提示词写得更长，都不能单独解决问题。
限制应结合任务复杂度设置。学习笔记记录了两组示例：讨论 Skill 设计时提到 8 至 10 个或 10 至 15 个场景；介绍 Planner 工作流时，又举了小改动约 3 至 5 个、较大任务约 10 至 12 个的例子。它们对应流程中的不同环节，不宜合并成一个通用上限。每个场景仍要说明为什么需要它。
团队约定同样重要。优先使用 Playwright 的语义定位器，例如 getByRole 和 getByLabel；确实需要时再退回 CSS 选择器或 class 名称。页面对象聚焦用户意图和操作，断言留在测试中。这样生成的代码更容易检查，也不容易被脆弱的页面细节牵着走。
团队还希望 Skill 固定命名规范、重试方式和完成标准。把这些规则写清楚，可以减少不同工程师各自解释时造成的偏差。
保留人工审批的五阶段工作流
| 阶段 | Agent 负责的工作 | 人工决策或交接 |
|---|---|---|
| 规划 | 阅读需求，在 scenarios.md 中提出有数量边界的场景清单 | 评审范围并批准场景 |
| 测试管理 | 将获批场景映射到已有 TestRail 用例，提出新增或修改建议 | 批准测试用例变更 |
| 实现 | 创建或更新页面对象和自动化测试 | 评审代码并确认符合仓库约定 |
| 执行 | 运行已批准的测试集，附证据总结失败 | 判断失败来自产品、测试、数据还是环境 |
| 评审 | 整理变更、执行结果和已知限制，准备拉取请求 | 工程师评审并决定是否合并 |
这条交接链可以概括为：规划 → TestRail → 编码 → 执行 → 评审。不同工具的实际能力和权限边界各不相同。这张表只是把分享中的流程拆开整理；每次交接仍要说清产出物是什么、谁来评审，以及满足什么条件才能进入下一步。
每个阶段都应有契约和固定的产出文件。团队选择 Markdown，是因为人和 Agent 都容易阅读，也有助于减少上下文和 Token 占用。例如，规划阶段必须产出 scenarios.md。场景记录可以包括来源需求、用户意图、前置条件、预期行为、风险和待澄清问题。TestRail 阶段先检查已有分组和用例，再决定映射、更新或新增。没有获得相应审批之前，不要让 Agent 写入 TestRail、修改仓库文件或创建拉取请求。
场景进入 TestRail 前，先由人批准。之后评审阶段可以创建拉取请求，然后停下来；代码评审和合并由人完成。这样，每次审批都只授权紧接着的那项操作，不会因为早期说过一次“可以”就默认开放后续所有权限。
自主循环也需要自己的边界：重试次数、超时时间、费用预算、失败分类和成功条件。按使用量计费时，无限制重试会持续消耗 Token 和费用。“一直重试到变绿”不是安全的完成标准。
为什么仍然需要人工评审
人工审批应放在假设即将变成受管理的测试资产、代码变更、外部写入或发布决定的节点，而不能只留到流程末尾。
评审者应检查输出是否符合需求、场景是否彼此独立且覆盖风险、定位方式是否使用稳定语义、页面对象是否只封装操作而没有藏入断言，以及是否有对应的真实执行记录。Agent 能访问浏览器，不代表它一定正确使用了浏览器。
审批要明确，也要有范围。一个人批准了场景意图，并不等于同时批准仓库修改、外部系统变更或合并拉取请求。
SauceDemo 对比演示说明了什么
现场演示在两个空白的 SauceDemo 仓库中使用同一条提示词，创建约 8 至 10 个检查，覆盖登录、购物车和结账。没有 Skill 时，Agent 直接给出基础实现：它使用了 page.locator()，没有优先采用语义定位器；只选了 Chromium，没有询问 Firefox 或 Safari；也没有确认 CI/CD、代码检查和格式化要求。
加入 grill-me Skill 后，Agent 开始询问项目是否使用 TypeScript、npm、代码检查、Prettier 和 GitHub Actions，也询问认证方式、测试类型（功能、视觉回归、无障碍或 API）、浏览器范围和仓库约定，再拟定计划。获批的示例包含 GitHub Actions 配置、Husky 提交前钩子、测试夹具、页面对象，以及覆盖三种浏览器的测试。这里可借鉴的是先澄清再实现；这段演示并非受控基准测试，不能据此断言某个 Skill 在所有项目里都会让测试更好。
工具清单是候选资源，不是推荐背书
分享链接了若干公开资源。这里记录的是演讲中讨论或列出的项目，并不表示它们适合所有团队。安装或接入前，请检查项目现状、支持的宿主、权限、维护情况和数据处理方式。
| 资源 | 学习笔记中的用途描述 | 使用前需要检查 |
|---|---|---|
| Superpowers:https://github.com/obra/superpowers | 演讲者先用头脑风暴 Skill 制定方案，再用编码 Skill 实现；方案可以保存为 plan.md | 当前版本、支持的 Agent 宿主和工作流适配情况 |
| grill-me:https://github.com/mattpocock/skills/tree/main/skills/productivity/grill-me | 编写自动化脚本前先通过提问厘清需求，包括涉及哪些文件和限制 | 避免有用的澄清变成没必要的盘问 |
| Ponytail:https://github.com/DietrichGebert/ponytail | 遵循 YAGNI（You Aren’t Gonna Need It，即暂时用不到的功能不必预先实现）的思路，提示可能未使用的代码 | 删除前验证引用关系和行为 |
| Graphify:https://github.com/Graphify-Labs/graphify | 绘制仓库关系图，让 Agent 聚焦相关文件和依赖，而不是每次都重读整个仓库 | 检查图谱是否新鲜、重要依赖是否遗漏 |
| find-skills:https://github.com/vercel-labs/skills/blob/main/skills/find-skills/SKILL.md | 用日常语言描述需求，从 Vercel 的 Skill 目录中寻找适用项 | 核实来源、请求的权限和质量 |
| claude-mem:https://github.com/thedotmack/claude-mem | 在 Claude 会话之间用 memory.md 保存项目决定及其原因，几个月后仍能查回当初的考虑 | 检查数据留存、敏感信息和记忆准确性 |
| skills.sh:https://www.skills.sh/ | Skill 发现目录 | 把目录中的 Skill 当作待审核项目，而非可信推荐 |
| skills.md:https://skills.md/ | 分享中列出的 Skill 相关目录或服务 | 使用前确认当前页面提供什么，以及是否适配目标 Agent |
| free-qa-skills:https://github.com/Quality-Max/free-qa-skills | 面向编码 Agent 的可复用 QA Skill | 逐项检查指引、权限和测试 |
| CodeBurn:https://github.com/getagentseal/codeburn | 官方分享资源清单中的额外项目；学习笔记没有说明其用途 | 先检查项目内容、收集的数据和存储方式 |
官方分享的资源清单还链接到了 CodeBurn，但提供的学习笔记没有说明它的用途。skills.md 链接也值得在使用时重新检查，因为当前落地页可能已不同于早期的描述。
讲者建议先搜索已有方案，再决定是否自己编写 Skill：学习笔记列出了 skills.sh 和 skills.md，也提到可以用 find-skills 直接描述需求。目录里能搜到某个项目，只是筛选的起点，不代表它已经通过质量或安全审核。
编写团队可以复用的 Skill
一个 Skill 不只有 SKILL.md，还可以配套参考资料、脚本和资源文件，把不适合放进主说明的细节拆出去。演讲示例的文件头元数据（front matter）只有 name 和 description；其中 description 字段应说明 Skill 能做什么、适合在什么时候触发。入口文件尽量精简，较长的资料放在配套文件中。讲者提到官方建议控制在 100 行以内，也有人接受 500 行以内；这些数字不能代替对清晰度和可维护性的检查。
学习笔记估算，一次对话开始时加载的各个 Skill 元数据合计约占 100 至 120 个 Token，之后 Agent 可根据 description 选择是否调用对应 Skill。实际开销取决于宿主和配置。讲者以百万 Token 级别的上下文窗口作比较；这是演讲中的举例，不代表所有模型或配置都能达到这一容量。团队应测量自己的环境。
Skill 需要反复试用和修订。拿真实任务试跑，保留失败案例，收紧边界，再补上评估。讲者提到，团队在分享当年开始加入评估，先从几条“黄金规则”做起，再检查输出结构、工具选择和审批边界。团队自己编写的 Skill 往往很有用，因为作者最清楚每条指令、护栏和评估背后的工作方式。
权限护栏与评估集各有分工
权限护栏（guardrails）规定 Agent 可以做什么：只读访问、允许执行的命令、受保护文件、外部写入权限、费用上限和审批要求。评估集（evals）则通过有代表性的输入检查它是否按预期行动。
可以从三个层面评估：
- 结构： 输出是否符合格式要求，必需字段是否齐全？
- 行为： Skill 是否遵循指引、只用获准工具，并在审批边界前停止？
- 质量： 场景是否能追溯到真实验收条件，是否重复，是否虚构功能或使用了薄弱断言？
评估样例可以简单到下面这样：
case: missing_acceptance_criteria
input: "Create tests for an unspecified checkout change"
expected:
ask_for_clarification: true
fabricate_requirements: false
create_testrail_cases: false“输出看起来不错”不是足够的通过条件。把真实失败样本保留下来作为回归集；每次修改 Skill 后，记录通过率、越权情况、人工修改量和回归结果。
效率提升的数据应怎样理解
分享中的一个团队案例是：一条 Jira 需求从分析到拉取请求，原本约需 8 小时；半自主工作流将它缩短到 2 至 2.5 小时。按这组案例数字计算，耗时减少约 69% 至 75%。这个结果不能直接外推到其他团队。
分享者还提到，使用 Skill 可能消耗更多模型词元（Token）：演示约为两倍，某些场景可能达到两至三倍。学习笔记还提到用 /compact 和 /clear 管理较长的对话。因此要一起衡量端到端耗时、评审时间、有效场景比例、代码返工、不稳定测试比例、错误的外部写入和模型费用。生成更快，不一定意味着总成本更低。
分享中还提到，过去六个月生产缺陷有所下降，但没有把变化全部归功于 AI。团队成熟度和风险管理的变化也可能产生影响。讨论效果时应保留这一区分。
从个人提示词走向组织能力
讲者表示，公司层面还没有确定统一的 ROI 衡量方式；个人可以先展示具体工作流节省的时间，为管理层提供讨论起点。分享还把组织采用 AI 的成熟过程大致分为四个阶段：
- 个人把 AI 当聊天机器人使用。
- 团队为日常工作创建可复用的 Skill。
- 团队之间共享 Skill，并组合跨团队的 Agent 工作流。
- 组织建立中央 Skill 目录，并为 IDE、Claude Desktop 等不同入口提供统一管理的访问方式。
采用范围扩大后，Skill 需要有负责人、版本、输入和输出契约、权限边界、评估集、变更记录和弃用流程。除了共享文件，还要管理这项能力的版本和使用规则。同一个 Skill 在不同 IDE、模型和 Agent 中可能表现不同，因此要分别检查触发条件和工具权限，不能直接假定它可以无差别迁移。
分享中的五个常见问题
Skill 会不会取代 MCP？ 不会。它们承担不同职责：一个可以描述工作方法，另一个可以连接外部数据或操作。
为什么不让整个流程完全自主运行？ 因为停止条件、重试、费用限制和失败恢复需要先可靠。把多个 Skill 串起来，并不会自动得到安全的自主系统。
AI 会不会取代测试人员？ 分享中的回答是否定的。人仍要编写指令、决定哪些风险重要、评审推理并维护标准。讲者提到，可以把省下的时间用于搭建质量体系，或为其他团队开发工具，例如他支持的营销技术、设计、Google Analytics 和 SEO 团队。
Claude 太贵怎么办？ 可以在企业安全评审后评估 Copilot 或其他模型，再用同一套行为与质量评估重新检查。模型可以替换，不表示效果天然相同。
讲者还提到团队正在尝试 GLM 系列开源模型和 Kimi K2，但都要先通过公司安全审查。学习笔记列出了 GLM 4.5/4.6，也记录了一个听起来像“GLM 5.2”的口述版本；记录彼此不一致，因此这些 GLM 版本号都不应视为已核实信息。
怎样证明价值？ 先做范围有限的单条需求耗时对比，再加入质量、成本和复用情况。没有证据时，不要把生产缺陷趋势归因于 AI。
可以把编写测试用例等重复工作交给 AI。遇到生成的代码看不懂时，也可以让 Agent 解释代码或给出更简单的写法，顺便学习不熟悉的语法。
让 Skill 成为可测试的工程资产
这场分享给出了一套可复用的工程做法：职责保持精简、契约明确、工具权限受限、人工审批到位，并针对真实失败做回归评估。
团队可以给每个 Skill 维护一张小型质量卡：触发是否准确、是否遵守工具边界、是否编造测试、是否符合输出契约、在支持的模型间是否表现一致、遇到缺失信息时能否安全停止？这样才能把好用的提示词变成可维护的工程资产。
如果想低成本起步，可以从分享页面提到的一项日常任务开始，例如整理缺陷报告、准备测试数据、探索新功能或查看日志。先试用一周，只让 Skill 生成草稿或读取信息；明确它能产出什么、必须在哪一步停下，再比较评审时间和返工情况，确认有价值后再扩大范围。这是本文提出的试点建议，并非讲者规定的固定步骤。
Skill 可以减少团队反复解释工作方式的时间，工程判断仍由人负责。评估 AI 编码工作流时，应看它是否减少重复沟通、交付可验证、可追溯、可评审的结果；代码量本身说明不了工作流有没有改善。Maddala 最后强调的两点可以概括为：用 Skill 引导 AI，而不是反复向它解释同一套工作方式；只有在 AI 能解决真实问题时才值得使用。已有合适方案时，先复用，不必再造一套。
参考资料
- 原始分享:https://www.ministryoftesting.com/media-sessions/everyday-ai-coding-skills-plugins-in-a-tester-s-workflow
- 上表所列资源均指向其原始项目或目录页面。安装或授予权限前，请确认兼容性与安全边界。
本文根据提供的学习笔记、分享公开页面和资源清单整理。工作流表格与评估样例是编辑整理，不代表讲者明确规定了完全相同的实现方式。