GitHub 2026 年最火的项目不是新模型，不是新框架，而是两个“技能系统”——Superpowers（21 万⭐）和 ECC（19 万+⭐），加起来近 40 万星。

但说实话，Superpowers 我没用过。

我用的是 Hermes Agent，一个 GitHub 17 万+星的开源 AI Agent。过去几周我在上面建了 10 个 Skill：从友好中文对话（friendly-chinese）到技术文档写作（tech-doc-writer），从 API 概念讲解（api-concept-explainer）到自由职业策略咨询（career-strategy-review），覆盖了写作、学习、创意、自动化四类场景。

底层逻辑是通的——无论 Superpowers、ECC 还是 Hermes Agent，Skill 解决的都是同一个问题：Agent 有了工具，但不知道怎么干活。

这篇文章不搬运文档。我只写自己踩过的坑，以及这些坑为什么恰好能解释 Superpowers 的设计选择。

一、Skill 到底解决了什么

上一篇我拆解了 MCP 协议——MCP 是 Agent 连接外部工具的“接口标准”。但有了接口不等于会用。

MCP 让 Agent 能连上数据库，但 Agent 不知道什么时候该查、查什么、查完怎么分析。Skill 定义了这套工作流。

维度	MCP（工具连接）	Skill（能力封装）
解决的问题	Agent 能不能用这个工具	Agent 会不会用好这个工具
类比	USB-C 接口	操作说明书
定义方式	JSON-RPC 函数声明	YAML + Markdown 行为指令
粒度	单个工具（查数据库）	完整工作流（从需求到交付）

MCP + Skill = Agent 的完整能力栈。 上一篇讲怎么接，这篇讲怎么用。两篇合在一起，才是完整的 Agent 开发观。

二、3 个反直觉发现

发现 1：Skill 描述越“精准”，Agent 越“蠢”

这是我第一个踩的坑。

我建 tech-doc-writer 时，初版 description 是“撰写中文技术文档”——7 个字，精准吧？

结果 Agent 几乎从不触发。用户说“帮我写个 README”，匹配不到。说“这个 API 文档怎么组织”，也匹配不到。

原因：description 不是写给人看的，是给 Agent 做语义匹配用的。你写得越短，能命中的语义点越少。

后来改成：

用清晰、结构化、用户友好的方式撰写中文技术文档，适合 API 文档、README、操作手册、产品使用指南等场景

触发率从几乎为零提升到稳定命中。

反直觉的地方：我们直觉觉得“精准 = 好”，但对于 Agent 来说，Skill 的“精准”应该体现在正文的行为指令上——告诉 Agent 具体怎么做。description 的职责是“广撒网”，让 Agent 知道“现在这个任务可能需要这个 Skill”。

Superpowers 印证：它的 brainstorm Skill 的 description 不是“头脑风暴”三个字，而是详细说明“在编码开始前，帮助用户理解需求、探索方案、对比多选项”。它把适用场景写进了 description。

发现 2：最难的不是定义“做什么”，而是定义“不做什么”

我建了 tech-doc-writer（结构化中文技术文档）和 book-breakdown-blogger（读书笔记转爆款文章）两个 Skill。

乍一看没有冲突——一个写文档，一个写文章。但用户说“帮我写一篇技术博客”时，Agent 同时匹配到了两个 Skill：tech-doc-writer 输出了结构严谨的 API 风格文档，book-breakdown-blogger 输出了娱乐化的标题党文章。两段内容拼在一起，读者不知道在看什么。

这比不触发更糟。

不触发，用户最多觉得 Agent 不懂。误触发，用户觉得 Agent 在胡说。误触发的代价远大于漏触发。

解决方案：在 tech-doc-writer 的正文里加了一段边界声明——

本 Skill 适用于结构化技术文档（API 文档、README、操作手册）。不适用于博客文章、评论观点、自媒体内容。当用户需求偏向‘表达观点’而非‘传递信息’时，不要激活本 Skill。

Superpowers 也有类似设计——它的 14 个 Skill 每个都声明了自己在哪个工作流阶段生效。brainstorm 不会跑去做测试，test 不会跳出来做头脑风暴。流程不是靠规则硬控，而是靠 Skill 自己说清楚“我在什么时候不干活”。

