一篇理清Prompt，Skill，MCP之间的区别

大家好，我是洋子

事情是这样的。

前两天我们团队在做AI自动化测试的时候，有个同事突然在群里问了一句，

「Prompt和Skill到底有啥区别？MCP又是啥？我感觉每个都能让AI干活啊，搞不懂这三个东西到底谁是谁。」

我当时看到这条消息，愣了一下。

因为我发现，不只是他，身边很多测试工程师朋友，甚至包括一些已经在用Claude Code干活的人，都对这三个概念处于一种「好像知道又说不清楚」的状态。

你要问他们Claude Code好不好用，他们能聊半天。你要问Prompt、Skills、MCP分别是干嘛的、什么时候该用哪个，十个人里有九个会卡壳。

我觉得这事儿挺重要的。因为搞不清楚这三个东西的边界，你就很难真正把Claude Code用到极致。就像你手里拿着一把瑞士军刀，但你分不清哪个是刀哪个是螺丝刀哪个是开瓶器，最后只会拿它切水果。

所以今天，我想用大白话，一次性把这三个东西讲透。

不搞什么「一文读懂」的标题党，就是实打实地，从一个测试工程师的视角出发，帮你理清楚它们各自是什么、能干什么、什么场景下该用哪个。

好，先从最好理解的开始。

Prompt，你可以理解为「便签纸」。

Prompt现在大部分人应该都知道官方学名叫提示词，提示词设计的越好，AI能更好理解你的需求，越能更好发挥出来AI的能力

关于提示词设计，有门课叫提示词工程（Prompt Engineering），感兴趣的同学可以去学习下

那么什么样的Prompt算是好的Prompt，好的Prompt一般包含4要素

要素	作用	常见表述
Role（角色）	激活模型的相关知识领域	你是一位 10 年经验的 Java 架构师
Task（任务）	明确要完成的具体动作	请评审以下代码的性能问题
Context（上下文）	提供任务相关的背景信息	当前线上 QPS 2000，响应时间超 500ms
Format（格式）	指定输出的结构要求	输出 JSON，包含 bottleneck、solution 两个字段"

❌ 差 Prompt：
分析这段代码的性能问题，给出优化建议。

✅ 好 Prompt：
你是一位有 10 年经验的 Java 架构师（Role），擅长性能优化与代码评审。
请评审以下 Java 接口代码的性能问题（Task）：
- 代码功能：用户订单查询
- 当前状况：线上 QPS 2000，响应时间超 500ms（Context）

输出需包含：
1. 性能瓶颈点（标注代码行号 + 问题描述）
2. 优化方案（附具体修改代码片段）
3. 优化后预期性能指标（输出 Format）

现在AI大模型能力已经很强了，对于简单的任务，直接给到自然语言描述，也能完成任务，还有一种技巧就是让AI给你生成Prompt，然后稍微调整后，再喂给AI

那在Claude Code里能用到的Prompt都有哪些场景

除了在命令行里面交互的场景，还有一个很多人不知道的是CLAUDE.md

这玩意就像你贴在工位上的便签纸，上面写着团队的规矩和约定。比如「我们用pytest做测试框架」「测试用例命名必须是test_功能_场景」「覆盖率不能低于80%」。每次你打开Claude Code开始干活，它都会先看一眼这张便签纸，然后按照上面的规矩来。

你不需要每次都重新跟它说一遍「我们用什么框架」「命名规范是什么」，它自己会记住。

听起来很简单对吧。

确实很简单。Prompt就是最轻量级的那个东西，你给AI一段指令，它照着做。像便签纸一样，写起来快，用起来也快，但它的能力边界也很明确，它就是一段文字指令，仅此而已。

那Skills呢？

Skills，是「操作手册」。

如果说Prompt是便签纸，那Skills就是你抽屉里那本厚厚的操作手册。

它不只是一段指令，它是一整套workflow。它有自己的目录结构，可以带上参考文档、模板文件、示例代码、甚至可以执行shell命令来动态获取信息。

举个实际的例子。

你作为测试工程师，经常需要给新模块写单元测试。如果用Prompt，你每次都得告诉Claude Code「帮我看看这个文件，按照我们的规范写测试用例，记得覆盖边界情况」。

但如果你做了一个Skill，比如叫/generate-tests，你可以把这些东西全部打包进去，你们团队的测试规范文档、几个写得好的测试用例作为参考、甚至一个自动检测当前测试覆盖率的脚本。

然后你只需要敲一句/generate-tests src/auth/login.ts，它就会自动读取你的规范、参考你的示例、检查当前覆盖率、然后生成一整套符合团队标准的测试用例。

感受到区别了吗。

Prompt是「帮我做这件事」，Skills是「按照这套完整的标准化流程来做这件事」。

而且Skills有几个Prompt做不到的骚操作。

• 一个是subagent模式 。你可以让Skill在一个独立的上下文里运行，不会污染你当前的对话。比如你正在写代码，突然想跑个测试分析，用context: fork的Skill就能在后台跑完给你结果，不会打断你的心流。

• 另一个是工具预授权。你可以在Skill里提前声明「这个Skill可以跑pytest命令」，这样每次执行的时候就不用一个个弹窗确认权限了。对于测试工程师来说，这个太实用了，不然每次跑测试都要点好几次同意，烦都烦死。

• 还有一个是动态信息注入 。Skill的markdown里可以写``!git diff```这种语法，执行的时候会先跑这个命令，把实时结果塞进去。你可以想象一下，一个/test-report` Skill，执行的时候自动拉取最新的git diff，然后只针对你改过的文件生成测试报告。

