AI 编程工具层出不穷，但真正的问题不是"AI 能不能写代码"，而是"如何让 AI 按照软件工程的标准流程开发"
最近两年，AI 编程工具的迭代速度让人眼花缭乱。从自动补全到对话式生成，从单文件改写到跨项目重构，AI 写代码的能力已经跨过了一道又一道门槛。
但很多团队用下来却发现一个尴尬的事实：AI 越能干，团队反而越累。
代码是产出了不少，可线上事故多了几倍，技术债越堆越厚，回头想看看当初为什么这么改——没人记得了。
问题出在哪？
出在大多数 AI 编程工具只解决了"写"这一环，而软件工程的完整链路远不止"写"。它至少包括：理解需求、设计方案、拆分任务、测试验证、代码审查、变更追溯。这些环节缺失任何一个，最终交付的都是一颗随时会爆的雷。
2026 年，开源社区有两个项目——Superpowers 和 OpenSpec——恰好补上了这套流程。它们一个管"怎么做"，一个管"做什么"，被业内称为 AI 编程的"黄金搭档"。
一、AI 编程的四个老毛病
在介绍这两个工具之前，先打个比方。
你招了一个能力超强的实习生，让他帮你做个用户管理功能。
你："帮我做个用户管理功能"
实习生（秒回）："好嘞！"
→ 直接开始写代码
三天后：
✅ 代码写完了
❌ 密码明文存储（安全隐患）
❌ 没有测试（不知道能不能跑）
❌ 改了三个版本，为什么改全忘了
❌ 需求理解偏了，你要的是手机号登录，他做了邮箱登录
这个场景是不是很熟悉？绝大多数团队引入 AI 编程后遇到的问题，本质上可以归结为四类：
| 问题 | 表现 | 后果 |
|---|---|---|
| 需求模糊 | 你说"用户管理"，AI 想的是邮箱登录 | 做出来的不是你想要的 |
| 执行失控 | AI 上来就写代码，不写测试不审查 | 代码能跑但质量堪忧 |
| 变更不可追溯 | 改了很多版，没人记得为什么改 | 后来人不敢动这段代码 |
| 质量不稳定 | 今天生成的好，明天生成的差 | 心里没底 |
这时候需要的不是"更强的 AI"，而是一套规范约束 + 执行流程。说白了，就是先立规矩，再干活。
Superpowers 和 OpenSpec，就是这两套机制的具象化。
二、Superpowers：给 AI 请了个"项目经理"
它解决什么问题
如果没有 Superpowers，AI 拿到需求就直接开始敲代码，质量全靠运气。有了 Superpowers，AI 会先做这一串动作：
- 追问你，需求到底要什么
- 把大任务拆成小步骤
- 先写测试
- 再写代码
- 互相审查
- 全部验证
它的核心理念只有一句话：
不是让 AI 多会写代码，而是尽量让它少在错误的时机写代码。
安装方式（Claude Code）
/plugin install superpowers@claude-plugins-official
八个核心技能，覆盖开发全流程
Superpowers 给 AI 配了 8 个"超能力"，每个对应开发流程的一个环节：
| 技能 | 白话解释 | 对应环节 |
|---|---|---|
brainstorming |
像产品经理一样追问你，把模糊需求变清晰 | 需求阶段 |
writing-plans |
把大任务拆成 2-5 分钟的小步骤 | 计划阶段 |
subagent-driven-development |
派多个 AI 并行干活，互相检查 | 开发阶段 |
test-driven-development |
先写测试再写代码，测试不过不写代码 | 开发阶段 |
systematic-debugging |
四步查 Bug：复现→定位→根因→修复 | 调试阶段 |
requesting-code-review |
写完代码自动找人审查 | 审查阶段 |
verification-before-completion |
交活前全部跑一遍，一个都不能少 | 验证阶段 |
finishing-a-development-branch |
提交代码、写 PR、清理环境 | 收尾阶段 |
典型工作流
当你让 AI 开发一个登录功能时，它不会立刻敲代码，而是按这个顺序走：
brainstorming → writing-plans → TDD → code-review
追需求 拆任务 先测后写 互相审查
先当产品经理，再当架构师，最后才当程序员。
三、OpenSpec：给项目建了个"病历本"
它解决什么问题
如果没有 OpenSpec，每次需求变更都像一次失忆：
你："加个登录"
AI：做好了
你：改一下吧
AI：改好了
你：上次改的啥？
AI：忘了
有了 OpenSpec，所有变更都有迹可循：
你："加个登录"
AI：先写个提案
┌────────────┐
│ proposal │ → 为什么要做
│ specs │ → 做成什么样
│ design │ → 怎么实现
│ tasks │ → 分几步干
└────────────┘
三个月后：翻开档案，一清二楚
核心理念：
在写第一行代码之前，先把"要做什么"和"为什么做"用结构化的方式写清楚。
安装方式
npm install -g @fission-ai/openspec@latest
目录结构
openspec/
├── specs/ ← "当前系统的标准是什么"
│ ├── auth/spec.md ← 认证规范（已归档的）
│ ├── order/spec.md ← 订单规范（已归档的）
│
├── changes/ ← "正在改什么"
│ └── add-login/
│ ├── proposal.md ← 为什么要做、做什么
│ ├── design.md ← 技术方案
│ ├── specs/ ← 新的/改的规范草案
│ └── tasks.md ← 具体干活的步骤
│
└── config.yaml ← "项目的基本信息"
理解关键：specs/ 是"已确定的标准"，changes/ 是"正在进行的改动"。改完归档后，changes/ 里的内容会合并进 specs/。
三个核心命令
| 命令 | 白话 | 什么时候用 |
|---|---|---|
/opsx:propose |
"我要改个东西，帮我写清楚改什么、怎么改" | 开始新变更前 |
/opsx:apply |
"提案批准了，按任务清单干活吧" | 开始编码前 |
/opsx:archive |
"活干完了，把变更记录存到档案里" | 开发完成后 |
四、黄金搭档：互补而非冲突
一个盖房子的比喻
很多人会问，OpenSpec 和 Superpowers 到底什么关系？
把它们想象成盖一栋房子的两个角色，就一目了然了：
OpenSpec = 建筑师 - 画蓝图（需求长什么样） - 写材料清单（需要哪些能力） - 记录每次改建的原因（为什么加这堵墙）
Superpowers = 施工队长 - 追问"这墙多厚？这梁多粗？"（brainstorming） - 拆成每天干活的清单（writing-plans） - 派人干活 + 派人检查（subagent + review） - 验收：水电、结构、装修全部过关才交钥匙（verification）
两者缺一不可：
- 只有建筑师 → 图纸画得再好，没人会盖
- 只有施工队长 → 盖得再快，可能盖错方向
| 工具 | 一句话 | 解决的问题 | 核心能力 |
|---|---|---|---|
| OpenSpec | 管"做什么" | 需求模糊、变更不可追溯 | 提案管理、规范沉淀、变更追踪 |
| Superpowers | 管"怎么做" | 执行失控、质量低下 | 头脑风暴、TDD、代码审查、自动化验证 |
完整工作流闭环
📋 OpenSpec 定方向 🛠️ Superpowers 保执行
┌────────────────────┐ ┌────────────────────┐
│ /opsx:propose │ │ brainstorming │
│ → 发起提案 │──────→│ → 追问需求 │
│ specs/ │ │ writing-plans │
│ → 细化需求 │──────→│ → 拆任务 │
│ tasks.md │ │ TDD │
│ → 任务清单 │ │ → 测试先行 │
└────────────────────┘ │ code-review │
│ → 代码审查 │
│ verification │
│ → 全部验证 │
└─────────┬──────────┘
│
📦 OpenSpec 管结果
┌─────────▼──────────┐
│ /opsx:archive │
│ → 归档变更 │
│ → 更新规范 │
│ → 知识沉淀 │
└────────────────────┘
一句话总结：
OpenSpec → "做什么" → 确保需求清晰、变更可追溯 Superpowers → "怎么做" → 保证执行规范、质量可靠 两者加起来 = "想清楚 → 做正确 → 做验证 → 留记录"
五、完整流程：从零开发一个功能
下面用"从零开发一个功能"做例子，看每一步该用什么工具。
阶段总览
①需求澄清 → ②规范定义 → ③任务拆解 → ④实施计划 → ⑤开发执行
OpenSpec + brainstorming writing-plans subagent-driven
→ ⑥测试驱动 → ⑦代码审查 → ⑧验证收敛 → ⑨分支收尾 → ⑩归档沉淀
TDD review verification finishing /opsx:archive
逐阶段详细说明
| # | 阶段 | 主导工具 | 用什么 | 产出物 | 白话解释 |
|---|---|---|---|---|---|
| 1 | 需求澄清 | OpenSpec + Superpowers | /opsx:propose + brainstorming |
proposal.md 草案 |
AI 追问你："你说的登录，是手机号还是邮箱？要验证码吗？" |
| 2 | 规范定义 | OpenSpec | /opsx:propose（继续） |
specs/*.md、design.md |
把需求写成"Given/When/Then"格式，明确验收标准 |
| 3 | 任务拆解 | OpenSpec | /opsx:propose（完成） |
tasks.md |
把大任务拆成小步骤，标注哪个先做哪个后做 |
| 4 | 实施计划 | Superpowers | writing-plans |
详细实施计划 | 把 tasks.md 再拆成 2-5 分钟的小活，标清楚改哪个文件 |
| 5 | 开发执行 | Superpowers | subagent-driven-development |
代码实现 | 派多个 AI 并行干活，一个写一个审 |
| 6 | 测试驱动 | Superpowers | test-driven-development |
测试 + 代码 | 先写测试（必须失败）→ 写代码让测试通过 → 优化代码 |
| 7 | 代码审查 | Superpowers | requesting-code-review |
审查意见 | AI 自己审查自己的代码：安全吗？性能好吗？好维护吗？ |
| 8 | 验证收敛 | Superpowers | verification-before-completion |
验证报告 | 交活前跑一遍：测试、lint、类型检查，全过才行 |
| 9 | 分支收尾 | Superpowers | finishing-a-development-branch |
合并请求 | 提交代码、写 PR 描述、确认 CI 全绿 |
| 10 | 归档沉淀 | OpenSpec | /opsx:archive |
合并后的主 Spec | 把这次改的内容合并到项目的"标准文档"里 |
六、七大典型场景流程
理论说完了，来点实际的。下面是七种常见开发场景，每个场景都回答三个问题：什么时候用 OpenSpec？什么时候用 Superpowers？两者怎么切换？
场景一：简单功能迭代（添加用户登录）
Phase 1：想清楚（OpenSpec 画蓝图）
/opsx:propose "添加用户登录功能"
↓
AI 追问（brainstorming）：
· 支持哪些登录方式？
· 需要 OAuth 吗？
· 密码怎么存？
↓
产出：proposal.md + specs/auth/spec.md + tasks.md
Phase 2：做正确（Superpowers 施工）
writing-plans：拆成 4 步
① 路由 → ② 验证 → ③ 服务 → ④ 测试
TDD：每个任务先写测试，再写实现
code-review：重点查安全
· 密码哈希了吗？
· JWT 签名对吗？
· CSRF 防护有了吗？
verification：全部测试通过才交活
Phase 3：留记录（OpenSpec 归档）
/opsx:archive
↓
把 auth 规范合并到主档案：
openspec/specs/auth/spec.md
↓
以后谁改登录功能，先看这个档案
场景二：复杂跨服务开发（订单 → 支付 → 库存联动）
Phase 1：蓝图先行（OpenSpec 重投入）
/opsx:propose "订单支付与库存联动"
↓
产出多份规范：
· specs/order/ → 订单状态机
· specs/payment/ → 支付流程
· specs/inventory/ → 库存扣减
· design.md → 跨服务数据流图
· tasks.md → 按依赖排序：库存 → 订单 → 支付
Phase 2：多 Agent 并行（Superpowers 重执行）
派 3 个 Agent 并行干活：
Agent-A（库存服务） TDD → review ✓
↑
Agent-B（订单服务） TDD → review ✓
↑
Agent-C（支付服务） TDD → review ✓
最后：集成测试跑一遍全链路
Phase 3：三份归档（OpenSpec 收尾）
/opsx:archive
↓
三份 spec 合并到主档案
场景三：Bug 修复（并发下单超卖）
Phase 1：查 Bug（Superpowers 主导）
systematic-debugging 四步诊断：
① 复现 → 写个并发测试，能重现超卖
② 定位 → 发现库存扣减不是原子操作
③ 根因 → 缺少并发控制
④ 修复 → 加分布式锁 / 乐观锁
TDD 保障：
先写并发测试（RED：超卖了 ❌）
→ 修复代码
→ 测试通过（GREEN：不超卖了 ✅）
Phase 2：补记录（OpenSpec 事后归档）
/opsx:propose "修复并发超卖 Bug"
↓
补充档案：
· specs/inventory/ 增加并发安全场景
· design.md 记录根因和修复方案
↓
/opsx:archive → 更新库存规范
场景四：紧急 Hotfix（线上故障）
Phase 1：快速救火（Superpowers 全速）
systematic-debugging 四步诊断
→ 修复 → 全部测试跑一遍 → hotfix 分支合并 → 发布
Phase 2：事后补录（OpenSpec 归档，别忘了！）
/opsx:propose "Hotfix: XX 故障修复"
补上档案：故障现象、影响范围、根因、修复方案
⚠️ 关键：事后必须补录，否则知识白丢了
场景五：存量代码重构
Step 1：看明白（OpenSpec explore）
/opsx:explore → AI 分析现有代码架构
Step 2：定目标（OpenSpec propose）
/opsx:propose "重构 XX 模块为分层架构"
关键：spec 定义的是"行为不变"
Step 3：安全重构（Superpowers 保障）
TDD → 行为保活测试
每步都是可回滚的原子操作：
① 提取接口 → 测试通过 ✓
② 迁移实现 → 测试通过 ✓
③ 删除旧代码 → 测试通过 ✓
Step 4：更新规范（OpenSpec archive）
旧架构 spec → REMOVED
新架构 spec → ADDED
场景六：技术债清理
Step 1：盘点（OpenSpec explore）
识别技术债：死代码、重复逻辑、风格不统一、缺失测试
Step 2：定计划（OpenSpec propose）
tasks.md 按安全级别排序：
① 删除死代码（最安全）
② 消除重复（需要测试保护）
③ 统一风格（工具自动处理）
Step 3：批量清理（Superpowers）
每类清理任务循环：
writing-plans → TDD → verification → subagent-driven
Step 4：固化规范（OpenSpec archive）
建立 lint 规则，防止技术债再生
场景七：性能优化
Step 1：测基线（OpenSpec + Superpowers）
产出性能基准测试：
· 当前 p50 = 30ms
· 当前 p99 = 200ms（不达标 ❌）
Step 2：定目标（OpenSpec propose）
/opsx:propose "性能优化: p99 < 50ms"
Step 3：逐项优化（Superpowers）
每项优化循环：
TDD：先写性能测试（RED） → 优化 → 通过（GREEN）
code-review：检查副作用
verification：回归测试 + 对比
Step 4：归档基线（OpenSpec archive）
建立性能回归 CI 检查
各场景工具占比对比
| 场景 | OpenSpec 占比 | Superpowers 占比 | 一句话概括 |
|---|---|---|---|
| 绿色项目从零搭建 | 40% | 60% | 蓝图先画好，按图施工 |
| 存量代码重构 | 30% | 70% | 先看明白再改，行为不能变 |
| 紧急 Hotfix | 5% → 事后 100% | 95% | 先救火，回头补档案 |
| API 破坏性变更 | 50% | 50% | 先搭新桥再撤旧桥 |
| 技术债清理 | 25% | 75% | 有测试保护才动刀 |
| 性能优化 | 35% | 65% | 没基线不瞎猜 |
| 技术迁移 | 45% | 55% | 行为契约和技术实现分开看 |
七、Skill 速查表
遇到问题不知道用什么？查这张表：
| 你需要…… | 就用这个 |
|---|---|
| "我不确定到底要做什么" | → brainstorming（追问需求） |
| "我要开始一个新功能" | → /opsx:propose（写提案） |
| "这个功能到底长什么样" | → specs/*.md（看规范） |
| "先干啥后干啥" | → tasks.md（看任务清单） |
| "把大任务拆小点" | → writing-plans（拆步骤） |
| "派多个人一起干" | → subagent-driven-development |
| "先写测试再写代码" | → test-driven-development |
| "出 Bug 了怎么办" | → systematic-debugging（四步诊断） |
| "写完代码谁来检查" | → requesting-code-review |
| "交活前要干什么" | → verification-before-completion |
| "活干完了怎么收尾" | → finishing-a-development-branch |
| "把变更记录存到档案里" | → /opsx:archive |
| "检查规范写得对不对" | → /opsx:verify 或 openspec validate |
| "我只想看代码不想写" | → /opsx:explore（探索模式） |
八、平台支持与生态对比
两个工具都支持主流 AI 编程工具：
| 工具 | Superpowers 怎么装 | OpenSpec 怎么用 |
|---|---|---|
| Claude Code | 插件市场一键安装 | 自动生成 .claude/ 配置 |
| Cursor | 插件市场安装 | 自动生成 .cursor/ 配置 |
| Codex/OpenCode | Fetch 安装 | 原生支持 |
| Gemini CLI | 扩展安装 | 集成支持 |
同类工具对比：
| 工具 | 特点 | 和本文两个工具的关系 |
|---|---|---|
| Spec-Kit | GitHub 官方出品，规范可执行化 | 侧重规范执行化，与 OpenSpec 理念相近 |
| Kiro | 强调编辑器深度集成 | 侧重编辑器集成，与工作流插件定位不同 |
三者与 Superpowers 的关系：都是 AI 编程工作流规范的一部分，各有侧重。
九、写在最后
2026 年的 AI 编程，战场早已从"拼模型参数"转移到了"拼工程化能力"。
用一句大白话总结这两个工具：
OpenSpec = 想清楚（Spec）
· 要做什么？
· 为什么做？
· 做成什么样？
· 改了什么要记下来
Superpowers = 做正确（Do）
· 先追问需求
· 再拆成小任务
· 测试先行
· 写完审查
· 交活前全部验证
两者加起来 = "规划 → 执行 → 验证 → 归档"的完整闭环
AI 写代码不难，难的是让它写出符合软件工程标准的代码。
如果你正在使用 Claude Code 或其他 AI 编程工具，建议同时安装这两个工具——它们会彻底改变你与 AI 的协作方式。
从"AI 能写代码"到"AI 能按流程交付"，中间差的不是更强的模型，而是这一套立规矩 + 守规矩的工程范式。
