字数 4855，阅读大约需 25 分钟

「AI健自习室原创」🔥 AI Skills 元年：19 万⭐ Superpowers vs 4 万⭐ Agent Skills 全面解剖

微信公众号：[AI健自习室]关注Crypto与LLM技术、关注AI-StudyLab。问题或建议，请公众号留言。

Info

Superpowers：https://github.com/obra/superpowers · 194,310 ⭐ · 作者 Jesse Vincent (Anthropic 官方插件市场作者)Agent Skills：https://github.com/addyosmani/agent-skills · 42,590 ⭐ · 作者 Addy Osmani (Google Chrome 团队)数据采集时间：2026-05-17

你写代码时让 AI 帮你写一段函数，它能跑就算赢；可当你让它自主完成"从需求到上线"的两小时长任务，它真的能不偏离计划、不跳测试、不写半截弃疗吗？这背后比拼的，是一个叫做"Skills"的东西。

这篇文章把当下两个最火的 AI Coding Skills 项目——Anthropic 官方插件作者 Jesse Vincent 的 Superpowers（19.4 万⭐）与 Google Chrome 团队 Addy Osmani 的 Agent Skills（4.26 万⭐）——一行行拆完了。然后我把我自己积累的 87 个 Skills 也一起放上对比台。

看完你会知道：为什么这两个项目设计哲学完全不同却同样火爆，又为什么它们都不能直接拷过来用，以及如何融合出"第三种 Skills"。

🌅 一、为什么 2026 年突然成了 "Skills 元年"？

如果你最近在写 Agent，一定听过这个词：Skill。

它不是 Function Call，不是 MCP Tool，也不是 Prompt 模板。它是一个介于这三者之间的新事物——用 Markdown 写的可复用工作流。

Anthropic、Google、OpenAI、Cursor、Gemini 在过去 6 个月里不约而同地把 Skills 写进了官方文档、开放了插件市场、设计了 hook 机制。我数了一下，光是公开支持 Skills 的 AI Coding Agent 平台就有 8 个：Claude Code、Codex CLI、Codex App、Cursor、Gemini CLI、OpenCode、GitHub Copilot CLI、Kiro。

所以问题就来了——"Skill 应该长什么样？"

每家平台给出的答案五花八门，但社区已经诞生了两个事实标准。它们不是来自大厂官方文档，而是来自两个开发者：

• • obra/superpowers — 作者 Jesse Vincent，在 Anthropic 官方插件市场挂着，PR 拒绝率 94%，被无数人称为 "Skills 圣经"。
• • addyosmani/agent-skills — 作者 Addy Osmani，前 Google Chrome 团队 Web Performance Lead，把 Software Engineering at Google 那本砖头书塞进了 Skills 里。

我先把它们俩的硬数据放在一起：

Superpowers 7 个月攒下 19.4 万⭐——这个数字几乎吊打 90% 的开源项目。Agent Skills 来得晚（2026-02-15 才创建），3 个月就冲到 4.26 万⭐，增长速度更猛。

但更有意思的是：它们的 Skill 数量差异很大——14 vs 23——而且几乎没有重叠。这就是我们今天要拆的核心。

别被 Star 数迷惑：少不一定是简陋，多不一定是完整。这两个项目代表了两种完全不同的 Skills 设计哲学。

⚡ 二、Superpowers · "完整开发方法论"派

打开 superpowers 仓库，你会发现一个反直觉的事实：

它只有 14 个 Skills——比 agent-skills 少一半，比我自己 ~/.kiro/skills 的 87 个少 6 倍。但每一个都不是"独立功能模块"，而是一条工作流上的一环。

2.1 14 个 Skill 串成一条端到端开发链路

来看看它的工作流：

这张图就是 superpowers 的灵魂——它把 AI 能写代码的全流程拆成 7 个串联阶段：

注意第 4 步——这是 superpowers 最杀手的设计。

我在 subagent-driven-development/SKILL.md 里读到这段话，差点起立鼓掌：

"You delegate tasks to specialized agents with isolated context. They should never inherit your session's context or history — you construct exactly what they need. This also preserves your own context for coordination work."

