从聊天驱动到规格驱动：SDD 与 OpenSpec / Spec Kit

April . 17 . 2026

SDD 与 OpenSpec / Spec Kit

对比对象：

说明：

  • 本文基于两个项目截至 2026-04-17 可见的官方 README、仓库结构与公开说明整理。
  • 其中“优缺点”和“适用建议”部分，包含基于公开材料做出的工程判断。

1. 什么是 SDD

SDD，通常指 Spec-Driven Development，也就是“规格驱动开发”。

它的核心思想不是先写代码、再补文档，而是先把“要做什么、为什么做、做到什么程度算完成”描述清楚，再让实现围绕这些规格展开。

和传统开发相比，SDD 有几个明显差异：

  • 规格不是附属品，而是开发主线
    • 需求、场景、约束、验收标准，不再只是开会纪要或聊天记录，而是实际驱动实现的核心材料。
  • 先对齐再实现
    • 在编码前，团队和 AI 助手先对“目标”和“边界”达成一致，减少后期返工。
  • 规格可以直接驱动 AI
    • 在 AI coding assistant 场景下，spec 不再只是给人看的文档，也是在约束 AI 输出。
  • 开发过程可追踪
    • 从 proposal、requirements、design 到 task breakdown，链路更完整，决策更容易回溯。

2. 为什么 SDD 在 AI 编码时代更重要

没有 SDD 时，很多 AI 开发流程实际上是“聊天驱动开发”：

  • 需求散落在上下文里
  • 实现边界不清晰
  • AI 容易补全错误假设
  • 多轮对话后，最初目标逐渐漂移

这会带来几个典型问题：

  • 需求漂移
    • 同一个功能在不同轮次里被 AI 理解成不同东西。
  • 实现不可控
    • AI 可能一次性做太多，也可能漏掉关键约束。
  • 难以协作
    • 如果多人或多 Agent 参与，聊天记录很难成为稳定的协作契约。
  • 难以复盘
    • 需求为什么这么写、为什么这么设计、任务为什么这样拆，后面很难追踪。

所以，SDD 在 AI 时代的价值，本质上是给 AI 开发加一层 结构化约束：

  • 让目标更清晰
  • 让实现更可预测
  • 让多人协作更稳定
  • 让项目积累下来的不是聊天记录，而是可复用的工程资产

3. 一个典型的 SDD 流程

虽然不同工具实现不同，但一个典型的 SDD 流程通常类似这样：

  1. 提出变更
    • 明确想解决什么问题、给谁用、预期效果是什么。
  2. 编写或生成规格
    • 把需求、场景、边界条件、验收标准结构化下来。
  3. 形成设计方案
    • 明确技术实现方向、数据结构、接口、约束。
  4. 拆解任务
    • 把工作拆成可以执行和验证的实现步骤。
  5. 实施与验证
    • AI 或开发者按规格和任务推进实现。
  6. 归档与沉淀
    • 将这次变更的 spec、设计和任务保留下来，形成团队资产。

OpenSpec 和 Spec Kit 都是在做这件事，只是两者做法不一样：

  • OpenSpec 更强调“轻量、流畅、快速进入实现”
  • Spec Kit 更强调“完整、规范、可治理、可扩展”

4. 两个项目分别在解决什么问题

OpenSpec

OpenSpec 想解决的问题是：

如何在不引入太重流程的前提下，让 AI coding assistant 的开发过程有 spec 约束，而不是完全靠聊天上下文驱动。

它的理念很鲜明：

  • fluid not rigid
  • iterative not waterfall
  • easy not complex
  • built for brownfield not just greenfield

它更像是给日常 AI 开发加一套“轻量护栏”。

Spec Kit

Spec Kit 想解决的问题是：

如何把 Spec-Driven Development 做成一套可落地、可扩展、可治理的方法与工具体系。

它不只是一个命令行工具，而是一整套：

  • CLI
  • templates
  • integrations
  • presets
  • extensions
  • workflows

它更像是“把 SDD 工程化”的工具箱。

5. 核心定位差异

| 维度 | OpenSpec | Spec Kit | |---|---|---| | 核心思路 | 给 AI 开发加轻量 spec 护栏 | 把 SDD 做成完整工程流程 | | 风格 | 轻量、迭代、少仪式感 | 完整、规范、强治理 | | 适合对象 | 个人开发者、小团队、已有项目 | 中大型项目、多人协作、需要制度化落地的团队 | | 工作方式 | 快速提出变更并推进实现 | 先治理原则，再规格，再计划，再任务，再实施 | | 工具生态 | Node / npm | Python / uv |

6. OpenSpec 的优缺点

优点

  • 上手成本低
    • Node 环境下安装直接，进入项目后 openspec init 即可开始。
  • 主流程短
    • /opsx:propose -> /opsx:apply -> /opsx:archive，很适合快速迭代。
  • 更适合 brownfield
    • 官方明确强调它适合已有项目，不只是新项目。
  • 更符合 AI 协作直觉
    • 先提出一个变更，再生成 proposal/spec/design/tasks，然后直接实施，交互阻力较小。
  • 仪式感较低
    • 对不想引入太重文档流程的团队更友好。
  • 支持多种 AI 工具接入
    • README 中强调支持 20+ AI assistants / 25+ tools。

