Skill机制实战：用AIAgent打造90分钟可用的APP测试搭子

这次我们来看一个不是模型、不是框架，却能大幅提升 AIAgent 落地价值的东西：Skill。

最近 Claude Code、Codex、Cursor 这些 AI 编程工具都在推 Skill 机制，尤其是skill 怎么用、skill 和 mcp 有什么区别、如何编写 skill这类问题搜索量很大。如果你以为 Skill 只是给写代码用的，那就低估它了。把 Skill 用对地方，它能把一个只会“聊天”的 AI 助手，调教成真正能干活的工作搭子——比如 APP 测试搭子。

这篇文章不聊概念堆砌，直接给你一套能在 90 分钟内跑通的方法：从理解 Skill 的目录结构，到写一个 APP 测试专用的 Skill，再把它装进 Claude Code 或 Codex，最后拿真实需求文档让 Agent 自动产出测试计划、测试用例和缺陷报告。整个过程不需要高配显卡，不需要写复杂的 Agent 框架，只需要一个文本编辑器加一套命令行工具。

先看核心结论：Skill 本质上是一份“带流程、带模板、带触发条件”的结构化指令包。它让 AIAgent 在特定场景下不再自由发挥，而是按你预先设计好的路径执行。这正好是 APP 测试最需要的——测试流程标准、输出格式统一、口径可复制。下面正式进入实操。

1. 核心能力速览

需要说明的是，Skill 的调用方式、字段名在不同工具中会略有差异。本文以社区最常见的 Claude Code / Codex 写法为例，具体命令以你本机安装的 Agent 工具版本为准。

2. Skill 与 MCP、脚本、插件的核心区别

这一节必须先讲清楚。很多人搜“agent skill 和 mcp 有什么区别”，是因为在实际使用中，三个概念很容易混。

2.1 MCP 解决的是“Agent 能调用什么”

MCP（Model Context Protocol）是模型上下文协议，相当于给 Agent 接外部工具和数据源的“插头”。接上 GitHub MCP，Agent 就能调 GitHub API；接上数据库 MCP，Agent 就能查表。它解决的是能力边界问题：让 Agent 能读写文件、能调接口、能查数据。

2.2 Skill 解决的是“Agent 按什么流程做事”

Skill 不新增外部工具，它是一包“方法论 + 模板 + 示例”。一个 APP 测试 Skill，里面会写清楚：接到需求文档后，先拆功能点，再排优先级，然后按模块生成测试用例，最后输出标准缺陷报告。Agent 读完 SKILL.md，就会按这个流程执行。

2.3 两者的协作关系

实际项目中两者经常配合使用。Skill 负责流程编排，MCP 负责在执行过程中调用真实工具。比如：

Skill 流程：读取需求文档 -> 拆分测试点 -> 生成用例 -> 执行用例 -> 生成报告 MCP 能力：读文件系统、调 Postman API、查询缺陷管理系统

更简单的记忆方式：脚本是“人写的固定程序”，插件是“扩展产品功能”，MCP 是“给 Agent 接工具”，Skill 是“给 Agent 塞流程和标准”。

3. 适用场景与使用边界

3.1 适用场景

从搜索热度看，现在很多人正在尝试把 Skill 用到 code review、UI 设计、爬虫脚本、数学建模、语言学习等方向。对于 APP 测试来说，Skill 特别适合这三类场景：

• 测试计划与用例生成：给 Agent 一份需求文档，它按标准格式输出测试计划、用例表和风险点。
• 缺陷报告标准化：让 Agent 按统一模板输出缺陷描述、复现步骤、预期结果、实际结果、优先级。
• 回归测试清单生成：根据版本变更说明，自动生成回归范围清单，避免漏测。

3.2 使用边界

Skill 不是万能的。它不能让 Agent 自动点击手机屏幕，也不能代替你判断测试数据是否正确。UI 自动化执行仍需要 Appium、XCTest、UIAutomator 这类工具配合，Skill 主要承担的是“测试设计、文档生成、流程编排”这一层。

同时要注意合规：涉及真实用户数据时，必须脱敏。测试包、测试账号、日志数据不要提交到公开仓库。如果做性能测试或自动化采集，需确认测试对象允许你的操作方式，避免触碰到隐私和数据安全红线。

4. 环境准备：先跑一个最小 Skill 再谈 APP 测试

在写 APP 测试 Skill 之前，先把 Skill 的运行环境搞清楚。Skill 本身不需要安装任何运行时，它只是文本文件。真正执行它的是 Claude Code、Codex、Cursor 这类工具。

4.1 准备工作

• 安装 Node.js 18+ 或 Python 3.9+（取决于你选择哪种 Agent 工具）。
• 选择一个支持 Skill 机制的 AI 编程工具。当前常见的是 Claude Code、Codex、Cursor。
• 准备一个测试用的项目目录，目录结构建议如下：

