三大规范区别：14-Spec-Kit、SDD、OpenSpec

Spec-Kit、SDD 与 OpenSpec 到底有何不同？底层逻辑相通：需求先行，再让 AI 执行

近几个月，AI 辅助编程领域持续升温。Cursor、Claude Code、Cline、Trae、Copilot 等 Agent 工具都能自主解读代码、修改代码并运行测试，听着确实令人振奋。

但实际使用中，尤其是项目复杂度提高、需求变得模糊时，AI 容易暴露出几个典型问题：一上来直接编码，完全跳过设计阶段；修改了 A 文件，却忽略 B 文件的约束条件；当前回答看似合理，下一步却出现“能力退化”；不理解项目的长期规则，仅围绕当前 prompt 回应；代码能运行，但架构、边界、测试和验收标准全是一团浆糊。

因此，现在许多团队开始关注 Spec-Kit、SDD、OpenSpec 这类方案。特别是 Spec-Kit，最近在 GitHub 上热度激增，Star 数持续上涨。这表明越来越多的开发者认识到：AI 编程不能仅靠一句 prompt 硬冲，复杂项目必须回归“规约先行”的工程化路径。

它们名称不同，工具形态各异，但底层试图解决同一个问题：先把需求写清楚，再让 AI 动手实现。

本文重点讲解 Spec-Kit，同时简要说明它与 SDD、OpenSpec 的差异。

结论先行：三者关系可这样理解

一句话概括：SDD 是“理念”，Spec-Kit 是“落地工具”，OpenSpec 是“契约语言”。

简单类比：

所以你会觉得它们“差不多”，这种感觉没错。因为它们都站在同一方向：让 AI 在明确约束下工作，而非胡乱推测。区别仅在于：SDD 偏向理念，Spec-Kit 偏向落地，OpenSpec 偏向开放描述与规范表达。

一、什么是 SDD？它是“先设计后编码”的思想

很多人会误写为 SSD，但在 AI 编程语境中更常见的说法是 SDD：Specification-Driven Development，即规约驱动开发。核心很简单：先把规格写清楚，再写代码。

传统 AI 编程方式通常是：

用户：帮我做一个忘记密码功能。AI：好的，我开始写代码……

听起来高效，但问题在于——忘记密码用手机号还是邮箱？验证码有效期多久？是否限制发送频率？新密码规则是什么？是否让旧登录态失效？前端要不要倒计时？后端要不要防止用户枚举？接口错误信息如何统一？测试用例覆盖哪些场景？这些如果事先不明确，AI 只能猜测。一旦 AI 猜测，项目就容易出问题。

SDD 的做法是将需求整理成类似结构：

1. 用户故事
2. 业务规则
3. 边界条件
4. 非功能需求
5. 接口约定
6. 数据模型
7. 异常场景
8. 验收标准
9. 测试清单
10. 实施任务

也就是说，SDD 不是一个具体工具，而是一种工作方式。它强调：先写规约，再写代码。这与传统软件工程中的需求文档、概要设计、详细设计有些相似，只不过面向的是 AI 协作场景。

二、什么是 Spec-Kit？它是把 SDD 落地的“施工流程”

如果说 SDD 是思想，那么 Spec-Kit 就是把这个思想真正工程化的一套工具和流程。我更愿意将 Spec-Kit 理解为：一套标准的 AI 工程化流程。

以前我们用 AI 编程，很像 Vibe Coding：

我有个想法 → 写个 prompt → AI 开始生成 → 看结果再改

这种方式适合小脚本、小页面、小 Demo。但一旦进入真实项目，比如登录注册、忘记密码、支付订单、权限系统、多服务协作、老项目重构、涉及数据库迁移、涉及前后端联调……直接让 AI 写代码很容易翻车。

Spec-Kit 的价值在于，它不让 AI 立即开工，而是先让 AI 进入一套固定流程。典型流程大致如下：

/specify → 生成需求规约
/clarify → 澄清模糊点
/plan    → 生成技术方案
/tasks   → 拆解实施任务
/implement → 按任务执行
/analyze → 检查规约、计划、任务是否一致

这就像现实工程中的流程：需求确认 → 技术方案 → 任务拆解 → 编码实现 → 验收检查。AI 不再是一个“想到哪写到哪”的实习生，而是更像一个受流程约束的工程执行者。

三、Spec-Kit 解决的核心问题：AI 的上下文失控

AI 编程最大的问题不是不会写代码，而是容易忘记上下文。尤其在复杂项目中，AI 可能当前文件看得很清楚，但全局关系完全断掉。

