90分钟Skill玩转APP测试调教AIAgent工作搭子最近在推进移动端测试提效时我发现单纯让 AIGC 帮忙写脚本仍然不够“顺手”每次都要重新描述项目背景、测试环境、用例规则Agent 给出的建议也经常前后不一致。后来接触了 Skill 机制把测试方法、命令脚本、业务规则封装成可复用的“技能包”AIAgent 才真正像一个随叫随到、且知道项目上下文的工作搭子。这篇文章会围绕“用 Skill 调教 AIAgent 做 APP 测试”这条主线完整梳理 Skill 是什么、如何设计一个 APP 测试 Skill、怎么在 90 分钟内完成从搭建到实战的闭环。内容偏向实操每一步都有对应代码和配置适合已经了解基础测试概念、想用 AI 工具把测试效率再提一档的读者。1. 背景与核心概念1.1 为什么测试需要 AIAgent传统 APP 测试流程中重复性工作量非常大。以冒烟测试为例每次发版前都要手动或半自动执行几十条核心用例确认登录、首页加载、支付流程、消息推送这些主链路没有回归问题。即使有自动化框架维护脚本、处理环境差异、筛选有效失败信息也都是体力活。AIAgent 的价值在于“理解需求”和“执行动作”可以拆开。Agent 本身有对话能力能理解测试人员用自然语言描述的场景再配合工具调用能力它可以直接执行 adb 命令、跑测试脚本、解析日志。这样测试人员只需要描述“帮我验证一下登录流程是否正常”Agent 就能自动完成环境检查、脚本执行、结果汇总。不过AIAgent 默认是“通用助手”它不了解你的项目结构、测试设备、账号密码体系、历史常见缺陷。如果每次都把上下文塞进对话里又累又容易出错。这就是 Skill 要解决的问题。1.2 Skill 是什么Skill 是 AIAgent 的一种“能力扩展包”。简单理解它把一组提示词、脚本、规则、参考文档打包在一起放在约定的目录结构里。Agent 在运行时会根据用户请求自动匹配对应的 Skill加载其中的说明和工具从而以更专业的方式完成任务。一个典型的 Skill 包含三部分描述文件告诉 Agent 这个 Skill 是干什么的、在什么场景下使用。规则与提示词约束 Agent 的行为方式比如“必须使用项目内已配置的设备”“执行完成后输出标准格式报告”。脚本或工具实际执行任务的命令、Python 脚本、配置文件等。这种机制让 Agent 从“什么都能聊”变成“在特定领域里真正会干活”。1.3 Skill 与普通提示词的区别有人会问那我直接把规则写进提示词不就行了为什么非要封装成 Skill区别在于复用性和隔离性。普通提示词每开一个新会话就要重新粘贴而且容易在长对话中丢失重点。Skill 是文件级别的封装一次创建永久复用多个项目可以各自维护自己的测试 Skill互不干扰。还有一个重要区别Skill 可以与脚本结合。普通提示词只能指导 Agent“怎么说”但 Skill 可以让 Agent“怎么做”。比如 Skill 内包含一个check_device.py脚本Agent 在测试前会主动运行它来检查设备状态这是单纯提示词做不到的。1.4 Skill 的常见应用场景Skill 在 APP 测试中能覆盖不少场景冒烟测试封装核心用例集每次发版前自动执行。稳定性测试集成交互测试脚本自动发现崩溃和 ANR。接口测试定义公共请求头、鉴权逻辑、断言规则。日志分析Agent 自动拉取 logcat筛选关键字并归类问题。竞品对照测试定义同一套操作路径在不同 APP 上执行并对比差异。这些场景的共同点是流程稳定、标准明确、重复频率高。Skill 最适合处理这类任务。2. 环境准备与工具选择2.1 硬件与操作系统本文示例以 Windows / macOS 双平台兼容为主涉及到的命令均为跨平台写法或同时给出两种写法。操作系统Windows 10/11macOS 12内存建议 8GB 以上硬盘预留 10GB 以上空间2.2 核心软件版本版本需要根据你的项目实际情况调整本文示例以常见环境为例重点演示配置思路。工具作用建议版本Python运行测试脚本3.9 及以上JDKAndroid 构建与工具链11 或 17Android SDKadb 设备调试最新稳定版Appium移动端自动化框架2.xpytest用例执行与报告7.x 及以上Node.jsAppium 服务端运行依赖18 及以上2.3 AIAgent 工具选择当前主流的 AIAgent 工具大多支持 Skill 机制例如 Claude Code、Codex、自建 Agent 框架等。不同工具对 Skill 的目录结构和加载方式略有差异但核心逻辑一致通过 Markdown 文件描述功能通过脚本文件提供能力。本文示例采用通用目录结构尽量不绑定某个特定平台。如果你使用的 Agent 工具对 Skill 目录有特殊要求按官方文档调整即可。2.4 示例项目结构为了便于理解和实验建议先创建一个用于练习的目录结构app-test-skill/ ├── skills/ │ └── app-smoke-test/ │ ├── SKILL.md │ ├── rules.md │ ├── scripts/ │ │ ├── check_env.py │ │ ├── run_smoke_test.py │ │ └── parse_log.py │ └── assets/ │ └── test_cases.json ├── reports/ └── logs/后续所有代码都会围绕这个结构展开。3. 理解 Agent Skill 机制3.1 Skill 的加载逻辑Agent 在接收到用户请求后会经历一个“任务规划”的过程。如果当前工具支持 Skill 机制它会先分析用户意图再检索可用的 Skill 列表匹配到合适的 Skill 后读取其描述文件和规则然后调用相关脚本执行任务。这个过程可以类比为你给实习生一份《APP 冒烟测试操作手册》手册里不仅写了操作步骤还附带了可以直接使用的脚本工具。实习生拿到手册后按流程执行遇到问题再根据手册里的排查指南处理。3.2 SKILL.md 的核心作用每个 Skill 目录下都有一个SKILL.md文件它是 Agent 理解和调用 Skill 的入口。这个文件的质量直接决定 Skill 好不好用。一个合格的SKILL.md至少要包含Skill 名称与简介。适用场景。使用步骤。输入参数说明。输出格式说明。注意事项。下面是一个 SKILL.md 的示例框架--- name: app-smoke-test description: APP冒烟测试专用Skill执行核心用例集并生成测试报告 --- # APP 冒烟测试 ## 适用场景 - 版本发布前的核心功能验证 - 每日构建后的快速回归 ## 使用步骤 1. 检查设备连接状态 2. 加载测试用例配置 3. 按优先级执行用例 4. 收集日志并生成报告 ## 输入参数 | 参数 | 必填 | 说明 | | --- | --- | --- | | device_id | 否 | 设备ID不填则使用默认设备 | | case_level | 否 | 用例级别如 P0/P1/P2不填则执行全部 | ## 输出格式 报告包含通过率、失败用例列表、崩溃信息、执行耗时。Agent 读取这个文件后就知道什么时候该使用这个 Skill以及如何使用。3.3 规则文件与行为约束rules.md用于约束 Agent 的行为边界。在 APP 测试场景中规则文件尤其重要因为测试行为涉及真实设备和业务数据一旦操作不规范可能产生脏数据或误操作。常见的规则包括禁止在未授权情况下修改线上环境数据。执行删除、重置类操作前必须二次确认。测试账号只能使用指定账号池。测试完成后必须恢复设备到初始状态。所有测试过程需要记录日志。# 使用规则 ## 数据安全 - 禁止使用真实用户手机号注册新账号 - 禁止向线上环境写入测试订单 ## 操作安全 - 执行 adb uninstall 前必须确认包名正确 - 清理应用数据时需先备份必要文件 ## 输出要求 - 每次测试结束后必须输出报告文件 - 失败用例必须附带日志片段这些规则的价值在于让 Agent 在“自由发挥”和“安全可控”之间找到平衡。3.4 Skill 与脚本的协作模式Skill 不只是一个文档包它可以携带可执行脚本这是它比普通提示词更强大的根本原因。脚本与 Agent 的协作方式通常有两种Agent 调用脚本Agent 根据 SKILL.md 中的步骤主动运行某个脚本然后读取脚本输出继续分析。脚本反馈数据脚本执行结果作为 Agent 的“观察”Agent 基于新观察决定下一步动作。这种“思考-行动-观察”循环是 Agent 自动化完成任务的基础。4. 90分钟实战搭建APP测试搭子下面进入核心环节。按照 90 分钟的时间分配建议拆成四个阶段0-15分钟 创建 Skill 目录与描述文件 15-40分钟 编写环境检查与用例执行脚本 40-70分钟 配置测试用例数据并跑通完整流程 70-90分钟 验证 Agent 自动调用与报告生成4.1 创建 Skill 目录结构打开终端执行以下命令mkdir -p app-test-skill/skills/app-smoke-test/scripts mkdir -p app-test-skill/skills/app-smoke-test/assets mkdir -p app-test-skill/reports mkdir -p app-test-skill/logs这个结构把“技能定义”和“产出物”做了分离。skills下面是可复用的能力包reports和logs是每次执行产生的过程信息和最终结果。4.2 编写 SKILL.md 描述文件创建app-test-skill/skills/app-smoke-test/SKILL.md--- name: app-smoke-test description: 用于APP核心功能冒烟测试自动检查设备环境、执行测试用例、输出测试报告。适合版本发布前验证或每日回归测试。 --- # APP 冒烟测试 Skill ## 功能概述 本 Skill 帮助测试人员对 Android APP 执行冒烟测试。它通过 adb 连接设备根据测试用例配置执行关键流程操作并生成 Markdown 格式的测试报告。 ## 使用步骤 1. 运行 check_env.py 检查设备连接与 APP 安装状态。 2. 读取 test_cases.json 获取用例列表。 3. 按优先级执行测试步骤记录通过/失败状态。 4. 执行完成后生成测试报告到 reports 目录。 ## 输入参数 | 参数 | 必填 | 默认值 | 说明 | | --- | --- | --- | --- | | package_name | 是 | 无 | 被测 APP 的包名 | | device_id | 否 | 自动选择 | 目标设备 ID | | app_activity | 否 | 无 | APP 主 Activity用于启动 | ## 输出说明 输出 reports/smoke_test_{timestamp}.md 报告文件包含 - 测试环境信息 - 用例执行汇总 - 失败用例详情 - 建议关注项 ## 注意事项 - 仅在已授权测试设备上执行 - 测试账号需使用专用测试账号池 - 不要修改真实业务数据这个文件是 Agent 的“操作手册”描述得越清晰Agent 的自主执行效果越好。4.3 编写环境检查脚本创建app-test-skill/skills/app-smoke-test/scripts/check_env.py#!/usr/bin/env python3 环境检查脚本检测 adb 设备连接状态、APP 安装状态、设备基本信息。 import subprocess import sys import re def run_cmd(cmd): 执行系统命令并返回输出。 result subprocess.run(cmd, shellTrue, capture_outputTrue, textTrue) return result.stdout.strip(), result.returncode def get_device_list(): 获取已连接的设备列表。 output, code run_cmd(adb devices) if code ! 0: print([ERROR] adb 命令执行失败请确认 Android SDK 已配置到 PATH。) sys.exit(1) devices [] for line in output.splitlines()[1:]: if line.strip() and device in line: device_id line.split()[0] devices.append(device_id) if not devices: print([ERROR] 未检测到已连接的 Android 设备或模拟器。) sys.exit(1) print(f[INFO] 检测到 {len(devices)} 台设备{, .join(devices)}) return devices def check_app_installed(device_id, package_name): 检查指定设备上是否安装了目标 APP。 output, code run_cmd(fadb -s {device_id} shell pm list packages {package_name}) if package_name in output: print(f[INFO] 设备 {device_id} 已安装 APP: {package_name}) return True else: print(f[WARN] 设备 {device_id} 未安装 APP: {package_name}) return False def get_device_model(device_id): 获取设备型号。 output, _ run_cmd(fadb -s {device_id} shell getprop ro.product.model) return output.strip() if __name__ __main__: if len(sys.argv) 2: print(用法python check_env.py package_name) sys.exit(1) package sys.argv[1] devices get_device_list() for device in devices: model get_device_model(device) print(f[INFO] 设备型号{model}) check_app_installed(device, package)这个脚本实现三层能力检测设备、读取设备型号、确认 APP 安装状态。Agent 调用后能快速判断“当前环境能不能跑测试”。运行方式python scripts/check_env.py com.example.app4.4 编写测试用例配置创建app-test-skill/skills/app-smoke-test/assets/test_cases.json{ cases: [ { id: SMOKE_001, priority: P0, name: APP冷启动, steps: [ 启动APP, 等待首页加载, 检查首页关键元素是否显示 ], expected: 首页在5秒内加载完成无白屏 }, { id: SMOKE_002, priority: P0, name: 登录流程, steps: [ 点击登录入口, 输入测试账号, 点击登录按钮, 等待跳转 ], expected: 登录成功并跳转到首页 }, { id: SMOKE_003, priority: P1, name: 核心页面切换, steps: [ 进入个人中心, 进入设置页, 返回首页 ], expected: 所有页面切换无崩溃无ANR } ] }这里的关键点是用例数据要和代码逻辑分离。以后新增用例只需要修改 JSON 文件不需要改动脚本。4.5 编写测试执行脚本下面编写核心执行脚本。为了演示清晰这里用 Python 模拟执行流程实际项目中可以替换为 Appium 或 UIAutomator2 等真实自动化框架。创建app-test-skill/skills/app-smoke-test/scripts/run_smoke_test.py#!/usr/bin/env python3 冒烟测试主执行脚本。 根据 test_cases.json 中的用例配置模拟执行测试步骤并生成报告。 import json import os import sys import time from datetime import datetime BASE_DIR os.path.dirname(os.path.dirname(os.path.abspath(__file__))) CASE_FILE os.path.join(BASE_DIR, assets, test_cases.json) REPORT_DIR os.path.join(BASE_DIR, .., .., reports) def load_cases(): 加载测试用例配置。 with open(CASE_FILE, r, encodingutf-8) as f: data json.load(f) return data[cases] def execute_case(case): 执行单条用例。 返回 (是否通过, 日志信息)。 真实项目中这里应调用 Appium 等自动化框架执行具体步骤。 case_id case[id] case_name case[name] print(f[执行] {case_id} - {case_name}) logs [] for step in case[steps]: # 模拟每一步耗时 time.sleep(0.5) log f - {step} print(log) logs.append(log) # 模拟随机失败演示失败用例输出效果 # 真实场景中通过自动化框架的断言结果判断 import random passed random.random() 0.3 if passed: print(f[通过] {case_id}) return True, \n.join(logs) else: print(f[失败] {case_id} - {case.get(expected, )}) return False, \n.join(logs) f\n [!] 期望结果{case.get(expected, )} def generate_report(results, total_time): 生成 Markdown 格式测试报告。 os.makedirs(REPORT_DIR, exist_okTrue) timestamp datetime.now().strftime(%Y%m%d_%H%M%S) report_file os.path.join(REPORT_DIR, fsmoke_test_{timestamp}.md) passed_count sum(1 for r in results if r[0]) failed_count len(results) - passed_count pass_rate passed_count / len(results) * 100 if results else 0 lines [ # APP 冒烟测试报告, , f- 执行时间{datetime.now().strftime(%Y-%m-%d %H:%M:%S)}, f- 用例总数{len(results)}, f- 通过用例{passed_count}, f- 失败用例{failed_count}, f- 通过率{pass_rate:.1f}%, f- 总耗时{total_time:.2f}s, , ## 执行详情, , | 用例ID | 用例名称 | 结果 | 备注 |, | --- | --- | --- | --- |, ] for case, (passed, log) in results: status ✅ 通过 if passed else ❌ 失败 lines.append(f| {case[id]} | {case[name]} | {status} | {log.splitlines()[-1] if not passed else -} |) lines.append() lines.append(## 失败用例详情) lines.append() for case, (passed, log) in results: if not passed: lines.append(f### {case[id]} - {case[name]}) lines.append() lines.append(text) lines.append(log) lines.append() lines.append() with open(report_file, w, encodingutf-8) as f: f.write(\n.join(lines)) print(f[完成] 报告已生成{report_file}) return report_file def main(): print( APP 冒烟测试开始 ) start_time time.time() cases load_cases() print(f共加载 {len(cases)} 条用例\n) results [] for case in cases: passed, log execute_case(case) results.append((case, (passed, log))) print() total_time time.time() - start_time report_file generate_report(results, total_time) print(f\n 测试结束总耗时 {total_time:.2f}s ) print(f报告路径{report_file}) if __name__ __main__: main()这个脚本演示了完整执行逻辑加载用例、逐条执行、生成报告。模拟失败逻辑仅用于演示报告效果真实场景中应基于实际断言结果判断。运行方式python scripts/run_smoke_test.py预期输出 APP 冒烟测试开始 共加载 3 条用例 [执行] SMOKE_001 - APP冷启动 - 启动APP - 等待首页加载 - 检查首页关键元素是否显示 [通过] SMOKE_001 [执行] SMOKE_002 - 登录流程 - 点击登录入口 - 输入测试账号 - 点击登录按钮 - 等待跳转 [失败] SMOKE_002 - 登录成功并跳转到首页 [执行] SMOKE_003 - 核心页面切换 - 进入个人中心 - 进入设置页 - 返回首页 [通过] SMOKE_003 测试结束总耗时 4.02s 报告路径reports/smoke_test_20250101_153000.md4.6 编写日志解析脚本APP 测试中日志分析是耗时的大头。添加一个日志解析脚本可以让 Agent 自动从 logcat 中提取关键信息。创建app-test-skill/skills/app-smoke-test/scripts/parse_log.py#!/usr/bin/env python3 日志解析脚本从 logcat 中提取崩溃、ANR、异常关键字。 import subprocess import sys import re KEYWORDS { FATAL EXCEPTION: 崩溃, ANR in: ANR, AndroidRuntime: 运行时异常, OutOfMemoryError: 内存溢出, NullPointerException: 空指针异常, } def get_logcat(device_idNone, lines500): 获取最近 logcat 日志。 cmd adb logcat -d -t str(lines) if device_id: cmd fadb -s {device_id} logcat -d -t {lines} output, _ subprocess.run(cmd, shellTrue, capture_outputTrue, textTrue).stdout, None return output def parse_logs(log_content): 解析日志返回问题列表。 issues [] for line in log_content.splitlines(): for keyword, issue_type in KEYWORDS.items(): if keyword in line: issues.append({ type: issue_type, keyword: keyword, content: line.strip() }) break return issues if __name__ __main__: device sys.argv[1] if len(sys.argv) 1 else None log_lines int(sys.argv[2]) if len(sys.argv) 2 else 500 print(f获取设备 {device or 默认设备} 最近 {log_lines} 行日志...) log_content get_logcat(device, log_lines) issues parse_logs(log_content) if not issues: print(未发现关键异常。) else: print(f发现 {len(issues)} 个问题\n) for issue in issues[:20]: print(f[{issue[type]}] {issue[content][:150]})4.7 让 Agent 调用 Skill以上文件准备好后需要教会 Agent 在什么场景下使用这个 Skill。在支持 Skill 的 Agent 工具中你只需要告诉它类似这样的话请使用 app-smoke-test Skill 对 com.example.app 执行冒烟测试。Agent 会主动读取SKILL.md按步骤执行调用check_env.py检查环境。读取test_cases.json。执行run_smoke_test.py完成测试。解析报告并输出摘要。如果使用 Claude Code 等支持 Skill 目录的工具需要把整个skills/app-smoke-test目录放入工具的 Skill 搜索路径。不同工具对路径的要求不同请以官方文档为准。4.8 完整执行演示下面模拟一次 Agent 完整交互过程用户请用 app-smoke-test 对 com.example.app 做冒烟测试 Agent: [1/4] 正在检查设备环境... 运行: python check_env.py com.example.app 输出: 检测到 1 台设备 设备型号: Pixel 7 设备已安装 APP: com.example.app [2/4] 正在加载测试用例... 共加载 3 条用例 [3/4] 正在执行测试... 执行结果 SMOKE_001 通过 SMOKE_002 失败 SMOKE_003 通过 [4/4] 正在生成报告... 报告已生成: reports/smoke_test_20250101_153000.md 结论3条用例中通过2条失败1条。 失败用例为 SMOKE_002 登录流程期望结果为“登录成功并跳转到首页”。 建议优先排查登录接口返回状态和登录后跳转逻辑。这个交互过程中Agent 起了“项目助理”的作用。它负责拆解任务、按步骤调用工具、汇总结果并给出建议而不是自己空想测试结果。5. 常见问题与排查思路5.1 Skill 未被 Agent 自动识别问题现象常见原因解决思路Agent 不调用 Skill而是直接泛泛回答Skill 目录位置不在 Agent 搜索路径中检查工具配置将 skill 目录加入搜索范围Agent 报错“找不到 Skill”SKILL.md 格式不正确确保文件头包含name和description字段Agent 能识别 Skill 但执行方式不对描述文件中的使用步骤不够详细细化 SKILL.md 中的步骤说明排查顺序先确认 Skill 文件路径正确 → 确认名称与描述与请求匹配 → 确认脚本权限可执行。5.2 adb 命令无法执行问题现象常见原因解决思路adb: command not foundAndroid SDK 未加入 PATH在环境变量中添加 platform-tools 路径device unauthorized设备未授权 USB 调试在设备上确认授权弹窗no devices found驱动问题或未开启 USB 调试检查数据线、开启开发者模式中的 USB 调试5.3 脚本执行报编码错误Windows 下运行 Python 脚本时如果项目路径包含中文可能出现 UnicodeDecodeError。解决方案chcp 65001或在执行 Python 时指定编码python -X utf8 scripts/run_smoke_test.py5.4 测试用例数据修改后不生效Agent 或脚本读取的是test_cases.json文件如果你修改后未保存或执行了缓存逻辑可能读不到最新内容。建议在脚本中加入文件修改时间检测或者在每次执行前强制重新读取。5.5 Agent 生成了看似合理但实际错误的步骤这是使用 AIAgent 时最需要警惕的问题。Agent 可能根据“经验”生成并不存在于你项目中的命令或断言。解决方式在rules.md中明确“只能使用 scripts 目录下提供的脚本执行操作”。要求 Agent 在执行关键操作前输出将要运行的命令供人工确认。配置白名单只允许 Agent 执行特定命令清单内的指令。6. 最佳实践与工程建议6.1 Skill 设计原则一个高质量的测试 Skill 应该满足“单一职责、覆盖完整、输入输出明确”。单一职责一个 Skill 只解决一个场景比如“冒烟测试”和“稳定性测试”分开。覆盖完整从环境检查到结果报告的完整链路都要覆盖。输入输出明确定义好参数和报告格式Agent 才知道该怎么调用。6.2 用例分层管理在test_cases.json中按优先级分层P0核心链路阻塞发布的问题。P1重要功能异常时需讨论是否延期。P2一般功能可后续修复。Agent 执行时可以支持级别过滤例如只跑 P0python scripts/run_smoke_test.py --level P0这样能大幅缩短反馈周期。6.3 安全边界与数据保护测试涉及真实 APP 时必须在 Skill 中明确安全规则使用专用测试账号不触碰真实用户数据。对涉及删除、重置的操作进行二次确认。测试结束恢复设备状态。日志和报告中的敏感信息自动脱敏。6.4 让 Skill 可维护Skill 本身也是代码资产需要版本管理。建议纳入 Git 仓库管理记录变更历史。每个 Skill 目录下有独立的 README说明使用方式和维护人。用例数据独立于脚本业务人员也能维护。定期更新规则文件沉淀团队测试经验。6.5 从“脚本化”走向“智能化”Skill 的价值不止是自动化更是知识沉淀。你可以逐步把团队的历史缺陷、易错点、排查思路写进 Skill 的参考文档中让 Agent 在测试时自动关联历史知识提前预警风险。例如在assets/下增加known_issues.md记录该项目历史上出现过的崩溃点和易错模块。Agent 在执行测试时可以参考这些信息重点检查高发区域。6.6 评估 Skill 的测试效果引入 Skill 后建议建立简单的效果指标单次冒烟测试耗时。用例执行效率提升比例。Agent 误判率。人工介入次数。持续收集数据才能知道 Skill 在哪些场景下真正提效哪些场景需要进一步调优。7. 总结与学习路线本文围绕“Skill 调教 AIAgent 做 APP 测试”这条主线先介绍了 Skill 与 AIAgent 的核心概念再通过一个完整的app-smoke-test示例演示了从 Skill 目录设计、SKILL.md 编写、环境检查脚本、用例配置到测试执行和报告生成的全过程。90 分钟的时间规划里真正关键的不是写代码而是把“测试经验结构化”这件事想清楚。如果你打算继续深入建议从以下几个方向展开学习主流 Agent 工具的 Skill 官方规范理解不同平台的能力边界。把示例中的模拟脚本替换为真实自动化框架比如 Appium 或 UIAutomator2。为你的项目定制一套“知识库型 Skill”把历史缺陷和排查经验写进去。尝试多 Skill 协作模式测试 Skill 负责执行日志分析 Skill 负责诊断报告 Skill 负责输出让 Agent 像团队一样分工。只要用例标准在、数据不碰生产、操作有确认Skill 完全可以成为一个靠谱的测试搭子。它不会替你做测试设计但能把你从重复执行和整理结果中解放出来让你把更多时间花在真正需要人判断的地方。