AI 编码 Skill 大 PK：Karpathy、Grill Me、Superpowers、GSD、OpenSpec 到底谁靠谱？
AI 编码助手能写出好代码，不是因为它聪明，而是因为它背后有人给它写了「说明书」。今天把市面上最火的几个说明书拆开看看。
一、一个被忽视的真相
现在很多人讨论 AI 编码，关注点都在模型能力上——GPT-4o 比 Claude Opus 强多少，Gemini 追没追上。
但一个被严重低估的事实是：同样一个 Claude 3.5 Sonnet，装不同的 Skill 文件，输出质量可以差出一个数量级。
Skill 文件（也叫 .md Rules 或 Agent Skills）本质上是给 AI 的「工作手册」。它告诉模型：遇到什么问题用什么方法解决、写代码前该做什么、写完代码后该检查什么、什么情况下该停下来问人。没有它，AI 就像个没受过培训的实习生——有脑子，没规矩。
Web Dev Cody 最近做了一个很扎实的对比评测，把市面上最火的几个 AI 编程 Skill 拉出来 PK，还拿他自己的系统一起测。结果很有意思，值得详细说说。
二、四大热门 Skill 库对比
1. Karpathy Skills — 14 万 Stars
Andrej Karpathy 出品，知名度最高。核心就四条原则：
- Think before coding：编码前先思考
- Simplicity first：简单至上
- Surgical changes：精准修改
- Goal driven execution：目标驱动执行
它的主要价值是解决 Claude「用力过猛」的问题——AI 经常为了修一个小 Bug，把半仓库文件都改了。Karpathy 强制模型保持克制：200 行代码能用 50 行写完？那就重写 50 行。
但说实话，这个 Skill 更像是「原则清单」而不是「工作流系统」。它告诉 AI 该怎么做，但没告诉 AI 每一步该做什么、什么时候停、怎么验证。很多用户安装它纯粹是因为 Karpathy 的名气，而不是因为它真的解决了什么具体问题。
2. Matt Pocock — Grill Me Skill — 10 万 Stars
核心机制极简：只有一两句话的 Prompt，强制 AI 在写代码前，先向人类提出一堆问题—— sometimes 60 到 70 个——直到把所有边界条件和需求对齐。
这个设计的初衷是对的：需求不清是 AI 写出垃圾代码的最大元凶。通过「拷问」机制，强迫用户在开始前把需求想明白。
但问题也很明显：对资深工程师来说，被 AI 问几十个基础问题是一种折磨。 如果你已经知道自己在做什么，Grill Me 的流程会变成阻塞而不是帮助。它更适合完全不知道怎么描述需求的小白，而不是有明确目标的开发者。
3. Superpowers Skills — 20 万 Stars
这是四个里面工作流最完整的一个。核心流程：
- 提问头脑风暴
- 用 Git Worktree 开新分支规划
- 拆解子任务
- 调用子 Agent 并行编码
- 测试驱动开发（TDD，自动跑测试验证）
- 代码审查与清理
Superpowers 的强项在于自动化验证闭环。当你想丢下一个任务让 AI 自己在后台跑 30–40 分钟时，它的 TDD 机制能确保出来的东西是可运行的、有测试覆盖的。这是很多其他 Skill 缺少的「验收层」。
4. Get Shit Done (GSD) — 6.3 万 Stars
专门为「从零脚手架构建新项目」或「消灭一整个 Backlog」设计。工作流是：
规划 → 执行里程碑 → 验证 → 下一个里程碑
GSD 的价值在批量自动化。如果你有一堆积压任务，想丢给 AI 让它一个接一个去消灭，GSD 的闭环设计非常合适。它不是帮你写某一个功能，而是帮你「跑完一个项目」。
5. OpenSpec — 4.9 万 Stars（重点推荐）
这个 Skill 我必须单独拿出来说，因为它的思路和上面四个完全不在一个维度上。
前面四个 Skill 解决的都是「怎么写」的问题——怎么思考、怎么对齐需求、怎么验证、怎么批量推进。OpenSpec 解决的是另一个问题：「写的是什么」。
它的核心理念是：Spec 是唯一真值（Single Source of Truth），代码只是 Spec 的实现物。
项目结构很有意思：
specs/ # 系统的当前真值，描述「现在是什么样」
changes/ # 每个变更独立文件夹，描述「要改成什么样」
├── add-payment-flow/
│ ├── proposal.md # 提案：为什么改、改什么
│ ├── delta.md # 增量 spec（ADDED/MODIFIED/REMOVED）
│ └── tasks.md # 拆解的任务列表核心工作流（OPSX）有四个阶段：
/opsx:propose：提出变更提案，先写 spec 再写代码/opsx:apply：按 spec 执行实现/opsx:sync：验证实现与 spec 一致/opsx:archive：合并 delta 到主 spec，归档变更
OpenSpec 的设计哲学和其他 Skill 有几个本质区别：
| 维度 | 其他 Skill | OpenSpec |
|---|---|---|
| 真值载体 | 代码 | Spec 文档 |
| AI 角色 | 编码执行器 | Spec 实现器 + 一致性校验器 |
| 变更管理 | Git Commit | Delta Spec（ADDED/MODIFIED/REMOVED） |
| 工具绑定 | 多数绑定特定 IDE | 支持 25+ AI 助手，不锁定工具 |
| 可定制性 | 修改 .md 规则 | Schema 驱动（yaml + template） |
这个差异看似细微，实际影响巨大。当 Spec 成为真值时，AI 的行为边界就被精确锁定了。 你不需要担心 AI 用力过猛改一堆无关代码（因为 Spec 没说要改），不需要担心需求漂移（因为每次变更都要先更新 Spec），不需要担心文档过期（因为 Spec 本身就是文档）。
对比同类方案：
- GitHub Spec Kit：太重，流程繁琐，适合大型企业但小团队用不起来
- Kiro（AWS）：锁死 AWS IDE 生态，迁移成本高
- OpenSpec：轻量、开放、跨工具，是目前 Spec-Driven 路线里最务实的选择
什么场景最适合 OpenSpec？
- 多人协作的中大型项目，需要严格的需求-实现追溯
- 对 API 契约稳定性要求高的后端服务
- 想从「Vibe Coding」升级到「规范驱动开发」的团队
- 需要在多个 AI 工具间切换（Claude Code、Cursor、Copilot、Cline 等）但又想保持一致性
一句话总结：OpenSpec 不是让 AI 写得更好，而是让 AI 写得「对」。 这是从「质量」到「正确性」的升级。
三、为什么 Skill 质量差距这么大？
把这几个 Skill 放在一起看，会发现一个清晰的进化脉络：
| 层级 | 代表 | 提供什么 | 缺失什么 |
|---|---|---|---|
| 原则层 | Karpathy Skills | 编码哲学和约束 | 执行步骤、验证机制 |
| 对话层 | Grill Me | 需求对齐机制 | 代码实现、质量验收 |
| 执行层 | Superpowers、GSD | 完整工作流 + 测试验证 | 需求-实现追溯、长期一致性 |
| 规范层 | OpenSpec | Spec 作为真值，AI 行为边界精确锁定 | 对小型快速迭代项目偏重 |
Karpathy 只给原则，Grill Me 加对话，Superpowers 和 GSD 加执行和验证，OpenSpec 把整个游戏规则改了——它不再问「AI 写得好不好」，而是问「AI 写的对不对」。
但这里有一个关键洞察：Skill 文件的价值不是「规则有多少条」，而是「规则能不能形成强制卡点」。
LLM 的本质是「预测下一个 Token」，没有外部约束时它很容易走捷径。比如：
- 你让它「优化这个函数」，它可能顺手改了三五个无关文件——因为「改得更干净」对它来说是更优的预测结果
- 你让它「加一个登录功能」，它可能忘了加输入验证和错误处理——因为这些在训练数据里不是高频 Token 序列
好的 Skill 文件，就是用流程设计来对抗模型的走捷径倾向。Superpowers 用 TDD 做卡点——代码必须过测试才算完成。GSD 用里程碑做卡点——每个阶段必须验证通过才能进入下一个。
这也是为什么「原则型」Skill（Karpathy）效果有限——它告诉 AI「要简单」，但没告诉 AI「怎么算简单、谁来验收简单」。没有验收标准的约束，原则就只是建议。
四、什么场景用什么 Skill
没有最好的 Skill，只有最适合场景的 Skill。
| 场景 | 推荐 Skill | 为什么 |
|---|---|---|
| 快速改一个 Bug / 调样式 | Karpathy Skills | 简单克制，不折腾 |
| 需求完全不清楚，不知道怎么开始 | Grill Me | 强迫你先把需求想明白 |
| 丢下任务让 AI 自己跑 30 分钟 | Superpowers | TDD 自动验证，出来就能跑 |
| 从零搭建一个新项目 | GSD | 批量消灭任务，路线图清晰 |
| 多人协作 + 长期维护的中大型项目 | OpenSpec | Spec 即真值，需求-实现可追溯 |
| 多 AI 工具切换但要保持一致性 | OpenSpec | 不锁定工具，支持 25+ AI 助手 |
这些 Skill 不是互斥的，是可以组合的。一个更成熟的工作流可以是：
- 用 OpenSpec 定义需求和系统契约（Spec 层）
- 用 Grill Me 在 Spec 阶段做需求拷问，把模糊点扫干净
- 用 Superpowers 拆解任务、并行执行、TDD 验证（实现层）
- 用 Karpathy 的克制原则约束具体编码行为（风格层）
- 用 GSD 管理整体路线图，批量消灭 backlog（项目层）
这个组合的精髓是：OpenSpec 管「写什么」，其他 Skill 管「怎么写」。 两者结合，才是完整的 AI 编码工程化方案。
Skill 文件的生态还在早期，未来很可能出现「Skill 组合包」——不是安装一个，而是安装一套针对不同阶段的 Skill 链。
五、写在最后
这个视频给我的最大启发不是「哪个 Skill 最好」，而是：AI 编码的质量上限，已经被 Skill 文件的设计能力决定了。
同样的 Claude 3.5 Sonnet，装 Karpathy 的 Skill 和装 Superpowers 的 Skill，写出来的代码完全是两个档次。这不是模型的问题，是「上下文工程」的问题。
在 AI coding 时代，工程师的核心竞争力正在从「写代码」转向「设计工作流」。谁更懂得用 Skill 文件来约束 AI 的行为、定义验收标准、建立质量卡点，谁就能让 AI 产出更靠谱的结果。
如果你现在还在裸用 Claude Code——就是直接跟它对话让它写代码，没有装任何 Skill——那你大概只用了它 30% 的能力。
去装一个 Skill 试试。如果是个人小项目，从 Superpowers 或 GSD 开始；如果是团队协作的中大型项目，强烈建议直接上 OpenSpec——它能解决的不仅是「AI 写得好不好」，更是「团队多人多 AI 之间如何对齐」的根本问题。
体验过有流程约束的 AI 编码后，你大概率回不去了。
本文基于 Web Dev Cody 的视频内容整理，并补充了 OpenSpec 的对比分析。视频原文标题：《The Most Popular AI Coding Skills Right Now》。