我最早开始想这件事时，想法也很常见：几个月前，我写过一篇 skill-scout 和 skill-squadron 的文章。当时我更关注两个工具本身——一个帮我发现、改造和生成 Skill，另一个帮我把多个 Skill 编成组，做关系分析和持续优化。
但真正进到 Skill 生态现场后，我先撞上的并不是"怎么写一个好 Skill"，而是更基础的几个问题：当 Skill 从几个变成几十个、上百个时，它还能只是一个列表吗？大家不再只问"怎么写一段好 Prompt"，而是开始问"有没有现成能力可以装"。
所以我后来更认可的一种做法是：Skill Marketplace（技能市场）会先出现，但下一步真正会遇到的问题，可能是 Capability Architecture（能力架构）。
也就是：我们到底是在管理一堆 Prompt，还是在构建一个能力系统？
先看结论
如果一个项目里只有 5 个 Skill，它们像工具箱；如果有 50 个、100 个，它们就开始像一个系统。
几个月前，我写过一篇《用 skill-scout 和 skill-squadron 打造趁手的技能矩阵》。那篇文章里，我把 skill-scout 比作"技能猎头"，把 skill-squadron 比作"技能经纪人"。
当时我想解决的问题比较直接：
- 想要一个 Skill，但不知道去哪里找；
- 找到一个 Skill，但不知道是不是还有更好的；
- 想改造成适合自己项目的 Skill，但不知道怎么落地；
- Skill 越写越多以后，不知道它们之间怎么关联、怎么维护。
所以那篇文章更偏"工具介绍"。它告诉大家：可以用 skill-scout 找能力、改能力、生成能力；可以用 skill-squadron 分析能力之间的关系，做编队巡逻和影响分析。
但这几个月过去以后，我对这件事的理解有点变化。
我越来越觉得，skill-scout 和 skill-squadron 的价值，不只是"帮我多生成几个 Skill"。它们真正有意思的地方，是开始触碰一个更长期的问题：
当 Skill 从几个变成几十个、上百个时，它还能只是一个列表吗？
如果只有 5 个 Skill，它们很像工具箱：写 SQL 用 SQL Skill，做 Code Review 用 Review Skill，写测试用 Testing Skill。每个 Skill 解决一个问题，用户自己选择就可以了。
但如果你有 50 个、100 个 Skill，事情就开始变了。
你会开始遇到新的问题：
- 哪个 Skill 是入口？
- 哪些 Skill 只是内部节点，不应该直接暴露给用户？
- 两个 Skill 的职责重叠了，谁说了算？
- 一个 Skill 改了以后，会不会影响另一个 Skill？
- 一组 Skill 应该一起升级，还是单独升级？
- 哪些能力已经过期，哪些能力只是暂时不用？
这时候，你管理的就不再是一个"技能列表"，而更像一个"能力系统"。
当前主流仍然更像 Skill Collection（技能集合）
我不是说当前主流做法不对。
相反，我觉得从 Prompt（提示词）到 Skill（技能），再到 Skill Collection（技能集合），是非常自然的演进路径。
最早大家关注的是 Prompt：怎么写出一段更有效的指令，怎么让 AI 按某个风格输出，怎么让它遵守约束。
后来这些 Prompt 被沉淀成文件，变成规则、说明、指令集、工作流。再往后，平台开始给这些可复用内容一个更正式的名字：Skill、Rule、Instruction、Prompt file。
这一步很重要。它把原本散落在对话里的经验，变成了可以复用、可以分享、可以安装的能力包。
现在我们已经能看到几个明显信号。
截至 2026-06-16，不同平台已经在用各自的方式把"可复用 AI 能力"产品化：OpenAI Codex 有 Skills，Claude 有 Agent Skills，Cursor 有 Rules，GitHub Copilot 和 VS Code 有 custom instructions / prompt files。社区侧也开始出现 awesome list、skills marketplace、best skills 这类目录化内容。
这些资料可以作为延伸阅读：
官方 / 一手资料
- OpenAI Codex Skills：说明 Skills 如何由 instructions、resources 和 optional scripts 组成，用来沉淀特定工作流。https://developers.openai.com/codex/skills
- OpenAI API Skills：更底层地说明带
SKILL.mdmanifest（清单文件）的 versioned bundle（带版本能力包）。https://developers.openai.com/api/docs/guides/tools-skills - Anthropic Agent Skills：Claude 侧的官方 Skills 文档。https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview
- Anthropic Skills GitHub：可以直接看到官方 Skills 的文件夹、说明、脚本和资源组织方式。https://github.com/anthropics/skills
- Cursor Rules：Project / Team / User Rules 与 AGENTS.md 的官方说明。https://cursor.com/docs/rules
- GitHub Copilot custom instructions：repository custom instructions 的官方说明。https://docs.github.com/copilot/customizing-copilot/adding-custom-instructions-for-github-copilot
- VS Code Copilot custom instructions：
.instructions.md、applyTo等更细粒度指令组织方式。https://code.visualstudio.com/docs/copilot/customization/custom-instructions
社区 / 生态观察样本
- GitHub Awesome Copilot：agents、instructions、skills、hooks、workflows、plugins 的社区集合。https://github.com/github/awesome-copilot
- Awesome Codex Skills：围绕 Codex Skills 的社区整理。https://github.com/composiohq/awesome-codex-skills
- awesome-cursorrules：Cursor Rules 社区集合。https://github.com/PatrickJS/awesome-cursorrules
- Agent Skills open format：一个轻量开放格式视角下的 Agent Skills 说明。https://agentskills.io/home
我列这些资料，不是为了证明某个平台已经给出了最终答案，而是想说明一个阶段已经到来：Skill 正在从个人经验，变成可包装、可分享、可安装的能力资产。
但如果从组织方式看，当前大多数形态仍然更像：
skill A
skill B
skill C
skill D
...也就是 Skill Collection（技能集合）。
比如一个目录里可能有：
- code-review
- unit-test-writer
- api-doc-generator
- frontend-fixer
- browser-debugger
- pr-summary
这当然有用。它解决了"有没有可复用能力"的问题。
但它还没有真正解决"这些能力之间如何协作"的问题。
用户面对的仍然是多个独立能力。你要自己知道什么时候用哪个，哪个先用，哪个后用，哪个是入口，哪个是辅助，哪个已经被另一个能力覆盖了。
所以我现在会把这两个阶段区分开：
Skill Collection（技能集合）解决的是：有没有可复用能力。
Capability System（能力系统）解决的是：这些能力如何协作。前者更像工具箱，后者更像系统架构。
Skill 多起来之后，问题会从"缺能力"变成"缺架构"
一个生态刚开始的时候，最明显的问题通常是"缺能力"。
没有 Review Skill，就写一个 Review Skill。
没有测试生成 Skill，就写一个测试生成 Skill。
没有文档归档 Skill，就写一个文档归档 Skill。
但当能力越来越多以后，真正的问题会慢慢变化。
你会发现，真正缺的开始变成一种组织能力的方式。
举个例子，如果我要做一个 feature-dev 能力，它可能不只是一个 Skill。它内部可能涉及：
- 需求澄清；
- 方案设计；
- API 设计；
- 数据模型设计；
- 测试设计；
- 代码实现；
- Review 和验证。
如果把它们全部摊开给用户，用户看到的可能是：
requirement-convergence
spec-designer
api-design
db-design
test-design
code-implementer
review-validation这当然也能用，但使用者需要理解每个 Skill 的边界，并且要知道它们的顺序。
更理想的方式可能是：
用户只看到一个入口：
feature-dev内部再由系统协调：
requirement-convergence
↓
spec-designer
↓
api-design / db-design / test-design
↓
review-validation这时候，用户消费的是能力系统，而不是一堆能力零件。
这也是我为什么觉得 Skill 多起来以后，真正稀缺的不是 Prompt，而是边界、关系、入口、分层、版本、影响分析和演化秩序。
如果没有这些东西，Skill 越多，系统反而越乱。
它可能会变成另一种形式的上下文垃圾场：每个 Skill 都写得很认真，但谁也不知道谁该在什么时候负责什么。
我现在更愿意把 Skill 看成 Capability Module（能力模块）
所以我现在不太愿意只把 Skill 理解成 Prompt。
更准确地说，我会把它看成 Capability Module（能力模块）。再进一步，它应该是：
Governed Capability Object（可治理的能力对象）。
因为一个真正能进入复杂系统的 Skill，不应该只有一段提示词。它至少应该有几个东西：
- 它解决什么问题；
- 它不解决什么问题；
- 它什么时候被触发；
- 它输入什么；
- 它输出什么；
- 它依赖谁；
- 它会影响谁；
- 它应该暴露给用户，还是只作为内部节点；
- 它如何升级和废弃。
这时候，思维模型就变了。
市场早期更常见的是：
Prompt
↓
Skill
↓
Collection而我现在更关心的是：
Skill
↓
Capability Module（能力模块）
↓
Capability Graph（能力图谱）
↓
Capability System（能力系统）这个差异看起来有点抽象，但落到使用体验上其实很直观。
在 Skill Collection（技能集合）里，用户要自己面对很多能力：
api-design
db-design
testing
event-design
security-review在 Capability System（能力系统）里，用户可能只需要面对一个顶层能力：
backend-engineering-system内部的 api-design、db-design、testing、event-design 仍然存在，但它们不一定都要暴露给用户。它们可以作为内部能力，被入口能力或协调能力调用。
可以画成这样：
这也是我觉得 Skill 编组最有意思的地方：
它不是让 Prompt 更复杂，而是让能力开始有架构。
Entry Skill（入口技能）、Internal Skill（内部技能）、Coordinator Skill（协调技能）
如果把 Skill 看成能力系统的一部分，它就不应该全部平级。
我现在会粗略分成三类。
1. Entry Skill（入口技能）：入口能力
Entry Skill（入口技能）是用户真正应该接触的能力。
它的职责不是解决所有细节，而是把用户的自然语言需求转成系统内部可执行的动作链。
比如：
feature-dev：我想开发一个功能；backend-engineering：我想完成一类后端工程任务；internal-article-workflow：我想写一篇内部分享文章。
用户不需要知道内部到底有多少个节点。入口能力应该把复杂性藏起来。
2. Internal Skill（内部技能）：内部能力
Internal Skill（内部技能）负责一个更窄、更清晰的子问题。
它可以很专业，但不一定适合直接暴露给用户。
比如：
- API 设计；
- 数据建模；
- 元数据校验；
- catalog 一致性检查；
- 某个特定文档格式转换。
这类能力很重要，但如果全部直接暴露出来，用户会被迫理解系统内部结构。
3. Coordinator Skill（协调技能）：协调能力
Coordinator Skill（协调技能）更特殊。
它不一定直接完成业务任务，而是负责：
- 分发；
- 调度；
- 聚合；
- 关系分析；
- 影响分析；
- 生成组级报告。
skill-squadron 就是这种能力。
它不负责写一个具体 Skill，也不负责完成某个业务需求。它负责看一组 Skill 之间的关系，判断它们应该如何巡逻、如何优化、改一个会影响谁。
一旦出现 Coordinator Skill（协调技能），Skill 就不再天然平级。
它开始有了系统结构。
这也是我觉得当前很多 Skill 讨论还没完全展开的地方：大家会讨论"怎么写一个好 Skill"，但较少讨论"Skill 在系统里扮演什么角色"。
Semantic Invocation（语义调用）还不够，必须有 Explicit Governance Graph（显式治理图谱）
这里还有一个关键问题：Skill 之间的关系应该怎么表达？
最自然的方式当然是自然语言。
比如在一个 Skill 里写：
当需要 API 设计时，调用 api-design skill。对 AI 来说，这很容易理解。
我把这种方式称为 Semantic Invocation（语义调用）。它不像传统编程语言里的 import，也没有编译器检查，但对大模型来说非常自然。
问题是，只靠自然语言很难支撑大规模系统。
当 Skill 数量变多以后，纯语义引用会带来几个问题：
- 依赖关系藏在正文里，不好找；
- 谁调用谁不清楚；
- 两个 Skill 互相引用，可能形成循环；
- 某个 Skill 被改名了，引用可能悄悄失效；
- 一个 Skill 的职责变化了，其他 Skill 不一定知道。
所以我现在越来越觉得，AI 原生的模块系统不会完全复制传统代码里的 import，但也不能停留在"名字提到了就算依赖"。
它需要语义，也需要治理。
在我自己的实践里，除了在自然语言里写触发和协作方式，还会在治理清单里显式登记关系。比如一个很简化的例子：
relations:
- target: skill-scout
type: complements
- target: verification-curator
type: shares_data这类关系不是给用户看的，而是给系统治理看的。它可以帮助回答：这个 Skill 和谁互补、它调用谁、谁调用它、它和谁共享数据、哪些节点是孤立的、哪些关系已经悬空。
所以我更愿意把这个模式描述成：
Semantic Invocation（语义调用） + Explicit Governance Graph（显式治理图谱）自然语言负责触发和理解。
显式关系负责治理和检查。
步骤链负责执行。
巡逻和验证负责演化。
这比单纯的"Semantic Import"更稳一点。
skill-scout 和 skill-squadron 是我的一个早期答案
回到 skill-scout 和 skill-squadron。
如果只看表面，它们像两个工具：
skill-scout：帮我找 Skill、评估 Skill、改造成自己的 Skill；skill-squadron：帮我分析一组 Skill 的关系，做编队巡逻。
但现在我更愿意把它们看成一个早期的能力治理闭环。
skill-scout 解决的是：
能力从哪里来，怎么进入本地体系？
它的流程大概是：
parse → search → evaluate → adapt → register也就是先理解需求，再搜索外部能力，再评估是否适合，再做私域化改造，最后登记到本地能力体系里。
skill-squadron 解决的是：
能力进入体系以后，如何一起维护？
它的流程大概是：
graph → group → patrol → impact → report也就是先构建关系图，再按关联关系分组，再逐组巡逻，再做跨 Skill 影响分析，最后输出编队报告。
如果把两者连起来，大概是这样：
这套东西当然还很早期。
但它的方向不是"生成更多 Skill"，而是"让 Skill 可以被治理"。
这里的治理不是大词，具体就是：
- 它有没有登记？
- 它和谁有关？
- 它是不是用户入口？
- 它是不是内部节点？
- 它有没有和说明文档漂移？
- 它的修改会不会影响其他 Skill？
- 它过期以后应该单独废弃，还是影响一整组？
这就是我觉得 skill-scout 和 skill-squadron 比较有意思的地方。
它们看起来是两个 Skill，但实际上是在回答 Skill 规模化以后的治理问题。
为什么这个方向现在还没有成为主流
如果这个方向有价值，为什么现在还没有明显成为主流？
我觉得有几个原因。
首先，大多数人还没真的被这个问题打疼。
如果你只有 5 个 Skill，根本不需要什么 Capability Architecture（能力架构）。一个 README、一个目录、几个触发词，就够用了。
只有当 Skill 数量上来以后，你才会开始关心：
- 谁和谁重复；
- 谁依赖谁；
- 谁该先运行；
- 谁不该暴露；
- 谁已经过期；
- 谁的改动会影响一组能力。
其次，市场天然更容易传播单个 Skill，而不是一套架构。
"SQL Review Skill"很好理解。
"Backend Engineering Capability System（后端工程能力系统）"就没那么好理解。
前者像一个工具，下载就能试。
后者像一套方法，需要解释入口、内部节点、关系、版本、巡逻、影响分析。教育成本明显更高。
第三，平台通常会先解决分发，再解决治理。
很多技术生态都是这样。
早期大家先分享脚本、插件、模板、扩展。等数量多了以后，才会慢慢出现包管理、依赖约束、版本协议、兼容性规则、可视化管理。
Skill 生态现在可能也处在这个阶段。
大家正在解决：
哪里找 Skill？
怎么装 Skill？
哪些 Skill 好用？但还没大规模进入：
一组 Skill 怎么组成系统？
系统怎么升级？
改动怎么评估影响？
能力之间怎么声明关系？第四，复杂编组会放大模型不稳定性。
单个 Skill 出错，定位还比较容易。
一组 Skill 协同出错，就会复杂很多：
- 是入口没判断对？
- 是内部 Skill 没触发？
- 是协调 Skill 分发错了？
- 是某个关系声明过期了？
- 是上下文加载太多互相干扰？
所以在模型能力和平台运行时还不够稳定的时候，大家自然更倾向于保持 Skill 独立、简单、无状态。
这不是保守，而是可靠性选择。
所以我不认为"还没成为主流"说明这个方向没价值。
更可能是：
大多数人还在 Collection 阶段，没有被 System 阶段的问题真正打疼。
我自己的方案也远没成熟
当然，我也不想把自己的实践说得太满。
我现在做的这套东西，更像早期原型，而不是成熟产品。
它已经考虑到一些问题：用显式关系图管理关系，用分组巡逻观察组级状态，用影响分析判断改动影响面，用分发范围区分用户入口和内部节点，用 metadata（元数据）校验减少说明文档和治理清单漂移。
但它还缺很多东西。
比如，还没有标准化的 capability-bundle.yaml（能力包清单）。
如果我要把一组 Skill 作为一个能力包发布，现在还没有一个稳定格式能声明：
- 入口是谁；
- 内部节点有哪些；
- 协调节点有哪些；
- 依赖版本是什么；
- 哪些能力对用户可见；
- 哪些能力只是内部实现；
- 升级时如何判断兼容性。
也没有真正的 semver（语义化版本）、兼容矩阵和回滚协议。
传统软件包可以说 1.2.0 兼容 1.x，但 Skill 的兼容性更复杂。因为它不只是函数签名，还包括行为、语气、步骤、输出结构、触发条件。
也没有完整的 Skill Trace（技能调用轨迹）。
也就是说，当一次任务执行完以后，我还不能稳定地回答：
- 这次为什么命中了这个 Skill？
- 为什么没有命中另一个 Skill？
- 哪个 Skill 委托了哪个 Skill？
- 哪一步失败了？
- 哪一步被跳过了？
这类 trace（调用轨迹）对调试能力系统非常重要。
另外，也还没有图形化关系视图。
现在关系图可以被构建、被报告，但还没有一个足够直观的 Graph View（图谱视图） / Tree View（树视图）。规模到几十个以后，仅靠 Markdown 和 YAML 还是会吃力。
还有一个更底层的问题：很多接口仍然是 AI 审查协议，不是机器强 schema。
也就是说，系统会要求 AI 判断"接口是否兼容""数据流是否变化""行为是否 breaking"。这比完全没有检查好很多，但还不是编译器级别的强约束。
所以我现在更愿意把它称为：
一个关于 Skill 系统化组织的早期实验。
而不是一个已经成熟的产品答案。
我期待的下一步：Capability Architecture（能力架构）
如果继续往前想，我觉得 Skill 生态迟早会需要一种类似 Capability Architecture（能力架构）的东西。
名字不一定叫这个。
它可能出现在 IDE 里，可能出现在 Agent 平台里，可能出现在 Skill Marketplace（技能市场）里，也可能先以某种开源约定出现。
但它大概率需要回答几个问题。
1. Capability Bundle（能力包）
一组 Skill 应该可以作为一个能力包发布，而不是永远以单个 Skill 分发。
比如：
backend-engineering-system
frontend-delivery-system
product-research-system
internal-writing-system这些能力包内部可以有多个 Skill，但用户主要看到入口能力。
2. Entry / Internal / Coordinator
能力系统内部应该有角色分层。
不是所有 Skill 都应该平级，也不是所有 Skill 都应该直接给用户调用。
至少应该能区分：
- Entry：用户入口；
- Internal：内部能力；
- Coordinator：协调能力。
3. Relation Graph（关系图谱）
能力之间的关系应该可以显式声明。
比如：
- calls；
- called_by；
- complements；
- shares_data；
- precedes；
- conflicts_with。
这些关系不一定完全像代码依赖，但应该能被检查、可视化和巡逻。
4. Impact Analysis（影响分析）
改一个 Skill 前，应该能看到影响面。
它会影响哪些入口能力？
会影响哪些内部节点？
会不会破坏已有输出结构？
会不会改变触发条件？
会不会让另一个 Skill 的说明失效？
5. Skill Trace（技能调用轨迹）
一次任务中，系统应该能记录：
- 命中了哪个 Skill；
- 为什么命中；
- 跳过了哪个 Skill；
- 为什么跳过；
- 谁委托了谁；
- 哪一步失败；
- 最后输出来自哪些能力。
没有 trace，复杂能力系统很难调试。
6. Graph View（图谱视图）
最后，人也需要看得懂。
如果能力系统越来越复杂，光靠目录和 Markdown 不够。需要图谱视图、树视图、关系过滤、影响面查看。
一个非常粗糙的能力包 manifest（清单）可能长这样：
capability_bundle:
name: backend-engineering-system
entry: feature-dev
internal:
- api-design
- db-design
- testing
coordinators:
- delivery-orchestrator
relations:
- source: feature-dev
target: api-design
type: calls
- source: feature-dev
target: testing
type: calls这不是标准，只是一个想象。
但我相信，随着 Skill 数量增长，类似这样的组织语言迟早会变得重要。因为到那时，大家需要的不只是"能装什么 Skill"，还会是"这些 Skill 如何形成一个可靠的能力系统"。
我想把问题抛给社区
所以这篇文章并不是要给一个确定答案。
我更想提出一个问题：
Skill 的下一步，是不是会从"更多可安装能力"，走向"更可治理的能力系统"？
我不确定 Skill 编组最后会不会叫 Capability Architecture（能力架构）。
也不确定它会出现在 IDE、Agent 平台、Skill Marketplace（技能市场），还是某种新的包管理器里。
但我越来越确定：当 Skill 足够多以后，只讨论单个 Skill 写得好不好是不够的。
真正的问题会变成：
- 这些能力之间是什么关系？
- 谁是入口？
- 谁是内部节点？
- 谁负责协调？
- 改一个会影响谁？
- 一组能力如何一起升级？
- 用户到底应该看到多少复杂性？
这也是我几个月后又想聊 skill-scout 和 skill-squadron 的原因。
我最初以为它们只是两个工具：一个负责找 Skill，一个负责管 Skill。
现在再看，它们更像是在试探一个方向：
Skill 能不能从 Prompt 集合，演化成 AI Native（AI 原生）的能力架构？
如果你也在用 Skills、Rules、Instructions 或者类似机制，我也很想知道：
- 你现在的 Skill 是一个列表，还是已经有分层？
- 你遇到过 Skill 之间互相覆盖、重复、冲突的问题吗？
- 如果有一个 Capability Bundle（能力包），你希望它至少声明哪些信息？
- 你更希望平台提供这套能力，还是项目自己治理？
也许现在讨论这个问题还有点早。
但很多架构问题，都是在规模真正压上来之前，先从少数人的"不舒服"里长出来的。
Skill 的下一步，也许不是写出更多 Prompt，而是学会像软件一样组织能力。
相关资源：
skill-scoutSkill：https://github.com/Idea-Maglev/skills-shared/tree/main/skill-scoutskill-squadronSkill：https://github.com/Idea-Maglev/skills-shared/tree/main/skill-squadron- 技能共享仓库：https://github.com/Idea-Maglev/skills-shared