AI 写代码一年,跑了三个号称＂先想清楚再动手＂的工具,发现它们解决的根本不是同一件事

最近一年我把 GitHub 上三个号称"先想清楚再动手"的 AI 编码工具都翻了一遍：GitHub 组织的spec-kit（11.7 万 Star）、obra/superpowers（24.4 万 Star），再加上 Claude Code、Cursor、Aider 这些 agent 里几乎都有的通用项目规划模式。

我以为它们会帮我"管住 AI"。结果翻完之后发现：它们都不是在解决同一个问题——它们三个连"AI 应该被怎么管"这个根本假设都不一样。盲选任何一个都会跑偏。

更关键的是，这三套工具的中文资料加起来可能不到 5 篇。我花了两天把两个 GitHub 仓库的关键文件读完（spec-kit 的 10 个命令模板、5 个 spec/plan/tasks 模板、converge 闭环逻辑、workflows YAML 系统、扩展 API 参考；superpowers 的 brainstorming/test-driven-development 等核心 SKILL.md 全文、CLAUDE.md 治理规则、hooks/session-start bootstrap 机制）后，想把这件事讲清楚——给你一个对照表，免得你自己踩我踩过的坑。

先看个具体场景

假设你刚开始一个 Python 后端项目，让 AI 实现一个"用户上传文件后异步处理"的接口。三套工具的反应差别大到像三个不同公司在做：

• spec-kit 是 5 步主流程 + 1 个反向校准工具，跑完才能动代码：

1. /speckit.constitution —— 先写项目宪法（约束原则）。比如"所有 API 必须有 OpenAPI 文档""所有依赖都要在 pyproject.toml 里声明""不许用 ORM 直接裸 SQL"。
2. /speckit.specify —— 写用户故事，**只能写"用户做什么"和"为什么"，不准写"用什么技术实现"**。比如"用户上传 PDF 后，2 秒内返回 task_id"，不能说"用 FastAPI + Celery + Redis 实现"。
3. /speckit.plan —— 这时才让 AI 选技术栈、出架构方案。specify 阶段定的用户故事是它的输入。
4. /speckit.tasks —— 把 plan 拆成可勾选的开发任务（"实现 POST /upload 接口""写 OpenAPI 文档""写单元测试"），按依赖顺序排列。
5. /speckit.implement —— 一步步执行 tasks，每步基于 spec/plan/tasks。
6. /speckit.converge（可选） —— 跑完后回头比对代码和 spec 的差距，把没做完的追加成新 tasks。

• superpowers 会让 agent 先brainstorming——不是写文档，是和你来回聊天搞清需求，每一步都让你确认。等需求清了你说"开始"，才 invokewriting-plans 写实现计划，再 dispatch 子 agent 一个任务一个任务执行，每个任务完成后用requesting-code-review 子 agent 做两层审查。

• 通用项目规划模式（plan 模式）—— Claude Code 的/plan、Cursor 的 Composer Plan、Copilot Workspace 都是这一类——核心思路是把 AI 锁在"只读 + 只写计划文件"的状态，等你看完计划文件，再决定要不要执行。

表面看都是在 AI 写代码前加一道墙。但读完关键文件后你会发现：墙的厚度、墙的位置、谁来维护这堵墙，差别比较大。选错一个不一定"AI 失控"，但很可能浪费你前期投入的规范工作。

spec-kit：靠"模板内容"管 AI

spec-kit 的核心哲学写在docs/concepts/sdd.md 里，叫 "Spec-Driven Development"（SDD）。SDD 把"代码是国王，规范只是脚手架"这个几十年来的关系整个反过来——规范不再是用来指导代码的文档，而是直接生成代码的源头。代码退到下游，变成"规范在某种语言里的表达"。

读完关键文件后我发现 spec-kit 的设计有几条比"命令式流程"更深一层：

1. 命令文件本身就是约束 LLM 的 prompt。 拿templates/commands/specify.md 来说，第 282-283 行直接写 "Focus onWHAT users need andWHY. Avoid HOW to implement (no tech stack, APIs, code structure)"——这是给 AI 看的负面约束。但templates/spec-template.md 本身只有结构化占位符（用户故事、验收场景、需求列表），不含这些约束。spec-kit 不靠模板约束 AI，它靠命令文件约束 AI——模板是给人看的结构，命令是给 AI 看的规则。这是 spec-kit 跟其他两个工具最不一样的地方。

2. 10 个内置命令 + 声明式扩展系统。templates/commands/ 下有 10 个.md 文件：constitution、specify、clarify、plan、tasks、taskstoissues、implement、analyze、converge、checklist。但 spec-kit 不止有命令——它有个完整的扩展系统：extensions/EXTENSION-API-REFERENCE.md 定义了 manifest schema、Python API、Command File Format、Hook System、CLI Commands。你能写一个extension.yml 声明新命令、新 hook、新 preset、新 bundle，等于在不动核心代码的情况下扩展整套流程。.specify/extensions.yml 只是这个扩展系统的入口配置文件。