翻译："你派任务给一个干净的 fresh-context 子 agent，绝不让它继承你的对话历史。这样既保证它专注，又保护你主 session 的上下文不被污染。"

这就是为什么 Superpowers 让 Claude 能自动跑 2 小时不偏离计划——因为每个任务都在一个隔离的世界里完成，主编排者只看汇总。

2.2 它的灵魂 DNA：让 Agent 不会"偷懒"的 6 种心理学武器

如果你只是机械地拷贝 superpowers 的 SKILL.md，你会错过它真正的精华。它的"灵魂"藏在每个 skill 都重复的 6 种结构里：

我挑 3 个最猛的拆给你看：

🔨 武器 1：THE IRON LAW · 一条铁律

每个 skill 都有一句绝对不可妥协的话，写在最显眼的地方。比如 TDD skill 里的：

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST

而且还会补一刀："违反规则的字面 = 违反规则的精神"。意思是别想找漏洞钻空子。

更狠的还在后面：

"Write code before the test? Delete it. Start over.""Don't keep it as 'reference'. Don't 'adapt' it while writing tests. Delete means delete."

写过的非测试代码 → 删了重写。不允许保留作为参考再写测试。这种刚性是 Superpowers 与"普通最佳实践"的本质区别。

🚩 武器 2：Red Flags · 红旗清单

每个 skill 都列出当 Agent 想偷懒时会冒出的内心独白：

❌ "Quick fix for now, investigate later"❌ "Just try changing X and see if it works"❌ "I already manually tested it"❌ "Tests after achieve the same goals"❌ "This is different because..."

看到红旗 = 立刻停下回到第一步。这是写给 Agent 的"心理诱惑识别指南"。

📋 武器 3：Rationalizations 借口对照表

最绝的设计——列举所有可能的借口，配上反驳证据：

这 3 件武器加上 GraphViz 流程图、Subagent 隔离、模型分级用模——这就是 superpowers 让 Agent 不可能偷懒的秘密。

💡 关键洞察：superpowers 的设计者深刻理解一件事——LLM 的失败模式不是能力不够，而是"想走捷径"。所以它整套体系都是在防止 agent 自己原地合理化偷懒。

🛠 三、Agent Skills · "Google 工程教科书"派

打开 agent-skills 仓库，你会立刻感觉到完全不同的气质——它像一本 Google 工程师的内部手册。

事实上它就是。Addy Osmani 直接把 Software Engineering at Google（业界俗称 SWE 砖头书）的核心原则编进了 Skills 里：Hyrum's Law（API 设计）、Beyonce Rule（测试覆盖）、Chesterton's Fence（代码简化）、Test Pyramid 80/15/5、Trunk-Based Development……

3.1 23 个 Skill 横跨 SDLC 全周期

agent-skills 不像 superpowers 那样追求"串成一条链"，而是按软件生命周期分维度覆盖：

6 个阶段，23 个 Skill：

注意星标的两个——它们是 superpowers 里完全没有的：

• • interview-me：当用户说"做个 dashboard"时，一次只问一个问题，每个问题附上你的猜测，直到达到 95% 置信度才停止。这个 skill 直接解决了 LLM 最大的失败模式：默默填补假设、然后一路狂奔。
• • doubt-driven-development：每做一个非平凡决策，就在内部 spawn 一个 fresh-context 反对派，专门挑毛病。Step 3 叫 "DOUBT" — 用对抗性 prompt 让审查者 biased to disprove, not approve。

3.2 杀手锏架构：Skills + Personas + Commands 三层

agent-skills 真正的秘密武器，是它比 superpowers 多了两层抽象：

每一层各司其职：

• • Layer 1 · Skills（the HOW） = 23 个 workflow，真正干活的 SOP
• • Layer 2 · Personas（the WHO） = 3 个特化角色（code-reviewer, security-auditor, test-engineer），每个是带视角和输出格式的"专家"
• • Layer 3 · Commands（the WHEN） = 7 个 slash command，用户手敲触发

而整个三层最妙的设计是一条铁律：

🚫 Personas 不能调用其他 Personas