缺点

  • 方法论深度不如 Spec Kit 完整
    • 在治理原则、模板体系、流程扩展等方面，公开材料里 Spec Kit 更系统。
  • 容易依赖团队自觉
    • 因为强调灵活，团队如果没有纪律，spec 可能又退化成“半结构化描述”。
  • 不那么偏向重治理场景
    • 对于需要严格留痕、清晰阶段边界、强模板约束的组织，默认流程偏轻。
  • 复杂项目的 artifact 粒度相对没那么重
    • 当你需要 research、data model、contracts 等细分输出时，OpenSpec 默认表达没有 Spec Kit 那么体系化。

7. Spec Kit 的优缺点

优点

  • SDD 方法论更完整
    • 从 constitution 到 specify、plan、tasks，链路清晰。
  • 治理能力更强
    • 把工程原则前置，适合多人协作和高质量要求场景。
  • 扩展能力强
    • 仓库里有 extensions、presets、integrations、templates 等结构。
  • AI agent 集成覆盖广
    • README 写明支持 30+ AI coding agents。
  • 更适合团队沉淀标准流程
    • 不只是解决“怎么让 AI 帮我写代码”，更在解决“团队怎么稳定地用 spec 驱动开发”。
  • 文档层次更完整
    • 公开材料中对流程、阶段、扩展和社区资源的说明更丰富。

缺点

  • 上手更重
    • 依赖 Python 3.11+、uv、Git，相比 OpenSpec 接入成本更高。
  • 流程更长
    • constitution -> specify -> plan -> tasks -> implement，本身就更正式。
  • 文档和 artifact 更多
    • 这提高了治理能力，但也提高了维护成本。
  • 对小项目可能偏重
    • 如果只是个人开发或快速试错，Spec Kit 可能会显得过度设计。
  • 团队执行门槛更高
    • 规范越完整，越需要团队真正愿意维护这些规范。

8. 使用流程

8.1 OpenSpec 使用流程

安装

npm install -g @fission-ai/openspec@latest

要求：

  • Node.js 20.19.0+

初始化

cd your-project
openspec init

提出变更并生成 spec

/opsx:propose

通常会生成：

  • proposal.md
  • specs/
  • design.md
  • tasks.md

按任务实施

/opsx:apply

完成后归档

/opsx:archive

可选扩展命令

如果要更完整流程，还可以使用：

  • /opsx:new
  • /opsx:continue
  • /opsx:ff
  • /opsx:verify
  • /opsx:sync
  • /opsx:bulk-archive
  • /opsx:onboard

适用场景

  • 已有项目增量迭代
  • 个人开发者配合 AI 助手
  • 小团队快速推进功能
  • 希望引入 spec，但不想流程太重

8.2 Spec Kit 使用流程

安装

推荐安装：

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z

一次性使用：

uvx --from git+https://github.com/github/spec-kit.git@vX.Y.Z specify init . --ai copilot

要求：

  • Python 3.11+
  • uv
  • Git
  • 支持的 AI coding agent

初始化

specify init .

或：

specify init --here --ai codex --ai-skills

建立治理原则

/speckit.constitution

这一阶段主要定义项目的工程原则，例如：

  • 质量要求
  • 测试要求
  • UX 一致性要求
  • 性能要求
  • 技术约束

生成功能规格

/speckit.specify

重点是把“做什么”和“为什么做”说清楚。

生成技术计划

/speckit.plan

这一阶段常见输出包括：

  • plan.md
  • research.md
  • data-model.md
  • contracts/
  • quickstart.md

生成任务拆解

/speckit.tasks

通常输出 tasks.md，包含：

  • 按用户故事组织的任务
  • 依赖关系
  • 并行标记
  • 实现提示

进入实施与验证

后续由开发者或 AI 按 spec、plan、tasks 推进开发。

适用场景

  • 从 0 到 1 的项目
  • 多人协作项目
  • 需要明确工程原则和决策边界的团队
  • 想把 SDD 作为正式开发制度落地的团队

9. 如何选

选 OpenSpec，如果你更看重

  • 快速落地
  • 少流程阻力
  • 在已有项目中自然接入
  • 把 spec 当成 AI 协作护栏，而不是正式治理体系

选 Spec Kit，如果你更看重

  • 团队统一规范
  • 从需求到实现的完整留痕
  • 强治理、强模板化、强扩展能力
  • 把 SDD 作为正式工程方法推广

一个务实判断

如果你们团队还没有稳定采用 SDD，通常 OpenSpec 更容易先落地。
如果你们已经接受“先规范、后计划、再实施”的节奏，并愿意维护更多 artifact，通常 Spec Kit 的长期收益更大。

10. 总结

从 SDD 的角度看，这两个项目不是简单的“谁更强”，而是代表了两种不同落地方向：

  • OpenSpec：把 SDD 做轻，优先解决“怎么尽快在 AI 编码里用起来”
  • Spec Kit：把 SDD 做全，优先解决“怎么把 spec 驱动开发变成稳定工程体系”

如果你是个人开发者或小团队，且项目已经存在，OpenSpec 往往更顺手。
如果你是多人协作团队，想把 SDD 正式纳入研发流程，Spec Kit 通常更合适。

11. 参考来源