夜雨聆风最近两个月，我用一个叫 Superpowers 的工具改造了我用 AI 写代码的方式。
以前的状态是：打开 Cursor，跟它说"帮我加个用户登录功能"，它写一版，我跑测试发现密码没加密、错误处理没做、消息格式不对……一个 1 小时能写完的功能，我能跟它聊一上午。
用了 Superpowers 之后变成这样：我先花 10 分钟写一份"用户登录功能"的规范文档（行业里叫 spec），Superpowers 接过去自己拆任务、自己写测试、自己写代码、自己跑测试通过、自己 review。我中间只在节点上点确认。同样的功能，30 分钟交付。
差的不是模型，是有没有那份 spec。
它有多火 · 先看一眼 GitHub
Superpowers 这个工具是 Jesse Vincent（GitHub ID `obra`）2025 年 10 月开源的，到 2026 年 5 月 19 日，GitHub API 拉的真实数据是 197,315 stars。
仓库地址：[github.com/obra/superpowers](https://github.com/obra/superpowers)
7 个月涨到接近 20 万 star，这种增长速度在 AI 工具圈里少见。
它已经被 Anthropic 收进官方插件市场（在 README 里挂的 [claude.com/plugins/superpowers](https://claude.com/plugins/superpowers) 就是 Anthropic 官方页）。
这两件事一起发生，意味着这套方法论是 Anthropic 官方认可的 Claude Code 该走的方向。
Superpowers 不是孤例。它跟另外两家工具是同一波，都是冲着"vibe coding 跑不动工业级项目"这件事去的。
跟它经常一起被提到的两家：
GitHub Spec Kit（[github.com/github/spec-kit](https://github.com/github/spec-kit)）。
GitHub 官方在 2025 年 8 月 21 日开源的工具。9 个月，102,414 stars。微软已经在 Microsoft Learn 出了配套训练课程。是大厂第一次给这套方法论出工具。
OpenSpec（[github.com/Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec)）。
Fission-AI 2025 年 8 月 5 日开源。9 个月，49,025 stars。它最有特色的能力叫 Delta Specs，专门给老项目改造用，只描述"这次改的部分"而不是把整套规范重写一遍。
OpenSpec 主页 · 截至 2026-05-19 的 49,025 stars
三家工具背后的方法论叫 spec-driven development（spec 驱动的开发，下面叫"文档驱动开发"）。
Superpowers 是它的代表产品之一，因为名字好记 + 增长最快，开发者社区在聊这套方法论时经常用 Superpowers 当代名词。
下面从 4 个角度看清楚这套方法论：它是什么、它跟你已经在用的东西什么关系、它从哪冒出来、你的业务该不该用。
· · ·
一、它是什么 · 先写文档，再让 AI 看着办
我第一次用 Superpowers 的时候有个认知冲击。
我跟它说"帮我加个用户登录功能"，它没有像 Cursor 那样直接写代码，而是反问我："这个功能的 spec 呢？没有的话我们先一起写一份。"
然后它开始问我：邮箱字段是什么类型？必填还是选填？错的情况要怎么处理（什么都不填？格式不对？域名不存在？）？每种情况要返回什么提示？测试要走哪几个 case？
我一边回答它一边发现：这些问题我自己平时都没仔细想过。
以前用 Cursor 写代码，我脑子里只有"用户登录功能"这 6 个字。Cursor 看到这 6 个字也开始猜，猜的就是 bug。Superpowers 让我先把这 6 个字背后该有的所有细节都明确出来，AI 看完不用猜，直接落地。
这就是文档驱动开发的核心：spec 是写给 AI 看的 PRD。
旧 PRD 写给同事看，同事懂业务、懂代码，PRD 里"这个字段大概是字符串"这种话他能补脑。AI 不能。所以 spec 必须精确到字段类型、错误处理、测试用例。
举个对照。旧 PRD 写"用户注册时校验邮箱"，AI 看到开始猜：什么叫校验？错了返回啥？
spec 写出来就不再是这种一行话了。它会精确到几件事：邮箱字段是什么类型、必填还是选填、空字符串要返回什么提示、不符合邮箱格式要返回什么提示、域名不存在要返回什么提示、测试时要走哪几个具体输入和对应的预期输出。一份合格的登录功能 spec，大概有 80-200 行这种规范条目。
AI 看完不用猜，直接落地。这就是"AI 能直接执行的 PRD"。
· · ·
二、它跟你已经知道的东西什么关系
文档驱动开发是个新概念吗？聊得多了发现不是。它是 4 样老东西的工程化升级。
跟 PRD 的关系：spec 不替代 PRD，是把 PRD 升级成 AI 能直接执行的版本。差别在你写给谁看。旧 PRD 写给同事，新 spec 写给 AI。
举个真实场景。我前两天帮一个朋友看他的 PRD，他写"用户头像支持上传"，他自己脑补了 10 个细节（格式 / 大小 / 存哪 / 前端组件）。
我让他把这 10 个细节明确写出来，他写了 20 分钟。然后我跟 AI 说"按这个 spec 实现"，AI 跑了 8 分钟交付。如果他没写那 20 分钟的 spec，AI 跟他聊一晚上都不一定收敛。
跟 TDD（测试驱动开发）的关系：Superpowers 把 TDD 强制升级。
老 TDD 是"建议先写测试"，工程师心情好就写，赶进度就跳。Superpowers 把这条变成铁律。它在 README 里直接写的规则是：先写一个会失败的测试，跑一遍确认它失败，再写最小代码让它通过，再 refactor 优化。原文是这套循环叫 RED-GREEN-REFACTOR。
更狠的一条规则是 README 里另一句话："测试写完之前你写的代码必须删掉"。这是为了堵死那种"我已经写好了正确答案，再补个测试"的逆向操作。
以前 TDD 靠工程师自觉，现在内置成工具的纪律。这是文档驱动开发跟传统 TDD 最关键的差别。
跟 vibe coding（Cursor / Copilot 自由聊）的关系：是分工，不是替代。
vibe coding 适合探索期。你不确定要做什么、想边聊边想边写、跑通一个 demo 看看可不可行。这一阶段聊得越多越好。
文档驱动开发适合交付期。你要的不是 demo 而是工业级项目，每个功能要进生产环境跑、要被 100 个用户同时用、出 bug 要能查到根因。这时候得先把 spec 写清楚。
现在比较成熟的做法是两个混用：先 vibe coding 1-2 天看可行性、跑一个 demo 看效果，再用 Superpowers 1-2 周做工业级版本。两条腿走路。
很多人卡在 vibe coding 的 happy path 假象里，demo 跑通就以为能交付，结果第 3 周项目崩。
跟 Coze / Dify 这种 no-code 的关系：完全不是一回事。
Coze / Dify 是给非工程师用的。你不写代码，拖几个组件拼一个流程，AI 帮你跑。
文档驱动开发是给工程师用的。你还是要写代码，只是用 AI 当帮手。spec 是工程师写给 AI 的工作指令，不是给业务方拖拽的可视化界面。
最简单的判断口径：你写代码吗？写 = spec-driven 路线。不写 = Coze / Dify 路线。
· · ·
三、它从哪冒出来 · 一条 2 年的演进线
聊这套东西的来历，是因为想搞清楚一件事：为啥这一波 superpower 工具突然在 2025 年下半年集中爆发。
往回看 2 年线就明白了。
2024 年，Cursor、Windsurf、GitHub Copilot 这一批工具进入主流。开发者第一次能直接跟 AI 聊代码。整个圈子陷入一种乐观。AI 写代码的关键就是 prompt 写得好，聊得多就准。"vibe coding"这个说法在 2025 年初被 Andrej Karpathy 在 Twitter 上正式叫开。他用这个词描述自己用 AI 写代码的状态：一种几乎不审视代码、只看能不能跑的随性模式。整个圈子兴奋了半年。
2025 年中，问题开始浮现。陆续有工程师发现，vibe coding 跑 demo 没问题，但要进入真业务系统就出事。第 1 周聊得开心，第 3 周项目收不住。bug 改了新 bug 又冒出来。
原因是 vibe coding 没有规范约束、没有测试覆盖、AI 的输出每次都飘一点。demo 阶段你能容忍这种飘，工业级阶段不行。飘一次进生产环境就是一个真 bug，影响真用户。
社区慢慢酿出一个共识：vibe coding 适合好玩，不适合交付。
2025 年 8 月，Fission-AI 开源 OpenSpec（8 月 5 日），GitHub 紧接着开源 Spec Kit（8 月 21 日）。这是大厂第一次给文档驱动开发出工具。Spec Kit 9 个月内涨到 102k+ stars。
2025 年 10 月，obra 开源 Superpowers。它把 Spec Kit 那套方法论加上一条"先写失败测试再写代码"的铁律，7 个月涨到 197k+ stars。Anthropic 官方插件市场上架。
2026 年，文档驱动开发进入主流话语。微软出 Microsoft Learn 训练课程，OpenSpec 的 Delta Specs 让老项目改造也能用上这套。技术媒体把 Spec Kit 称为"vibe coding 的解药"。
整条线背后的逻辑：AI 写代码这件事，2024 年靠"模型聪明"在 demo 阶段够用，但到 2025 年要解决工业级问题，光靠模型聪明不够，需要工程纪律。spec-driven development 就是把工程纪律变成 AI 能执行的格式。
· · ·
四、它是不是噱头
简单说，不是。
挑工具有个习惯，拿"合格 AI 项目"6 维诊断尺（场景选对 / 接真业务系统 / Happy path 之外测过 / 工作流真改造 / 价值能量化 / 经得起多轮迭代）逐项对位 ✓ 看下来 6 项全部能对位。197k stars 和 Anthropic 官方上架这两件事一起，已经把它从"看起来很火"推到"被官方认证"了。
但这不等于人人该上。一个简单的判断口径：你写的代码上线后会被多少人用？只有自己用，不必上；团队几个人用，可以上不强制；公司客户用、100+ 用户的项目，必须上。
至于你自己不写代码但带技术团队 —— 至少得知道这套范式存在。两派开发的工作节奏完全不一样：vibe coding 派起步快但代码进生产容易出问题，spec-driven 派起步慢但稳定输出。leader 不懂这两派差别，会把好的 spec-driven 派给开了，留下一堆 vibe coding 派搞工业级项目，第 3 周整个项目崩。
· · ·
收尾
我用 Superpowers 这两个月最深的感受是这样：以前我跟 AI 写代码，是我在用 AI；现在我跟 Superpowers 写代码，是 Superpowers 在带着我用一套工程纪律。
vibe coding 是 AI 写代码的"好玩阶段"，Superpowers 是 AI 写代码的"能交付阶段"。
GitHub Spec Kit 102k 星、Superpowers 197k 星。这两个数字什么概念？平均算下来 Superpowers 每天涨 900+ stars 涨了 7 个月。这是工业级 AI Coding 这条路上，开发者用脚投出来的票。
当然，Superpowers 现在很火不代表它就是终极方案。2 年后可能又有新的工具来替代。AI Coding 这两年的演进速度大家也看到了。我能确定的是，vibe coding 这一波的"happy path 假象"已经被业内承认是个真痛点，spec-driven 现在是行业给出的第一份系统化答案。
你跟那个 1 天交 3 个 PR 的同事中间，隔的不是模型，是他先写了一份 AI 看得懂的 spec。
看完如果还有问题，欢迎在评论区提问，如果你还想要了解更多落地AI项目的工程化开发，也欢迎进入公益的大模型技术社区～
