Zed 也支持 Skills 了，AI 编辑器卷到这一步

行业快讯

Zed 在最新版本中加入对 Skills 的支持，至此主流 AI 编辑器在这项能力上完成集结。但作为 Rust 阵营里跑得最快的那个，Zed 这次明显慢了半拍，IntelliJ 系仍在原地观望。

Zed 终于补上了 Skills 这一课

5 月底，Zed 在新版更新里正式加入了对 Skills 的支持。这件事本身不算大新闻，但放在过去两个月的时间线里看就挺有意思——Cursor、Windsurf、Cline、Continue 几乎都在 4 月就跟进了 Skills 这套机制，Zed 这次明显是压着队尾过线的。一位 linux.do 的用户调侃说，"好久没写代码，今天打开 Zed 都开始支持 Skills 了"，话糙理不糙，整个 AI 编程工具圈在这件事上算是完成了一轮集成。

至于一直被开发者追问的 IntelliJ 系，目前依然没有官方动作。JetBrains 的 AI Assistant 和 Junie 走的是另一条路线，短期内大概率不会直接对齐 Anthropic 这套 Skills 协议。

Zed 编辑器 Skills 配置界面截图

先把 Skills 这件事说清楚

对没跟上节奏的开发者，简单解释一下 Skills 到底是什么。

Skills 最早是 Anthropic 在 Claude 平台上推的一套机制，本质上是把"专家知识"打包成可被 Agent 按需调用的模块。每个 Skill 就是一个文件夹，里面放着一个 SKILL.md（用 YAML frontmatter 描述这个 Skill 是干嘛的、什么时候该用）、若干参考文档、可能还有一些可执行脚本。

它跟 MCP（Model Context Protocol）不是一回事，但经常被放在一起比较：

  • MCP 解决的是"模型怎么连外部工具和数据"的问题，是一套通信协议
  • Skills 解决的是"模型在什么场景下、按什么流程办事"的问题，是一套行为说明书
  • Slash Commands 是用户主动触发的快捷指令
  • Subagents 是把任务委派给另一个上下文独立的 Agent

这四者在一个成熟的 AI 编辑器里其实是互补的：MCP 提供能力，Skills 决定怎么用这些能力，Slash Commands 让用户能手动叫起来，Subagents 负责切分任务边界。

一个典型的 Skill 长这样：

.claude/skills/
├── pdf-extraction/
│   ├── SKILL.md
│   ├── reference.md
│   └── scripts/
│       └── extract.py
├── react-component-author/
│   ├── SKILL.md
│   └── examples/
└── postgres-migration/
    └── SKILL.md

SKILL.md 的头部一般是这样：

---
name: pdf-extraction
description: Extract structured data from PDF files including forms, tables and scanned documents. Use when the user mentions PDF parsing, form extraction, or OCR.
---

关键就在 description 这一行。Agent 在每轮对话开始时只会加载所有 Skill 的元信息（也就是这段描述），等判断当前任务相关时才会把完整的 SKILL.md 和参考文件拉进上下文。这是一种典型的渐进式上下文加载思路，跟早期把所有 system prompt 全塞进去的做法完全不同。

Zed 这次怎么接的

Zed 的实现方式遵循了它一贯的"原生集成、配置驱动"风格。Skills 直接挂在 Agent Panel 下，扫描项目内的 .claude/skills/ 和用户全局目录里的 Skills，启用之后会自动出现在 Agent 的可用工具列表里。

相比 Cursor 把 Skills 塞在 Rules 体系底下、Cline 用扩展的方式挂载，Zed 的做法更接近 Claude Code CLI 的原始形态——基本就是 Anthropic 给什么就用什么，没有额外抽象。这其实符合 Zed 团队一贯的克制：能不造概念就不造。

好处是迁移成本几乎为零，你在 Claude Code 里写过的 Skills 直接放进项目里就能用；代价是 Zed 暂时没有 GUI 层面的 Skill 编辑器，全靠手写 Markdown 文件。

慢了一个月，到底慢在哪

值得讨论的是：以 Zed 团队的工程能力，加一个 Skills 加载器其实就是几百行 Rust 的事，为什么压到了 5 月底？

从 Zed 的 GitHub issue 区能看出一些端倪。Zed 的 AI 子系统从去年开始重构过一次，把 Assistant、Agent、Inline Edit 拆得比较清楚，每一层都有自己的上下文管理逻辑。Skills 作为一种外部上下文注入机制，要塞进这套架构得想清楚几个问题：

  • Skills 加载的内容算"工具调用"还是"上下文片段"？算在 input token 哪一栏？
  • 项目级 Skills 和用户全局 Skills 冲突时谁优先？
  • Skills 里的 scripts/ 目录要不要走沙箱？Zed 的 Agent 本来就有 shell 执行权限
  • 多 Provider 场景下（Zed 同时支持 OpenAI、Anthropic、自定义兼容端点），非 Claude 模型怎么用 Skills？

