目录

一、你给AI的Prompt，每次都在碰运气
二、本质变化：从“一次性对话”到“可执行技能包”
三、核心机制拆解：一个Markdown文件怎么做到“不瞎猜”
四、典型案例：三种工具，同一个Skill模板
五、工程落地启示：对测试从业者意味着什么
六、趋势判断：Skill正在变成Plugin，你要不要上车
一、你给AI的Prompt，每次都在碰运气
身边越来越多的测试同事开始用AI写自动化脚本。

但没过两周，不少人回来吐槽同一件事：同样的需求，给AI的描述稍微换几个词，输出结果就完全不一样。有时候生成一套能跑的代码，有时候在同一个地方反复报错，有时候模型直接说“我不知道你在说什么”。

这不是你Prompt写得不好。这是当前AI编程工具的底层缺陷——不确定性。

Claude Code可以自己编译、跑测试、修Bug，Cursor能同时起8个Agent帮你补代码，OpenClaw甚至能打通WhatsApp替你执行任务。但不管多强，你让它们干同一件事两次，结果可能天差地别。

3万人的NEC用Claude，不是因为它“聪明”，而是因为它终于找到了一个让AI不再“瞎猜”的方案。

这个方案的核心，是一个叫SKILL.md 的Markdown文件。

二、本质变化：从“一次性对话”到“可执行技能包”
过去的AI交互模式是：你说一句，它猜一句。你给的Prompt越细，它猜得越准。但只要超出你写过的范围，它就开始自由发挥。

这本质上不是模型的问题。是没有“工程约束”的问题。

SKILL.md的本质，是把一个人的操作经验，固化成了机器可读的标准作业程序。

可以被截图传播的观点句：Prompt是一次性猜，Skill是确定性的工程。

你可以把SKILL.md 理解成“给AI看的SOP（标准操作流程）”。它不只是告诉AI“你要做什么”，还告诉AI“在什么条件下怎么做、出错了怎么办、调哪个脚本、读哪个文档”。

这背后的变化是范式级的：

之前：人类写自然语言指令 → 模型推理 → 输出（每次不同）
现在：人类写结构化技能包 → Agent解析 → 按步骤调用确定性工具 → 输出（可复现）
多了一层“技能编排”，就消除了大多数歧义。

三、核心机制拆解：一个Markdown文件怎么做到“不瞎猜”
先看SKILL.md 长什么样。

一个标准的Skill文件夹：

my-test-skill/
├── SKILL.md # 核心指令文件
├── scripts/ # 辅助脚本（Python/Shell）
├── templates/ # 输出模板
└── resources/ # 参考资料
SKILL.md 的内部结构只有三块：

name:regression-tester
description:当用户提到回归测试、全量用例、冒烟测试时，主动加载该技能，不要等他明确要求。

version:1.0

执行流程

1.读取test_suite.yaml获取用例列表
2.调用scripts/runner.py并行执行
3.失败用例自动重试2次，间隔5秒

4.生成JSON报告并存储到reports/目录

异常处理

-环境未就绪→调用scripts/setup_env.sh
-用例超时→标记为TIMEOUT，继续下一用例
核心不在于写了什么文字，而在于模型不再需要“猜”怎么做。

完整的执行逻辑可以用这张图说明：

flowchart TD
Start[用户输入] --> Scan[Agent扫描metadata]
Scan --> Match{匹配description?}
Match -- 否 --> Normal[普通对话模式]
Match -- 是 --> Load[加载SKILL.md全文]
Load --> Parse[解析执行流程]
Parse --> Check{需要脚本?}
Check -- 是 --> CallScript[调用scripts/确定性脚本]
CallScript --> Exec[脚本执行并返回结果]
Check -- 否 --> LLMStep[模型按指令推理]
Exec --> Next{还有步骤?}
LLMStep --> Next
Next -- 是 --> Parse
Next -- 否 --> Output[输出结果+报告]
三个设计让它“不瞎猜”：

第一，渐进式披露。Agent启动时只扫描所有Skill的metadata（几百字节），只有当用户问题匹配某个description才加载完整内容。不会把全量的指令一次性塞给模型，避免了上下文污染。

第二，确定性降级。凡是能用脚本做的事，绝不让模型去“写代码做”。编写好的runner.py永远是同一个行为，而模型每次生成的代码可能都不一样。所以Skill里把脚本路径写死，Agent只负责调用，不负责生成。