这个约束看起来奇怪，但它解决了一个真实问题：避免无限套娃的代理调用链。编排是 Commands 与用户的工作，Persona 内部可以调 Skill，但 Persona 之间是平级的。

唯一被认可的"并行编排"模式叫 /ship——它是这个仓库里唯一的 fan-out orchestrator：

/ship  ├── (并行) code-reviewer    → 五轴 review report  ├── (并行) security-auditor → OWASP audit report  └── (并行) test-engineer    → coverage report                  ↓        主 Agent 合并三份报告                  ↓        输出 GO / NO-GO + 回滚计划

三个独立视角真正的并行（不是顺序伪装的并行），各自跑完后由主 agent 合并出一个 ship 决策。这是少有的、把"多 agent 协作"做对的开源案例之一。

3.3 内置的 Google 工程文化

最后说一下 agent-skills 最不可见但最值钱的部分——它把 Google 的工程文化压缩进了 SKILL.md。

随便挑几个例子：

• • 测试金字塔 80/15/5：unit 80% / integration 15% / e2e 5%
• • The Beyonce Rule："If you liked it, you should have put a test on it" — 没测试的代码出 bug 怪自己
• • Chesterton's Fence：删除任何代码前，先理解它为什么存在
• • Hyrum's Law：API 的"实际行为"会被无意中依赖，所以任何接口都要把实现细节当公共契约对待
• • Change sizing ~100 lines：每个 PR 不超过 ~100 行，太大要 split
• • Severity 标签：Critical / Important / Suggestion / Nit / FYI——评审反馈分级

这些都是身在 Google 的 staff engineer 才能 osmosis 来的隐性知识。Addy 把它们 变成了 agent 可以直接 follow 的步骤。

🔬 四、像素级对比 · 11 大维度

到这里你应该已经感受到差异了。但为了让你一眼看完所有维度，我做了一张大表：

我重点解读 4 个让人意外的维度：

4.1 触发机制：Hook 还是 Slash Command？

• • Superpowers 用 SessionStart hook——你启动 Claude Code 的瞬间，它自动读 using-superpowers/SKILL.md 全文塞到上下文里。Agent 没得选，必须遵守。
• • Agent Skills 用 slash command 入口——/spec/plan/ship 这些是用户主动敲的；当然 skill description 里也写了"自动触发条件"，但更轻量。

前者是"强制宪法"，后者是"按需 SOP"。哪种好？看你想让 agent 多自由。

4.2 防偷懒强度：极强 vs 中等

我读了两边所有 SKILL.md，总结：

Superpowers 默认假设 Agent 会想方设法走捷径，所以处处设防。Agent Skills 更像"教科书"，假设读者愿意学习。

这是设计哲学的根本差异：superpowers 把 Agent 当"会偷懒的实习生"，agent-skills 把 Agent 当"愿意学习的初级工程师"。

4.3 流程图表达：GraphViz dot vs ASCII art

Superpowers 在 SKILL.md 里大量使用 GraphViz dot 代码：

digraph tdd_cycle {    red [label="RED\nWrite failing test"];    green [label="GREEN\nMinimal code"];    refactor [label="REFACTOR\nClean up"];    red -> verify_red -> green -> verify_green -> refactor;}

这玩意 Claude 内置 GraphViz 渲染能力，所以 agent 看到代码会脑补出真实流程图。这是只有 Anthropic 圈内人才知道的小窍门。

Agent Skills 用 纯 ASCII art + Markdown 表格：兼容性更好，但视觉冲击力弱一点。

4.4 学习曲线：陡 vs 缓

• • 想用 superpowers，你得先理解整套方法论（脑暴→worktree→plan→subagent→TDD），然后整体 buy in。所以学习曲线陡。
• • agent-skills 的 23 个 skill 可以单独使用——你今天只想用 code-review-and-quality？没问题，它独立成立。所以学习曲线缓。

🧬 五、那……我自己的 87 个 Skills 在哪？

写到这里我必须坦白一件事——

我自己 ~/.kiro/skills 里有 87 个 Skill。

它们不是从 superpowers 或 agent-skills 拷的，是过去一年我在写代码、做项目、踩坑过程中慢慢沉淀出来的。但当我把它们和这两个开源项目对比的时候，发现了一个让我自己震惊的事实：

