30万星工作流:逼AI先写计划再动手

你有没有过这种体验：让 AI 一上来就写代码，前面写得飞快，写到一半你发现它理解的需求跟你想的根本不是一回事，改三处崩五处，最后还不如自己从头写。那不是模型不行，是顺序错了——先动手，再对齐，返工就是必然的。

先给判断：Superpowers 是目前把“先对齐、再动手”这套流程做得最完整的一套免费方法论，它不换模型、不加新功能，只是给 Claude Code 一套强制走的流程：先问清楚、先写计划、先拆小任务，最后才写代码；但它不是质量保证书，流程越完整，token 花得也越多，小活上全套纯属浪费。

obra/superpowers

它到底是什么：不是插件，是一套流程

先把概念掰开，免得被名字唬住。Superpowers 的本体是一组 skill，一共十几个，每个 skill 就是一份“在什么情况下、按什么步骤做”的说明书：什么时候该头脑风暴、什么时候该写计划、什么时候该停下来做代码评审。Claude Code 会在每一步开始前先查一遍有没有对应的 skill，有就按说明书走，没得商量。

这就是它跟普通提示词模板的区别：提示词是你每次都要记得说一遍的话，skill 是装好之后 agent 自己会去执行的流程。你不用每次提醒它“先别写代码”，它到那一步会自动停下来问你。

这个项目最近是真的热：10 月 27 日登上 GitHub 日榜第一，写稿时仓库页面显示 30.6 万星，MIT 开源。作者是 Jesse Vincent，思路就一句话：给 agent 立规矩，比换更强的模型见效更快。

完整一圈：从一句话需求到合并分支

整个流程按顺序是七步，记住顺序比记住名字重要：

第一步，头脑风暴。你只说一句话需求，它会反过来连珠炮式地问你：这个功能给谁用？边界在哪？有没有不能碰的旧逻辑？问完还会把自己的理解复述一遍给你纠正。小改动直接在对话里定下来，大项目会落成一份设计文档。

第二步，建隔离工作区。设计定稿后，它会用 git worktree 另开一个干净分支和目录跑项目初始化，并确认测试基线是干净的。主分支上的代码全程不受打扰，搞砸了删工作区就行。

第三步，写计划。这是最关键的一步。计划会拆成一个个 2 到 5 分钟能做完的小任务，每个任务写明：改哪几个文件、接口长什么样、用什么测试证明做对了。计划默认存在 docs/superpowers/plans 下面，按日期加功能名命名。

第四步，执行计划，二选一。子代理模式是每个任务派一个全新的子代理去做，做完先审“做没做对”，再审“写得好不好”，两关都过才算完；inline 模式是当前会话自己按顺序做完，最后统一审一次。前者最严也最贵，后者最便宜。

第五步，测试先行。写功能之前先写失败的测试，看着它变红，再写最少量的代码让它变绿，然后提交。测试之前写出来的代码，它会直接删掉，不留情面。

第六步，任务间评审。每做完一个任务，都会有一次针对计划的评审，按严重程度列问题，严重问题会直接拦住进度，不让你带着 bug 往下走。

第七步，收尾。全部任务做完、测试全过，它会把选项摆出来：合并、提 PR、保留分支还是直接丢弃，然后清理工作区。

装好它：三条路线，十分钟能用上

硬门槛先说在前面：你得有一个能用 skill 的 agent，Claude Code 是最顺的一条路；其次要会用 git，因为 worktree 和分支是整套流程的地基，不会 git 的话先补这一课。

Claude Code 走插件市场，两条命令：

/plugin marketplace add obra/superpowers-marketplace/plugin install superpowers@superpowers-marketplace

其他 agent（Cursor、Codex、OpenCode 这些）走通用安装：

npx skills add obra/superpowers

装完不用特意学什么，验证方法很简单：新开一个会话，随便提一个“给我的项目加个某某功能”这种需要动手的需求，看它是不是先停下来问你问题、而不是直接开始写代码。先问问题，说明 skill 生效了；直接开写，说明没装上，回去检查安装步骤。

实战走一遍：给博客加个站内搜索

光讲流程太虚，拿一个具体需求走一遍你就明白了。假设你要给自己的博客加站内搜索：

你先说一句话：“给博客加个站内搜索，搜标题和正文。”装好 Superpowers 的 agent 不会直接开写，它会先问：搜索范围包不包括草稿？结果按什么排序？数据量大了要不要分页？要不要高亮关键词？

你答完，它把设计复述一遍，你点头之后，它建工作区、写计划。计划大概会拆成这样：先给文章建索引的小任务、再写搜索接口的小任务、再写前端搜索框的小任务、最后补测试的小任务，每个任务都带文件路径和验证方法。

执行时你选子代理模式也行，inline 模式也行。过程中每做完一个任务，它会停下来告诉你审过了、有什么问题。全部做完，它问你：合并还是提 PR？你选合并，工作区清理干净，主分支上多了一个能跑的搜索功能。

对比一下你平时的做法：直接说“加个搜索”，模型吭哧吭哧写一堆，跑起来发现搜不到草稿里的数据，你再补一句，它再改一处，改到第三处的时候第一处又崩了。省下来的不是写代码的时间，是返工的时间。

三个坑，全是真实用户先踩过的

坑一：提了需求，skill 没触发。最常见的原因是需求说得太笼统，或者你在一个已经装了好几个 skill 的项目里提需求，agent 匹配错了 skill。解法是把需求说具体一点，或者直接点名：“用 brainstorming 先对齐需求再动手。”别跟它客气，点名是最快的纠偏。

坑二：小活也上全套，越用越慢。改一行配置、修一个拼写错误这种活，走完整流程就是大炮打蚊子：问一堆问题、写计划、拆任务、评审，十分钟的活拖成一小时。判断标准就一条：改动会不会超过三个文件、你自己有没有想清楚怎么做。两个答案都是“否”，就别上流程，直接在对话里改。

坑三：子代理模式烧 token 比预期多。每个任务一个全新子代理、每任务两轮评审，任务一多，token 账单会吓你一跳。省钱的办法是：任务之间有关联的用 inline 模式，只把真正独立的大任务交给子代理；或者把计划拆粗一点，别拆成几十个两分钟任务。

还有一条红线要提前说：skill 只是指令，不是沙箱。它能让 agent 按流程走，但拦不住模型犯错，更替代不了你最后的检查。合并之前，测试结果和关键 diff 必须自己过一眼。

按项目大小选档位，别全套照搬

说到底，Superpowers 值不值得装，取决于你平时写的代码有多大。

三天以上的大功能、涉及多个模块的重构、你自己还没完全想清楚的需求，这三类最值得上全套：流程帮你省下的返工时间，远远超过多花的 token。日常的小修小补、改配置、改文案，直接对话改，别走流程。介于中间的活，折中方案是：只走头脑风暴加写计划这两步，执行自己来，既对齐了需求，又不被评审拖慢。

我自己的用法是：新功能默认走全套，修 bug 只走系统性调试那一个 skill，改文案一律不上流程。流程是工具，不是仪式，照单全抄的人最后都会嫌它慢。

你现在手头有没有一个“AI 写到一半跑偏”的项目？如果有，下次试试先让它问你五个问题再动手，看看返工是不是真的少了。