app-test-demo/ ├── docs/ # 需求文档、版本说明 ├── skills/ # 本地 Skill 包 ├── outputs/ # Agent 生成结果 └── inputs/ # 测试素材、接口文档

4.2 安装一个 Skill 的通用方式

不同工具安装命令不一样，但逻辑都是“把 Skill 目录注册到 Agent 的配置中”。下面给出常见命令模板：

# Claude Code 安装本地 Skill（以实际 CLI 为准） claude skill add ./skills/app-test-planner # Codex 安装 Skill（以实际 CLI 为准） codex skill install ./skills/app-test-planner # 查看已安装的 Skill claude skill list

如果你用的工具还没有 skill 命令，还有一种通用做法：把 Skill 目录链接到 Agent 的~/.claude/skills/或项目级.claude/skills/目录下。因为 Skill 本质是文本文件，只要 Agent 能读取到，就能识别。

5. “90 分钟玩转”实操路线

标题里说 90 分钟，不是夸张，而是给出一条可执行的练习路径。这样安排：

这套安排的核心逻辑是：先让 Skill 机制跑通，再专注于 APP 测试领域的内容设计，最后做反馈调优。

6. Skill 目录结构与编写规范

Skill 的标准结构通常是这样：

app-test-planner/ ├── SKILL.md # 主文件：定义能力、触发条件、工作流程 ├── scripts/ # 可选：辅助脚本 │ ├── generate_testcases.py # 把结构化用例转成 Excel/CSV │ └── parse_requirements.py # 解析需求文档中的功能点 ├── templates/ # 可选：输出模板 │ ├── test_plan_template.md │ ├── testcase_template.md │ └── bug_report_template.md └── resources/ # 可选：参考文档 └── test_design_practices.md

6.1 SKILL.md 的推荐结构

SKILL.md 是 Skill 的核心。它给 Agent 提供了“何时使用、怎么使用、输出什么”的完整描述。一个推荐的骨架是这样的：

--- name: app-test-planner description: 用于移动端 APP 测试计划与测试用例生成。适合在用户提供需求文档、功能说明或版本变更清单时使用。 version: 1.0.0 triggers: - APP 测试 - 测试计划 - 测试用例 - 版本回归 --- # APP 测试规划 Skill ## 适用场景 在产品质量验证、版本迭代、需求评审之前，需要快速生成测试计划和测试用例时使用。 ## 输入要求 - 需要用户提供需求文档、PRD 或功能描述 - 推荐提供目标平台（iOS / Android / 小程序） - 推荐提供版本号和测试范围 ## 工作流程 1. 读取需求文档，提取功能模块清单 2. 按功能模块拆解测试点 3. 对测试点进行优先级排序 4. 生成测试计划 5. 生成测试用例 6. 输出风险提示 ## 输出格式 - 测试计划：Markdown 文档 - 测试用例：Markdown 表格，字段包括编号、模块、用例名称、前置条件、测试步骤、预期结果、优先级 ## 注意事项 - 不确定的功能点必须标记待确认，不能自行假设 - 涉及用户隐私的测试数据必须使用脱敏示例 - 用例步骤要可执行，不能写模糊描述

6.2 为什么要用 YAML frontmatter

name、description、version、triggers这些字段放在开头，是为了让 Agent 能快速判断“这个 Skill 适不适用于当前任务”。description尤其重要，因为它决定了 Agent 在什么情况下会想起调用这个 Skill。写得太泛，Agent 不会主动触发；写得太窄，又容易错过调用时机。

好的做法是：description里包含明确的动作词和领域词，比如“生成测试计划”“拆解测试用例”“APP 版本回归”。

7. APP 测试专用 Skill 实战：从零编写

下面直接进入核心环节，写一个可用的app-test-plannerSkill。这里的示例覆盖三个功能：测试计划生成、测试用例生成、缺陷报告模板化。

7.1 创建目录和主文件

mkdir -p app-test-planner/{scripts,templates,resources} touch app-test-planner/SKILL.md

把第 6 节的 SKILL.md 内容写入app-test-planner/SKILL.md，然后根据你的项目情况把“输入要求”和“工作流程”扩展成更细的版本。

对于 APP 测试，建议把“工作流程”细化成这样：

1. 读取需求文档，提取功能模块清单。
2. 将功能模块拆解为可测试的测试点。
3. 按“核心功能 / 非核心功能 / 边缘功能”给测试点定优先级。
4. 对每个测试点生成测试用例，覆盖正常流、异常流、边界值。
5. 生成测试计划：范围、策略、环境要求、时间预估、风险。
6. 输出 Markdown 报告。

7.2 编写测试用例生成辅助脚本