我的 ~/.kiro/skills 已经几乎完全吸收了 agent-skills 的"宽度"——21 个工程类 skill 名字几乎一一对应（test-driven-development、debugging-and-error-recovery、code-review-and-quality、spec-driven-development……）。

但我完全没有借鉴 superpowers 的"深度"——那 10 个执行链路 skill 我一个都没有：

我有一个叫 subagent-quality-standard 的 skill，但读完 superpowers 之后才意识到——我那个只是"质量约束"，不是"完整的 fresh-context 调度链"。差了不止一个量级。

但反过来，我有的，他俩都没有——

我的 87 个 Skill 里有 48+ 个是业务工作流：

• • 飞书 Lark 集群（22 个）：base/calendar/im/sheets/doc/drive/mail/minutes/okr/task……飞书 CLI 全套封装
• • AWS 集群（5 个）：aws-pricing-query, aws-blog-writer, aws-personal-cost-analyzer……
• • 内容创作（8+ 个）：wechat-article-writer, deep-research-ppt, apple-html-ppt, image-generator, fireworks-tech-graph……（你正在读的这篇文章就是 wechat-article-writer 写的）
• • 运维 / 远程访问（6 个）：mac-mini-access, macbook-neo-access, aws-gpu-access……
• • 工具/业务深集成（15+ 个）：doubao-meeting（逆向豆包接口）、ringtone-forge（铃声切片）、wbr-sfdc-sync、sfdc-customer-opps、wechat-cli……

这些是任何通用 Skills 库都无法复制的——长期积累的"业务深度"。逆向集成、跳板机访问、CLI 封装、API 接入、特定平台知识……

🌟 六、融合方案：第三种 Skills

到这里答案就很清楚了：

这两个开源项目不是替代关系，是互补关系。而我自己的体系，是"业务深度"的第三极。三方融合一下，可以做出一个真正适合自己的 Skills OS：

具体的融合清单是：

📥 应从 Superpowers 吸收 10 个 · 补"执行链路"短板

✓ using-git-worktrees             → 多线开发隔离✓ writing-plans                   → bite-sized task 详细计划✓ executing-plans                 → 批量执行 + checkpoint✓ subagent-driven-development ⭐  → fresh-context 三段式（升级我的 quality-standard）✓ dispatching-parallel-agents     → 并行 subagent 调度✓ verification-before-completion  → 完成前强验证✓ finishing-a-development-branch  → merge / PR 决策✓ systematic-debugging ⭐         → 4-phase 系统化调试✓ writing-skills                  → 创建新 skill 标准化流程✓ requesting/receiving-code-review→ 双向审查

📥 应从 Agent Skills 吸收 2 个 · 补"前期挖需求"短板

✓ interview-me ⭐               → 一次一问、95% 置信度才停✓ doubt-driven-development ⭐   → 在飞 fresh-context 自我质疑

💎 保持自有 48+ 业务工作流 · 不可替代的护城河

飞书 22 个 + AWS 5 个 + 内容创作 8 个 + 运维/工具集成 21+ 个——这是任何通用 Skills 库都无法复制的。

🏗 最终架构

我的 Skill OS =     Skills 80+        （来自 superpowers/agent-skills 的工程能力）  + Personas 3+       （来自 agent-skills 的特化角色）  + Hooks 注入        （来自 superpowers 的强制 bootstrap）  + 业务工作流 48+    （我自己沉淀的护城河）

🎯 七、关键启示与行动建议

通读完这两个 19 万 + 4 万⭐的项目，我提炼出 6 条对所有 Skills 设计者都有用的铁律：

启示 1：Skills 是 Code，不是 Prose

引用 superpowers using-superpowers/SKILL.md 里的原话：

"Skills are not prose — they are code that shapes agent behavior."

意思是：Skills 不是 Markdown 散文，是塑造 Agent 行为的代码。每一行都要为某个 agent 行为负责，不能是"纸面好看"。

启示 2：Anti-Rationalization 比技术细节更重要

