这 90 分钟的关键不是把 Agent 的所有功能都学一遍而是先把“Skill”这个机制用起来并且直接落在 APP 测试这一个具体场景里。Skill 在 AI Agent 里的作用和“岗位说明书”很像你告诉它怎么理解任务、按什么顺序执行、输出什么格式。APP 测试恰恰是特别适合做这种固化的场景因为测试的流程、判断标准、报告格式都相对稳定。这篇文章我按自己实际跑通的方式拆开讲适合 QA、移动端开发、测试开发以及想给 AI Agent 加固定工作流的同学看。先不讨论各种概念直接说怎么在 90 分钟内把一个能干活的工作搭子调出来。1. 先搞清楚 Skill 到底是什么和 Prompt、MCP 有什么区别很多人在热词里看到 Skill、Agent、MCP 连在一起出现容易混淆。我先用最直接的方式区分一下。1.1 Skill 的本质一段能被 Agent 稳定读取和执行的“经验包”你可以把 Skill 理解成一个文件夹里面有一个 SKILL.md 文件再加上一些辅助文件。SKILL.md 用 Markdown 格式写内容是这个技能的名字、适用场景、执行步骤、输入要求、输出格式、注意事项。为什么要单独做一个 Skill而不是每次在对话框里写一大段提示词因为提示词是一次性的。你每次都要重新描述需求Agent 每次理解的侧重点还不一样。Skill 是把这些描述固化下来放到指定目录Agent 读到之后就知道遇到这类任务按固定流程走。比如你告诉它“这是 APP 冒烟测试流程先分析需求再生成用例再写脚本最后输出报告”。如果只是对话里说一次下次换个会话它可能就忘了。写成 Skill 之后每次使用都会按这个路径执行输出格式也保持一致。1.2 Skill 与 Prompt、MCP 的核心差异这里直接把对比写清楚因为这是理解 Skill 最关键的入口。对比项PromptSkillMCP形态一次性对话文本目录 Markdown 文件 辅助资源标准化的服务接口解决的问题让 Agent 理解这一次任务让 Agent 按固定步骤完成一类任务让 Agent 与外部系统交换数据和能力复用性较低每次要重新写高可反复加载高可多工具共用类比你临时交代一件事岗位操作手册外部插件或数据管道这段话很重要Skill 管的是“怎么做”MCP 管的是“能做什么”。如果你要给 Agent 接上内部缺陷管理系统那可能用到 MCP。如果你想让它每次都按同样的测试规范输出用例和报告那是 Skill 的活。两者不冲突甚至可以配合使用。1.3 为什么 APP 测试特别适合先用 Skill 做落地场景APP 测试有四个特点导致它特别适合固化到 Skill 里。第一流程固定。无论是需求理解、用例设计、脚本生成还是结果分析测试工作都有固定套路。第二输出格式稳定。测试用例、缺陷报告、测试总结都有行业默认模板。第三重复度高。每个版本都要做冒烟、回归、兼容性。第四日志和报错信息是结构化的。Agent 分析崩溃堆栈、接口返回、性能数据天然比写探索性文案更稳定。我用一个实际项目验证过把一套“登录注册模块冒烟测试”流程固化到 Skill 里Agent 生成的用例在覆盖度和格式上比直接对话给出的结果更稳定。并不是说它的智能程度变高了而是它不会漏掉那些你写在手册里的必要步骤。2. 动手前的准备环境、模型和测试场景三个都要想清楚90 分钟看着短但如果环境没准备好光折腾安装就要花掉一半时间。我建议把准备工作拆成三块。2.1 需要准备哪些基础条件一个支持 Skill 功能的 AI 编程助手或 Agent 工具。目前在 Claude Code、Codex CLI、OpenCode 这类工具中Skill 已经是比较常见的扩展方式。不同工具的目录规则略有差异但核心都是一样把 Skill 文件夹放到指定位置。一个能跑的本地开发环境。APP 测试涉及解析代码、读日志、生成脚本至少要有 Python 或 Node.js 环境并且能执行命令行。一个最小测试对象。不建议一上来就拿完整商业 App 做实验我建议先选一个简单 APP或者一个页面模块比如登录页、注册页、设置页。测试相关的账密或测试包。有些操作需要测试包、测试账号或者真机设备提前确认这些是否可用。从热词里的“uniapp ios app 打测试包全流程”来看很多人关心的其实是拿到一个 iOS 测试包之后怎么开始测试。这里有一点要提醒如果测试包还没打包好Skill 也只能帮你写测试计划和脚本不能替代打包过程。先把测试包准备好再让 Agent 介入手头工作效率会高很多。注意不一定要 GPU不一定要高配服务器。APP 测试 Skill 的核心是流程和上下文不是模型推理能力。大部分场景下一个能跑 Agent 的普通开发机就够了。2.2 把 APP 测试场景拆成 Agent 能理解的任务拿到一个 App 测试需求人脑会先做几个判断这是什么模块影响范围有多大重点测什么哪些是冒烟必测哪些是回归可以后置。Agent 默认不会自动做这些判断除非你在 Skill 里写清楚。我建议把 APP 测试拆成五个阶段需求理解读需求描述、看页面路径、列出测试点和风险点。用例设计按优先级输出测试用例包含前置条件、步骤、预期结果。脚本生成生成可直接执行的测试脚本骨架或给出执行命令。结果分析读取测试日志、崩溃信息、接口返回定位问题。报告输出形成一份结构清晰的测试报告。Skill 就是把这五个阶段变成 Agent 的执行步骤。它看到任务后会按这个顺序走而不是东问一句西答一句。2.3 选择一个最小测试任务第一次调试时不要让 Agent 处理“整个 App 全量回归”这类大任务。给它一个非常小而具体的任务效果会好很多。我用的是登录页面冒烟测试。这个模块业务逻辑清晰输入项固定预期结果容易判断日志也容易拿到。哪怕你没有登录模块只测一个“设置页的深色模式开关”也完全可以。最小任务的好处是验证周期短Agent 出错时你能快速判断是 Skill 的问题还是环境的问题。2.4 90 分钟怎么分配我给你一个比较稳的时间分配但实际可以按自己节奏调整。时间段任务产出0-15 分钟环境检查、场景选择、确认测试对象环境通畅场景明确15-45 分钟编写第一个 Skill 文件SKILL.md 可被 Agent 加载45-60 分钟验证加载、跑最小任务输出格式稳定60-80 分钟跑一个完整测试闭环需求到报告全流程通过80-90 分钟记录问题、调整参数、补充边界复盘清单这套分配方式和很多人“先研究功能菜单再慢慢试”的做法不一样核心是逼自己先用最小闭环跑通。如果你在某个环节卡住超过 15 分钟建议先跳过用备用方案补上否则整体节奏会乱。3. 编写第一个 APP 测试 Skill从零到能用的关键步骤这部分是整个 90 分钟的核心。Skill 写得太虚Agent 没法执行写得太死遇到新场景又不会变通。下面给出一个相对通用且稳的写法。3.1 Skill 文件基本结构一般一个可用的 Skill 至少包括app-ui-test-skill/ ├── SKILL.md └── references/ ├── test-case-template.md └── bug-report-template.mdSKILL.md 是入口文件必须存在。references 目录放模板和辅助资料不是必须但建议加上。没有辅助模板时Agent 生成出来的报告格式会比较随意有了模板输出质量会稳定很多。3.2 SKILL.md 核心内容怎么写SKILL.md 不需要很复杂但关键的几个部分不能缺技能名称和触发条件。适用场景。明确说明它处理什么任务不处理什么任务。输入要求。需要用户提供哪些信息比如页面路径、需求描述、测试包地址、模拟器或真机信息。执行步骤。分阶段说明 Agent 应该做什么。输出要求。规定用例表格、报告模板、缺陷单的格式。注意事项。写边界和常见坑。这里给一个简化版的 SKILL.md 示例只保留了最基本结构实际使用中可以按项目继续细化。# App UI 冒烟测试 Skill ## 触发条件 用户要求对某个 APP 页面或核心流程执行冒烟测试时使用。 ## 输入要求 用户需要提供 - APP 名称和版本 - 被测页面路径或功能入口 - 测试设备信息真机/模拟器系统版本 - 测试包是否可用 ## 执行步骤 1. 需求理解将用户输入整理成功能列表。 2. 用例设计编写冒烟测试用例包含前置条件、步骤、预期结果、优先级。 3. 脚本生成根据用例生成测试脚本或可执行命令。 4. 结果分析如果用户提供日志、截图或崩溃信息先定位问题再给出结论。 5. 输出报告按照 references/test-case-template.md 生成报告。 ## 输出要求 - 所有用例必须给出唯一的用例编号。 - 预期结果必须可判断不允许写“正常”“没问题”。 - 报告必须包含结论、风险点、遗留问题三部分。 ## 注意事项 - 只做 UI 冒烟测试不做性能压测。 - 如果没有真机日志必须在报告中标注“未验证”。 - 如果需求描述不清楚先向用户提问不要自行假设。写的时候有两点容易踩坑。第一执行步骤不要写得太笼统。如果只写“对 APP 进行测试”Agent 不知道从哪开始。写成“先整理功能列表再设计用例再生成脚本”它就知道顺序了。第二输出要求要非常具体。比如“预期结果必须可判断”这会让 Agent 避免生成一堆无法验证的废话。3.3 编写测试步骤和验收标准时要注意什么在 Skill 里写测试步骤的时候我建议用“输入-操作-预期”三列式而不是大段描述。原因有两个一是 Agent 读取结构化内容更准确二是后续生成测试脚本时结构化的步骤能直接映射到代码。比如登录页冒烟测试可以这样写用例编号操作步骤预期结果优先级TC-LOGIN-001输入正确账号密码点击登录按钮页面跳转到首页本地存储登录态P0TC-LOGIN-002输入错误密码点击登录按钮页面提示密码错误不跳转P0TC-LOGIN-003点击“忘记密码”链接跳转到找回密码页面P1这种表格放在 SKILL.md 的参考模板里也行放在 references 目录的模板文件里也行。重点是让 Agent 知道最后生成的用例要按照这个结构去做。3.4 一个最小 Skill 的实际编写顺序如果你是第一次写我建议按下面三步走先写触发条件和输入要求大约 10 分钟。再写执行步骤和输出要求大约 15 分钟。最后放一个用例模板文件大约 10 分钟。不要一开始就把所有测试场景都写进去。先写一个“登录页冒烟测试”适用的最小 Skill跑通之后再扩。4. 安装和调用不同 Agent 工具的差异与验证方法很多人写完 SKILL.md结果 Agent 完全不认大概率不是内容问题而是“这个工具认不认这个目录”的问题。4.1 安装方式不同工具对 Skill 的支持方式并不完全一致。有的要求放在项目目录下的.claude/skills有的要求放在全局配置目录下的skills文件夹还有的通过配置中心加载。具体细节要以你正在使用工具的文档为准。这里给一个通用判断顺序先查工具是否支持 Skill。可以直接在对话中问 Agent或者看工具的说明文件。查看 Skill 的目录规则。一般工具文档都会写清楚。按规则放置 SKILL.md。重新加载或重开一个会话。如果你用的是 Codex CLI 这类带命令行的工具通常还需要确认命令是否已经安装完整。命令装了一半Skill 加载也会失败。4.2 如何验证 Skill 是否被加载装完之后不要直接跑大任务先做两个小验证。第一个问 Agent 能不能列出可用的 Skills。有些工具是/skills命令有些工具是直接对话询问。只要它能把 Skill 名称列出来说明加载成功。第二个让它用一段非常简单的输入跑一次。比如你给一个登录页需求描述它如果按 SKILL.md 里定义的步骤执行说明成功。如果回答完全无视 Skill 的结构就要检查配置或重新加载。注意部分工具修改 Skill 文件后需要重启会话才会重新加载。不是文件改错了是缓存问题。4.3 第一次调教让 Agent 按你的习惯说话和输出加载成功只代表 Agent 能读到 Skill不代表它会自动符合你的习惯。第一次使用时建议在对话里加上一些约束。比如“使用 APP 冒烟测试 Skill严格按执行步骤来。”“没有真机日志时标注未验证。”“报告只输出 Markdown 格式不要输出解释性废话。”这些约束不是每次都要重新写而是在 SKILL.md 没覆盖到的地方做补充。跑几次之后把稳定的约束再补进 SKILL.md 里后续就不用反复说了。5. 实战90 分钟内跑通一个 APP 测试闭环这是最有价值的部分。Skill 只是手段跑通测试闭环才是目的。我以“登录模块冒烟测试”为例子完整拆解一遍。5.1 第一阶段需求理解和用例生成第 0-15 分钟先让 Agent 处理需求。给出的输入可以是这样输入登录模块冒烟测试 APP演示App 2.3.0 功能入口登录页 测试设备Android 模拟器 API 34 测试账号请使用默认测试账号 需求描述验证登录主流程是否可用包括正确登录、错误密码、验证码、退出登录Agent 收到这个输入后按 Skill 执行需求理解。它应该先输出一份功能列表再输出测试用例表。这一步能看出 SKILL.md 有没有写清楚。如果它跳过了需求理解直接开始写代码说明 Skill 里执行步骤部分还不够具体。5.2 第二阶段生成测试脚本第 15-35 分钟让 Agent 生成可执行脚本。注意一个问题Agent 本身不能直接点击手机屏幕它靠的是生成测试脚本或者给你命令。这意味着你本地要有对应的测试框架。对于 Android常见做法是 Appium 或自研的 UI 自动化框架。对于 iOS可能是 XCUITest 或者带测试框架的脚本。Skill 里不用假设具体框架而是让 Agent 在生成脚本前先问清楚你的技术栈。比较稳的写法是在 Skill 里加一句“如果用户没有指定测试框架先询问用户再生成代码。”这样就不会默认生成一个跑不起来的框架。5.3 第三阶段执行结果和缺陷分析第 35-55 分钟是发现问题最多的时候。执行测试后把日志、截图、崩溃栈喂给 Agent。Skill 里定义的结果分析步骤会要求它先定位问题再给结论。一个典型的输出是结论登录按钮点击后无响应页面未跳转。 问题定位可能是登录接口请求未触发或前端路由阻塞。 建议操作 1. 检查登录按钮绑定事件是否生效。 2. 检查接口请求日志中是否有 login 请求。 3. 检查登录返回后路由跳转逻辑。 风险点无真机日志结果基于模拟器日志。这里有个容易误判的点Agent 说出的“建议操作”不一定准确。它是在日志分析基础上推断的不是你亲眼确认的结论。报告里要把“已确认”和“推测”分开标注。5.4 第四阶段输出测试报告第 55-80 分钟让 Agent 按模板生成报告。报告里应该有这些部分测试结论通过、不通过、风险通过。测试范围哪些功能覆盖了哪些没覆盖。用例统计总用例数、通过数、失败数、阻塞数。缺陷列表缺陷描述、优先级、复现步骤、截图或日志。遗留问题哪些点当前无法验证原因是什么。报告建议生成 Markdown 格式方便直接转成文档或者上传到内部平台。如果你想要 HTML 格式在 Skill 的输出要求里补充一句就行。5.5 一个完整的示例对话流为了更直观我把一套最小对话流列出来便于第一次实践时照着走。你使用 APP UI 冒烟测试 Skill执行登录模块冒烟测试。需求描述验证登录主流程包括正确登录、错误密码、验证码、退出登录。测试设备Android 模拟器。 Agent已加载 Skill开始执行。先整理功能列表再输出测试用例。 Agent输出需求理解 用例表格 你使用 Appium 生成测试脚本只生成核心用例不需要处理错误截图。 Agent输出脚本骨架和命令说明 你这是执行后的日志与截图。 Agent按 Skill 先定位问题再给结论 你生成最终测试报告按照模板。 Agent输出完整报告这个流程不算复杂但已经覆盖了测试的完整链路。跑完这一步你就有了一个可以重复使用的工作搭子。6. 常见问题排查链路Skill 不生效、Agent 不听指令怎么办实际使用中你大概率会碰到下面几类问题。这里给出一个优先排查顺序不要一上来就怀疑模型能力。6.1 Skill 被加载但没有按 Skill 执行现象Agent 能列出 Skill但回答时完全无视 SKILL.md 的结构。比如没有先做需求理解直接输出用例或者用例格式和模板完全不一样。优先排查顺序确认当前会话是否加载了最新版 SKILL.md。修改文件后是否重启会话。确认 SKILL.md 里的执行步骤是否足够明确。如果是“进行测试”这种模糊描述它可能就直接自由发挥了。确认你当前使用的模型是否支持多步骤指令。有些轻量模型对复杂指令的遵循能力偏弱。在对话里强调“严格按照 Skill 定义”看是否有改善。如果还是不行可以试着把 SKILL.md 写得“更强制”。比如“第一步必须输出功能列表第二步必须基于功能列表生成用例”。少用“应该”“可以”多用“必须”。6.2 Agent 生成的测试脚本跑不起来现象代码看起来完整但执行时报错比如依赖缺失、选择器错误、WebDriver 版本不兼容。这通常不是 Skill 文件的问题而是当前场景下的技术栈问题。排查顺序先看报错信息。大部分是依赖版本或选择器错误。确认 Agent 生成脚本前有没有问清楚你的技术栈。如果没问你要在输入里主动补上。把报错信息重新丢给 Agent让它修正。它会基于错误信息逐步定位。如果连续报错减少生成范围让它先生成单个用例的脚本跑通后再生成全部。这里要特别强调Agent 生成的脚本本质是“基于描述的代码”它没有真正在设备上点击过所以第一次执行失败非常正常。重点是看它能否根据日志和报错信息修正。6.3 输出报告格式不符合预期现象报告没有按模板输出缺少测试结论或者把推测写成确认结果。排查方式在 SKILL.md 的输出要求里给出一个非常具体的模板甚至可以给一个完整的 Markdown 示例。如果还要严格可以在 SKILL.md 里写“报告必须包含以下字段缺少任一字段则视为不合格”。在 final 输出前让 Agent 用模板自检一遍。这个问题的根因通常是模板定义不清晰。写好模板之后输出稳定性会提升很多。6.4 几个容易被忽略的边界Skill 的知识截止时间。如果 Agent 内置模型的知识有截止时间新发布的 SDK 版本它可能不知道。这时你需要在参考资料里补最新文档。输入文件路径和权限。路径不对或者权限不足Agent 拿到日志也会解析失败。大小写和目录结构。部分工具对 Skill 文件名、目录名大小写敏感。并发问题。如果同时跑多个测试任务Agent 可能混淆日志。建议一次只分析一个任务。6.5 如果排查后仍然不理想如果以上都排查完还是不理想可以换个思路不追求 Agent“一步到位”而是把它拆成更小的子任务。让 Skill 只负责“用例生成”或“报告生成”其他环节用你熟悉的工具完成。这不是退步反而更容易稳定落地。7. 从能用到好用把 Skill 变成长期工作搭子的思路90 分钟跑通最小闭环只是起点。真正让 Skill 发挥价值是要持续迭代。7.1 把反复手工操作沉淀成 Skill 规则如果你发现自己连续几次都在给 Agent 同样的补充说明比如“记得加测试结论”“记得把日志路径贴出来”那就可以把这些话写进 SKILL.md。每一次补充都是在帮“工作搭子”变聪明。7.2 为不同测试阶段建多个 SkillAPP 测试不只是冒烟测试还包括接口测试、回归测试、兼容性测试、性能测试。一个 Skill 不可能覆盖全部。更好的做法是分多个 Skillapp-smoke-test-skill冒烟测试app-api-test-skill接口测试app-issue-analysis-skill缺陷日志分析app-test-report-skill报告生成每个 Skill 只关注一件事分工越清晰Agent 的表现越稳定。这和你在团队里让一个人只负责一个模块是同一个道理。7.3 Skill 与 MCP、测试框架的协作前面讲了 Skill 和 MCP 的区别。实际应用中它们可以配合。一个可参考的组合是用 MCP 把 Agent 接到内部缺陷系统用 Skill 规定“收到缺陷后如何分析、如何填写缺陷单”再用测试框架执行脚本最后把结构化的执行结果交给 Agent 生成报告。这套组合搭建起来需要一定工作量但一旦跑通日常版本迭代中的测试启动、用例生成、缺陷初步分析、报告输出大部分重复劳动都可以交给 Agent 完成。7.4 对 Skill 的能力边界要有清醒认知最后说一个必须接受的现实Skill 解决的是“流程稳定性”和“输出一致性”不能替代业务判断和探索性测试。你在一个关键版本上线前不能只依赖 Agent 生成的用例和报告下结论。用例覆盖是否完整、异常路径是否考虑到、业务逻辑变更是否影响旧用例这些仍然需要测试人员来做判断。把 Skill 当工作搭子而不是当最终决策人是最合适的定位。7.5 下一步可以往哪个方向延伸如果你已经跑通了 APP 测试的 Skill下一步可以做三件事沉淀一套项目级的测试数据模板包括用例模板、缺陷模板、报告模板。把日常代码变更和测试范围关联起来让 Skill 自动判断改动影响面。针对自己项目里最容易出问题的模块写一个专门的深度测试 Skill。这一步一步做下来Agent 对你项目的熟悉程度会越来越高最终达到“你给出需求它按规范产出你来确认质量”的状态。到那个时候你会感觉到 AIAgent 不再只是一个聊天窗口而是一个真正能承接固定工作的搭子。 AI Agent Skill实战：90分钟搞定APP测试工作流
这 90 分钟的关键不是把 Agent 的所有功能都学一遍而是先把“Skill”这个机制用起来并且直接落在 APP 测试这一个具体场景里。Skill 在 AI Agent 里的作用和“岗位说明书”很像你告诉它怎么理解任务、按什么顺序执行、输出什么格式。APP 测试恰恰是特别适合做这种固化的场景因为测试的流程、判断标准、报告格式都相对稳定。这篇文章我按自己实际跑通的方式拆开讲适合 QA、移动端开发、测试开发以及想给 AI Agent 加固定工作流的同学看。先不讨论各种概念直接说怎么在 90 分钟内把一个能干活的工作搭子调出来。1. 先搞清楚 Skill 到底是什么和 Prompt、MCP 有什么区别很多人在热词里看到 Skill、Agent、MCP 连在一起出现容易混淆。我先用最直接的方式区分一下。1.1 Skill 的本质一段能被 Agent 稳定读取和执行的“经验包”你可以把 Skill 理解成一个文件夹里面有一个 SKILL.md 文件再加上一些辅助文件。SKILL.md 用 Markdown 格式写内容是这个技能的名字、适用场景、执行步骤、输入要求、输出格式、注意事项。为什么要单独做一个 Skill而不是每次在对话框里写一大段提示词因为提示词是一次性的。你每次都要重新描述需求Agent 每次理解的侧重点还不一样。Skill 是把这些描述固化下来放到指定目录Agent 读到之后就知道遇到这类任务按固定流程走。比如你告诉它“这是 APP 冒烟测试流程先分析需求再生成用例再写脚本最后输出报告”。如果只是对话里说一次下次换个会话它可能就忘了。写成 Skill 之后每次使用都会按这个路径执行输出格式也保持一致。1.2 Skill 与 Prompt、MCP 的核心差异这里直接把对比写清楚因为这是理解 Skill 最关键的入口。对比项PromptSkillMCP形态一次性对话文本目录 Markdown 文件 辅助资源标准化的服务接口解决的问题让 Agent 理解这一次任务让 Agent 按固定步骤完成一类任务让 Agent 与外部系统交换数据和能力复用性较低每次要重新写高可反复加载高可多工具共用类比你临时交代一件事岗位操作手册外部插件或数据管道这段话很重要Skill 管的是“怎么做”MCP 管的是“能做什么”。如果你要给 Agent 接上内部缺陷管理系统那可能用到 MCP。如果你想让它每次都按同样的测试规范输出用例和报告那是 Skill 的活。两者不冲突甚至可以配合使用。1.3 为什么 APP 测试特别适合先用 Skill 做落地场景APP 测试有四个特点导致它特别适合固化到 Skill 里。第一流程固定。无论是需求理解、用例设计、脚本生成还是结果分析测试工作都有固定套路。第二输出格式稳定。测试用例、缺陷报告、测试总结都有行业默认模板。第三重复度高。每个版本都要做冒烟、回归、兼容性。第四日志和报错信息是结构化的。Agent 分析崩溃堆栈、接口返回、性能数据天然比写探索性文案更稳定。我用一个实际项目验证过把一套“登录注册模块冒烟测试”流程固化到 Skill 里Agent 生成的用例在覆盖度和格式上比直接对话给出的结果更稳定。并不是说它的智能程度变高了而是它不会漏掉那些你写在手册里的必要步骤。2. 动手前的准备环境、模型和测试场景三个都要想清楚90 分钟看着短但如果环境没准备好光折腾安装就要花掉一半时间。我建议把准备工作拆成三块。2.1 需要准备哪些基础条件一个支持 Skill 功能的 AI 编程助手或 Agent 工具。目前在 Claude Code、Codex CLI、OpenCode 这类工具中Skill 已经是比较常见的扩展方式。不同工具的目录规则略有差异但核心都是一样把 Skill 文件夹放到指定位置。一个能跑的本地开发环境。APP 测试涉及解析代码、读日志、生成脚本至少要有 Python 或 Node.js 环境并且能执行命令行。一个最小测试对象。不建议一上来就拿完整商业 App 做实验我建议先选一个简单 APP或者一个页面模块比如登录页、注册页、设置页。测试相关的账密或测试包。有些操作需要测试包、测试账号或者真机设备提前确认这些是否可用。从热词里的“uniapp ios app 打测试包全流程”来看很多人关心的其实是拿到一个 iOS 测试包之后怎么开始测试。这里有一点要提醒如果测试包还没打包好Skill 也只能帮你写测试计划和脚本不能替代打包过程。先把测试包准备好再让 Agent 介入手头工作效率会高很多。注意不一定要 GPU不一定要高配服务器。APP 测试 Skill 的核心是流程和上下文不是模型推理能力。大部分场景下一个能跑 Agent 的普通开发机就够了。2.2 把 APP 测试场景拆成 Agent 能理解的任务拿到一个 App 测试需求人脑会先做几个判断这是什么模块影响范围有多大重点测什么哪些是冒烟必测哪些是回归可以后置。Agent 默认不会自动做这些判断除非你在 Skill 里写清楚。我建议把 APP 测试拆成五个阶段需求理解读需求描述、看页面路径、列出测试点和风险点。用例设计按优先级输出测试用例包含前置条件、步骤、预期结果。脚本生成生成可直接执行的测试脚本骨架或给出执行命令。结果分析读取测试日志、崩溃信息、接口返回定位问题。报告输出形成一份结构清晰的测试报告。Skill 就是把这五个阶段变成 Agent 的执行步骤。它看到任务后会按这个顺序走而不是东问一句西答一句。2.3 选择一个最小测试任务第一次调试时不要让 Agent 处理“整个 App 全量回归”这类大任务。给它一个非常小而具体的任务效果会好很多。我用的是登录页面冒烟测试。这个模块业务逻辑清晰输入项固定预期结果容易判断日志也容易拿到。哪怕你没有登录模块只测一个“设置页的深色模式开关”也完全可以。最小任务的好处是验证周期短Agent 出错时你能快速判断是 Skill 的问题还是环境的问题。2.4 90 分钟怎么分配我给你一个比较稳的时间分配但实际可以按自己节奏调整。时间段任务产出0-15 分钟环境检查、场景选择、确认测试对象环境通畅场景明确15-45 分钟编写第一个 Skill 文件SKILL.md 可被 Agent 加载45-60 分钟验证加载、跑最小任务输出格式稳定60-80 分钟跑一个完整测试闭环需求到报告全流程通过80-90 分钟记录问题、调整参数、补充边界复盘清单这套分配方式和很多人“先研究功能菜单再慢慢试”的做法不一样核心是逼自己先用最小闭环跑通。如果你在某个环节卡住超过 15 分钟建议先跳过用备用方案补上否则整体节奏会乱。3. 编写第一个 APP 测试 Skill从零到能用的关键步骤这部分是整个 90 分钟的核心。Skill 写得太虚Agent 没法执行写得太死遇到新场景又不会变通。下面给出一个相对通用且稳的写法。3.1 Skill 文件基本结构一般一个可用的 Skill 至少包括app-ui-test-skill/ ├── SKILL.md └── references/ ├── test-case-template.md └── bug-report-template.mdSKILL.md 是入口文件必须存在。references 目录放模板和辅助资料不是必须但建议加上。没有辅助模板时Agent 生成出来的报告格式会比较随意有了模板输出质量会稳定很多。3.2 SKILL.md 核心内容怎么写SKILL.md 不需要很复杂但关键的几个部分不能缺技能名称和触发条件。适用场景。明确说明它处理什么任务不处理什么任务。输入要求。需要用户提供哪些信息比如页面路径、需求描述、测试包地址、模拟器或真机信息。执行步骤。分阶段说明 Agent 应该做什么。输出要求。规定用例表格、报告模板、缺陷单的格式。注意事项。写边界和常见坑。这里给一个简化版的 SKILL.md 示例只保留了最基本结构实际使用中可以按项目继续细化。# App UI 冒烟测试 Skill ## 触发条件 用户要求对某个 APP 页面或核心流程执行冒烟测试时使用。 ## 输入要求 用户需要提供 - APP 名称和版本 - 被测页面路径或功能入口 - 测试设备信息真机/模拟器系统版本 - 测试包是否可用 ## 执行步骤 1. 需求理解将用户输入整理成功能列表。 2. 用例设计编写冒烟测试用例包含前置条件、步骤、预期结果、优先级。 3. 脚本生成根据用例生成测试脚本或可执行命令。 4. 结果分析如果用户提供日志、截图或崩溃信息先定位问题再给出结论。 5. 输出报告按照 references/test-case-template.md 生成报告。 ## 输出要求 - 所有用例必须给出唯一的用例编号。 - 预期结果必须可判断不允许写“正常”“没问题”。 - 报告必须包含结论、风险点、遗留问题三部分。 ## 注意事项 - 只做 UI 冒烟测试不做性能压测。 - 如果没有真机日志必须在报告中标注“未验证”。 - 如果需求描述不清楚先向用户提问不要自行假设。写的时候有两点容易踩坑。第一执行步骤不要写得太笼统。如果只写“对 APP 进行测试”Agent 不知道从哪开始。写成“先整理功能列表再设计用例再生成脚本”它就知道顺序了。第二输出要求要非常具体。比如“预期结果必须可判断”这会让 Agent 避免生成一堆无法验证的废话。3.3 编写测试步骤和验收标准时要注意什么在 Skill 里写测试步骤的时候我建议用“输入-操作-预期”三列式而不是大段描述。原因有两个一是 Agent 读取结构化内容更准确二是后续生成测试脚本时结构化的步骤能直接映射到代码。比如登录页冒烟测试可以这样写用例编号操作步骤预期结果优先级TC-LOGIN-001输入正确账号密码点击登录按钮页面跳转到首页本地存储登录态P0TC-LOGIN-002输入错误密码点击登录按钮页面提示密码错误不跳转P0TC-LOGIN-003点击“忘记密码”链接跳转到找回密码页面P1这种表格放在 SKILL.md 的参考模板里也行放在 references 目录的模板文件里也行。重点是让 Agent 知道最后生成的用例要按照这个结构去做。3.4 一个最小 Skill 的实际编写顺序如果你是第一次写我建议按下面三步走先写触发条件和输入要求大约 10 分钟。再写执行步骤和输出要求大约 15 分钟。最后放一个用例模板文件大约 10 分钟。不要一开始就把所有测试场景都写进去。先写一个“登录页冒烟测试”适用的最小 Skill跑通之后再扩。4. 安装和调用不同 Agent 工具的差异与验证方法很多人写完 SKILL.md结果 Agent 完全不认大概率不是内容问题而是“这个工具认不认这个目录”的问题。4.1 安装方式不同工具对 Skill 的支持方式并不完全一致。有的要求放在项目目录下的.claude/skills有的要求放在全局配置目录下的skills文件夹还有的通过配置中心加载。具体细节要以你正在使用工具的文档为准。这里给一个通用判断顺序先查工具是否支持 Skill。可以直接在对话中问 Agent或者看工具的说明文件。查看 Skill 的目录规则。一般工具文档都会写清楚。按规则放置 SKILL.md。重新加载或重开一个会话。如果你用的是 Codex CLI 这类带命令行的工具通常还需要确认命令是否已经安装完整。命令装了一半Skill 加载也会失败。4.2 如何验证 Skill 是否被加载装完之后不要直接跑大任务先做两个小验证。第一个问 Agent 能不能列出可用的 Skills。有些工具是/skills命令有些工具是直接对话询问。只要它能把 Skill 名称列出来说明加载成功。第二个让它用一段非常简单的输入跑一次。比如你给一个登录页需求描述它如果按 SKILL.md 里定义的步骤执行说明成功。如果回答完全无视 Skill 的结构就要检查配置或重新加载。注意部分工具修改 Skill 文件后需要重启会话才会重新加载。不是文件改错了是缓存问题。4.3 第一次调教让 Agent 按你的习惯说话和输出加载成功只代表 Agent 能读到 Skill不代表它会自动符合你的习惯。第一次使用时建议在对话里加上一些约束。比如“使用 APP 冒烟测试 Skill严格按执行步骤来。”“没有真机日志时标注未验证。”“报告只输出 Markdown 格式不要输出解释性废话。”这些约束不是每次都要重新写而是在 SKILL.md 没覆盖到的地方做补充。跑几次之后把稳定的约束再补进 SKILL.md 里后续就不用反复说了。5. 实战90 分钟内跑通一个 APP 测试闭环这是最有价值的部分。Skill 只是手段跑通测试闭环才是目的。我以“登录模块冒烟测试”为例子完整拆解一遍。5.1 第一阶段需求理解和用例生成第 0-15 分钟先让 Agent 处理需求。给出的输入可以是这样输入登录模块冒烟测试 APP演示App 2.3.0 功能入口登录页 测试设备Android 模拟器 API 34 测试账号请使用默认测试账号 需求描述验证登录主流程是否可用包括正确登录、错误密码、验证码、退出登录Agent 收到这个输入后按 Skill 执行需求理解。它应该先输出一份功能列表再输出测试用例表。这一步能看出 SKILL.md 有没有写清楚。如果它跳过了需求理解直接开始写代码说明 Skill 里执行步骤部分还不够具体。5.2 第二阶段生成测试脚本第 15-35 分钟让 Agent 生成可执行脚本。注意一个问题Agent 本身不能直接点击手机屏幕它靠的是生成测试脚本或者给你命令。这意味着你本地要有对应的测试框架。对于 Android常见做法是 Appium 或自研的 UI 自动化框架。对于 iOS可能是 XCUITest 或者带测试框架的脚本。Skill 里不用假设具体框架而是让 Agent 在生成脚本前先问清楚你的技术栈。比较稳的写法是在 Skill 里加一句“如果用户没有指定测试框架先询问用户再生成代码。”这样就不会默认生成一个跑不起来的框架。5.3 第三阶段执行结果和缺陷分析第 35-55 分钟是发现问题最多的时候。执行测试后把日志、截图、崩溃栈喂给 Agent。Skill 里定义的结果分析步骤会要求它先定位问题再给结论。一个典型的输出是结论登录按钮点击后无响应页面未跳转。 问题定位可能是登录接口请求未触发或前端路由阻塞。 建议操作 1. 检查登录按钮绑定事件是否生效。 2. 检查接口请求日志中是否有 login 请求。 3. 检查登录返回后路由跳转逻辑。 风险点无真机日志结果基于模拟器日志。这里有个容易误判的点Agent 说出的“建议操作”不一定准确。它是在日志分析基础上推断的不是你亲眼确认的结论。报告里要把“已确认”和“推测”分开标注。5.4 第四阶段输出测试报告第 55-80 分钟让 Agent 按模板生成报告。报告里应该有这些部分测试结论通过、不通过、风险通过。测试范围哪些功能覆盖了哪些没覆盖。用例统计总用例数、通过数、失败数、阻塞数。缺陷列表缺陷描述、优先级、复现步骤、截图或日志。遗留问题哪些点当前无法验证原因是什么。报告建议生成 Markdown 格式方便直接转成文档或者上传到内部平台。如果你想要 HTML 格式在 Skill 的输出要求里补充一句就行。5.5 一个完整的示例对话流为了更直观我把一套最小对话流列出来便于第一次实践时照着走。你使用 APP UI 冒烟测试 Skill执行登录模块冒烟测试。需求描述验证登录主流程包括正确登录、错误密码、验证码、退出登录。测试设备Android 模拟器。 Agent已加载 Skill开始执行。先整理功能列表再输出测试用例。 Agent输出需求理解 用例表格 你使用 Appium 生成测试脚本只生成核心用例不需要处理错误截图。 Agent输出脚本骨架和命令说明 你这是执行后的日志与截图。 Agent按 Skill 先定位问题再给结论 你生成最终测试报告按照模板。 Agent输出完整报告这个流程不算复杂但已经覆盖了测试的完整链路。跑完这一步你就有了一个可以重复使用的工作搭子。6. 常见问题排查链路Skill 不生效、Agent 不听指令怎么办实际使用中你大概率会碰到下面几类问题。这里给出一个优先排查顺序不要一上来就怀疑模型能力。6.1 Skill 被加载但没有按 Skill 执行现象Agent 能列出 Skill但回答时完全无视 SKILL.md 的结构。比如没有先做需求理解直接输出用例或者用例格式和模板完全不一样。优先排查顺序确认当前会话是否加载了最新版 SKILL.md。修改文件后是否重启会话。确认 SKILL.md 里的执行步骤是否足够明确。如果是“进行测试”这种模糊描述它可能就直接自由发挥了。确认你当前使用的模型是否支持多步骤指令。有些轻量模型对复杂指令的遵循能力偏弱。在对话里强调“严格按照 Skill 定义”看是否有改善。如果还是不行可以试着把 SKILL.md 写得“更强制”。比如“第一步必须输出功能列表第二步必须基于功能列表生成用例”。少用“应该”“可以”多用“必须”。6.2 Agent 生成的测试脚本跑不起来现象代码看起来完整但执行时报错比如依赖缺失、选择器错误、WebDriver 版本不兼容。这通常不是 Skill 文件的问题而是当前场景下的技术栈问题。排查顺序先看报错信息。大部分是依赖版本或选择器错误。确认 Agent 生成脚本前有没有问清楚你的技术栈。如果没问你要在输入里主动补上。把报错信息重新丢给 Agent让它修正。它会基于错误信息逐步定位。如果连续报错减少生成范围让它先生成单个用例的脚本跑通后再生成全部。这里要特别强调Agent 生成的脚本本质是“基于描述的代码”它没有真正在设备上点击过所以第一次执行失败非常正常。重点是看它能否根据日志和报错信息修正。6.3 输出报告格式不符合预期现象报告没有按模板输出缺少测试结论或者把推测写成确认结果。排查方式在 SKILL.md 的输出要求里给出一个非常具体的模板甚至可以给一个完整的 Markdown 示例。如果还要严格可以在 SKILL.md 里写“报告必须包含以下字段缺少任一字段则视为不合格”。在 final 输出前让 Agent 用模板自检一遍。这个问题的根因通常是模板定义不清晰。写好模板之后输出稳定性会提升很多。6.4 几个容易被忽略的边界Skill 的知识截止时间。如果 Agent 内置模型的知识有截止时间新发布的 SDK 版本它可能不知道。这时你需要在参考资料里补最新文档。输入文件路径和权限。路径不对或者权限不足Agent 拿到日志也会解析失败。大小写和目录结构。部分工具对 Skill 文件名、目录名大小写敏感。并发问题。如果同时跑多个测试任务Agent 可能混淆日志。建议一次只分析一个任务。6.5 如果排查后仍然不理想如果以上都排查完还是不理想可以换个思路不追求 Agent“一步到位”而是把它拆成更小的子任务。让 Skill 只负责“用例生成”或“报告生成”其他环节用你熟悉的工具完成。这不是退步反而更容易稳定落地。7. 从能用到好用把 Skill 变成长期工作搭子的思路90 分钟跑通最小闭环只是起点。真正让 Skill 发挥价值是要持续迭代。7.1 把反复手工操作沉淀成 Skill 规则如果你发现自己连续几次都在给 Agent 同样的补充说明比如“记得加测试结论”“记得把日志路径贴出来”那就可以把这些话写进 SKILL.md。每一次补充都是在帮“工作搭子”变聪明。7.2 为不同测试阶段建多个 SkillAPP 测试不只是冒烟测试还包括接口测试、回归测试、兼容性测试、性能测试。一个 Skill 不可能覆盖全部。更好的做法是分多个 Skillapp-smoke-test-skill冒烟测试app-api-test-skill接口测试app-issue-analysis-skill缺陷日志分析app-test-report-skill报告生成每个 Skill 只关注一件事分工越清晰Agent 的表现越稳定。这和你在团队里让一个人只负责一个模块是同一个道理。7.3 Skill 与 MCP、测试框架的协作前面讲了 Skill 和 MCP 的区别。实际应用中它们可以配合。一个可参考的组合是用 MCP 把 Agent 接到内部缺陷系统用 Skill 规定“收到缺陷后如何分析、如何填写缺陷单”再用测试框架执行脚本最后把结构化的执行结果交给 Agent 生成报告。这套组合搭建起来需要一定工作量但一旦跑通日常版本迭代中的测试启动、用例生成、缺陷初步分析、报告输出大部分重复劳动都可以交给 Agent 完成。7.4 对 Skill 的能力边界要有清醒认知最后说一个必须接受的现实Skill 解决的是“流程稳定性”和“输出一致性”不能替代业务判断和探索性测试。你在一个关键版本上线前不能只依赖 Agent 生成的用例和报告下结论。用例覆盖是否完整、异常路径是否考虑到、业务逻辑变更是否影响旧用例这些仍然需要测试人员来做判断。把 Skill 当工作搭子而不是当最终决策人是最合适的定位。7.5 下一步可以往哪个方向延伸如果你已经跑通了 APP 测试的 Skill下一步可以做三件事沉淀一套项目级的测试数据模板包括用例模板、缺陷模板、报告模板。把日常代码变更和测试范围关联起来让 Skill 自动判断改动影响面。针对自己项目里最容易出问题的模块写一个专门的深度测试 Skill。这一步一步做下来Agent 对你项目的熟悉程度会越来越高最终达到“你给出需求它按规范产出你来确认质量”的状态。到那个时候你会感觉到 AIAgent 不再只是一个聊天窗口而是一个真正能承接固定工作的搭子。