说到这里，Prompt和Skills的区别应该很清楚了。一个是便签纸，一个是操作手册。一个轻便灵活随手写，一个系统完整可复用。

那MCP呢？

MCP，是「万能翻译官」。

这是三个概念里最容易被误解的一个。

很多人觉得MCP就是另一种形式的Skill，或者就是个插件系统。不是的。

MCP的全称是Model Context Protocol，模型上下文协议。注意这个词，协议。它不是一个具体的工具，它是一套通信标准。

你可以这么理解。

Claude Code本身很聪明，但它是个「宅男」。它能读代码、写代码、跑命令，但它出不了自己的那个终端世界。它不知道你Jira上有哪些Bug单，它不知道你Jenkins上今天的构建是不是挂了，它不知道你TestRail里有哪些测试用例还没覆盖。

MCP就是那个帮宅男连接外部世界的万能翻译官。

它是一个客户端-服务端的协议。Claude Code是客户端，各种外部工具（Jira、GitHub、Playwright、数据库、你们公司的内部系统）各自跑一个MCP Server，然后通过这套标准协议来通信。

对测试工程师来说，MCP最杀手级的应用场景是什么？

Playwright MCP。

配好之后，Claude Code可以直接操控浏览器。你跟它说「帮我测一下登录页面，用错误的密码试试看报错提示对不对」，它真的会打开浏览器，输入账号密码，点击登录，然后看页面上的报错信息是不是符合预期。

不是生成测试代码让你自己去跑，是它自己去跑。

再比如Jira MCP。测试过程中发现了Bug？Claude Code可以直接帮你在Jira上创建一个Bug单，把复现步骤、截图、关联的代码文件全都填好。你甚至可以在Skill里编排这个流程，跑完自动化测试之后，失败的用例自动创建Jira Bug单。

这就是MCP和前两者本质上的不同。

Prompt和Skills都是在告诉AI「怎么想」和「怎么做」。MCP是在给AI「一双手」，让它能够触及到外部世界。

好，到这里三个概念都讲完了。我来做个类比帮你串一下。

想象你是一个厨师。

CLAUDE.md（Prompt）就是你厨房墙上贴的菜谱和规矩。「这家店不用味精」「所有肉必须腌制两小时以上」。它定义了基本的规范。

Skills就是你的标准化制作流程。「宫保鸡丁SOP」，从切丁的大小到下锅的顺序到调味的比例，全部标准化。新来的厨师照着做就行。

MCP就是你的供应链和厨房设备。冰箱里有什么菜？烤箱能用吗？外卖系统能不能直接接单？没有这些，你手里有再好的菜谱和SOP也做不出菜来。

对于测试工程师来说，一个理想的工作流大概长这样，

CLAUDE.md
定义测试规范、框架偏好、命名约定
        ↓
/generate-tests Skill
按规范自动生成测试用例
        ↓
Playwright MCP
实际执行UI自动化测试
        ↓
/test-report Skill + Jira MCP
分析结果 + 自动提Bug单

三层各司其职，组合起来才是一个完整的AI测试工作流。

说真的，我自己在搭建这套东西的时候，也走了不少弯路。

一开始我犯了一个很典型的错误，就是什么都往Prompt里塞。把测试规范、执行流程、工具配置全写进一个巨大的CLAUDE.md里。结果就是每次对话，Claude的上下文窗口一大半都被这些静态信息占满了，真正干活的空间反而很小。

后来我才想明白，CLAUDE.md只放那些「每次都需要知道」的基本规范就行了。具体的操作流程封装成Skill，用的时候再加载。外部工具的连接交给MCP。

这就像收拾房间，常用的放桌面上，不常用但重要的放抽屉里，需要连外部世界的装个网线。

另一个我踩过的坑是，一开始不理解MCP和Skills的边界。

比如我想让Claude帮我在云效（Bug管理平台）上提Bug，我一开始是写了一个Skill，里面用Bash命令调API。

后来改成MCP的方式，把云效的API封装成一个MCP Server，Claude Code通过标准协议去调用，清爽多了。而且MCP Server可以复用，不只是提Bug，查Bug、改状态、关联用例都能用同一个Server。

对于提Bug的场景，封装成Skill，还是MCP Server 其实都可以，建议先以Skill形式，如果实在不满足使用场景再改为MCP ，很多简单的场景脚本+API调用就能完成的，封装SKill就够了

Skill负责编排流程，MCP负责连接外部系统，各管各的事，这才是对的。

最后，我整理了一个简单的决策树，帮你快速判断什么时候该用哪个。

• 你的需求是定义团队规范和基本约定？→ 用CLAUDE.md

• 你的需求是一个快速的一次性指令？→ 用斜杠命令（Prompt）

• 你的需求是一个可复用的标准化流程？→ 封装成Skill

• 你的需求是连接外部工具和服务？→ 配置MCP Server

• 你的需求是一个完整的自动化工作流？→ 三个组合着来

坦率的讲，AI工具生态现在发展太快了，这三个概念的边界可能在未来还会继续演化。我自己也还在不断摸索和调整。

但我觉得，比起记住每个概念的精确定义，更重要的是理解它们各自的「位置感」。

Prompt是思想，Skills是流程，MCP是连接。

三者不是互相替代的关系，是互相补充的关系。就像一个人，光有想法不行，还得有做事的章法，还得跟外部世界产生连接，才能真正把事情做成。

希望这篇文章能帮你理清这团乱麻。如果你身边也有搞不清这三个概念的同事，转给他们看看，说不定能省下不少来回解释的时间。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～

谢谢你看我的文章，我们，下次再见。