SKILL.md 负责给 Agent 指令，scripts/里的脚本负责把 Agent 生成的用例转成更易用的格式。比如一个把 Markdown 表格转成 CSV 的 Python 脚本：

#!/usr/bin/env python3 # scripts/md_table_to_csv.py import csv import re import sys def md_table_to_csv(md_text: str, output_csv: str): lines = [line.strip() for line in md_text.splitlines() if line.strip().startswith("|")] if not lines: print("未找到 Markdown 表格内容") return rows = [] for line in lines: cells = [cell.strip() for cell in line.strip("|").split("|")] rows.append(cells) if len(rows) >= 2: rows = [rows[0]] + rows[2:] # 去掉分隔行 with open(output_csv, "w", newline="", encoding="utf-8-sig") as f: writer = csv.writer(f) writer.writerows(rows) print(f"已输出: {output_csv}") if __name__ == "__main__": input_file = sys.argv[1] # 输入的 Markdown 文件 output_file = sys.argv[2] if len(sys.argv) > 2 else "testcases.csv" with open(input_file, "r", encoding="utf-8") as f: md_text = f.read() md_table_to_csv(md_text, output_file)

这一步不是必须的，但加上之后，Skill 的实用性会明显提升：Agent 可以在生成用例后，直接把表格转成测试管理系统能导入的 CSV 格式。

7.3 编写测试用例模板

templates/testcase_template.md是 Agent 生成用例时参考的输出格式。建议直接给出一个精炼的模板：

# 测试用例：{模块名称} | 用例编号 | 模块 | 用例名称 | 前置条件 | 测试步骤 | 预期结果 | 优先级 | | --- | --- | --- | --- | --- | --- | --- | | TC-001 | 登录 | 正常登录 | 已注册账号 | 1. 输入账号 2. 输入密码 3. 点击登录 | 登录成功并跳转首页 | P0 | | TC-002 | 登录 | 密码错误 | 已注册账号 | 1. 输入账号 2. 输入错误密码 3. 点击登录 | 提示“密码错误”，停留在登录页 | P1 | | TC-003 | 登录 | 账号为空 | 任意状态 | 1. 不输入账号 2. 输入密码 3. 点击登录 | 提示“请输入账号” | P2 |

模板的价值在于：它给 Agent 设定了输出锚点。没有模板时，Agent 生成的用例很容易字段不一致，有了模板，格式就稳定了。

8. 让 Agent 跑起来：调用 Skill 做推理验证

写好 Skill 之后，把它装进 Agent，然后实际跑一次。以一个简单的“APP 登录模块”需求为例。

8.1 准备输入材料

在inputs/目录下放一个需求说明login_requirement.md：

# 登录模块需求说明 - 登录方式：手机号 + 密码登录，支持验证码登录 - 密码规则：6-20 位，至少包含数字和字母 - 登录状态：保持 7 天 - 异常情况：密码错误 5 次锁定 30 分钟 - 支持退出登录

8.2 用对话方式调用 Skill

在 Agent 的交互界面中，直接输入：

请读取 inputs/login_requirement.md，使用 app-test-planner skill 生成测试计划和测试用例。

Agent 会先读取 SKILL.md，识别到任务匹配，然后按工作流程执行。

8.3 用非交互式 CLI 调用

如果要做批量处理，可以用命令行直接调 Agent：

claude --print \ --prompt "读取 inputs/login_requirement.md，调用 app-test-planner skill 输出测试计划和测试用例" \ --output outputs/login_module_test_plan.md

不同工具的 CLI 参数不太一样，--print、--output是常见写法，具体以你安装的版本说明为准。批量处理时，可以用脚本遍历inputs/下的多个需求文档，逐个生成测试产物。

8.4 验证输出

判断一个 Skill 是否生效，看三点：

1. 流程是否完整——是否按“拆功能点 -> 排优先级 -> 生成用例 -> 输出风险”的顺序执行。
2. 用例质量——常规流、异常流、边界值是否覆盖。
3. 格式是否统一——用例编号、字段、优先级是否跟模板一致。

如果 Agent 没有按预期执行，优先检查 SKILL.md 的triggers和description是否匹配你的调用话术。

9. 调教 AIAgent 工作搭子的五个关键动作

“调教”不是玄学，核心是让 Agent 越来越懂你的工作习惯。这里给出五个可落地的动作。

9.1 明确角色定义

在 Skill 或系统提示词里，给 Agent 一个清晰的角色。比如“你是资深移动端测试工程师，有 5 年 APP 功能测试经验”。角色定义会明显影响输出措辞和考虑维度。

9.2 固化规则而不是每次重复

常见的测试规范，比如“P0 表示阻塞发布必须修复”“P1 表示严重缺陷需尽快修复”“P2 表示一般缺陷按计划修复”，直接写进 SKILL.md。以后每次生成用例，Agent 都会按这套优先级口径输出，不需要你重复解释。

