💡 一句话总结：规格驱动开发（SDD）是 2026 年让 AI 写出可维护代码的主流方法——先写「需求 → 设计 → 任务」规格，让它成为人和 AI 共同的事实来源，再照着实现。本文横评 Kiro、Spec Kit、Tessl、OpenSpec 四款工具，分属「一次性脚手架」和「长期活文档」两条路线。
一、Vibe Coding 的账，迟早要还
「Vibe coding」是 2025 年最出圈的词之一——你完全跟着感觉走，对 AI 说「给我做个 X」，它哗哗生成一堆代码，能跑就行，你甚至不看代码长啥样。
demo 阶段，这爽得不行。但凡把 vibe coding 的产物推到生产、维护几个月，所有人都会撞上同一堵墙：
- 没人说得清代码为什么这么写——当初是「凭感觉」生成的，意图没留下来。
- 改一处崩三处——没有结构化的设计，agent 每次都在猜你想要什么。
- AI 自己也迷路——上下文里全是它过去随手写的代码，越改越乱。
2026 年的行业共识是：vibe coding 的「快」，是把成本推迟到了维护阶段。 解药是规格驱动开发（Spec-Driven Development，SDD）。
SDD 的核心很简单：在写代码之前，先把意图写成结构化的规格。典型是三层——
requirements.md → 说清「要做什么、为什么」
design.md → 说清「怎么设计、数据模型、接口」
tasks.md → 拆成「一步步可执行的任务」规格成为人和 AI 共同的事实来源，agent 照着规格施工，而不是照着模糊的口头指令猜。下面横评四款代表性工具。
二、AWS Kiro：开箱即用的双模式 IDE
Kiro 是 AWS 推出的 SDD 产品，IDE 形态（还有 kiro-cli），集成度最高、最省心。
它的招牌是两种模式：
- Spec Mode：完整的结构化流程——写需求 → 自动生成设计 → 拆出任务列表 → 逐个实现。每一步你都能审阅和修改，规格全程可见。
- Vibe Mode：保留自由对话的快速通道，适合探索性的小改动。
这个双模式设计很务实——承认 vibe coding 在某些场景（快速试错）确实有用，但把它和严肃开发分开。
优点：开箱即用、体验顺滑、AWS 生态集成。 代价：绑定 Kiro 的环境、需要付费。
适合：愿意为体验付费、已经在 AWS 生态、想要最低上手门槛的团队。
三、GitHub Spec Kit：开源、工具无关的平替
Spec Kit 是 GitHub 开源的命令行工具，可以理解为 Kiro 核心理念的开源版。
它最大的特点是工具无关（tool-agnostic）——不绑定任何特定的 AI 编码 agent，你可以把它配到你已有的 agent 上。它通过一套命令把 SDD 流程固化下来：初始化规格结构、从需求生成计划、把计划拆成任务、驱动实现。
优点：开源免费、不锁定、可定制、和现有工具链组合自由。 代价：要自己搭工作流、没有 IDE 级别的集成体验。
适合：偏好开源、不想被单一厂商锁定、愿意自己折腾工作流的团队和个人。Reddit 上「Kiro is cooked, GitHub’s Spec Kit」的调侃，说的就是它对 Kiro 的开源替代意味。
四、Tessl：把规格当可复用资产
Tessl 走得最远——它不把规格当成「生成代码后就扔的脚手架」，而当成一等公民和可复用资产。
两个标志性设计：
- Spec Registry：类似 npm 之于包，你可以发布、共享、复用规格。规格成了可流通的工程资产。
- Living Spec（活文档）：规格和代码长期双向同步——代码改了规格更新，规格改了驱动代码变更。规格是持续维护的事实来源，不是一次性产物。
优点：规格资产化、长期可维护、理念最彻底。 代价：心智模型最重，要求团队真正把「规格优先」当工作方式，不是轻量上手的工具。
适合：认同「规格是长期资产」、做长生命周期产品、愿意为可维护性投入的团队。
五、OpenSpec：轻量开源的改动驱动
OpenSpec 代表另一类——轻量、开源、改动驱动。它不追求大而全的平台，而是聚焦「把一次具体改动说清楚」，规格围绕变更组织，适合渐进式引入。
优点：轻、开源、上手快、适合给现有项目逐步加规格。 代价：功能边界比平台型工具窄，不提供 Registry、IDE 等重型能力。
适合：想低成本试水 SDD、不想一上来就上重型平台的个人和小团队。
六、横向对比
| 维度 | AWS Kiro | GitHub Spec Kit | Tessl | OpenSpec |
|---|---|---|---|---|
| 形态 | IDE + CLI | CLI | 框架 + Registry | 轻量 CLI |
| 开源 | 否 | 是 | 部分 | 是 |
| 规格定位 | 结构化流程 | 结构化脚手架 | 长期活文档/资产 | 改动驱动 |
| 工具绑定 | 绑定 Kiro | 工具无关 | 框架内 | 工具无关 |
| 上手门槛 | 低 | 中 | 高 | 低 |
| 适合规模 | 中大团队 | 各规模 | 长周期产品 | 个人/小团队 |
需要说清的是，这两条路线没有绝对优劣：
- 一次性脚手架路线（Spec Kit、OpenSpec 的常见用法）：规格用来生成代码，之后主要维护代码。轻、灵活，但规格可能慢慢和代码脱节。
- 长期活文档路线（Tessl、Kiro 的 Spec Mode）：规格和代码长期同步，规格是持续的事实来源。可维护性强，但要求团队纪律。
七、选型建议
- 个人开发者 / 玩具项目：多数情况 vibe coding 就够，真要上 SDD 选 OpenSpec 或 Spec Kit，轻量起步。
- 中小团队、已有工具链：选 GitHub Spec Kit，开源、不锁定、和现有 agent 组合自由。
- 要最低上手成本、不在乎付费：选 AWS Kiro，开箱即用、双模式务实。
- 长生命周期产品、把规格当资产：选 Tessl，理念最彻底，但要团队真心认同规格优先。
八、结语
SDD 的本质不是「多写一份文档」，而是把意图从一次性对话里抢救出来，固化成人和 AI 都能复用的事实来源。
Vibe coding 不会消失——快速试错、探索性原型，它仍然好用。但凡是要维护、要协作、要活过几个月的代码，规格驱动都会慢慢回本。选哪款工具是次要的，先建立「写代码前先说清意图」的习惯才是关键。工具只是把这个习惯固化下来的脚手架。