Goofy Logo高飞宇 | Goofy

从技能集合到能力系统：我最近重新理解 Skill 的方式

这篇文章不是想重新介绍某两个 Skill 怎么用，而是想把我最近一个更具体的变化讲清楚。

前一段时间，我更关心的是怎么找到一个趁手的 Skill，怎么把它改成适合自己项目的样子，怎么把常用动作沉淀下来。那时候我写过 skill-scout 和 skill-squadron，一个偏技能发现与接入，一个偏能力编组与巡检。最近再看一圈公开生态，我发现讨论已经明显往前走了一步：Skills、Rules、Instructions、Prompt files 都在变得更正式，目录、清单和 marketplace 也越来越多。

但我自己遇到的问题，反而不再是“找不到 Skill”。我开始更频繁地卡在另一层：当 Skill 从几个工具，慢慢长成几十个能力对象时，它们到底该怎么组成系统。

这一篇只想补中间还缺的一层：为什么 Skills 开始被目录化、市场化之后，真正难的问题会从“找 Skill”切到“组织 Skill”。

相关公开资源

相关阅读

发生了什么变化

我最近重新看这些公开对象时，最直接的感受不是“又多了几个工具”，而是“能力包装”已经开始成为一件更公开的事。

OpenAI 在讲 Skills，Anthropic 在讲 Agent Skills，Cursor 在讲 Rules，Copilot 和 VS Code 也在把定制指令、规则文件和工作流入口做得更显性。社区侧也越来越像一个真正的目录生态：你可以找清单，可以找推荐，也可以直接把别人已经沉淀过的能力包装拿来试。

这次让我更明确地意识到“问题已经换层”，还有一个更具体的公开支点：我把原本只在本地体系里长出来的一部分能力，单独整理成了公开仓库 Idea-Maglev/skills-shared。这个仓库里已经不只是孤立的 skills/ 目录，还同时出现了：

  • catalog.yaml 这种公开索引；
  • skillsets/capability-evolution-suite.yaml 这种显式编组；
  • docs/design-principles.md 和 docs/skillsets.md 这类边界与协作说明；
  • scripts/check-public-boundary.mjs、scripts/validate-catalog.mjs 这类面向公开发行的校验脚本。

对我来说，这些对象比“我又多写了几个 Skill”更能说明问题。因为一旦你开始需要 public catalog、skillset、public boundary 和校验脚本，关注点就已经从“单个 Skill 好不好用”延伸到“这些 Skill 怎样作为一组公开能力被组织和分发”。

这一步我觉得很重要，因为它解决了一个早期阶段最实际的问题：

  • 可复用能力终于有了稳定的包装形式；
  • 经验不必继续散落在聊天记录里；
  • “哪里找、怎么装、怎么带进项目”开始有公共答案。

如果只看这一步，我其实是乐观的。因为生态从 Prompt 走向 Skill，本来就该先经过“先把东西装起来、摆出来、传起来”的阶段。

也正因为如此，我现在并不想否定 skill marketplace。我的判断更像是：它解决的是第一层问题，而且第一层问题本来就必须先被解决。

只是当我继续往下用的时候，痛点已经换层了。

哪些地方比预期更难

真正难的地方，不再是“缺一个 Skill”，而是 Skill 多起来之后，谁和谁的边界怎么算。

当可复用能力还只是零散几个的时候，大家通常把它当工具箱来用：缺什么补什么，需要什么点什么。

但当目录开始拉长、命名开始变多、能力之间开始互相覆盖的时候，问题就会变得很不一样：

  • 哪个 Skill 才是入口，用户应该先看到谁；
  • 哪些 Skill 只是内部节点，不应该直接暴露出来；
  • 两个 Skill 都说自己负责需求收敛，冲突时谁说了算；
  • 一个 Skill 改了之后，会不会影响另一组相关能力；
  • 一组 Skill 应该一起升级，还是可以单独替换；
  • 系统这次到底命中了哪些能力，为什么跳过了另一些能力。

这些问题的共同点在于：它们已经不是“能力有没有被包装好”的问题了，而是“能力之间怎么协作”的问题。

这也是我为什么会把“技能市场”和“能力系统”明确分开看。

  • 技能市场解决的是发现、安装、分享和单点复用。
  • 能力系统解决的是入口、边界、依赖、升级和演化秩序。

前者更像把工具摆上架子，后者更像开始设计一间工厂。

我现在更愿意把 Skill 看成能力模块

我以前也会比较轻地把 Skill 理解成“结构化一点的 Prompt”。这样想并不完全错，但现在对我已经不够用了。

因为一个真的会被反复调用、会进入复杂任务链的 Skill，通常不只是说明文字。它还至少隐含了几件事：

  • 它负责什么；
  • 它不负责什么；
  • 它在什么时候被触发；
  • 它前后依赖谁；
  • 它暴露给谁；
  • 它改动之后会影响谁。