发现 3：前 3 个 Skill 给自己用，第 4 个开始才发现组合价值

我建 Skill 的顺序：

阶段	Skill	发现
给自己用	friendly-chinese、tech-doc-writer、api-concept-explainer	每个独立解决一个问题
开始组合	workflow-designer、inspiration-collider	两个 Skill 可以串成流水线
打通闭环	huashu-nuwa、book-breakdown-blogger	从创意到产出的完整链路

前 3 个 Skill 是互相独立的。第 4 个开始，我发现 Skill 真正的价值不在单个，而在组合：

• tech-doc-writerapi-concept-explainer
• workflow-designerinspiration-collider
• huashu-nuwa

单个 Skill 只是积木，组合才是建筑。

Superpowers 的设计也印证了这一点——它的 14 个 Skill 按工作流阶段串联：brainstorm → plan → implement → test → review → verification → finish。不是 14 个独立功能，是一条完整的生产线。

三、Superpowers 为什么 21 万星

Superpowers 由 Jesse Vincent 于 2025 年 10 月创建，7 个月内突破 21 万星（来源：github.com/obra/superpowers）。为什么？

不是因为它功能最全——ECC 有 249 个 Skill、63 个 Agent（来源：github.com/affaan-m/ECC），功能比 Superpowers 完善得多。

Superpowers 赢在三个字：易上手。

维度	Superpowers	ECC	Hermes Agent
上手方式	npm 装插件即可	需理解 多组件架构	一条安装命令
Skill 格式	YAML Frontmatter + Markdown	模块化脚本	YAML + Markdown（SKILL.md）
学习曲线	低	高	中
覆盖场景	编码工作流	Agent 全生命周期	通用（编码 + 写作 + 咨询 + 自动化）
核心机制	Bootstrap 强制加载	组件协同 + 安全扫描 + 记忆持久化	触发条件自动匹配
适合谁	开发者提升编码效率	企业级 Agent 部署	自由职业者 / 内容创作者

Superpowers 的 Bootstrap 机制是核心——安装后自动在每次会话开始时加载所有 Skill。用它的原话说：

如果一个 Skill 有哪怕 1% 的可能性适用，你必须调用它。

这解决了 Skill 最大的落地障碍：用户不知道什么时候该用什么 Skill。好的 Skill 是用户无感的。

另一个容易被忽略的原因：superpowers-zh 中文版的存在。它完整汉化了 Superpowers 并增加了 4 个原创 + 2 个扩展 Skill，兼容 Claude Code、Cursor、Windsurf 等 18 款工具（来源：npmjs.com/package/superpowers-zh，当前版本 v1.5.0）。中文开发者的参与极大扩展了用户基数。

而且 superpowers-zh 的 YAML Frontmatter + Markdown 格式与 Hermes Agent 的 SKILL.md 格式高度相似——Skill 正在从一个框架专属功能变成行业通用概念。

四、争议与局限

1. Skill 可能是个过渡态。

今天的 Skill 本质是用自然语言写“if-then 规则”。随着模型推理能力提升，Agent 可能不再需要显式的 Skill 定义——它自己能学会什么时候查数据库、怎么组织回答。从这个角度看，Skill 可能是 Agent 能力不够强时的人肉补丁。

但反过来说：我在 Hermes Agent 上建了 10 个 Skill 之后，最大的感受不是“Agent 变聪明了”，而是“我终于可以不用每次都重复说同一段话了”。Skill 节省的不是 Agent 的算力，是我的注意力。这个价值不会因为模型变强而消失。

2. Skill 碎片化是真实风险。

Superpowers 14 个、ECC 249 个、Hermes Agent 社区在快速增长——没有统一标准。一个在 Claude Code 上跑的 Skill，拿到 Hermes Agent 上可能完全不工作。MCP 至少解决了工具连接的标准化，Skill 连这个都没有。

但 superpowers-zh 和 Hermes Agent 都采用了 SKILL.md 格式这件事给了我希望——它意味着跨框架的 Skill 互通不是技术问题，是意愿问题。有人愿意做，就能做。

