为什么我们需要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.mdCursor位置通常为 /.cursor/skills/.cursor/ └── skills/ └── deploy-app/ ├── SKILL.md ├── scripts/ │ ├── deploy.sh │ └── validate.py ├── references/ │ └── REFERENCE.md └── assets/ └── config-template.jsonTrae位置通常为 /.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 工具 Aget_file_listMCP 工具 Banalyze_fileSkill 脚本你可以写一个脚本循环调用 A过滤结果然后传给 B最后输出统计报表。优势你把“循环与判断”的计算压力从 LLM昂贵、慢转移到了 CPU便宜、快。C. 本地文件操作 Claude Code 是在本地运行的。Skill 脚本可以直接通过 bash 访问你项目里的文件系统这比远程 MCP Server 通过网络传输文件内容要高效得多。-END -如果您关注前端AI 相关领域可以扫码进群交流添加小编微信进群关于奇舞团奇舞团是 360 集团最大的大前端团队非常重视人才培养有工程师、讲师、翻译官、业务接口人、团队 Leader 等多种发展方向供员工选择并辅以提供相应的技术力、专业力、通用力、领导力等培训课程。奇舞团以开放和求贤的心态欢迎各种优秀人才关注和加入奇舞团。