LLM 最容易出问题的不是能力，是**"自我合理化偷懒"**。所以好的 Skill 一定要有：

• • 一条铁律（IRON LAW）
• • 红旗清单（Red Flags）
• • 借口反驳表（Rationalizations）

这三件加起来，比你写 200 行技术细节有用得多。

启示 3：上下文隔离比追求"全能"更重要

不要让一个 agent 干所有事。fresh-context subagent 是 2026 年最重要的设计模式。

主 session 做编排，每个具体任务派子 agent 干，主 session 永不被污染。

启示 4：架构分层 ≠ 过度设计

agent-skills 的 Skills/Personas/Commands 三层不是为了好看，是为了：

• • 让 Skill 可独立测试
• • 让 Persona 可被复用（如 /ship 用 3 个 Persona）
• • 让 Commands 提供给用户的 UX 入口

清晰的层次比抽象的"统一"更有价值。

启示 5：业务深度无法被通用 Skills 库取代

我的 87 个 skill 里有 48+ 个是飞书、AWS、微信、运维这种业务工作流。这是 superpowers 和 agent-skills 永远做不到的。

如果你也维护自己的 Skills 库，别想着替代通用 skill，要专注业务深度。这是你的护城河。

启示 6：Star 数高 ≠ 适合你

Superpowers 19 万⭐很猛，但你直接拿来用未必合适——它假设你想做"端到端自主开发"。如果你只想要"代码审查 + 文档"，agent-skills 更合适。

最佳实践是：从两边各拿你需要的，配上你自己的业务 skill。

📚 八、参考资料

项目仓库

1. 1. obra/superpowers^[1] — Jesse Vincent · 完整开发方法论 · 194,310 ⭐
2. 2. addyosmani/agent-skills^[2] — Addy Osmani · SDLC 全周期 · 42,590 ⭐

推荐阅读

1. 3. The Original Superpowers Release Announcement^[3] — Jesse Vincent 写于 2025-10-09，讲清楚了 Superpowers 的设计动机
2. 4. Software Engineering at Google^[4] — agent-skills 的方法论来源
3. 5. Google's Engineering Practices^[5] — 5-axis review 与 change sizing 的源头
4. 6. Anthropic's Skills System Documentation^[6] — 官方对 Skills 的定义

相关 Skill 单文件深读推荐

• • superpowers/skills/subagent-driven-development/SKILL.md — 最值得读的 skill，理解 fresh-context 思想
• • agent-skills/skills/doubt-driven-development/SKILL.md — 最值得抄的 skill，加进任何 agent 都能立刻提质
• • agent-skills/agents/README.md — 三层架构最清晰的解释

我用到的工具

• • 文章本身：wechat-article-writer skill (我自己的)
• • 全部 8 张配图：手写 SVG → rsvg-convert 转 1200px PNG → @upic/upload_image 上传到 img.aws.xin
• • 数据采集：GitHub API + 本地文件深读

💬 互动时间：

读完这篇，你最想吸收的是哪个 Skill？是 superpowers 的 subagent-driven-development，还是 agent-skills 的 doubt-driven-development？或者你也维护自己的 Skills 库，想分享你的独门 Skill？欢迎在评论区告诉我。

如果你已经在用 Claude Code / Codex / Cursor / Gemini CLI 的 plugin 系统，强烈建议今天就去把 superpowers 装上跑一次：

# Claude Code/plugin install superpowers@claude-plugins-official# Gemini CLI  gemini extensions install https://github.com/obra/superpowers

体验完之后再装 agent-skills，对比着看，会有完全不同的感受。

如果觉得有帮助，别忘了点个"在看"并分享给需要的朋友～

👆 扫码关注，获取更多精彩内容

引用链接

[1] obra/superpowers: https://github.com/obra/superpowers[2] addyosmani/agent-skills: https://github.com/addyosmani/agent-skills[3] The Original Superpowers Release Announcement: https://blog.fsck.com/2025/10/09/superpowers/[4] Software Engineering at Google: https://abseil.io/resources/swe-book[5] Google's Engineering Practices: https://google.github.io/eng-practices/[6] Anthropic's Skills System Documentation: https://docs.claude.com/