01Skill 和 MCP 的区别
一句话区分: Skill 是「操作说明书」,改变模型的行为方式; MCP 是「新接口」,给模型提供原本没有的能力。
两种能力的本质差异
| Skill | MCP | |
|---|---|---|
| 本质 | 知识 + 流程:告诉模型「遇到这类任务,按这个步骤做」 | 通道 + 动作:告诉模型「你可以调用这个工具,它真能做事」 |
| 载体 | Markdown 文档(SKILL.md)+ 可选脚本/模板/参考文件 | 一个可执行进程(Python/Node 等),通过 stdio 或 HTTP 通信 |
| 运行位置 | 模型「读进去」的上下文,不产生外部副作用 | 独立进程,真实操作外部世界(文件、网络、服务器) |
| 给模型什么 | 步骤、规范、示例、禁忌——提升回答质量 | 工具列表 + 参数 schema——扩展能力边界 |
| 典型例子 | 「写中文技术文档用这套排版规范」「遇到 bug 先按五步排查」 | 「查服务器磁盘」「发飞书消息」「执行 nginx -t」 |
打个比方
Skill = 给新员工培训手册
- 教他公司的行文规范、审批流程、禁忌事项
- 手册本身不干活,但员工读了活干得对
- 内容越具体,执行越稳定
MCP = 给员工配新工具
- 给他一台服务器、一个数据库客户端、一部电话
- 工具真能产生外部效果,也能造成外部破坏
- 能力越强,越需要安全护栏
▎两者常常配合使用
一个 MCP server 提供「能查服务器」的工具,一个 Skill 教模型
「部署前先备份、验证用哪几个命令、回滚怎么走」——工具负责能做什么,
Skill 负责该怎么做。本系列第一篇的 chengdu-mcp(23 个服务器运维工具)
就是这种配合的实例。
02哪些做 Skill,哪些做 MCP
决策表:拿到需求先过这四个问题
| 问题 | 答「是」→ 倾向 | 答「否」→ 倾向 |
|---|---|---|
| 需要真实操作外部系统吗?(写文件、发请求、跑命令) | MCP(要通道) | Skill(纯知识/流程) |
| 核心价值是「教模型按什么套路做」吗? | Skill(要行为规范) | MCP |
| 会被多个客户端 / 多种模型复用吗? | MCP(协议标准,客户端通用) | Skill(跟 Agent 框架绑定较紧) |
| 能力是「稳定接口」还是「易变知识」? | MCP(接口要稳) | Skill(知识要常更新) |
实战案例对照
| 需求 | 该做什么 | 理由 |
|---|---|---|
| 「帮我查一下服务器磁盘和 nginx 状态」 | MCP | 要真实执行命令、读远端文件,必须有通道 |
| 「写公众号文章按历史排版规范来」 | Skill | 是行为规范:查重规则、排版基线、发布流程,不碰新系统 |
| 「用公司内部 API 发审批」 | MCP | 稳定的外部接口,还要处理认证、错误码——封装成工具 |
| 「写代码前先写测试(TDD)」 | Skill | 纯流程规范,教模型按红-绿-重构套路走 |
| 「部署到服务器」 | 两者结合 | MCP 提供 scp/nginx/备份工具;Skill 规定部署步骤与验证清单 |
▎最常见的误用
把「操作流程」硬写成 MCP 工具,或把「系统接口」硬塞进 Skill。
前者会让工具数量爆炸、每个工具都很「薄」;后者会让 Skill 里全是
「调用某 API 的命令」,换环境就失效。记住:工具是名词,Skill 是动词。
03一个极简 Skill 示例(可落地)
一个 Skill 就是一个目录,核心文件是 SKILL.md(YAML frontmatter + Markdown 正文)。
以「部署前必须备份」为例——这个 Skill 的价值是让模型每次都记得先备份,
而不是偶尔记得:
backup-before-deploy/SKILL.md
---
name: backup-before-deploy
version: 1.0.0
description: "部署前必须备份。当用户要对线上站点/nginx 配置做任何修改、覆盖、回滚、升级时使用。不负责执行部署本身。"
metadata:
requires:
bins: ["ssh"]
---
# 部署前备份(强制)
**触发条件**:模型检测到用户要对线上资源做写操作(覆盖文件、改 nginx 配置、
重启服务、升级版本)时,无论用户是否主动要求,都必须先走本 Skill。
## 步骤
1. 确认目标路径属于可备份范围(站点目录 / nginx conf.d / 数据库文件)。
2. 执行备份,命名带时间戳:
ssh chengdu "cp -a /var/www/zhugdamo_cn/site /root/backups/site-$(date +%Y%m%d_%H%M%S)"
3. 校验备份确实生成(ls 确认存在、体积合理),备份失败立即中止部署。
4. 向用户报告备份路径,再继续部署。
## 禁忌
- 绝不在没有备份的情况下覆盖线上文件。
- 备份失败 ≠ 继续部署,必须停下。
## 验证
部署完成后,把新文件与备份 diff 一遍,确认改动符合预期。
关键点
| 要素 | 示例里在哪 | 为什么重要 |
|---|---|---|
| 触发条件 | frontmatter description + 正文第一段 | 让模型在「用户没明说」时也能主动想起用这个 Skill |
| 编号步骤 | ## 步骤 1-4 | 模型对编号步骤的执行率远高于散文描述 |
| 禁忌(负面约束) | ## 禁忌 | 只讲「怎么做」不够,要讲「什么不能做」 |
| 验证环节 | ## 验证 | 闭环:做完还要确认做对了 |
04常见 Skill 代码分析
下面拆解的是生产级 Skill 的完整结构(取自本机技能库中真实在用的
lark-approval 等技能,它们服务日常飞书审批等真实任务)。
4.1 frontmatter:给调度器看的元数据
---
name: lark-approval
version: 1.2.0
description: "飞书审批:查询和处理审批待办/已办/实例……当用户要处理审批任务、查看审批实例、搜索或发起审批时使用。审批待办不是飞书任务;非审批类待办走 lark-task。不负责创建审批定义;三方审批定义不走原生提单。"
metadata:
requires:
bins: ["lark-cli"]
cliHelp: "lark-cli approval --help"
---
| 字段 | 作用 |
|---|---|
name | 唯一标识,目录名保持一致 |
version | 语义化版本,改内容要升版本 |
description | 最重要的字段——Agent 靠它决定「什么时候加载这个 Skill」。要写清触发场景、边界(什么情况不用它) |
metadata.requires.bins | 前置依赖声明,缺了工具直接提示安装 |
▎description 是给「检索」看的
模型不是每次把所有 Skill 都读一遍,而是先扫描 description 决定加载谁。
写得模糊(「处理审批」)会被漏掉;写得具体(含触发词、排除边界)
才会在正确时机被想起。这个字段值得花最多心思。
4.2 正文:路由规则放最前
**CRITICAL — 开始前 MUST 先用 Read 工具读取 [`../lark-shared/SKILL.md`](../lark-shared/SKILL.md),
其中包含认证、权限处理**
所有命令默认 `--as user`(审批是人的动作)。调用前先按需读取 references 下对应的文件,
查参数结构,不要猜字段;**references 是第一信息源**……
## 路由优先级(先判断是不是审批,再选命令)
审批待办不是飞书任务。**只要用户的核心对象是审批单据 / 审批待办 / 审批实例,
就优先使用 `lark-approval`,不要让渡给 `lark-task`。**
### 明确归 `lark-approval` 的高优先级语义
- 审批待办 / 审批单据 / 审批实例 / 审批意见 / 审批定义
- 同意 / 拒绝 / 转交 / 退回 / 撤回 / 催办 / 加签 / 抄送
……
**判定规则:** 只要最终动作是对审批单据做同意、拒绝、转交……就归 `lark-approval`。
只有当用户处理的是**非审批类任务/待办**时,才走 [`lark-task`](../lark-task/SKILL.md)。
4.3 生产级 Skill 的共性结构
| 结构 | 作用 |
|---|---|
| CRITICAL 前置说明 | 必须先读的共享前置(认证、通用规则)用粗体 + MUST 强调,模型不会跳过 |
| 路由优先级 | 多个 Skill 边界重叠时,写清「什么情况归我、什么情况让给谁」 |
| References 引用 | 大参数表、完整命令清单放 references/ 目录,正文保持短——正文太长模型会「读不完」 |
| 「不要猜字段」 | 明确禁止模型凭记忆编参数,强制查 reference——这是减少幻觉的关键指令 |
| 判定规则 | 把「是/不是」的边界写成可判定的清单,而不是模糊描述 |
4.4 Skill 还能带什么
my-skill/
├── SKILL.md # 主文档:触发条件 + 步骤 + 禁忌 + 验证
├── references/ # 参数表、API 文档、完整命令清单(按需读取)
├── templates/ # 可直接套用的模板(报告、prompt、配置文件)
└── scripts/ # 可执行脚本(skill 可调用,如验证脚本、转换器)
05Skill 写作的三个常见坑
| 坑 | 表现 | 修法 |
|---|---|---|
| 正文写成散文 | 一坨长段落,模型执行时丢步骤 | 拆成编号步骤、表格、清单;一条指令一行 |
| 只写怎么做,不写不能做 | 模型在边界场景自由发挥,出错 | 专门写「禁忌」「不适用场景」小节 |
| 一更新就全量重写 | 版本混乱,老逻辑被误删 | 改内容升 version;用 patch 局部更新;沉淀「踩过的坑」小节 |
▎Skill 的维护原则
用的时候发现 Skill 过时、步骤缺失、命令错误,当场修掉(patch),不要等下次。
技能库是活文档——每次踩坑都是它变强的机会。判断标准:
一个流程第二次遇到时,就该考虑固化成 Skill 了。