目录一、你给AI的Prompt每次都在碰运气二、本质变化从“一次性对话”到“可执行技能包”三、核心机制拆解一个Markdown文件怎么做到“不瞎猜”四、典型案例三种工具同一个Skill模板五、工程落地启示对测试从业者意味着什么六、趋势判断Skill正在变成Plugin你要不要上车一、你给AI的Prompt每次都在碰运气身边越来越多的测试同事开始用AI写自动化脚本。但没过两周不少人回来吐槽同一件事同样的需求给AI的描述稍微换几个词输出结果就完全不一样。有时候生成一套能跑的代码有时候在同一个地方反复报错有时候模型直接说“我不知道你在说什么”。这不是你Prompt写得不好。这是当前AI编程工具的底层缺陷——不确定性。Claude Code可以自己编译、跑测试、修BugCursor能同时起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无人值守自动化完全自主跑完所有步骤输出报告CursorIDE日常编码调试按调用流程一步步执行期间可人工打断修改OpenClaw手机/消息平台远程监控/响应收到消息触发执行后发回结果同一个Skill不需要改一行代码就能在不同工具上跑。这背后的承诺是Skill是Agent生态的“可移植执行单元”。举个例子一个测试团队把“冒烟测试流程”写成了Skill。CI里的Claude Code每天晚上自动跑一遍开发人员修Bug时在Cursor里手动触发同一个Skill验证线上出事故时运维在群里发一条指令OpenClaw调用同样的Skill快速复现。一套逻辑三处落地。对比没有Skill的情况你要在CI里写Jenkins流水线在IDE里配置自定义脚本在消息平台搭Webhook。三个系统三套维护成本。Skill的工程价值就是把“流程”从特定工具里解放出来。五、工程落地启示对测试从业者意味着什么测试是受“不确定性”伤害最深的领域。因为测试本身追求确定性——同样的用例跑一百次结果应该一样。但让AI帮你写测试用例、执行回归、分析失败恰恰面对最大的不确定性。Skill给了测试从业者一套应对方案。建议一把“核心测试流程”写成Skill而不是写Prompt。把你团队的回归测试步骤拆解出来拉取最新代码安装依赖执行pytest –tagsregression收集失败截图和日志发送报告到钉钉/飞书每一步写成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它会在执行到哪一步的时候“卡住”