Claude Code 扩展篇：Skills 技能系统与插件架构

2026-07-07 14:00 Claude Code; Skills; MCP; Agent 2472 words 13 min read

This post is not yet available in English. Showing the original.

前三篇我们讲了范式、上手和配置。到这里，Claude Code 已经能按你的规则干活了。但真正让它从”通用助手”变成”你的专属工具”的，是扩展机制——Skills（技能）、Plugins（插件）、以及它们背后那套”渐进式加载”的设计哲学。

这一篇聚焦 Skills。它是 Claude Code 里最容易被低估，也最值得投入的一块。

一、先建立一个心智模型：Agent 自主性的三个阶段

在讲 Skills 具体怎么用之前，先引用一个我认为最精准的框架（来自 sshh.io 的《How I Use Every Claude Code Feature》）。作者把”给 Agent 提供能力”这件事分成三个阶段：

单次提示（Single Prompt）：把所有上下文塞进一个巨大的 prompt。脆弱，无法扩展。
工具调用（Tool Calling）：经典 Agent 模型。人工制作工具，为 Agent 抽象出现实世界。更好，但每个工具都是一层新抽象，会制造上下文瓶颈。
脚本化（Scripting）：给 Agent 访问原始环境的权限——二进制文件、脚本、文档——让它动态地编写代码去和这些东西交互。

Skills 就是第三阶段的产品化。理解这一点，你才明白 Skills 不是”又一个配置文件”，而是一种把”你平时怎么干活”沉淀成 Agent 可复用能力的方式。

用 vibecoding 教程里一句大白话说：Skills 就是告诉 AI”在什么场景就做什么事情”，让它知道自己有哪些额外功能、怎么用。比如 Claude 默认读不了 PDF，装一个 PDF skill，它就会了。

二、Skills 系统架构：零配置可用，有配置强大

Claude Code 的技能系统是一个多层次扩展机制。设计目标只有一句话：零配置可用，有配置强大。

它就像一套厨师工具箱：内置的刀具锅具应对大部分需求，需要做特定菜系时再添专用工具。而且这些工具按层级管理——家庭厨房（用户级）、餐厅厨房（项目级）、连锁标准（管理级）。

内置技能：开箱即用的一批

Claude Code 编译进二进制的内置技能（Bundled Skills）在启动时统一注册。核心的一批始终可用：

技能	用途	典型场景
`verify`	验证代码变更的正确性	提交前的最终验证
`debug`	调试辅助，提供诊断思路	定位 bug 根因
`simplify`	代码简化与重构审查	消除重复、降复杂度
`skillify`	把 prompt 转换成可复用技能	将一次性 prompt 模板化
`remember`	记忆管理（写 CLAUDE.md 条目）	添加项目规范
`batch`	批量文件处理	批量重命名/格式化
`stuck`	帮模型走出困境	陷入循环时的”解围”指令

还有一批 Feature-gated 技能，只在对应功能标志开启时才注册，比如 loop、schedule（远程定时任务）、claude-api（构建 Claude 应用）。这套”条件注册”的设计让同一份代码能服务不同的产品形态。

注意 skillify 这个技能——它能把你临时写的一段 prompt 直接转成一个正式的 SKILL。这是新手起步最省事的路径：先随便写，跑顺了，让它帮你固化。

技能的三个加载层级

文件系统上的技能由统一的加载引擎加载，并行从五个来源收集：

管理策略级（managedSkillsDir）——企业统一下发
用户级（~/.claude/skills/）——你的全局技能
项目级（.claude/skills/）——随项目走、可入 Git
--add-dir 额外目录
旧版 /commands/ 目录（向后兼容）

生效范围和 CLAUDE.md 规则一致：放全局目录就全局生效，放项目目录就只对当前项目生效。

这里有个容易踩的坑,加载引擎会用 realpath 解析符号链接后按物理路径去重。这意味着如果你用符号链接把同一个技能目录挂了两次，它只会加载一次——避免了重复注册和冲突。

三、SKILL.md：技能的定义格式

每个技能是一个目录，目录里放一个 SKILL.md。这是唯一的格式。文件用 YAML frontmatter 配置，最常用的字段：

---
name: my-skill                    # 技能名（也是目录名）
description: 一句话说明这个技能干什么
when_to_use: 当用户需要 XXX 时使用   # 关键：AI 靠这句话判断何时触发
argument-hint: "[arg1] [arg2]"    # 参数提示
allowed-tools:                    # 限定这个技能能用哪些工具
  - Bash
  - Read
  - Write
model: claude-sonnet-4            # 可为技能单独指定模型
context: fork                     # inline（当前上下文）或 fork（独立子进程）
user-invocable: true              # 用户能否用 /skill-name 主动调用
paths:                            # 条件技能：仅当涉及这些文件时激活
  - "src/**/*.ts"
hooks:                            # 技能级生命周期钩子
  pre:
    - command: npm run lint
---

