最近测试团队里聊得最多的话题除了自动化测试框架就是 Agent Skill。有人把它当成更高级的提示词模板有人把它和 MCP 混为一谈还有人觉得这只是技术社区在造新概念。实际上在测试场景里 Skill 解决的问题非常具体让 AI 按照一位资深测试工程师的工作习惯完成从需求拆分、用例设计、脚本生成到测试报告输出的整套流程。测试工程师一天的精力分布其实很残酷。需求评审要参加用例要写测试数据要准备环境要部署回归要执行缺陷要跟进测试报告还要在下班前输出。真正用来思考业务风险和测试策略的时间往往不到 20%。过去几年自动化测试解决的是“执行重复点一点”的问题但没有解决“测试设计的经验如何沉淀”的问题。老测试退休了他脑子里的用例设计思路也跟着带走新人上手慢靠翻历史用例猜当初为什么这么设计。Skill 提供了一条新路径把测试方法论、用例模板、断言规则、报告格式做成一个可加载的技能包交给 Agent 来执行。它不只是给 AI 一段提示词而是给 AI 一套“带边界、带步骤、带输出规范”的作业指导书。本文会围绕测试全流程给出一个提效 Skill 合集的设计思路和落地示例包含完整目录结构、SKILL.md 写法、辅助脚本和调用验证方式。即使你所在团队还没有引入 Agent也可以先理解这套方法等工具链到位后直接落地。在动手之前先明确边界Skill 在不同 Agent 工具中的实现细节存在差异本文以通用结构为例不绑定某个具体厂商。部署时以你使用的工具官方文档为准。1. 为什么测试工作值得引入 Skill先看一个常见的场景版本迭代进入第三周产品经理丢过来一份 40 页的需求文档要求周五前提测。测试工程师小 A 需要把需求拆成测试点再设计用例准备数据执行一轮功能测试最后输出测试报告。这个过程中哪些环节最耗时间第一需求拆解和用例设计完全依赖个人经验。同一个需求三年经验的测试能拆出 80 个测试点新手可能只能拆出 30 个而且漏掉的往往是边界条件和异常分支。第二自动化脚本的重复编写。接口测试和 UI 测试的代码结构其实高度相似但每次都要重新写请求、封装断言、处理参数化。第三测试报告的整理。执行结果散落在各个用例里汇总通过率、失败原因分析、遗留风险这些事情几乎没有创造性却非常消耗时间。Skill 提效的路径不是让 AI 替代测试人员思考而是把上面三类工作标准化。第一类把资深测试的用例设计思路固化成规则让 Agent 在拿到需求后自动输出测试点清单和用例表格第二类把接口测试、UI 测试的脚手架代码模板化Agent 根据接口定义自动生成可执行脚本第三类把报告格式和统计逻辑封装成脚本执行结果入库后一键输出测试报告。这里要澄清一个误区很多人以为 Skill 只是“让 AI 写代码”。其实在测试场景里Skill 更大的价值是“让 AI 按标准做分析”。比如一个登录功能普通的 AI 提示词会让 AI 生成几条测试用例看起来都正确但覆盖不到“连续输错密码后锁定”这类业务规则。而一个设计良好的测试用例 Skill会强制 Agent 先拆功能点再遍历正常流、异常流、边界值、权限、兼容性、安全等维度最后还要自查用例是否覆盖了需求中的每条验收标准。所以判断一个测试团队是否真的需要 Skill可以看三个信号用例设计是否经常依赖个别资深员工的个人经验自动化脚本是否每天都在写结构相似的重复代码测试报告是否还需要手工汇总执行结果。如果三个信号中了两个Skill 就值得认真考虑。2. Skill 是什么与 MCP 有什么区别在聊测试 Skill 合集之前先把概念厘清。Skill 是 AI Agent 中的一种能力封装通常表现为一个包含 SKILL.md 说明文件、辅助脚本、参考模板和示例数据的目录。当 Agent 接到相关任务时会读取这个目录中的指令按照里面定义的工作流逐步执行。Skill 的本质是把“完成一类任务的方法论”外置成可复用、可版本化、可共享的文件。MCP 是 Model Context Protocol模型上下文协议。它解决的是 Agent 如何与外部系统通信的问题。通过 MCPAgent 可以访问数据库、缺陷管理平台、接口文档服务、测试执行平台等外部资源。MCP 更像是一个标准化连接器决定了 Agent 能拿到的数据范围和能操作的工具集合。Skill 和 MCP 经常被放在一起讨论但两者解决的问题不同。MCP 解决的是“Agent 能不能调用某个外部能力”Skill 解决的是“Agent 接到任务后知不知道按什么步骤做”。用一个不算精确但很好理解的类比MCP 是工具箱Skill 是作业指导书。工具箱决定你有什么工具可用作业指导书决定你按什么工序完成检修。如果没有 MCPAgent 拿不到测试平台的数据如果没有 SkillAgent 即使能拿到数据也不知道该怎么组织测试点、怎么判断缺陷优先级、怎么生成符合团队规范的报告。在测试场景里两者通常是配合使用的。一个接口测试 Skill 会描述生成脚本的步骤和规范而一个 MCP Server 可以为 Agent 提供接口文档内容和测试环境地址。Skill 负责“怎么做”MCP 负责“用什么做”。对比维度SkillMCP核心定位任务方法论的封装外部工具与数据源的标准化接入解决什么问题Agent 按什么流程完成任务Agent 能访问什么外部能力表现形式SKILL.md 脚本 模板Server 端工具集与协议测试场景示例需求拆解规则、用例模板、报告格式数据库查询、缺陷单创建、接口文档读取变更影响影响 Agent 的行为步骤影响 Agent 的能力边界在搭建测试 Skill 时不必一上来就引入 MCP。很多测试流程的提效比如用例生成、报告汇总完全可以在不依赖外部系统的情况下完成。先把 Skill 层做好后续需要连接测试平台或数据库时再考虑 MCP这个顺序更稳妥。3. 测试全流程提效 Skill 合集设计一个完整的测试流程从需求进入测试团队开始到测试报告输出结束大致包括需求分析、测试计划、用例设计、测试数据准备、测试执行、缺陷管理、回归验证、报告输出八个环节。每个环节都有重复性脑力劳动。设计 Skill 合集时优先选择对效率影响最大、规则最容易固化的环节。3.1 需求分析 Skill需求分析 Skill 的输入是 PRD 文档或需求描述文本输出是测试点清单和需求疑问列表。这个 Skill 的价值在于强迫 Agent 按照统一的维度拆解需求避免遗漏。Skill 内部定义的工作流一般包括提取功能清单识别用户角色梳理业务流程标注业务规则识别异常场景最后输出一份结构化测试点列表。对于不确定的地方Skill 会要求 Agent 以“待确认”的形式列出而不是直接跳过。3.2 测试用例设计 Skill需求分析完成后测试点需要转化成可执行的测试用例。用例设计 Skill 会把测试点映射为用例编号、前置条件、操作步骤、预期结果、优先级和用例类型。它的核心不是生成“看起来正确”的测试步骤而是保证覆盖度。在实现上可以内置等价类划分、边界值分析、错误推测等方法的规则描述让 Agent 生成用例时自动套用。3.3 接口自动化测试 Skill接口自动化测试 Skill 用来把接口定义转化为可执行的 Python 脚本。它的输入是接口文档片段或手工整理的接口信息输出是 pytest 风格的测试代码。这个 Skill 要包含请求构造、超时设置、状态码断言、JSON 字段断言、参数化等模板同时要求 Agent 在生成脚本后检视是否存在硬编码的敏感信息。3.4 UI 自动化测试 SkillUI 自动化测试 Skill 主要面向 Appium、Selenium 等框架根据测试用例步骤生成元素定位和操作代码。相比接口测试UI 自动化的不确定性更高因此 Skill 的设计重心是生成“可维护”的脚本。比如强制要求使用 Page Object 模式要求元素定位器统一放在配置文件中要求等待策略使用显式等待而不是固定 sleep。3.5 测试数据构造 Skill测试数据准备往往被低估。一条用例能不能稳定复现往往取决于造数是否准确。测试数据构造 Skill 可以定义造数的步骤先分析接口字段约束再根据字段类型生成合法值和边界值最后生成可执行的 SQL 或 API 调用脚本。Skill 里需要包含常见的身份证号、手机号、时间戳等生成规则。3.6 缺陷报告 Skill缺陷报告 Skill 的作用是把一条测试失败记录转化为结构化缺陷单。它不只是格式化标题和复现步骤还会要求 Agent 分析失败原因判断是环境问题、数据问题还是代码问题再给出建议优先级。这个 Skill 对团队沉淀缺陷分析经验很有帮助。3.7 测试报告 Skill测试报告 Skill 负责把执行结果汇总成文档。输入是测试结果 JSON输出是包含统计结论、失败明细、风险分析和建议的 Markdown 报告。基础统计可以由脚本完成而风险分析和建议部分则依赖预置的规则和判断逻辑。实际项目中不建议一次上齐所有 Skill。先挑一个痛点最明确的环节比如用例设计或测试报告做最小闭环跑通后再逐步扩展。Skill 合集的目录结构可以按阶段组织方便维护。4. Skill 环境准备与项目结构搭建测试 Skill 并不需要全新的技术栈核心是选择一个支持 Skill 能力的 Agent 工具然后按约定组织目录和文件。当前主流的 Agent 编程工具如 Claude Code、Codex 等都已经支持类似 Skill 的机制只是目录约定和加载方式略有不同。实际使用中以你所选工具的官方文档为准。4.1 目录组织建议测试 Skill 合集建议使用一个总目录承载多个技能每个技能一个子目录。例如test-skills/ ├── requirement-analysis/ │ ├── SKILL.md │ ├── scripts/ │ │ └── extract_points.py │ └── examples/ │ └── sample_requirement.md ├── test-case-generator/ │ ├── SKILL.md │ ├── scripts/ │ │ └── generate_cases.py │ ├── templates/ │ │ └── test_case_template.md │ └── examples/ ├── api-test-generator/ │ ├── SKILL.md │ ├── scripts/ │ │ └── generate_api_test.py │ └── examples/ ├── test-data-builder/ │ └── ... ├── defect-reporter/ │ └── ... └── test-report-generator/ ├── SKILL.md └── scripts/ └── generate_report.py从工程角度看把 Skill 文件与代码放在同一个仓库里是更好的做法这样 Skill 的变更可以走代码评审、版本回滚也能让团队成员共享同一套测试方法论。4.2 SKILL.md 的标准结构SKILL.md 是 Skill 的核心入口。它一般包含两部分开头的 YAML front matter 描述技能名称和触发场景后面的正文描述工作流程和输出要求。不同工具对 front matter 字段的定义不完全相同但 name 和 description 是常见的核心字段。一个测试用例设计 Skill 的 SKILL.md 可以这样组织--- name: test-case-generator description: 用于从需求文本或测试点生成结构化测试用例适用于功能测试用例设计阶段。 --- # 测试用例生成 Skill ## 任务目标 根据用户提供的需求描述或测试点清单生成符合团队规范的测试用例表格。 ## 输入 - 需求文本功能描述或 PRD excerpt。 - 测试点清单可选如果用户已提供测试点则直接进入用例生成。 ## 工作流程 1. 如果输入是需求文本先按功能模块拆分提取业务规则。 2. 如果没有测试点先按正常流、异常流、边界值、权限、兼容性五个维度生成测试点。 3. 将测试点映射为测试用例每个用例包含用例编号、所属模块、优先级、前置条件、操作步骤、预期结果、用例类型。 4. 检查用例是否覆盖输入中的所有业务规则和验收标准。 5. 输出 Markdown 表格并在末尾单列“未覆盖风险”清单。 ## 输出格式 每个用例需要包含以下字段 | 用例编号 | 模块 | 优先级 | 前置条件 | 操作步骤 | 预期结果 | 用例类型 | | --- | --- | --- | --- | --- | --- | --- | ## 注意事项 - 边界值必须覆盖“最小值、最大值、超限值”三类。 - 异常流必须包含输入非法、依赖服务异常、权限不足三种情况。 - 不要生成没有前置条件的用例。4.3 运行环境要求Skill 中的辅助脚本建议使用 Python 3.8 以上版本编写并保持一个 Skill 只依赖最少的三方库。例如接口测试生成的脚本依赖 requests 和 pytest测试报告生成脚本只使用标准库即可。如果团队的 Agent 运行在容器中还需要在环境准备阶段安装相关依赖并记录在 requirements.txt 中。Python 环境准备示例python -m venv .venv source .venv/bin/activate pip install requests pytest这里强调最小依赖是因为 Skill 的脚本通常是零散地被 Agent 调用依赖越少越不容易出现环境不一致的问题。5. 提效 Skill 合集核心示例实现接下来给出三个核心 Skill 的完整示例测试用例生成、接口自动化测试脚本生成、测试报告生成。这三个 Skill 覆盖了测试流程中最常见、最耗时的三个环节。5.1 示例一测试用例生成 Skill这个 Skill 接收需求文本提取测试点并生成基础用例。为了演示我们用一个最小 Python 程序实现核心逻辑。真正在 Agent 中运行时SKILL.md 负责引导 Agent 分析需求脚本负责把分析结果转成结构化用例。# 文件路径test-skills/test-case-generator/scripts/generate_cases.py import json import re import sys from typing import List, Dict def extract_test_points(requirement: str) - List[str]: 从需求文本中提取可测点。 points [] for sentence in re.split(r[。;], requirement): sentence sentence.strip() if not sentence: continue if any(keyword in sentence for keyword in [验证, 支持, 允许, 必须, 展示, 返回, 提示, 跳转, 限制, 不允许]): points.append(sentence) return points def generate_test_cases(test_points: List[str]) - List[Dict]: 根据测试点生成基础测试用例。 cases [] for idx, point in enumerate(test_points): cases.append({ id: fTC_{idx 1:03d}, title: f验证{point}, precondition: 已登录并进入目标功能模块, steps: [进入目标功能模块, point], expected: f系统正常处理“{point}”对应的业务逻辑, type: 功能测试, priority: P2 }) return cases if __name__ __main__: if len(sys.argv) 1: with open(sys.argv[1], r, encodingutf-8) as f: requirement_text f.read() else: requirement_text sys.stdin.read() test_points extract_test_points(requirement_text) cases generate_test_cases(test_points) result {test_points_total: len(test_points), cases: cases} print(json.dumps(result, ensure_asciiFalse, indent2))这段脚本的逻辑有三个关键点第一用正则按句读拆分需求文本保证每个句子独立成一个候选测试点第二通过关键词过滤掉描述性信息只保留能被验证的业务规则第三每个测试点生成一条完整用例。实际使用中SKILL.md 会要求 Agent 在调用脚本前先做一轮语义分析补充脚本无法识别的隐含规则再生成最终用例表。5.2 示例二接口自动化测试脚本生成 Skill接口测试脚本生成 Skill 的目标是给定接口定义输出一段可直接执行的 pytest 测试代码。脚本的核心是代码模板加参数替换。为了避免每次生成的代码结构差异过大模板中固定了超时时间、状态码断言、JSON 字段断言和异常场景的骨架。# 文件路径test-skills/api-test-generator/scripts/generate_api_test.py import json import sys from typing import Dict API_TEST_TEMPLATE import requests import pytest BASE_URL {base_url} def test_{case_name}(): {description} url f{{BASE_URL}}{path} headers {headers} payload {payload} response requests.request( method{method}, urlurl, headersheaders, jsonpayload if payload else None, timeout10 ) assert response.status_code {expected_status}, funexpected status: {{response.status_code}} result response.json() assert {core_field} in result, fmissing core field in response: {{result}} def build_case(spec: Dict) - str: 根据接口定义生成测试代码字符串。 case_name spec.get(case_name, api_test).lower() return API_TEST_TEMPLATE.format( base_urlspec.get(base_url, http://127.0.0.1:8000), descriptionspec.get(description, 接口功能验证), pathspec[path], methodspec.get(method, POST), headersjson.dumps(spec.get(headers, {}), ensure_asciiFalse), payloadjson.dumps(spec.get(payload, {}), ensure_asciiFalse), expected_statusspec.get(expected_status, 200), core_fieldspec.get(core_field, data) ) if __name__ __main__: spec json.loads(sys.stdin.read()) print(build_case(spec))运行这个脚本时需要把接口定义通过标准输入传给程序。示例接口定义如下{ case_name: login_success, description: 验证正确用户名密码可以登录成功, method: POST, path: /api/login, headers: {Content-Type: application/json}, payload: {username: tester, password: 123456}, expected_status: 200, core_field: token }执行方式echo {case_name:login_success,description:验证正确用户名密码可以登录成功,method:POST,path:/api/login,headers:{Content-Type:application/json},payload:{username:tester,password:123456},expected_status:200,core_field:token} | python scripts/generate_api_test.py生成后的测试代码会自动包含状态码断言和核心字段断言。这个 Skill 的价值在于减少重复代码编写尤其适合接口数量多、结构相似的业务模块。但要注意生成脚本只是一个起点真正的断言逻辑需要测试人员根据业务补全。5.3 示例三测试报告生成 Skill测试报告生成 Skill 把测试执行结果 JSON 转换为 Markdown 格式的报告。报告内容包含总体统计、通过率、失败明细和风险提示。实现中坚持使用标准库不引入额外依赖保证在任何 Python 环境下都能运行。# 文件路径test-skills/test-report-generator/scripts/generate_report.py import json import sys from collections import Counter from datetime import datetime class TestReportGenerator: def __init__(self, results: list): self.results results self.total len(results) self.counter Counter(item.get(status, unknown) for item in results) def generate_markdown(self) - str: passed self.counter.get(passed, 0) failed self.counter.get(failed, 0) skipped self.counter.get(skipped, 0) pass_rate round(passed / self.total * 100, 2) if self.total else 0.0 lines [ # 自动化测试执行报告, , f- 生成时间{datetime.now().strftime(%Y-%m-%d %H:%M:%S)}, f- 用例总数{self.total}, f- 通过{passed}, f- 失败{failed}, f- 跳过{skipped}, f- 通过率{pass_rate}%, , ## 失败用例明细, , ] for item in self.results: if item.get(status) failed: lines.append(f- {item.get(name, unknown)}{item.get(error, unknown error)}) if failed 0: lines.append(本轮无失败用例。) return \n.join(lines) if __name__ __main__: data json.loads(sys.stdin.read()) reporter TestReportGenerator(data) print(reporter.generate_markdown())执行示例echo [{name:test_login_success,status:passed},{name:test_login_wrong_password,status:failed,error:assert 401 200}] | python scripts/generate_report.py输出结果# 自动化测试执行报告 - 生成时间2025-01-01 12:00:00 - 用例总数2 - 通过1 - 失败1 - 跳过0 - 通过率50.0% ## 失败用例明细 - test_login_wrong_passwordassert 401 200这个 Skill 真正的价值不在于统计数字而在于它把报告格式固定下来让每次测试报告的结构保持一致。团队可以在此基础上扩展增加失败用例自动归因、历史趋势对比等功能。6. 运行结果与效果验证Skill 是否生效可以通过一次最小任务来验证。以测试用例生成 Skill 为例准备一段需求文本用户登录页面支持用户名、邮箱、手机号三种账号方式登录连续输错密码5次后账号锁定30分钟锁定期间不允许登录。在 Agent 中调用测试用例生成 Skill预期输出应包含以下内容登录方式正常流测试点、账号锁定规则测试点、锁定期间登录被拒绝的异常流测试点。如果只输出了“输入正确账号密码可以登录”这类基础用例说明 Skill 的工作流没有被完整加载或者 SKILL.md 中的维度拆解要求没有被严格执行。对于接口测试生成 Skill验证方式是运行生成后的测试代码观察是否能够正常执行并且断言是否符合预期。如果生成的代码出现语法错误优先检查输入 JSON 中是否包含非法字符或模板字段缺失。对于报告生成 Skill验证方式比较简单输入一个包含失败用例的 JSON确认报告中失败明细和通过率计算正确。验证通过的判断标准有三个第一输出结构是否符合 SKILL.md 中定义的格式第二生成的用例是否覆盖了明显的边界条件和异常分支第三整个过程是否不需要人工干预地完成了从输入到输出的转换。如果都满足说明这条 Skill 链路已经跑通。运行时如果出现问题先看 Agent 的日志中是否加载了 Skill 目录再看辅助脚本能否在命令行独立执行。脚本无法独立执行的问题在 Agent 中调用时大概率也会失败。7. 测试 Skill 常见问题与排查方法在实际搭建和使用测试 Skill 的过程中会遇到一些重复出现的问题。下面列出最常见的几种以及对应的排查思路。问题现象可能原因排查方式解决方案Agent 未找到 SkillSkill 目录未放入受支持的路径检查 Agent 的加载目录配置将 Skill 目录移动到正确位置或修改配置指定目录Skill 加载了但输出不符合预期SKILL.md 中的工作流描述过于模糊查看 SKILL.md 的 step 描述细化每个步骤的输入、输出和验收条件辅助脚本报语法错误本机 Python 版本与脚本语法不兼容执行python --version并运行脚本检查统一 Python 版本或改写为低版本兼容语法生成的接口测试代码没有断言输入 JSON 中缺少 expected_status 和 core_field检查接口定义模板在 Skill 中增加输入必填字段校验报告中文乱码标准输出编码不是 UTF-8在终端执行python scripts/generate_report.py观察输出设置环境变量PYTHONIOENCODINGutf-8或脚本内重新配置标准输出Skill 输出内容被截断单次输出超过 Agent 上下文限制查看输出长度和 Agent 日志拆分输入批次或让脚本将结果写入文件而不是直接输出全文与 MCP 工具联动失效MCP Server 未返回预期数据先直接调用 MCP Server 接口验证确认 MCP Server 地址、鉴权和数据格式排查顺序建议按照“环境、代码、指令”三个层次进行。先确认 Skill 目录被正确加载、Python 依赖正常再确认辅助脚本单独运行是否成功最后检查 SKILL.md 中的指令是否写得足够具体。大部分问题出在第三层因为指令越是含糊Agent 的自由发挥空间越大输出的稳定性就越差。8. 测试 Skill 的最佳实践与工程建议把 Skill 引入测试流程不是把一堆 Markdown 文件放进仓库就结束了。要让 Skill 真正提高团队效率有几个工程层面的建议值得关注。第一一个 Skill 只解决一个问题。新手容易把 SKILL.md 写成一个“万能手册”既有用例设计又带接口测试还包含报告生成。这样看起来全面但实际上每个任务都得不到足够精细的指令。更稳妥的做法是按职责拆分 Skill每个 Skill 专注一个目标这样也方便独立测试和维护。第二Skill 的指令要可验证。不要写“生成高质量的测试用例”而要写“每个用例必须包含前置条件、测试步骤和预期结果边界值必须覆盖最小值和最大值”。可验证的指令意味着 Agent 的输出可以被自动化检查也意味着 Skill 的质量是可评审的。第三安全边界要提前定义。测试 Skill 涉及接口测试、数据构造、甚至安全测试时必须在 SKILL.md 中明确授权范围例如“只允许在测试环境执行不得访问生产环境数据”“不得使用真实用户敏感信息作为测试数据”。涉及权限验证、数据操作类任务时坚持最小权限原则并在执行前要求人工确认。第四Skill 与代码仓库一起管理。建议把 Skill 目录纳入版本控制跟随业务代码一起评审、发布。这样 Skill 的变更可追溯回滚也容易。同时Skill 的更新频率和代码不同建议单独拆分目录避免混在一起导致评审噪音。第五建立 Skill 的评测用例集。每个 Skill 都需要一组固定的输入和预期输出用来验证修改 SKILL.md 后没有影响原有行为。比如测试用例生成 Skill可以准备三个典型需求文档作为回归样本每次修改后运行一遍对比输出覆盖度。第六渐进式落地。一个团队如果从来没有用过 Agent直接一次性上五六个 Skill大概率会失败。建议从“测试报告生成”这种低风险、高复用、边界清晰的环节入手跑通后再扩展到用例设计和接口测试。每个阶段都要保留手工流程作为兜底等 Skill 的输出稳定性得到验证后再逐步依赖它。9. 总结与后续学习方向这篇内容从测试人员的日常痛点出发解释了 Skill 的概念梳理了它与 MCP 的区别并给出了一套覆盖需求分析、用例设计、接口测试、测试数据、缺陷报告和测试报告的 Skill 合集设计。三个完整的代码示例已经可以直接复用测试用例生成脚本、接口测试代码生成脚本、测试报告生成脚本。建议先在自己的项目仓库中创建 test-skills 目录把一个最简单的 Skill 跑通再逐步扩展。后续值得深入的方向有三个一是学习 MCP 协议把测试平台、缺陷管理系统、数据库通过 MCP 接入 Agent让 Skill 能拿到实时数据二是研究断言生成策略让接口测试 Skill 不止生成请求代码还能根据接口字段约束自动生成更完整的断言三是探索测试结果与历史数据的关联分析让测试报告 Skill 从“统计结果”升级为“风险预测”。Skill 不是银弹。它不会让一个不做测试设计的团队突然变得专业但它能把已有的专业方法放大。先把一份资深测试的用例设计文档写成 SKILL.md用最小闭环验证效果这个动作比反复讨论概念更有价值。