3. Converge 命令做"反向校准"。converge.md 的 frontmatter 描述得很直接："Assess the current codebase against the feature's spec, plan, and tasks, then append any remaining unbuilt work as new tasks to tasks.md so implement can complete it."——跑完 implement 之后，回头比对 spec/plan/tasks 和当前代码的差距，把没做完的追加成新任务。但有个细节需要注意——docs/concepts/sdd.md 明确说 "Spec Kit does not prescribe how teams preserve or mutate spec.md, plan.md, and tasks.md after requirements change"——converge 不修改现有 spec，只追加新 tasks。

4. Workflows 系统按官方文档支持 gate / fan-out / fan-in / 循环，但仓库里只有 1 个示例。docs/reference/workflows.md 第 3 行声明 "support conditional logic, loops, fan-out/fan-in, and the ability to pause and resume"。但workflows/speckit/workflow.yml（77 行）这个唯一示例只演示了 gate 模式（specify 后插入 approve/reject，plan 后再插入一个）。所以理论上能做并发分支、条件循环，实际用法只见过 gate。

5. 不强制"AI 在某 agent 里"。 spec-kit 跟 30+ coding agent 集成（Claude Code、Copilot、Cursor、Gemini CLI、opencode、Codex CLI 等等），但核心命令载体是 markdown 文档，让你自己塞进任何 coding agent。这是它和 superpowers 最大的架构差异——spec-kit 是内容平台，superpowers 是 agent 插件。

但 spec-kit 也有几个让 AI 失控依然可能的局限：

• TDD 不是默认强制，但有条件强制。constitution-template.md 第 19 行示例了 TDD 强制条款；tasks.md 第 146 行明确 "Tests are OPTIONAL: Only generate test tasks if explicitly requested"——但implement.md 第 148 行强制 "Execute test tasks before their corresponding implementation tasks"。意思是测试本身可选，但一旦 tasks 包含测试，TDD 顺序被强制。
• 不做子 agent 审查。 它假定执行 implement 的 agent 是可靠的，不额外审查。
• 没有 git workflow 强制。 它管 spec 不管分支——你可以在任何分支跑，但你得自己管理分支策略。
• 没有"流程之上的流程"。 spec-kit 自身就是流程，不在这个流程外面再套一层。

superpowers：靠"流程刚性"管 AI

读完 superpowers 的关键 SKILL.md 后我意识到一件事——它的定位跟 spec-kit 不完全一样。spec-kit 更像"AI 帮你写规范"，superpowers 更像"AI 按规矩做工程"——两者的关注点差了好几层。

1. skills 是可自动触发的，不是手动跑的命令。 superpowers 的README.md 写得很清楚——using-superpowers/SKILL.md（62 行）这条 bootstrap 规则第一句就是 "Invoke relevant or requested skills BEFORE any response or action"，后面跟着一句不容置疑的 "IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT." skill 不是slash command 让 AI 执行某个动作，而是预先定义好的提示注入机制——AI 每接一个任务前会扫描所有 skill，决定哪些自动生效。

2.using-superpowers 通过 SessionStart hook 自动注入。hooks/hooks.json 配置SessionStart 事件触发hooks/run-hook.cmd session-start 脚本。session-start 是个 bash 脚本，根据$CURSOR_PLUGIN_ROOT /$CLAUDE_PLUGIN_ROOT /$COPILOT_CLI 三个环境变量分支输出三种 JSON 格式给 agent：

• Cursor 用additional_context（snake_case）
• Claude Code 用hookSpecificOutput.additionalContext（嵌套）
• Copilot CLI 和其他用顶层additionalContext

bash 脚本第 11 行cat ${PLUGIN_ROOT}/skills/using-superpowers/SKILL.md 把 skill 内容读出来，escape 后塞进 JSON 输出。这意味着每次开新 session，AI 第一眼就看到"你有 superpowers"的指令。spec-kit 是被动等用户敲命令，superpowers 是主动接管行为。

3. 新增集成必须通过"金标准测试"。CLAUDE.md 第 78-89 行给新增 harness 设了官方验收测试——在干净会话里输入 "Let's make a react todo list"，brainstorming skill必须自动触发，否则视为不合格集成。手动复制 skill、用npx skills shim 包装、要求用户 opt-in 的都不算合格。**这是 superpowers 对外暴露的核心契约——不是"装了就行"，是"装完必须证明 bootstrap 生效"**。CLAUDE.md 第 76 行原话："A real integration loads theusing-superpowers bootstrap at session start. The bootstrap is what causes skills to auto-trigger at the right moments. Without it, the skills are dead weight."

