当前位置：首页 > news >正文

秒懂SKILLS: 模块化的RULES + 轻量化脚本

news 2026/5/11 17:17:34

为什么我们需要skills?

众所周知，在AI编程的语境下，RULES几乎是必不可少的，人们需要在RULES中提前给AI制定规则：

它是一个什么样的角色
本工程采用了什么技术栈，它应该按什么编码规范来编码，如何组织工程代码。
当遇上一些非常见情况时，它应该如何处理，遵循什么原则
如何处理某些异常

但是，问题来了：

如果 RULES 太短，那它能覆盖的范围就非常有限。
如果 RULES 太长，每次会话AI都需要完全加载一遍它，浪费token倒是其次，重要的是token会降低AI的准确性提升幻觉。

于是，模块化【懒加载】的诉求，便血淋淋摆在人们面前了。

SKILLS要解决的也正是这个痛点。

它允许不同的规则被注册在不同的 SKILL.md 中，只在需要的时候进行加载。

SKILLS 的结构

要实现懒加载，有一个重要的问题需要解决：

大模型需要知道合适加载哪个 Skill。

因此，SKILLS的结构笼统性来说，分为两个部分：

元数据: 告诉大模型我是谁，我有什么能力，什么时候应该调用我。
内容：指导大模型如何进行编程。

这是一个典型 SKILL.md 文件的结构：

--- name: API公约 description: 适用于当前代码库的 API 设计模式 --- 在编写 API 接口（端点）时： - 遵循 RESTful 命名规范 - 返回统一的错误格式 - 包含请求参数校验

在头部被---包裹起来的部分就是markdown元数据，在这里它们被用来描述技能本身的特性。

name：技能的名称
description：技能的描述，有什么用，什么时候应该被加载

而下面具体指导编程规范的部分，则是该技能的【内容】。

一开始的时候，【内容】并不会被加载到上下文中，只加载精简过的【元数据】，这会极大地节约token消耗，也能降低模型幻觉。

SKILLS 放在哪？

结合 Claude Code、Trae、OpenCode 以及 Cursor 的最新文档，

Claude Code

位置：项目根目录 /.claude/skills/

结构：

ProjectRoot/ └── .claude/ └── skills/ ├── skill-a/ <-- 技能名称文件夹 │ ├── SKILL.md <-- 核心定义 (SOP & Prompts) │ └── scripts/ <-- (可选) 对应的 Python/Node 脚本 └── skill-b/ └── SKILL.md

生效方式：Claude Code 启动时自动扫描该目录，根据 User Prompt 和 SKILL.md 中的 description 自动挂载。

OpenCode

位置：通常为 /.opencode/skills/

Project config: .opencode/skills/<name>/SKILL.md Global config: ~/.config/opencode/skills/<name>/SKILL.md Project Claude-compatible: .claude/skills/<name>/SKILL.md Global Claude-compatible: ~/.claude/skills/<name>/SKILL.md

Cursor

位置：通常为 /.cursor/skills/

.cursor/ └── skills/ └── deploy-app/ ├── SKILL.md ├── scripts/ │ ├── deploy.sh │ └── validate.py ├── references/ │ └── REFERENCE.md └── assets/ └── config-template.json

Trae

位置：通常为 /.trae/skills/

.trae/skills/ ├──skill-name/ ├── SKILL.md ├── scripts └── references

总的来说，各家有各家的习惯和地盘，希望后续能统一成标准吧。

有了SKILLS，可以不要MCP了吗？

绝对不可以！

它们并不是互斥的两套技术。

恰恰相反，它们是 “黄金搭档”，是底层能力 (Capabilities) 与上层应用 (Applications) 的关系。

如果把构建 Agent 比作雇佣一个员工，那么：

MCP (Model Context Protocol) 是这个员工的 “手”和“感官”。
- 它定义了员工能做什么（比如：能拿杯子、能查数据库、能运行 Python 代码）。
- 它解决了“怎么连接”的问题（标准化的接口协议）。
Skills (技能/规则) 是这个员工的 “职业培训手册” (SOP)。
- 它定义了员工该怎么做（比如：看到客人来了要倒水、查库前要先鉴权、代码报错了要重试）。
- 它解决了“怎么思考”和“怎么决策”的问题（业务逻辑与流程控制）。

总的来说，只要把SKILLS当作模块化的RULES来理解会比较容易。

但，SKILLS 除了是模块化的 RULES 外，它还有一个重要的能力：

它具备脚本执行能力。

软硬一体的 SKILLS

之前的回答为了强调“规则”的重要性，确实简化了 Skills 的定义。实际上，完整的 Skills 是“软硬一体”的。

在 Claude Code 的架构中，一个 Skill 确实可以包含它私有的、本地的脚本。

1. 重新定义：Skills 的完整公式

纠正之前的定义，现在的公式应该是：

Skill = 🧠 业务规则 (SOP) + 🛠️ 专用脚本 (Local Scripts)

SOP (SKILL.md)：这是大脑。它告诉 AI 什么时候用、怎么用。

Scripts (/scripts/*.py)：这是随身工具包。它是为了配合这个 SOP 而存在的轻量级代码。

2. 为什么要允许 Skill 包含脚本？

既然有了 MCP，为什么还需要 Skill 自带脚本？

这就像：虽然工厂里有重型机床（MCP），但工人腰带上还是得挂一把螺丝刀（Skill Script）。

主要有以下三个原因：

A. 降低依赖 (Self-Contained) 如果你的 Skill 只是为了做一些简单的文本处理（比如“把 xxx 格式化一下”），为此启动一个 HTTP MCP Server 太重了。把这个逻辑写成一个 20 行的 Python 脚本放在 Skill 文件夹里，随拿随用，这才是“技能包”的便携性。
B. 胶水逻辑 (Glue Logic) 有时候，MCP 提供的原子能力太碎了。
- MCP 工具 A：get_file_list
- MCP 工具 B：analyze_file
- Skill 脚本：你可以写一个脚本，循环调用 A，过滤结果，然后传给 B，最后输出统计报表。
- 优势：你把“循环与判断”的计算压力从 LLM（昂贵、慢）转移到了 CPU（便宜、快）。
C. 本地文件操作 Claude Code 是在本地运行的。Skill 脚本可以直接通过 bash 访问你项目里的文件系统，这比远程 MCP Server 通过网络传输文件内容要高效得多。

-END -

如果您关注前端+AI 相关领域可以扫码进群交流

添加小编微信进群😊