最后一个问题是 Zed 比 Cursor 更头疼的地方。Cursor 的主力 Provider 就那几家，Zed 一直把"自带 API Key、随便接"作为卖点，这就意味着 Skills 机制必须做成模型无关的——不能依赖 Claude 特有的 prompt 模板。从目前的实现看，Zed 选择了在客户端做 prompt 注入，由编辑器负责把 Skill 描述拼进 system prompt，再把按需加载的判断逻辑也放进 prompt 里。换句话说，Skills 在 Zed 里是纯客户端实现，任何支持 tool use 的模型都能跑，包括 GPT 系列、Gemini，乃至开源的 DeepSeek、Qwen3、GLM-4.6 这些。

这也回答了用户那个问题：Skills 不绑死 Claude，但用 Claude 体验最丝滑，因为 Anthropic 在模型层就训过这套调用模式。

Token 消耗的真实情况

linux.do 那位用户还问了一个所有人都关心的问题：开 Skills 之后 token 是不是烧得更快？

答案是：会，但没你想的那么夸张。

机制设计上 Skills 已经做了优化，只有元信息（description 那一行）是默认常驻的，单个 Skill 大概 20-50 token，10 个 Skill 也就 500 token 上下，加在 system prompt 里几乎可以忽略。

真正烧 token 的是被触发之后：

  • 完整的 SKILL.md 加载进上下文，一般几百到几千 token
  • 如果 Skill 引用了 reference.md，那又是几千到上万 token
  • 如果 Agent 决定执行 scripts/ 里的脚本，输出也要回填到上下文

一个典型的复杂任务（比如让 Agent 用 react-component-author Skill 写一个组件），相比不用 Skill 直接问，输入 token 会增加 30%~80%，但输出质量的提升通常远大于这个成本。而且因为 Skill 把"标准做法"固化下来了，Agent 来回试错的次数会减少，总账算下来不一定更贵。

真正需要警惕的是滥用：把几十个 Skill 全开着、每个 Skill 里塞一堆没用的参考文档、description 写得太宽泛导致频繁误触发，这些才是吃 token 的大头。

编辑器格局的一点观察

把视线拉远一点看，过去这两个月 AI 编辑器圈的更新节奏其实挺值得玩味的：

  • Cursor 4 月初接 Skills，搭配自家的 Background Agent 形成了"长任务 + 专家模块"的组合
  • Windsurf 跟进得最快，但实现得最潦草，基本是直接复用 Cascade 的 memory 机制
  • Cline / Roo Code 在 4 月中下旬完成集成，开源社区贡献的 Skill 仓库已经攒了几百个
  • Zed 5 月底压哨上线，实现最干净
  • JetBrains 全家桶 仍然不动
  • VS Code 官方的 Copilot 走的是 GitHub Custom Instructions 那条路，暂时没有对齐计划

这背后的逻辑其实挺清楚的：Skills 之所以能在两个月里走完一轮集成，是因为它的协议成本足够低——一个文件夹、一份 Markdown，谁都能解析。它不像 MCP 那样需要起进程、建连接、维护生命周期，编辑器侧的工作量小到可以一个工程师两周搞定。

但低门槛也意味着差异化空间小。当所有编辑器都支持 Skills 之后，比拼的就回到了底层模型能力、上下文管理、UI 交互这些老问题上。Zed 这次"慢半拍"反倒让我们看清楚一件事：Skills 不是壁垒，会用 Skills 的模型才是。

对开发者的几个实用建议

如果你打算在 Zed 里开始用 Skills：

  1. 先从一两个高频场景开始，比如项目里的代码规范、特定框架的最佳实践，别一上来就堆几十个
  2. description 写得越具体越好，"Use when..." 句式比泛泛的功能描述更容易让 Agent 准确触发
  3. 把 Skill 当文档维护，而不是当 prompt 调优——前者可读、可复用，后者很快就乱
  4. 如果你的工作流横跨多个模型（比如用 OpenAI Hub 这类聚合平台同时接 Claude、GPT-5、Gemini、DeepSeek、Qwen），优先把 Skills 写成模型无关的描述，避免依赖某家特有的 prompt 风格
  5. 定期清理没在用的 Skill，元信息虽然不贵，但 description 写得不好会污染 Agent 的判断

至于 IntelliJ 用户，再等等。JetBrains 这家公司在 AI 这块的节奏一向不快，但一旦动手往往会做得比较深。在那之前，把项目里的 Skill 文件夹建好放着，将来不管哪个工具支持，迁移成本都接近零。

这或许就是 Skills 这套机制最大的好处：它把开发者的知识沉淀，从某一个工具里解放了出来。

参考来源