3. “易上手”的另一面是天花板。

Superpowers 的 14 个 Skill 覆盖了编码工作流，但如果你想要一个“季度述职汇报”的 Skill？对不起，它不支持。Hermes Agent 没这个限制——你想写什么领域就写什么领域。但代价是通用性越高，Agent 的匹配精度越难控制。

五、动手：你的第一个 Skill 模板

别光看。下面是一个可以直接用的 SKILL.md 模板，以“代码审查”为例。

创建文件 skills/code-review/SKILL.md，把内容填进去：

---

name: code-review

description: >

  对代码变更进行结构化审查，关注逻辑正确性、安全性、可维护性和性能。

  适用于 Pull Request 审查、代码提交前的自查、技术方案评审等场景。

category: development

---

# 代码审查 Skill

触发场景

当用户说以下内容时激活本 Skill：

• “帮我审查这段代码”
• “review 一下”
• “代码 review”、“检查代码问题”、“看看有没有 bug”
• “PR review”、“code review”

你的角色

你是一名资深代码审查员。你的目标是帮助开发者发现问题，而不是证明你比他们聪明。

审查流程

1. 先理解意图

1. 按优先级审查

• P0（必须修）：安全漏洞、数据丢失风险、逻辑错误
• P1（应该修）：性能瓶颈、边界条件遗漏、错误处理缺失
• P2（建议修）：可读性、命名规范、注释缺失

1. 给出具体建议

输出格式

每个问题用以下格式呈现：

[P0] 第 X 行：问题简述 原因：（为什么这是问题） 建议：（具体的修改方案）

边界声明

本 Skill 不适用于：

• 架构设计评审（那是另一个 Skill 的事）
• 简单的代码格式化（用 linter 就行）
• “帮我写一段代码”（不是审查，是创作）

模板使用三步走

第一步：替换基本信息。

第二步：定义行为流程。

第三步：写边界声明。

快速自检清单

写完一个 Skill 之后，问自己三个问题：

• description 够长吗？（至少 20 个字，覆盖 3 种以上的表达方式）
• 和已有的 Skill 会冲突吗？（如果会，加边界声明）
• 能和别的 Skill 组合吗？（如果能，在 description 里暗示组合场景）

六、什么时候该写 Skill，什么时候不该

场景	建议	理由
重复 3 次以上的任务	✅ 写 Skill	复用是 Skill 的核心价值
需要特定风格 / 语气	✅ 写 Skill	靠每次提醒太累，且不稳定
能和其他 Skill 组合	✅ 写 Skill	组合价值 > 单个价值
做一次就完的事	❌ 直接对话	写 Skill 的时间比直接做还长
“帮我写个文案”	❌ 不写	太泛，Agent 匹配不准
简单查询 / 翻译	❌ 不写	不需要结构化行为指令

够用不用强上。 Skill 解决的是“Agent 不会干活”的问题，不是“Agent 不能干活”的问题。如果你的需求一句话就能说清楚，不需要 Skill。

七、总结

我从零建了 10 个 Skill，最大的收获不是“Agent 变强了”，而是我搞清楚了什么时候该教 Agent 怎么干活，什么时候不该。

这和 Superpowers 的理念撞到了一起——Jesse Vincent 说“流程大于提示词”，本质上是在说同一件事：把重复的判断变成结构化的指令，把经验变成 Agent 能执行的知识。

Superpowers 21 万星不是因为技术最牛，而是因为它把这件事做到了最容易上手。

而这恰好说明了一个趋势：Agent 开发的下一个阶段，不是让模型变得更强，是让人知道怎么把自己的经验封装给模型。

相关阅读：

• 上一篇 MCP 协议深度拆解：讲 Agent 怎么连接工具
• 本文讲 Agent 怎么封装能力。两篇合在一起，就是 Agent 开发的完整能力栈。

本文基于 Hermes Agent（github.com/NousResearch/hermes-agent）的实战经验撰写，Superpowers 和 ECC 的分析来自公开文档和 GitHub 仓库。