Skill、Slash Command、MCP、Rules 到底怎么选？
很多人在搭建 AI 工作流时，最容易混淆的就是这 4 个概念：
- Skill
- Slash Command
- MCP
- Rules
它们都能"影响 AI 怎么做事"，但分工完全不同。
如果用一句最白话的话来概括：
- MCP 决定：AI 能连到什么工具
- Skill 决定：AI 拿到工具后，应该按什么流程做
- Slash Command 决定：我想立刻执行一个快捷动作
- Rules 决定：AI 无论做什么，都要遵守哪些通用规则
一、先用最直白的话理解这 4 个概念
1. Skill：可复用的"工作方法包"
你可以把 Skill 理解成：
把某个领域的最佳实践、固定流程、标准步骤，打包给 AI 使用。
它适合处理这类任务：
- 步骤比较多
- 输出有标准
- 希望每次结果都稳定
- 能重复复用
- 最好还能给团队共享
比如：
- 按公司模板生成项目周报
- 给新 API 自动补文档、做兼容性检查、生成测试框架
- 按品牌规范生成宣传文案和海报说明
简单说：Skill 更像"标准作业手册"。
2. Slash Command：一次性快捷指令
Slash Command 就是用户手动输入的快捷命令，比如：
text
/summary
/fix
/translate它更适合：
- 临时操作
- 单次执行
- 逻辑简单
- 不需要长期复用
比如：
- 快速总结这段文字
- 把这句话翻译成英文
- 让 AI 帮你润色一段邮件
简单说：Slash Command 更像"快捷键"。
3. MCP：让 AI 连接外部系统
MCP 是 Model Context Protocol 的缩写。
可以把它理解成：给 AI 接上外部工具和数据源的标准接口协议。
比如连接：
- 数据库
- GitHub
- Notion
- 日历
- 邮件系统
- 工单系统
- Linear、Jira 等项目管理工具
MCP 解决的是：
AI 能不能访问外部世界的数据和工具。
但它本身不负责告诉 AI：
- 先做什么
- 后做什么
- 按什么标准做
- 哪些步骤不能漏
所以：MCP 提供能力，Skill 提供方法。
4. Rules：始终生效的全局规则
Rules 就是一直放在上下文里的"长期约束"，例如：
- 始终用中文回答
- 输出必须是 Markdown
- 回答不要超过 300 字
- 代码注释必须是英文
- 给出结论时必须先列风险
它适合：
- 全局统一风格
- 长期约束
- 不需要复杂流程
- 不依赖外部工具
简单说：Rules 更像"办公室通用制度"。
二、四者对比：一张表看懂差别
| 维度 | Skill | Slash Command | MCP | Rules |
|---|---|---|---|---|
| 触发方式 | AI 根据任务自动判断，也可主动调用 | 用户手动输入 /xxx |
调用外部工具时自动触发 | 始终在上下文中生效 |
| 内容复杂度 | 高：适合多步骤流程、脚本、模板、引用文件 | 低：通常是一小段固定提示词 | 中：主要是工具接口定义 | 低：主要是行为约束 |
| 上下文占用 | 极低：通常只加载元数据，需要时再取详细内容 | 中：会直接加载固定提示词 | 高：常常要一次性加载工具定义 | 低：规则持续存在，但内容通常不长 |
| 可分发性 | 强：天然适合团队共享和生态传播 | 弱：通常只适合个人临时使用 | 强：可以通过服务端共享工具能力 | 弱：多为个人或组织内部配置 |
| 最适合的场景 | 标准化工作流、跨项目规范、领域最佳实践 | 一次性快捷动作 | 访问外部系统和实时数据 | 全局风格、语言、格式约束 |
三、不会选？用这个"简单判断法则"
如果你还拿不准，按下面这套逻辑判断就行：
1. 需要调用外部系统？
比如：
- 查数据库
- 发邮件
- 读日历
- 写 Notion
- 操作 GitHub
- 更新 Linear / Jira
那优先选：→ MCP
因为这类问题的关键不是"提示词怎么写"，而是 AI 能不能接触到这些系统。
2. 只是一条长期有效的统一约束？
比如：
- 一律用中文
- 输出必须是表格
- 不要使用 emoji
- 每次回答最后都给建议
那优先选：→ Rules
因为这不是工作流，而是"长期生效的共识"。
3. 只是一个一次性的小动作？
比如：
- 帮我总结这段话
- 快速翻译
- 改写一句标题
- 生成一个 commit message
那优先选：→ Slash Command
因为它追求的是"快"，不是"复杂"和"可复用"。
4. 是可重复、可共享、可标准化的工作流程？
比如：
- 新功能上线前检查清单
- 内容发布前品牌审校
- 新 API 发布后的文档和测试流程
- 每周固定格式的项目汇报
那优先选：→ Skill
因为你需要的不是一句提示词，而是一整套稳定方法。
四、什么任务最适合写成 Skill？
根据 Anthropic 的总结，Skill 最适合 3 大类场景。
如果你的任务落在下面这些类型里，基本就值得做成 Skill。
场景一：文档与资产创建
Document & Asset Creation
这里的"资产（Asset）"可以理解为：
文档、演示稿、视频、设计稿、海报、网页、社媒图文等可交付成果。
适合哪些人？
几乎所有知识工作者都适合，尤其是：
- 运营
- 产品经理
- 设计师
- 市场营销人员
- 行政与销售支持
- 需要经常产出文档的人
这类任务的核心特征
它们通常都有一个共同点：
- 最终输出要"像专业人士做的"
- 风格、格式、结构有固定标准
- 不只是"写出来"，而是"写得对、做得像、符合规范"
比如：
- 宣传文案要符合品牌语气
- PPT 要符合公司模板
- 前端页面要符合设计规范
- 海报要遵守视觉标准
- 视频脚本要符合平台节奏
典型案例
-
给产品制作宣传视频
例如：把分镜、旁白、字幕风格、节奏要求都写进 Skill，让 AI 按专业视频流程生成脚本。
-
生成高质量前端界面
例如：把组件规范、布局原则、交互建议、响应式要求放入 Skill，减少"看起来能用，但不专业"的结果。
-
按公司模板生成 Word / PPT / Excel
例如：标题层级、封面格式、数据表写法、图表标准，都可以被固定下来。
-
生成符合设计规范的海报或社交媒体图文
例如：品牌色、文案语气、字号层级、图片建议、禁用表达，都能写入 Skill。
为什么这类任务特别适合 Skill？
因为很多时候，问题不在于 AI "不会写"，而在于你自己也很难准确描述什么叫"专业标准"。
举个很常见的情况：
- 你知道自己想要一份"像大公司做的产品介绍"
- 但你不一定说得清：
- 结构怎么排
- 语气怎么定
- 哪些信息先讲
- 图文比例如何控制
- 什么叫"高级感"
这时 Skill 的价值就出来了：
Skill 能把专家经验提前装进去
这样 AI 不需要每次从零猜，而是直接按成熟方法执行。
也就是说：
- 你不熟悉某个领域
→ Skill 帮你补足专业方法 - 你知道结果要高标准
→ Skill 帮你稳定输出 - 团队多人都要做类似内容
→ Skill 帮你统一质量
场景二：工作流自动化
Workflow Automation
这类任务的重点不只是"产出内容"，而是"按固定步骤持续完成工作"。
适合哪些人？
尤其适合：
- 开发者
- 测试工程师
- 技术负责人
- 项目经理
- 运营同学
- 所有存在重复性工作的岗位
这类任务的核心特征
这类任务通常具备 4 个特点：
- 步骤多
- 每一步都不能漏
- 每次都希望结果一致
- 重复出现，值得沉淀
比如：
- 每次发版前都要走一套检查流程
- 每次新增接口都要同步文档、测试和兼容性验证
- 每周项目汇报都有固定模板
- 每次代码提交前都要做规范化审查
典型案例
1. 新增 API 后自动完成一整套动作
例如：
- 检查接口命名是否规范
- 生成或更新接口文档
- 补充变更说明
- 校验兼容性风险
- 提示需要增加哪些单元测试
这已经不是一句"帮我写文档"能解决的事了，
它更像是一条完整流水线。
2. 提交代码前自动执行 Code Review 规范
例如检查：
- 命名是否清晰
- 是否有重复逻辑
- 是否有潜在空指针或边界问题
- 是否缺少测试
- 是否违反团队约定的架构规则
如果把这些审查思路写进 Skill，AI 每次都能按同样的标准检查。
3. 按固定模板生成项目进展报告
例如统一包含：
- 本周完成项
- 风险点
- 依赖项
- 下周计划
- 需要管理层协助的事项
这样团队每次看到的报告结构都一致，方便比对和决策。
为什么这类任务特别适合 Skill？
1. 重复动作可以脚本化，减少遗漏
很多工作其实不难，难的是"步骤多，容易忘"。
Skill 的作用，就是把"人脑记忆"变成"机器执行"。
2. 不依赖 AI 临场发挥，结果更稳定
如果不做成 Skill，你往往要每次提醒 AI：
- 先做这个
- 再做那个
- 别忘了检查第三项
- 最后按模板输出
但 AI 每次理解角度可能不同，结果也会飘。
Skill 则能把流程固定下来，让执行更稳定。
3. 能减少上下文消耗，降低成本
这里的"上下文"指的是 AI 当前处理任务时需要加载的信息量。
如果你每次都把整套流程手动贴进去：
- 内容长
- token 消耗高
- 成本更高
- 还容易复制错、漏贴
而 Skill 可以把这些步骤固化到文件里，按需调用。
这样既省成本，也更方便维护。
注：Token 可以简单理解为 AI 处理文本时使用的计量单位。
文本越长、规则越多、提示越复杂，消耗的 token 往往越高。
场景三：MCP 能力增强
MCP Enhancement
这是很多团队最容易忽略、但其实最有价值的组合方式。
先说结论
MCP 和 Skill 不是替代关系，而是互补关系。
- MCP 负责：给 AI 工具权限
- Skill 负责：教 AI 正确使用这些工具
换句话说：
- MCP 解决的是 "AI 能做什么"
- Skill 解决的是 "AI 应该怎么做"
为什么光有 MCP 还不够？
很多团队接入 MCP 后，会以为 AI 已经"能自动干活了"。
但实际使用时往往发现：
- AI 虽然能访问系统
- 却不一定知道最佳操作顺序
- 也不一定知道你的团队标准
- 更不知道什么是"高质量完成"
结果就是：
能力有了，方法没有。
典型案例
1. 接入 Linear MCP，但 Sprint 规划总要重新解释
假设 AI 已经能读取 Linear 里的任务信息。
它现在"能看到任务"了，但它不知道：
- 你的 Sprint 怎么拆分
- 优先级如何评估
- 哪些任务应当延后
- 风险项怎么标注
- 依赖关系如何处理
这时就可以写一个 Skill，把这套 Sprint 规划流程固定下来。
2. 接入 GitHub MCP，但代码审查没有统一标准
AI 可以读 PR、看 diff、查提交记录。
但如果你不告诉它审查原则，它可能只能给出零散建议。
如果配套一个 Skill，你就可以明确规定：
- 先看变更范围
- 再查架构影响
- 再看测试覆盖
- 再找安全与性能风险
- 最后按统一模板输出审查意见
这样，AI 的审查才会变成真正可用的团队流程。
Skill + MCP 的最佳组合价值
当两者结合时，效果通常远大于单独使用：
1. MCP 提供"触手"
让 AI 真的能访问外部信息和系统。
2. Skill 提供"大脑中的方法论"
让 AI 不只是"看到了"，而是"知道怎么做才对"。
3. 用户不必每次从头解释
最直接的收益是：
- 少写重复提示词
- 少解释流程
- 少担心 AI 漏步骤
- 多得到稳定结果
这对技术团队尤其重要，因为很多真实工作并不是"调用一下工具"就结束，而是要走完完整链路。
五、判断一个任务值不值得做成 Skill，看这 4 个信号
如果一个任务满足越多项，就越适合沉淀成 Skill。
信号 1：这个任务会重复出现
如果只是做一次，写 Slash Command 往往就够了。
如果每周、每天、每个项目都要做，Skill 就很值得。
信号 2：它有明确步骤，且步骤不能漏
比如：
- 先收集信息
- 再分析
- 再校验
- 最后按模板输出
这就是典型的 Skill 候选。
信号 3：任务背后有专业标准
比如：
- 品牌规范
- 法务审查要点
- 设计准则
- Code Review 标准
- 项目管理流程
只要"不是随便做都行"，而是"要按专业规则做"，Skill 就特别有价值。
信号 4：团队里不止一个人会用到
如果这套方法只有你自己偶尔用一次，那不一定值得沉淀。
但如果团队里很多人都在重复类似操作，把它做成 Skill 就能快速放大价值。
六、一句话总结：什么时候该用谁？
你可以直接记住下面这 4 句：
- 要连外部系统：用 MCP
- 要长期统一行为：用 Rules
- 要快速执行一次小动作：用 Slash Command
- 要沉淀成可复用、可共享、可标准化的流程：用 Skill
七、最后的核心判断
如果一个任务同时满足下面这些条件：
- 会重复发生
- 有固定步骤
- 有明确质量标准
- 希望团队共享
- 最好还能减少提示词重复输入
那么它几乎就是一个标准的 Skill 场景。
而如果这个任务还需要连接 GitHub、Notion、数据库、工单系统等外部工具，
那最理想的组合通常就是：MCP + Skill
也就是：
- MCP 负责接工具
- Skill 负责定流程
这也是很多团队把 AI 从"会聊天"升级为"能稳定干活"的关键一步。