去年有段时间，我每天花在写 Prompt 上的时间比写测试代码还多。
为了让 AI 帮我生成一批接口测试用例，我得在对话框里反复描述：先调登录接口拿 token，再调业务接口，断言 code=0，data 不能为空，token 字段得是非空字符串……写第一版的时候觉得挺新鲜，写到第五个接口的时候就开始烦了。每次都得把同样的规则重述一遍，稍不留神漏掉一个约束条件，生成的用例就跑偏。
更让人头疼的是，同一个团队里，每个人写的 Prompt 风格都不一样。有人习惯把参数约束写在最前面，有人喜欢放在最后。结果就是同一个需求，不同人用 AI 生成的测试代码质量参差不齐，审查成本反而更高了。
这不是模型能力的问题。是我一直在用“对话”的方式做“工程”。
Prompt 的边界在哪里
用 Prompt 驱动 AI 做测试，本质上是在做一件事：用自然语言描述一个确定性的流程，然后期待模型每次都稳定地执行它。
这个期待在简单场景下是成立的。让 AI 写一个判断闰年的单元测试，怎么写都没问题。但一旦进入真实的测试工程，变量就多了：接口有前置依赖，环境有配置差异，断言有业务规则，失败后还有重试和上报的流程。
我印象很深的一次，是让 AI 帮我生成一个支付回调的测试脚本。Prompt 里写了“校验订单状态变更为已支付”，结果它只断言了 HTTP 200，没有去查数据库里的订单状态。这个用例表面上通过了，实际上什么都没验证。测试圈管这叫“假通过”，做过的人都知道，这种用例比没有用例更危险。
Prompt 能表达“做什么”，但很难稳定地表达“怎么做才算对”。它可以描述流程，但流程的每个节点需要哪些前置条件、执行时允许调用哪些工具、失败后应该如何回滚——这些确定性的工程细节，靠自然语言描述，总会有遗漏。
Skill 解决的是另一个问题
Anthropic 在 2025 年 10 月推出的 Agent Skills，思路和 Prompt 完全不同。
一个 Skill 就是一个文件夹。核心是 SKILL.md 文件，里面用 YAML 声明技能名称和触发描述，正文用 Markdown 写执行指令。还可以附带 scripts/ 目录放可执行脚本，references/ 放领域知识文档。
听起来很简单。但它解决的问题很关键：把“怎么做一个任务”从一次性的对话，变成可复用、可版本控制、可被 Agent 自动调度的能力单元。
你可能会问，这跟写一个测试函数有什么区别？
区别在于“谁在执行”。测试函数是给人调用的，需要人理解参数和上下文。Skill 是给 Agent 调度的，它的 description 决定了 Agent 在什么场景下会自动加载它。一个设计得好的 Skill，Agent 看到用户说“跑一下登录接口的回归测试”，就能自动匹配到对应的 Skill，按里面定义的流程去执行。
这意味着测试经验不再锁死在某个人的脑子里，也不锁死在某个脚本文件里。它变成了一个 Agent 能理解、能调用的标准化模块。
Skill 和 MCP 不是一回事
聊 Skill 的时候，很多人会问：那 MCP 呢？
这两个东西经常被放在一起比较，但它们解决的问题完全不同。MCP 是连接层，让 Agent 能连上外部工具——数据库、Git 仓库、接口文档、测试平台。它回答的是“能不能做”。
Skill 是流程层，告诉 Agent 怎么组合这些工具、按什么顺序、遇到什么情况该怎么处理。它回答的是“怎么做才对”。
打个比方。MCP 是厨房里的刀具和炉灶，Skill 是菜谱。你给一个新手全套厨具，他可能切到手。给他一份菜谱，他至少能做出能吃的菜。
这个区别在实际使用中有很现实的影响。MCP 服务器在会话启动时会加载全部工具描述，如果装了一堆 MCP，光工具定义就能吃掉大量上下文窗口。而 Skill 的元数据在 Agent 启动时只占约 100 个 token，只有当任务匹配时才会展开完整内容。
有实测数据：在困难任务上，MCP 路径的平均 token 消耗是 Skill 路径的数倍，工具调用次数也明显更多。另一个对比显示，Skill 方案在描述加载环节的 token 消耗降低了约 96%。
省 token 本身不是目的。真正的价值是：上下文窗口是有限的，省下来的空间可以用来做更重要的推理。
测试场景里，Skill 怎么用
说几个我们团队实际跑过的场景。
接口测试的断言校验。 传统做法是在测试脚本里写死断言。assert resp.json()["code"] == 0，代码一多，满屏都是这种东西。上游字段一改，几十个用例全崩。我们把校验逻辑拆成了独立的 Skill：状态码校验 Skill、JSON 路径存在性校验 Skill、Schema 匹配 Skill、业务规则 Skill。Agent 不直接生成断言代码，而是生成一份“校验计划”，然后由这些 Skill 来解释执行。字段改了，只需要更新对应的 Skill，所有引用它的用例自动生效。
回归测试的失败诊断。 之前跑回归，用例失败了就失败了，人要自己去翻日志、看截图、判断是环境问题还是代码问题。现在我们把失败诊断封装成了一个 Skill：当测试失败时，Agent 自动收集 requestId、响应体、页面截图，然后按预定义的排查清单逐项检查。初步判断结果直接附在失败报告里，人只需要看结论。
压测脚本的生成。 k6 或 Locust 的脚本结构其实很固定。我们写了一个 Skill，输入是接口文档和压测场景描述，输出是完整的压测脚本。关键的设计是 Thresholds 自动判定——脚本里自带通过/失败标准，跑完 k6 自动出结论，退出码 0 表示通过，99 表示失败，天然适合接 CI。不需要人去解读压测报告，CI 流水线自己就能判断。
一个 Skill 该长什么样
踩过一些坑之后，我总结了几条比较实用的设计原则。
description 要写“不适用场景”。 这一条最容易被忽略，但直接决定了 Agent 会不会滥用你的 Skill。只写“这个 Skill 能做接口测试”，Agent 会在各种无关场景下尝试调用它。加上“不适用于 UI 自动化测试、不适用于性能压测”，Agent 在规划阶段就能正确排除。
输入参数用 JSON Schema，别用自然语言描述。 Agent 对结构化约束的遵循程度远高于自然语言。参数的类型、是否必填、取值范围、枚举值，全部用 Schema 写清楚。能枚举就别让模型“自由发挥”。
allowed-tools 不是可选项。 一个日志分析 Skill 不应该有权访问数据库删除工具。这不是信任问题，是工程规范。Anthropic 在 SKILL.md 的 YAML 前置元数据里专门设计了 allowed-tools 字段来限制技能可以调用的工具范围。
脚本做确定性的事，模型做判断性的事。 复杂的数学计算、PDF 解析、文件格式转换，交给脚本。判断“这个断言失败是环境问题还是代码问题”，交给模型。两者的边界划清楚，Skill 的稳定性会好很多。
为什么说这是效率杠杆
手工测试岗位在收缩，这是事实。但测开的需求在涨。涨的部分，不是“会写更多脚本”，而是“能把测试经验封装成 AI 能调用的能力”。
Simon Willison 在 Hacker News 上写过一篇文章，标题直接说“Claude Skills maybe a bigger deal than MCP”。他的理由很简单：Skill 简单到离谱，一个 Markdown 文件就能开始，但它的复用性和可组合性，让 Agent 的能力增长方式从“堆工具”变成了“积经验”。
对测试开发来说，这件事的意义在于：你脑子里那些值钱的东西——接口参数该怎么构造、断言该怎么设计、失败后该怎么判断——终于有了一个标准化的地方可以存放。它不是一个 PPT 里的方法论，也不是一段只有你自己看得懂的脚本。它是一个 Agent 能理解、能调度、能版本控制的能力单元。
这件事，值得花一个周末搞清楚。
实操建议： 从你每周重复次数最多的一个测试任务开始。写一个 SKILL.md，把 description 的“不适用场景”写清楚，把参数用 JSON Schema 约束好，然后丢给 Claude Code 或 Cursor 跑一遍。跑通了，再考虑第二个。别一开始就想搭一个大而全的 Skills 库，那是给自己挖坑。