比如你让它做一个“忘记密码”功能，它可能会：前端新增了页面，但没接入路由；后端写了接口，但没加 DTO 校验；密码重置成功了，但没有让旧 token 失效；返回了“手机号不存在”，造成账号枚举风险；改了 auth-service，却忘记 web 侧 API 类型；写了代码，但没有补测试和验收标准。

这些问题本质上都是：AI 在执行时，看不到完整的上下文。Spec-Kit 的作用就是把这个上下文沉淀下来。它会把一个功能拆成多份文档，例如：

spec.md         需求规格
plan.md         技术方案
tasks.md        实施任务
research.md     调研结论
contracts/      接口契约
quickstart.md   验收说明

这些文件不是写给人看的形式主义文档，而是写给 AI 的“施工图纸”。只要图纸清晰，AI 每次执行任务时就能回到同一套约束里，而不是每次重新猜测。

四、OpenSpec 又是什么？它更偏“开放规约表达”

OpenSpec 这个词在不同团队可能有不同用法。有些人说 OpenSpec，指的是一种开放的 specification 描述方式；有些人会将其理解为类似 OpenAPI 那样的契约文档；也有人把它当作一套面向 AI Agent 的开放规约格式。

但无论具体实现是哪一种，它通常强调的是：规约应该是开放的、标准化的、机器可读的。所以 OpenSpec 更关注“规约怎么表达”。比如它可能更在意：接口契约是否清楚；输入输出是否标准化；schema 是否可被工具解析；能不能跨工具、跨团队复用；能不能作为 AI、测试、文档、代码生成的共同输入。

从这个角度看，OpenSpec 和 Spec-Kit 是互补关系。OpenSpec 偏“格式和表达”，Spec-Kit 偏“流程和执行”。

五、Spec-Kit 和 OpenSpec 的区别

它们最大的区别不在理念，而在关注点。

1. Spec-Kit 更关注流程闭环

Spec-Kit 关心的是：一个需求如何从想法变成可执行任务？AI 在每一步应该产出什么？什么时候可以编码？什么时候需要澄清？什么时候需要分析一致性？它强调的是完整生命周期，从需求到实现，中间每一步都要留下规约痕迹。

2. OpenSpec 更关注规约本身的开放性

OpenSpec 关心的是：规约如何被不同工具理解？接口、行为、约束如何标准化描述？这些描述能不能被测试工具、文档工具、AI 工具共同消费？它更像一个开放契约层。

3. Spec-Kit 更适合 AI 编码流程控制

如果你的核心问题是：AI 老是乱改；需求总是说不清；复杂功能容易做到一半偏航；多文件、多服务修改不好控制；希望 AI 先规划、再编码——那 Spec-Kit 更直接。

4. OpenSpec 更适合统一接口和能力描述

如果你的核心问题是：多系统之间契约不一致；接口文档和实现脱节；希望规约可以被多个工具消费；希望规范更开放、更标准化——那 OpenSpec 的价值更明显。

六、为什么主要推荐讲 Spec-Kit？

因为对大多数正在使用 AI 编程的开发者来说，真正的痛点不是“不知道怎么写规约”，而是“怎么让 AI 执行规约时不出错”。Spec-Kit 的好处是，它把“先设计后编码”变成了强制流程。你不是靠自觉，而是靠工具约束。这点很重要。

因为 AI 编程最大的诱惑就是“快”。你输入一句话，它马上给你 300 行代码，这种反馈太爽了。但爽完以后，常见结局是：第一版看着能用；第二轮需求开始打补丁；第三轮改动破坏原逻辑；第四轮 AI 已经忘了之前为什么这么设计；最后代码变成一坨更难维护的新屎山。

Spec-Kit 的价值就在这个地方。它会强制你慢下来：别急，先写 spec。别急，这里还有模糊点。别急，先出 plan。别急，先拆 tasks。别急，先检查一致性。短期看，它比直接写代码慢。长期看，它是在帮你省返工成本。

七、用一个例子理解：忘记密码功能

可以拿实际项目里的“忘记密码”功能举例。一开始的原始需求其实很简单：

我想实现忘记密码功能。前端页面已经有了，位置在 apps/web/src/pages/ForgotPassword。认证微服务在 services/auth-service。业务微服务在 services/backend。

如果直接把这段话丢给 AI，它大概率会马上开始改前端页面、写接口、补几个表单校验。但真正进入项目以后，会发现这里面其实有很多隐含规则：