9.3 给足参考素材

Agent 生成测试用例时，输入越具体，输出越可靠。需求文档之外，尽量提供：目标平台、版本号、测试范围、往期案例模板。这些信息可以放在一个resources/文件里，由 SKILL.md 统一引用。

9.4 建立反馈闭环

如果 Agent 生成的用例有遗漏，不要只在对话里纠正，要把“为什么遗漏”补充进 SKILL.md 的注意事项。比如“登录模块必须覆盖验证码发送频率限制”“订单模块必须覆盖重复提交场景”。每纠错一次，Skill 就变强一次，这就是调教的累积效应。

9.5 记录失败样本

建议在 Skill 目录下增加一个resources/failure_cases.md，把 Agent 常犯的错误记下来。下次生成时可以提示“参考失败样本，避免以下问题”。这个文件就是团队测试经验的沉淀。

10. APP 测试场景验证清单

Skill 写好后，不要只测一个登录模块。建议按下面几个维度做一次完整验证。

10.1 功能测试设计

让 Agent 输出一个功能模块的测试用例，检查是否覆盖正常流、异常流、边界值。比如输入“登录模块密码框，输入 5 位密码”，看 Agent 是否会生成边界值用例。

10.2 版本回归测试

给 Agent 一份版本变更说明，让它生成回归范围清单。重点验证它能否识别影响范围，而不是把所有用例都列一遍。

10.3 风险识别

让 Agent 输出测试计划中的风险列表。这一步能检验 Skill 是否包含足够的测试设计经验。如果 Agent 只输出千篇一律的风险项，说明 SKILL.md 里的“注意事项”写得太少，需要补充具体领域的风险提示。

10.4 缺陷报告模板

要求 Agent 按模板输出一个缺陷报告，检查是否包含复现步骤、实际结果、预期结果、优先级、出现环境（iOS/Android/版本号）。

11. 常见问题与排查方法

这里要提醒一点：Skill 文件本身很小，不消耗模型推理之外的资源，但调用时消耗的是 Agent 的上下文 token。需求文档越长，单次调用费用越高。批量处理时，建议控制单文档长度，超出预期就拆分。

12. 最佳实践与进阶方向

12.1 最佳实践

• 第一次先跑最小用例：不要一上来写一个超大的全功能 Skill，先写一个“生成登录模块测试用例”的最小版本，跑通后再扩。
• 每个 Skill 都建独立目录：名称、版本、更新日期写进 SKILL.md 的 frontmatter 里，方便后面迭代。
• 用一个目录集中管理 Skill：建议把团队用的 Skill 放进一个 git 仓库，统一版本管理，方便多人共享。
• 输出目录要和输入目录分离：inputs/放需求文档，outputs/放生成结果，避免 Agent 读到自己刚生成的文件。
• 日志不能省：批量调用 Agent 时，把每次的请求、输出、错误都记录下来。Skill 是文本指令，但批量任务经常坏在输入格式上，日志能帮你快速定位是哪一步断了。

12.2 进阶方向

如果 90 分钟跑通基础流程，后续可以顺着这几个方向继续扩展：

• 把 Skill 的输出接进测试管理系统（如 Jira、禅道、Tapd）的导入格式。
• 让 Skill 调用 MCP 工具，在生成用例后直接查询接口文档或数据库表结构，补全接口测试用例。
• 让 Skill 支持“一句话生成完整测试报告”，在测试结束后自动汇总结果数据。
• 做一个“回归范围助手” Skill：每次发版前，给 Agent 一份变更列表，它自动输出受影响模块和回归清单。

12.3 合规提醒

最后再强调一遍：Skill 能把 AIAgent 变成高效率的测试搭子，但使用边界要守住。测试环境的数据要脱敏，真实用户信息不要交给第三方模型处理，涉及外部系统接口的测试要确认授权范围，自动化采集、批量请求要控制在合理频率内。工具提升效率，规则保证安全。

13. 总结

最有价值的一点是：Skill 把“AI 对话”变成了“AI 流程执行”。它不需要显卡、不需要部署服务、不需要写复杂的 Agent 编排代码，但对测试工作的效率提升是实打实的——需求文档进去，结构化测试计划、测试用例、缺陷报告出来。

如果你准备尝试，先做三件事：装一个支持 Skill 的 Agent 工具；按本文的目录结构写一个最小的app-test-planner；用登录模块的需求文档跑一遍验证流程。最容易踩的坑是 SKILL.md 写得太泛，Agent 不触发或输出不统一，解决办法就是像调教新同事一样，把你的测试规范一条条写进去，并不断补充注意事项和失败案例。真正的难度不在于技术，而在于把你的测试经验“结构化”进一份 Markdown 文件——这件事一旦做起来，收获的不只是一个 Skill，而是一套可以复制到团队的工作方式。