只要这些问题开始出现，Skill 的角色就已经更接近一个能力模块，而不是一段提示词。

我现在更常用的思路是：

Prompt
→ Skill
→ Skill Collection
→ Capability Module
→ Capability System

前半段解决的是“能力怎么被写出来”。后半段解决的是“这些能力怎么一起活下去”。

这个变化看上去像是概念升级，但我觉得它其实很落地。因为一旦你开始把 Skill 当成能力模块，就会自然问出另一批问题：

  • 它是不是顶层入口；
  • 它是不是只服务其他能力；
  • 它是不是负责协调、分发和巡检，而不是直接干活。

这几个问题一旦成立，Skill 就不再天然平级了。

如果要落回我自己已经公开写过的命名里，那两类角色其实正好对应得很直白：

  • skill-scout 更接近“技能发现与接入”；
  • skill-squadron 更接近“能力编组与巡检”。

我现在重新看这两个名字，关注点已经不是“它们各自会做什么”，而是：为什么当系统里开始出现这种角色分化时，Skill 就更接近一个有结构的系统，而不是平铺列表。

对我来说，这张图比“再多收集几个 Skill”更重要。因为只要出现协调能力，系统就已经不是一个平铺列表了。

哪些地方确实变好了

虽然我现在开始更在意系统问题，但这不代表前面的市场阶段没价值。恰恰相反，我觉得正是前面的事情先做出来了，后面的痛点才有机会被看见。

如果没有公开的 Skills、Rules、Instructions 和目录生态，很多人甚至还没机会遇到“Skill 多起来以后怎么办”这个问题。

所以我现在看到的，不是前后两种路线互相否定，而是一个更顺的演化顺序：

  1. 先把能力沉淀成可复用对象；
  2. 再把这些对象变成可以分享和安装的资产；
  3. 等数量和复杂度上来之后，再被迫面对系统问题。

我最近重新看这件事时，一个很明显的变化是：我不再急着问“还能不能再多做几个 Skill”，而会先问“系统是不是已经开始缺边界和关系图了”。

这个问题一换，很多实践动作也会跟着变：

  • 我会先区分哪些能力是入口、哪些是内部、哪些是协调；
  • 我会更在意一个能力的职责句，而不是先堆功能；
  • 我会更在意改动影响面，而不是只看单个 Skill 是否变强；
  • 我会更在意用户最终面对的是不是一个顶层能力，而不是几十个零件名词。

这些变化未必直接让系统更“炫”，但会让系统少一点越来越乱的趋势。

如果重来一次

如果从今天重新开始搭一套 Skill 体系，我不会先从“尽快把数量堆起来”开始。

我大概会更早做四件事。

1. 先定义能力角色，而不是先写名字

先分清入口能力、内部能力、协调能力，各自负责什么。这样后面就不容易出现“所有 Skill 都想直接面对用户”的混乱。

2. 先写职责句，而不是先补功能清单

我现在越来越觉得，一个 Skill 最重要的不是它能做多少事，而是它那句最短的职责到底是什么。职责句模糊，后面再怎么扩展，都会开始和其他能力撞车。

3. 先看关系，再看单点强弱

单个 Skill 很强当然有价值，但规模上来以后，真正容易让系统失控的往往不是单点不够强，而是关系不清楚：谁依赖谁，谁补谁，谁冲突时优先。

4. 先把演化秩序当成设计对象

我以前会把升级、退役、替换这些事看成“后面再处理”。现在我更倾向于一开始就承认：只要这套能力会继续增长，演化秩序本身就是系统设计的一部分。

这件事我也还远没做成熟

我不太想把这篇文章写成“我已经有了标准答案”。因为老实说，很多关键部分我也还在早期阶段。

比如我现在仍然缺这些东西：

  • 更清晰的能力 bundle 结构；
  • 更可靠的版本和兼容关系；
  • 更可解释的命中 trace；
  • 更直观的关系图视图；
  • 更稳定的影响分析方式。

也就是说，我现在更像是被这些问题推着往前走，而不是已经把这套东西做成了成熟产品。

但正因为这些缺口还在，我反而更确定一件事：

当 Skill 越来越多，真正先把人拖住的，通常不会是“我还缺一个好 Skill”，而是“我已经有不少 Skill，但它们还没有形成系统”。

总结

如果只把最近的变化概括成“大家开始做 skill marketplace 了”，我会觉得这个判断只说对了一半。

另一半是：一旦 marketplace 真的把 Skill 普及起来，后面很自然就会有人撞上能力系统的问题。

我现在更愿意把这件事理解成一个顺序，而不是两个互相否定的立场：

  • 先有技能集合；
  • 再有能力系统。

前者让能力可以被看见，后者才决定这些能力能不能长期协作。

所以这篇文章真正想说的不是“技能市场没价值”，而是：我最近开始更清楚地意识到，至少对我自己来说，问题已经从找 Skill，走到了组织 Skill。

如果你想继续看

Comments