2026 年 AI 编程工程化指南：用 Spec 让 Agent 不再"飘"
2026 年 AI 编程工程化指南：用 Spec 让 Agent 不再”飘”
🔥 一、先说扎心结论：vibe coding 救不了你
去年我刚拿到 Claude Code 的时候，真香。
一句”帮我做个任务管理 App”扔进去，几分钟就能跑起来。但当我把这套玩法搬进公司项目，立刻翻车：
😩 同一个需求，今天问和明天问，AI 给出的实现完全不一样；
😩 改一个小 bug，AI 顺手把三个无关模块”优化”了；
😩 代码 review 时根本说不清”它当时为什么这么写”，聊天记录早就被吞没。
vibe coding 的崩溃链： 随意 prompt → AI 自由发挥 → 架构漂移 → 上下文丢失 → 反复返工 → 债台高筑
直到我接触到 SDD（Spec-Driven Development，规范驱动开发），才意识到一个朴素的道理：
AI 不是不能写代码，它是不知道你到底想要什么。 把意图写成文件，AI 就老实了。
🧭 二、SDD 是什么？一张图秒懂
核心就一条流水线：
意图 → Spec → Plan → Tasks → 代码
每一步都落盘成 Markdown，可 review、可版本控制、可回滚。
GitHub 官方在 Spec Kit 介绍里把它说得很狠：
“Specification 才是源头，代码只是 spec 的一种编译产物。”
下面把目前最火的四个 SDD 框架——Superpowers / Spec Kit / OpenSpec / Kiro——一次讲完。
⚡ 三、Superpowers：最像”资深同事”的那个
👉 一句话定位：Claude Code 的”灵魂插件”
Jesse Vincent（@obra）做的开源插件，MIT 协议，GitHub 217K star。本质是一堆 Skills + SessionStart Hook，你一打开 Claude Code，工作流就自动启动。
它最猛的两件事：
① 强制 TDD（RED-GREEN-REFACTOR） 必须先写失败测试再写实现。敢先写代码？框架直接删掉。
② Subagent 驱动 每个 task 派一个全新子 agent 去做，做完再派一个冷读 diff 的 reviewer 子 agent。主 agent 永不被污染，所以它能连续干几个小时不”飘”。
安装：
/plugin install superpowers@claude-plugins-official
✅ 优点：零配置、单人最优解、长任务不跑偏
❌ 缺点：小需求会被它整出一套企业级流程
🎯 场景：个人开发、单仓库 feature、无人值守跑几小时
🛠 四、GitHub Spec Kit：把 Spec 钉死在 Git 里的官方答案
👉 一句话定位：SDD 界的”工程化标杆”
GitHub 官方出品的 CLI，不绑任何 AI，Claude / Copilot / Gemini / Cursor / Windsurf 通吃。
七个核心命令构成一条流水线：
| 命令 | 阶段 | 作用 |
|---|---|---|
/speckit.constitution |
Setup | 写项目宪法 |
/speckit.specify |
规约 | 自然语言 → 结构化 spec |
/speckit.clarify |
澄清 | 交互式逼出歧义 |
/speckit.plan |
计划 | 加入技术栈与架构 |
/speckit.tasks |
拆任务 | 拆成原子工作单元 |
/speckit.analyze |
复核 | 检查计划是否符合 spec |
/speckit.implement |
实现 | 按顺序逐个执行 |
安装：
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
specify init my-app --ai claude
✅ 优点：跨团队协作神器、Agent 无关、可追溯审计
❌ 缺点：偏 Greenfield（新项目）；token 消耗高 20%–40%
🎯 场景：生产级新项目、需要长期维护、跨角色协作
🌱 五、OpenSpec：专治”老项目改造”的轻量派
👉 一句话定位：Brownfield 战场的最佳武器
Spec Kit 是给新项目的，OpenSpec 是给老代码的。它把”系统现状”和”提议变更”在文件系统里物理隔离：
openspec/specs/—— 当前真相openspec/changes/—— 每次变更一个独立文件夹（proposal / design / tasks / delta）
完成后归档，自然形成一份可审计的变更历史，金融、医疗场景狂喜。
核心 3 命令：
/opsx:propose # 生成 proposal / design / specs / tasks
/opsx:apply # AI 按 tasks 逐步实现
/opsx:archive # 合并 delta，归档变更
✅ 优点：极轻量、纯 CLI + Markdown、本地隐私、流程自由
❌ 缺点：写 spec 时”扶持”少、生态比 Spec Kit 新
🎯 场景：老代码迭代、合规审计、追求”轻量但严肃”
🚀 六、Kiro：AWS 出品的”全套 IDE 级”SDD 体验
👉 一句话定位：把 SDD 装进 IDE 的”操作系统”
Kiro 是 AWS 2025 年下半年正式推出的 Agentic IDE，基于 Code OSS 魔改，底层默认接 Claude Sonnet 4.0 / 3.7（最新版已内置Opus 4.8）。和前面三个最大的不同——SDD 不是插件，是 IDE 本身。一打开就让你二选一：Spec 还是 Vibe？
Kiro 把 SDD 拆成三块组件，缺一不可：
1️⃣ Specs：三阶段强制流水线（落在 .kiro/specs/<feature>/）
| 阶段 | 产物 | 关键点 |
|---|---|---|
| Requirements | requirements.md |
强制 EARS 记法：WHEN [触发] THE SYSTEM SHALL [行为]，把”系统要快”挡在门外 |
| Design | design.md |
自动扫码扫出组件层级、数据流、DB schema、API 契约 |
| Tasks | tasks.md |
按依赖拆分，反链回 requirement，带 [ ] / [x] 进度跟踪 |
每个阶段都强制 Approve 才能往下走，这是 Kiro 与 vibe coding 最本质的差别。
2️⃣ Hooks：事件驱动的自动化
绑在文件保存/创建/删除上的自动 agent 动作。比如保存源文件时自动更新对应测试、提交前自动跑安全扫描。AI 版的 Git hook。
3️⃣ Steering Files：项目级长期记忆
.kiro/steering/ 下的一堆 Markdown：product.md / tech.md / structure.md，外加你自己写的 architecture.md / tdd.md / code-style.md。Kiro 每次工作自动读，不用你每次都重复”我们用 hexagonal 架构、不准用 any”。
下面这张图一次看清「三根支柱」如何咬合：
使用步骤：
1. 装 Kiro（去 kiro.dev 下载）
2. 点 "Generate steering files" 让它扫码扫出三件套
3. 顶部切到 Spec 模式 → 输入需求
4. 依次产出 requirements → design → tasks（每步可改可拒）
5. 进入实现：Supervised 模式（一步一审）或 Autopilot 模式（无人值守）
✅ 优点：体验最完整、EARS 强制可测、Hook 让质量门禁可编排、IDE 原生体验
❌ 缺点：要换 IDE（最新版已支持web和cli）；按 credit 收费；模型选择目前以 Claude 系为主
🎯 场景：企业团队、有架构师把关的生产项目、对审计可追溯性要求高的系统
📊 七、四款 SDD 框架对比：一张表搞定
| 维度 | Superpowers | Spec Kit | OpenSpec | Kiro |
|---|---|---|---|---|
| 形态 | skills 插件 | 独立 CLI | 轻量 CLI | 完整 IDE、web、cli |
| 开发方 | @obra | GitHub 官方 | 社区 | AWS 官方 |
| 最佳场景 | 单人长任务 | 跨团队新项目 | 老代码迭代 | 企业级生产 |
| 学习成本 | 低 | 中 | 低 | 中高 |
| 强制力 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| 适合阶段 | 实现期 | 0→1 | 1→n | 0→1 + 1→n |
| 多 AI 支持 | ~6 一线平台 | 30+ 🏆 | 25+（新增 Kimi） | 内置（Opus 4.8） |
| 是否开源 | ✅ MIT | ✅ MIT | ✅ MIT | ❌ 闭源 |
| 成本 | 免费 | 免费 | 免费 | 按 credit 收费 |
| 原生 Hook | 子 agent 链 | ❌ | ❌ | ✅ 事件 Hook |
我现在的真实打法：
- 个人 side project → Superpowers
- 创业团队 0→1 → Spec Kit + Superpowers
- 大公司老系统改造 → OpenSpec
- 企业级新项目（有架构师） → Kiro
四者并不互斥。Kiro 的 spec 文件结构和 Spec Kit 高度相似，完全可以混搭使用。👌
🎯 八、SDD 真正解决的是什么痛点？
近期SDD实战，浓缩成三句话：
1️⃣ 解决了”AI 意图漂移” —— Spec 落盘，不会被聊天窗口冲掉；
2️⃣ 解决了”AI 代码无法 review” —— 你 review 的是 spec 和 plan，不是几千行 diff；
3️⃣ 解决了”AI 写不了生产代码”的偏见 —— 配 TDD + 子 agent + EARS + Hook，AI 真的能交付能上线的代码。
四款工具的本质区别，其实就是对”开发者自由 vs 工程纪律”的权衡：
Superpowers 把纪律装进插件，
Spec Kit 装进 CLI，
OpenSpec 装进文件结构，
Kiro 干脆装进了整个 IDE。
如果让我给你一些实用建议：
先用 vibe coding 验证想法，再切 SDD 上生产。
前者要的是速度，后者要的是不翻车。
别把 AI 当工具，把它当一个非常聪明但记性差的实习生。
而 Spec 就是你给它写的工牌、JD 和 KPI。
写清楚了，它真能高效率高质量的干活。
📎 参考链接
- GitHub Spec Kit 官方仓库 —— github.com/github/spec-kit
- AWS Kiro 官方文档 —— aws.amazon.com/documentation-overview/kiro/
- OpenSpec 深度解析 —— redreamality.com/garden/notes/openspec-guide/
- Spec-Driven Development with Kiro: AI Code Ownership —— doit.com/blog/spec-driven-development-with-kiro-ai-code-ownership
- Superpowers Review: The 124K-Star Skills Framework —— andrew.ooo/posts/superpowers-agentic-skills-framework-claude-code/
觉得有用？
🌟 点个”在看”+ 转发给你那个还在 vibe coding 的同事
💬 评论区聊聊：你目前在用四件套里的哪一款？踩了什么坑？