4. brainstorming 是"对话设计"，不是"写文档"。skills/brainstorming/SKILL.md 第 7-9 行的 HARD-GATE："Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it." 但 brainstorming 的过程不是让 AI 写 spec.md——它是一次次问你问题，每次一个问题（"Ask questions one at a time"），等你全部确认后才把对话整理成docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md 文件。**整个过程是交互式的，而不是"AI 一口气写完"**。

5. 测试驱动是基础信仰，不是可选项。skills/test-driven-development/SKILL.md 第 30 行的铁律："NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST"。第 35 行更硬核："Write code before the test? Delete it. Start over."——不允许把违规代码留作参考、不允许"边写测试边参考它"、不允许看它，必须删掉从测试重新写。但留了 4 个例外（throwaway prototypes、generated code、configuration files、ask your human partner）——TDD 默认立场是拒绝，但留了沟通出口。

6. 用 subagent 强制分层审查。skills/subagent-driven-development/SKILL.md 第 6-7 行是这个工具最硬核的设计——"Fresh subagent per task + task review (spec compliance + code quality) + broad final review"。每个任务 dispatch 一个全新的 implementer 子 agent（不继承主上下文），任务完成后用 task-reviewer 子 agent 做"spec 合规 + 代码质量"两层审查，最后整个分支做一次 broad review。这是 superpowers 对"AI 在长会话里走偏"这个问题给出的一个解法——每一步上下文都是隔离的，主协调 agent 的上下文不会污染。

7. writing-skills 是 TDD 应用到文档。skills/writing-skills/SKILL.md 第 5 行："Writing skills IS Test-Driven Development applied to process documentation." 写一个 skill 必须先跑 baseline（用 pressure scenario 看 agent 不读 skill 时怎么出错），然后写 skill，再跑同样的 case 验证 agent 现在守规矩。这是用 TDD-on-doc 的方法论来验证 skill 是不是真的有效——不是写完就用，要先证明它能改变 agent 行为。这个 skill 文件 689 行，是整个仓库最长的 SKILL.md。

8. 项目维护方极其严格。CLAUDE.md 第 7 行直接写 "This repo has a 94% PR rejection rate"，第 66 行重申。列出了 9 条"不会被接受"的 PR 类型（第三方依赖、批量 PR、推论性修复、fork 同步、合规改名、领域专属 skill、项目专属配置、虚构内容、捆绑无关变更）。每个 PR 模板必须填完整，缺字段直接关。skill 修改要带 eval evidence。这套治理逻辑说明 superpowers 的核心不只是工具，还有方法论库——一旦方法论库质量下滑，整个项目的可信度也跟着崩。

9. brainstorming 还支持 visual companion。skills/brainstorming/scripts/server.cjs（723 行 Node.js 代码）是个完整的 WebSocket 服务器，把 HTML 推送到浏览器，让用户用看图的方式回答设计问题。这个细节很有意思——它把"做设计"这件事扩展到了视觉通道。

但 superpowers 也有几个让 AI 失控依然可能的局限：

• 学习曲线陡。 14 个 skill，每个 SKILL.md 都是长文档（TDD 371 行、subagent 418 行、writing-skills 689 行），agent 实际遵守要靠 bootstrap 注入。如果 harness 没正确加载 bootstrap，skill 就是死的——CLAUDE.md 直接说"without the bootstrap, the skills are dead weight"。
• 强 TDD 信仰有摩擦。 不是所有项目都适合 TDD（一次性脚本、配置类代码、纯 UI 静态文件），虽然 skill 留了"ask your human partner"的出口，但默认立场就是拒绝。
• 不解决"先想清楚"这个前置问题。 superpowers 假定你已经知道大致要做什么，它的 brainstorming 是用来细化需求的，不是用来从 0 到 1 探索方向的。

通用项目规划模式：靠"暂停键"管 AI

通用项目规划模式（Claude Code 的/plan、Cursor 的 Composer Plan、Copilot Workspace 等）和上面两个不在一个量级——它们是 agent 内置的轻量模式，而不是独立的工具。核心思路是让 agent 在 plan 模式下不能写代码、不能改项目文件（除了 plan md 文件）、不能跑 mutate 的终端命令——但具体哪些命令被禁、plan 模板长什么样、什么时候自动从 plan 切回 normal，每个 agent 自己定义。

这种模式的设计思路非常克制——它不规定"用什么模板写计划"，不规定"计划必须包含哪些部分"（虽然提示了目标 / 上下文 / 方案 / 分步计划 / 受影响文件 / 验证步骤 / 风险），也不规定"执行前必须做哪些事"。

通用项目规划模式的核心是把"AI 该不该动手"这个决策权交回给你。它假定 AI 不一定靠得住，所以给你个暂停键——但它不替你判断这个计划好不好。