（下面是自然语言写的技能正文，告诉 AI 具体怎么做这件事）

几个字段值得单独说：

when_to_use 是最重要的字段。Claude 自动判断”要不要用这个技能”完全靠它。写得含糊，技能就不会被触发；写得精准，AI 会在恰当的时候自己调起来。
context: fork 让技能在独立子进程里执行——这是节省主上下文的关键（下一篇编排篇会详细讲 Fork）。
allowed-tools 是安全边界。一个只该读文件的技能，就别给它 Write 和 Bash。
paths 让技能变成”条件触发”——只有当本次任务涉及匹配的文件时才激活，平时不占上下文预算。

渐进式加载：Skills 的上下文经济学

Skills 最精妙的地方是按需加载。技能的正文（prompt 生成器）是延迟执行的——只在技能真正被调用时才运行；引用文件（files）也是首次调用时才提取到磁盘。

这对应了 vibecoding 教程里那条制作建议：如果字数多，就分目录，在主文件里放引导，避免 AI 一次性加载过多信息浪费 token。一个好技能的 SKILL.md 主文件应该很薄，把细节拆到子文件，让 AI 需要时再去 Read。

安全细节：技能引用文件在提取时用了 O_NOFOLLOW（防符号链接劫持）、O_EXCL（防 TOCTOU 竞态）、0o600 文件权限（防泄露）。这些不是你日常要关心的，但它体现了一个原则——扩展机制的每个入口都是潜在攻击面，都要设防。这也是自定义 Skills 时你该有的意识：别在 SKILL.md 里硬编码密钥。

四、怎么做一个 Skill

新手起步最简单的两条路：

# 1. 用官方的 skill-creator 来创建（推荐新手）
claude install anthropics/skills/skill-creator

# 2. 或者直接 npx 安装现成技能
npx skills add https://github.com/anthropics/skills --skill skill-creator

skill-creator 是 Anthropic 官方的 Skill 开发助手，会引导你创建、优化、打包技能。

日常实践中更常见的做法是：遇到重复的事，就把它固化成 Skill。比如代码审查——每次都要提醒 AI 检查哪些点，与其每次手打 prompt，不如做成一个 review skill。当结果和预期不一致时，实时更新这个 skill 就行。这就是把”通解”转化成”你自己的特解”。

五、Skills vs MCP：一个正在发生的重心转移

这是本篇最想讲清楚的一个判断：很多资深使用者正在从 MCP 转向 CLI + Skills。

sshh.io 那篇文章说得很直接：他已经在大多数开发工作流里放弃了 MCP，转向构建简单的 CLI。理由是——以前很多人构建了糟糕的、上下文沉重的 MCP，塞了几十个只是镜像 REST API 的工具（read_thing_a()、read_thing_b()、update_thing_c()……）。每个工具都占着上下文，还把 Agent 锁进僵硬的、类 API 的调用模式。

那 MCP 就没用了吗？不是。它的角色变精准了：MCP 不该是臃肿的 API，而该是一个简单、安全的网关，只提供少数几个高层次工具:

download_raw_data(filters…)
take_sensitive_gated_action(args…)
execute_code_in_environment(code…)

在这个模型里，MCP 的职责不是替 Agent 抽象现实，而是管理认证、网络和安全边界，然后让开。它给 Agent 一个入口点，剩下的让 Agent 用脚本能力（Skills）自己完成。

一个很有代表性的表态：那位作者唯一还在用的 MCP 是 Playwright——因为浏览器是一个复杂、有状态的环境，值得用 MCP 管理。而所有无状态的工具（Jira、AWS、GitHub），他都迁移到了简单的 CLI。

给你的实践建议：不要一上来就装一堆 MCP。vibecoding 教程说得对——首次使用可以什么工具都不装，先建立这个思维。用一段时间后你自然知道自己缺什么，那时再针对性地装。对大多数场景，一个记得住文档的 context7、一个能操作浏览器的 playwright 就够了，其余的用 CLI + Skills 解决。

小结

Skills 是 Agent”脚本化”阶段的产品化，本质是把”你怎么干活”沉淀成 AI 可复用的能力。
SKILL.md 的 when_to_use 决定技能能否被自动触发；context: fork 和 paths 决定它是否省上下文。
渐进式加载是 Skills 的核心经济学：主文件薄、细节拆分、按需 Read。
重心正在从”臃肿 MCP”转向”CLI + Skills”，MCP 退回到”安全网关”这个更专注的角色。

下一篇进入编排篇：子智能体、Fork 模式和协调器——当一个 Agent 不够用时，Claude Code 怎么让多个 Agent 协同。

主要参考：

《御舆：解码 Agent Harness》第 11 章”技能系统与插件架构”（lintsinghua/claude-code-book，CC BY-NC-SA 4.0）
sshh.io《How I Use Every Claude Code Feature》中译（Skills / MCP 章节）
L 站《AI 编程新阶段 Claude Code 上手指南》Skills 教程部分