上周，我让 Claude 帮我写个用户登录功能。一开始挺顺利，它很快就给出了代码。但当我要求"加上邮箱验证"时，事情开始失控——它重写了整个认证逻辑，把我之前确认好的密码加密方案也改了。
这就是典型的"拍脑袋编码"：AI 像个充满热情但缺乏方向的新手，想到哪写到哪。
经过几个月的摸索，我发现了三个能真正"驾驭" AI 的工具。它们就像三种不同风格的缰绳，帮你把 AI 的创造力引导到正确的方向上。
Github：
Spec-Kit： github.com/github/spec… OpenSpec： github.com/Fission-AI/… superpowers： github.com/obra/superp…
快速认识
想象一下你要装修房子：
- Spec-Kit 像一本详细的《装修规范手册》——告诉你什么能做、什么不能做
- OpenSpec 像便利贴系统——快速记录变更，灵活调整
- Superpowers 像专业施工队的工作流程——每一步都有检查点，确保质量
| 维度 | Spec-Kit | OpenSpec | Superpowers |
|---|---|---|---|
| 风格 | 严谨规范派 | 灵活敏捷派 | 质量把控派 |
| 核心方法 | 先写规范再编码 | 边做边调整 | 测试驱动开发 |
| 上手难度 | 需要学习成本 | 开箱即用 | 需要适应期 |
| 最佳场景 | 大型项目 | 快速原型 | 质量敏感项目 |
缰绳1：Spec-Kit（规范派）
它解决什么问题？
如果你担心 AI "越改越偏"，Spec-Kit 就是你的定海神针。它强制要求：动手之前，先把规矩说清楚。
实际体验
我第一次用 Spec-Kit 时，感觉像在填一份超详细的申请表。它要求你回答：
- 这个项目的"宪法"是什么？（代码风格、质量标准）
- 具体要做什么功能？（不写技术细节，只描述需求）
- 用什么技术实现？（技术选型）
- 怎么一步步做？（任务拆解）
填完之后，AI 就像拿到了一份完整的施工图纸，不会再随意发挥。
上手试试
# 安装（需要 Python 环境）
curl -LsSf https://astral.sh/uv/install.sh | sh
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
# 开始一个项目
/speckit.constitution # 制定规矩
/speckit.specify # 描述需求
/speckit.plan # 技术规划
/speckit.tasks # 任务拆解
/speckit.implement # 开始实现
适合谁？
- 团队规模：10人以上
- 项目类型：需要长期维护的企业级应用
- 个人特质：喜欢未雨绸缪，讨厌返工
优缺点实话实说
优点：
- 一旦规范定好，AI 执行很稳定
- 团队协作时，大家按同一套规矩来
- GitHub 官方出品，长期维护有保障
缺点：
- 前期投入大，小项目用起来像"杀鸡用牛刀"
- 需要写很多文档，对急性子不友好
- Python 技术栈，前端同学需要适应
缰绳2：OpenSpec（灵活派）
它解决什么问题？
如果你嫌 Spec-Kit 太"重"，OpenSpec 就是轻量级替代品。它的理念是：规范要跟着需求变，不能一成不变。
实际体验
用 OpenSpec 的感觉就像在便利贴上写待办事项：
- 提出想法：
/opsx:propose "做个暗黑模式" - 自动生成规范文档（proposal.md、design.md、tasks.md）
- 执行：
/opsx:apply - 需要调整？随时改，再执行
没有繁琐的流程，就像和 AI 在 Slack 上对话一样自然。
上手试试
# 一行命令安装
npm install -g @fission-ai/openspec@latest
# 进入项目目录
cd your-project
openspec init
# 开始干活
/opsx:propose "我要的功能..."
/opsx:apply
适合谁？
- 团队规模：1-5人的小团队或个人开发者
- 项目类型：MVP、原型验证、快速迭代的产品
- 个人特质：喜欢快速试错，讨厌被流程束缚
优缺点实话实说
优点：
- 安装简单，npm 一键搞定
- 学习成本低，30分钟上手
- 支持 Claude、Copilot、Cursor 等主流 AI
- 社区活跃，插件丰富
缺点：
- 太灵活了，容易变成"另一种形式的随意"
- 需要自律，否则规范文档会变成摆设
- 企业级功能相对薄弱
缰绳3：Superpowers（质量派）
它解决什么问题？
如果你最在意代码质量，Superpowers 就是你的不二之选。它核心强调 TDD（测试驱动开发）——先写测试，再写代码。
实际体验
Superpowers 给我的感觉像请了一个严格的代码审查员：
- 你想写功能？先写测试
- 测试通过了？才能写实现
- 实现写完了？必须重构
- 每一步都有检查点，别想偷懒
刚开始很不习惯，但用了一段时间后，代码质量确实提升明显。
核心技能
Superpowers 提供了一套"技能卡"，按需启用：
- brainstorming - 帮你理清需求
- writing-plans - 生成详细计划
- test-driven-development - 强制 TDD 流程
- systematic-debugging - 系统化调试
上手试试
# Claude Code 用户
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace
# Cursor 用户
/add-plugin superpowers
适合谁？
- 团队规模：任何规模
- 项目类型：对质量要求高的长期项目
- 个人特质：追求完美，愿意花时间写测试
优缺点实话实说
优点：
- 代码质量有保障，Bug 明显减少
- 技能可组合，按需启用
- 支持多平台（Claude、Cursor、Codex）
- 强制 TDD，养成好习惯
缺点：
- TDD 学习曲线陡峭，前期很痛苦
- 开发速度会变慢（但后期维护成本降低）
- 概念较多，需要花时间理解
三绳合璧：我的实战组合
这三个工具不是互斥的，我现在的 workflow 是：
阶段1：项目启动（Spec-Kit）
- 用 Spec-Kit 制定项目大方向和核心规范
- 输出 constitution.md 和 plan.md
阶段2：快速迭代（OpenSpec）
- 具体功能开发用 OpenSpec
- 灵活调整，快速验证
阶段3：质量保证（Superpowers）
- 核心模块启用 Superpowers 的 TDD 技能
- 确保关键代码的质量
这种组合既保证了规范性，又保持了灵活性，还能确保质量。
选型指南：找到适合你的那一把
按团队规模
| 团队规模 | 推荐工具 | 理由 |
|---|---|---|
| 1-3人 | OpenSpec | 轻量快速，不拖慢节奏 |
| 3-10人 | Superpowers | 技能标准化，质量有保障 |
| 10人以上 | Spec-Kit | 规范统一，协作顺畅 |
按项目类型
| 项目类型 | 推荐工具 | 理由 |
|---|---|---|
| 快速原型/MVP | OpenSpec | 快速验证，随时调整 |
| 长期维护产品 | Superpowers | TDD保证代码质量 |
| 企业级系统 | Spec-Kit | 流程严谨，可预测性强 |
按你的性格
| 你的风格 | 推荐工具 | 理由 |
|---|---|---|
| 喜欢提前规划 | Spec-Kit | 满足你的控制欲 |
| 喜欢边做边想 | OpenSpec | 不束缚你的创造力 |
| 追求完美主义 | Superpowers | 强制质量保证 |
Github：
Spec-Kit： github.com/github/spec… OpenSpec： github.com/Fission-AI/… superpowers： github.com/obra/superp…
写在最后
这三个工具就像三种不同的驾驶风格：
- Spec-Kit 像开豪华轿车——舒适安全，但需要学习复杂的仪表盘
- OpenSpec 像骑自行车——轻便灵活，但需要自己把握平衡
- Superpowers 像开赛车——速度快、质量高，但需要专业训练
没有最好的工具，只有最适合你的工具。
我的建议是：先从 OpenSpec 开始，感受规范驱动开发的魅力。当你觉得需要更强的规范性时，尝试 Spec-Kit；当你追求代码质量时，引入 Superpowers 的 TDD 流程。
毕竟，工具是为人服务的，不要让工具成为你的负担。
关注
对 AI 辅助开发和工程化实践感兴趣？关注我，我会持续分享实用的开发方法论和工具评测，帮你提升团队开发效率。