它的优势是"零摩擦"——你不需要学任何新命令，不需要装插件，只需要在启动 agent 时切个开关。它至少能保证一件事："agent 在你 approve 之前不会动你的项目文件"。代价是 plan 内容质量完全依赖底层模型——AI 写的计划可能是空的，可能是错的，可能根本不切合项目实际。规划模式只是给你一个"先停一下"的机会，用不用是你的事。具体的细节规则因 agent 而异（Claude Code、Cursor、Copilot Workspace 的 plan 模式行为不完全一致），但核心机制一致。

三者对比——从关键文件看差异

按"你现在处于什么状态"选

按场景选——比抽象对比更直接：

头脑风暴场景的对比（你问的这个）：

关键区分：

• **superpowers 的 brainstorming 是"对话式"**——AI 不写代码、不出方案，只和你聊。一次一个问题，直到需求清晰。
• **spec-kit 的 specify 是"结构化"**——基于你已经有的 feature description，写出标准格式的 spec.md。

实际怎么配合：先用 superpowers brainstorming 把模糊想法聊清楚（产出 design.md），再把 design.md 当作输入给 spec-kit/speckit.specify 出正式 spec，最后用 superpowerssubagent-driven-development 执行。

怎么不踩坑：

按项目类型选：

怎么不踩坑：

• 别一上来就装 superpowers——它有 14 个 skill 都强制用，对"先快速试一下"的场景过度工程。先用 plan 模式或 spec-kit 跑两周，再考虑加 superpowers。
• 别装 spec-kit 但不用它的 TDD——spec-kit 的宪法写不写 TDD 完全看你，但如果你写了就要真执行，否则宪法就是空文。
• bootstrap 没生效就别用 superpowers——干净会话输入 "Let's make a react todo list" 看 brainstorming 自动触发没？没触发就是 harness 集成没做好。

叠加用法（高阶玩法）：spec-kit 出规范 → superpowers 执行（spec.md 转成 writing-plans 的输入）→ 通用规划模式作为任何阶段的临时刹车。这套叠法对超大型项目有用，对小项目是过度工程。

一个让所有读者都能记住的判断框架

把这三个工具拉到一起看，**它们的差别不是"功能不同"，而是"对 AI 的信任模型不同"**——

• spec-kit 信任模板与命令：它假定只要命令文件里的负面约束和结构足够精准，AI 自然会输出合规的规范。这是"内容驱动"的信任。
• superpowers 信任流程：它假定只要流程足够刚性（每个 skill 都有 HARD-GATE，每个任务都有 subagent 审查，bootstrap 必须自动注入），AI 更可能守规矩。这是"流程驱动"的信任——但能不能真的守规矩，最终还是看底层模型能不能跟住。
• 通用规划模式信任人：它假定 AI 不一定靠得住，所以给你个暂停键。这是"开关驱动"的信任。

你信哪种，决定了你用哪个。 如果你想从这三个里只选一个：

• 大型新项目 / 团队项目 → spec-kit（先定规矩比先写代码重要）
• 已有项目的持续开发 → superpowers（流程能保证长期一致）
• 个人 side project / 一次性工具 → 通用规划模式（没那么多讲究）

三方都指向同一个方向——**让 AI 写代码这件事从"凭感觉"变成"按规矩办"**。但路径不同，不存在"哪个更好"，只有"哪个更适配你的项目阶段"。

我从这次"读关键文件"里学到的三件事

最后给你三句我抄给自己的话：

AI 写代码不是变快了，是把"哪里会出错"这件事转移了。 至少从我的体验看，AI 直接出错的次数在下降，但你需要为"AI 没按你预期做事"投入更多注意力。规范流程不是为了防 AI 出错——更多是为了让你和 AI 对齐"什么算错"。

"约束 AI"是个有点夸张的说法——更准确地说，是约束 AI 的工作流。 spec-kit 的命令文件约束的是 agent 在 specify 阶段该输出什么；superpowers 的 subagent 审查约束的是每个任务实现完要不要 review；规划模式的暂停键约束的是 agent 在你 approve 之前能不能动文件。这些约束不保证 AI 不出错——它们保证的是出错时你能早点发现。

选工具前可以先想想你对 AI 的信任程度。 信任内容就选 spec-kit，信任流程就选 superpowers，信任自己就选规划模式。这不是非此即彼——我自己的倾向是 spec-kit 做规范、superpowers 做执行、规划模式做临时刹车。盲目跟着 Star 数选一个，你大概率会用得别扭——因为工具的设计假设和你对 AI 的预期可能差很多。

你现在正在用哪个？或者你已经在用其他类似工具了——觉得它们跟这三套有什么区别？留言聊聊，我下一篇文章挑呼声最高的那个继续读源码。