• 前端不能直接调用 auth-service，只能调用 backend；
• backend 只是中间层，真正的密码重置能力仍然归 auth-service；
• 当前阶段验证码能力还没接入，所以重置密码暂时不校验验证码；
• 但获取验证码按钮仍然要有模拟成功或友好提示，不能阻断主流程；
• 手机号必须是 11 位数字；
• 新密码和确认密码必须一致；
• 新密码不能和旧密码相同；
• 密码重置后，旧密码必须登录失败，新密码必须登录成功；
• 重置成功后，需要清理用户已有的 Refresh Token，让旧登录态失效；
• 错误提示不能直接暴露“手机号是否已注册”，避免账号枚举；
• 日志里不能记录明文密码、完整验证码、Token 等敏感信息。

这些内容如果不提前写清楚，AI 就会自己猜。而 Spec-Kit 的价值，就是把这些“隐藏在脑子里的规则”拆成不同的规约产物。

比如在 spec.md 里，它会把需求拆成用户故事：

US1：用户可以通过手机号重置密码。
US2：验证码未接入阶段，也能先完成可用恢复流程。
US3：忘记密码流程不能暴露账号存在性和敏感信息。

在 contracts/forgot-password-api.md 里，它会继续把接口契约写清楚：

POST /auth/forgot-password/send-code
POST /auth/forgot-password/reset
前端只调用 backend。
backend 再调用 auth-service。
当前阶段 code 字段可以接收，但不作为重置成功的必要条件。
响应里不能返回密码、Token、完整验证码或内部错误细节。

在 tasks.md 里，它会把实现拆成可执行任务：

先确认 auth-service、backend、前端 API 的现有结构。
再创建 DTO、响应类型和错误码。
然后实现 auth-service 的 resetForgotPassword。
再实现 backend 的袋里入口。
最后把前端 ForgotPassword store 从 localStorage mock 改成真实调用 backend API。

在 quickstart.md 里，它还会把验收方式写出来：

使用已注册手机号重置密码。
确认新密码登录成功，旧密码登录失败。
确认验证码未接入时不阻断主流程。
确认未注册手机号不会直接暴露账号是否存在。
分别在 auth-service、backend、apps/web 执行 lint、build、typecheck。

这就是 Spec-Kit 和普通 prompt 最大的区别。普通 prompt 是：帮我做忘记密码。Spec-Kit 是：先明确业务规则，再明确服务边界，再明确接口契约，再明确任务顺序，最后明确验收标准。这样 AI 再去实现时，它就不是在“自由发挥”，而是在按施工图施工。

八、什么时候不需要 Spec-Kit？

Spec-Kit 不是银弹。如果你只是写一个临时脚本、一个简单组件、一个 Demo 页面、一个一次性数据处理工具、一个很小的 bugfix——那没必要上这么重的流程。直接用 AI 写就行。否则你会感觉：工具反而比干活还累。

但如果你面对的是复杂业务功能、多模块联动、前后端一起改、涉及认证、安全、支付、权限、老项目重构、团队协作、长期维护项目——那 Spec-Kit 就非常值得用。因为这类任务最怕的不是写得慢，而是写错方向。

九、核心理解：Spec-Kit 是 AI 时代的“需求防火墙”

以前我们写代码，最重要的是代码规范。现在用 AI 写代码，最重要的可能是规约规范。因为 AI 的输出质量，很大程度取决于输入质量。你给它一句模糊需求，它就只能输出一个模糊实现。你给它一套结构化规约，它才可能输出一个可维护、可测试、可验收的工程结果。

所以 Spec-Kit 的意义不是“让 AI 更聪明”。它真正的意义是：让 AI 先理解工程约束，再动手干活。这也是我觉得 Spec-Kit 最值得讲的地方。它不是又一个炫酷的 AI 编码插件，而是把 AI 编程重新拉回软件工程基本面：需求清楚、边界清楚、设计清楚、任务清楚、验收清楚。只要这五件事清楚，AI 才能真正成为生产力。否则，它只是一个打字很快的风险放大器。

最后总结

Spec-Kit、SDD、OpenSpec 的区别可以这样记：

• SDD：规约驱动开发的方法论，强调先写 specification，再写代码；
• Spec-Kit：把 SDD 落地成 AI 编程流程的工具链，强调从需求到任务再到实现的闭环；
• OpenSpec：更偏开放规约表达，强调规约可以标准化、结构化、跨工具复用。

它们本质上确实差不多，都是为了解决 AI 编程里的同一个核心问题：只给 prompt 不够，必须给 AI 写清楚“规约”。

如果你主要想讲 Spec-Kit，可以把核心观点放在这句话上：在 AI 编程越来越普及的今天，真正拉开差距的可能不再是谁更会写代码，而是谁更会给 AI 写“施工图”。

来源：互联网