第三，强制流程固化。SKILL.md 里的执行步骤是顺序文本，模型读取后必须按这个顺序执行。不是“建议”，是“指令”。这直接解决了Prompt里“模型跑偏”的核心问题。

可以被截图传播的观点句：SKILL.md把人的经验变成了可执行的代码，而不是可参考的建议。

四、典型案例：三种工具，同一个Skill模板
Claude Code、Cursor、OpenClaw，今年被讨论最多的三款工具。很多人以为它们三选一就行。实际上它们分别对应不同的运行环境，但都可以加载同一个Skill文件夹。

把上面那个regression-tester的Skill，直接放进三种环境：

工具
运行环境
适用场景
用同一个Skill的效果
Claude Code
终端/CI
无人值守自动化
完全自主跑完所有步骤，输出报告
Cursor
IDE
日常编码+调试
按调用流程一步步执行，期间可人工打断修改
OpenClaw
手机/消息平台
远程监控/响应
收到消息触发，执行后发回结果
同一个Skill，不需要改一行代码，就能在不同工具上跑。

这背后的承诺是：Skill是Agent生态的“可移植执行单元”。

举个例子：一个测试团队把“冒烟测试流程”写成了Skill。CI里的Claude Code每天晚上自动跑一遍；开发人员修Bug时在Cursor里手动触发同一个Skill验证；线上出事故时，运维在群里发一条指令，OpenClaw调用同样的Skill快速复现。

一套逻辑，三处落地。

对比没有Skill的情况：你要在CI里写Jenkins流水线，在IDE里配置自定义脚本，在消息平台搭Webhook。三个系统，三套维护成本。

Skill的工程价值，就是把“流程”从特定工具里解放出来。

五、工程落地启示：对测试从业者意味着什么
测试是受“不确定性”伤害最深的领域。因为测试本身追求确定性——同样的用例，跑一百次结果应该一样。但让AI帮你写测试用例、执行回归、分析失败，恰恰面对最大的不确定性。

Skill给了测试从业者一套应对方案。

建议一：把“核心测试流程”写成Skill，而不是写Prompt。

把你团队的回归测试步骤拆解出来：

拉取最新代码
安装依赖
执行pytest –tags=regression
收集失败截图和日志
发送报告到钉钉/飞书
每一步写成SKILL.md 的条目。尤其是“执行pytest”这一步，不要写自然语言描述，直接指向scripts/run_pytest.sh。脚本里把超时、重试、输出格式全部写死。

建议二：description字段写“过一点”。

很多团队的Skill没人用，因为Agent从不主动触发。检查一下你的description，是不是写得太保守。对比一下：

差：“执行测试”
好：“当用户提到运行、执行、跑一下、回归、冒烟、全量、suite、用例、pytest、unittest时，主动加载并询问是否需要执行测试”
可以被截图传播的观点句：AI编程不再靠瞎猜，靠的是流程。

建议三：一个Skill只做一件事。

看到有人写一个“全流程测试Skill”，里面包括了环境部署、用例执行、报告发送、Jira建单……结果上下文窗口炸了。拆成三个独立Skill：环境准备Skill、执行测试Skill、报告Skill。Agent按需串起来用。

六、趋势判断：Skill正在变成Plugin，你要不要上车
Skill解决了“不确定性”，但没有解决“怎么卖”的问题。

一个Skill本质上是一堆文本和脚本。复制给另一个人，他也能用。这对个人开发者是好事，对商业平台是灾难。

所以Anthropic已经明确下一步方向：从Skill演进到Plugin。

Plugin比Skill多了三样东西：

环境绑定：声明自己需要什么MCP Server、什么版本依赖
认证托管：OAuth token、API key在平台侧管理，不写死在文件里
分发渠道：通过插件市场安装，无法通过文件副本复用
这意味着商业闭环能跑通了。也意味着今天的Skill作者，明天就是Plugin生态的第一批供给方。

对测试从业者来说，这不是远处的故事。你完全可以把团队的测试编排、数据生成、缺陷分析沉淀成Skill，甚至在未来Plugin市场上发布。这个能力只有现在开始写SKILL.md 的人才能积累。

最后想问你一个问题：

如果明天你让Agent全权接管你们项目的回归测试，你写出来的那个SKILL.md，它会在执行到哪一步的时候“卡住”？