chat

AI 规范驱动开发“三剑客”深度对比：Spec-Kit、Kiro 与 OpenSpec

下面给你一篇接地气、面向实践、适合技术人阅读的深度对比文章，主题正是你要的：

AI 规范驱动开发“三剑客”深度对比：Spec-Kit、Kiro 与 OpenSpec

AI 规范驱动开发（Spec-Driven Development，SDD）这半年火得离谱。原因很简单——大家都发现： “先写清楚规则，让 AI 按规则写代码”，比“让 AI 自己瞎编”靠谱得多。

于是三个生态逐渐成为主流选择，江湖人称 SDD 三剑客：

  • Spec-Kit
  • Kiro
  • OpenSpec（OpenAI 出品）

它们到底差在哪？适合什么团队？坑在哪里？下面一次讲透。

一、三者定位概览（一句话版本）

把三者比喻成“AI 驾驶的安全系统”，就很好理解：

工具 一句话描述 更像什么
Spec-Kit 规范最严格、颗粒最细，约束到“连注释都不能乱写” F1 赛车法规
Kiro 强调“验证”，更像 LLM 的单元测试框架 单元测试 + 静态扫描器
OpenSpec OpenAI 官方规范系统，偏“平台级协议”，用于构建 API 级 AI 行为 Web API 的 OpenAPI

三者分别站在约束、验证、协议三个角度切入同一个问题： ——“如何让 AI 的产出更可控、更稳定、更生产级”。

二、核心理念深度对比

🟦 1. Spec-Kit：“把 AI 绑定在规则之内”

Spec-Kit 的核心思想是：

把你希望 AI 遵守的要求，全都写进一个可执行的规范文件。 然后每次调用 AI，都会强制对照规范。

它的关键能力：

✔ 极细颗粒度的规则系统

能够约束到：

  • 目录结构必须满足什么模版
  • 函数必须包含哪些参数
  • 不允许修改某段已有代码
  • 不允许新增无关文件
  • 生成内容必须遵守安全规则
  • 响应里禁止出现哪些模式
  • 必须使用某个日志标准、异常风格、变量命名策略

换句话说，Spec-Kit 的哲学是：

“不信任 AI，所有规则写死；AI 只能在规定的轨道上走。”

适合场景：

  • 后端 / 工程驱动团队
  • 构建大型多文件代码库
  • 需要可预测、可迭代的代码产出
  • 希望控制 AI 对项目的所有写入行为

🟩 2. Kiro：“AI 产出的单元测试框架”

Kiro 解决的问题不是“怎么约束 AI”，而是：

“AI 写出来的东西到底靠不靠谱？”

它的本质是一种「验证层」（Validation Layer）：

  • 你可以写规则：

    • 结构是否符合要求？
    • 是否有安全风险？
    • 是否破坏某段逻辑？
    • 是否违背你的架构风格？
    • 是否包含敏感词？

  • AI 的产出必须通过验证，否则必须重新生成。

它的设计哲学是：

“不阻止 AI 发挥，但必须通过验证才能进入主干。”

非常像：

  • eslint / golangci-lint
  • 单元测试
  • 质量门禁（Quality Gate）

适合场景：

  • 希望允许 AI 自由生成，但要自动审核
  • 需要用 “拒收机制” 确保质量
  • 团队规范相对灵活
  • 侧重质量和一致性的工程团队

🟥 3. OpenSpec：“AI 的 OpenAPI 规范”

OpenSpec 是 OpenAI 官方推出的规范系统，它其实更底层：

它不是为了约束 AI 代码，而是为了“描述一个 AI 服务的行为”。 类似：给 LLM 做 OpenAPI。

你能用它描述：

  • 一个“AI 工具”的 schema
  • 输入有哪些字段？
  • 输出是什么格式？
  • 哪些字段是强制的？
  • 有哪些枚举？

重点是：

这是 OpenAI 官方在构建“AI 操作系统（AI OS）”的基建。 以后所有“让 AI 调用工具、知识库、API”，都将依赖 OpenSpec。

适合场景：

  • 构建 AI Agents
  • 构建 API 型工具生态
  • 多模型、多工具的复杂协作
  • 想让模型“可靠调用你的系统”

它不适合：

  • 管控代码生成
  • 限制 AI 变更内容
  • 规则校验

它是“上层 AI 工程生态的协议层”，而不是“产出约束层”。

三、设计哲学差异（关键理解）

可以用一幅图说明三者的差异：

                [验证层 Validator]
                          ▲
Kiro ----------------------┘
           放飞，但验证

          [规则层 Rule Engine]
                     ▲
Spec-Kit ------------┘
         强规则约束

      [协议层 Specification]
                    ▲
OpenSpec ----------┘
      定义 AI 服务契约

三者像是不同维度：

  • Spec-Kit 管“过程”
  • Kiro 管“结果”
  • OpenSpec 管“接口”

这三者并不竞争，而是互补。

四、实战选型：什么团队用哪个？

✔ 你是后端工程师 / 架构师 → Spec-Kit

痛点：

  • AI 动不动就乱改文件
  • AI 会重写你写好的代码
  • AI 会生成不合规范的结构
  • 多次调用无法保持一致性

Spec-Kit 的强约束最适合你。

典型使用效果： 让 AI 和实习生一样，只能做你允许的事。

✔ 你是全栈 / 独立开发者 → Kiro

你希望：

  • AI 生成得广一些、活一些
  • 但不要越界
  • 产出必须“符合验收标准”

Kiro 的验收机制最合适。

✔ 你要做 AI Agent / 多工具生态 → OpenSpec

比如：

  • 让模型调用自建 API
  • 让模型知道数据库结构
  • 让模型调用不同的插件
  • 构建一个新的 agent 平台

OpenSpec 是未来标准。

它不是限制 AI，而是告诉 AI： “你要学会如何正确地使用我的系统。”

五、能力矩阵对比（硬核版本）

能力 Spec-Kit Kiro OpenSpec
控制 AI 修改文件 ⭐⭐⭐⭐⭐ ⭐⭐⭐ ⭐
限制 AI 的响应结构 ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐⭐
失败时自动重试 ⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐
验证产出质量 ⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐
API/工具 schema ⭐ ⭐⭐ ⭐⭐⭐⭐⭐
用于 Agent 构建 ⭐⭐ ⭐⭐⭐ ⭐⭐⭐⭐⭐
支持复杂规范编排 ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐
工程可控性（稳定性） ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐
可扩展性 ⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐
适合团队协作 ⭐⭐⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐⭐

一句话总结：

  • Spec-Kit → “产出必须完全按我说的来”
  • Kiro → “产出可以多样，但必须合格”
  • OpenSpec → “模型之间的协议标准”

六、三者能否一起组合？

答案是：完全可以，而且更强。

例如：

组合玩法示例：构建企业级 AI Coding Bot

  • OpenSpec → 描述 API & 工具
  • Spec-Kit → 约束生成规则
  • Kiro → 对生成结果验收

就像 DevOps：

  • OpenSpec = OpenAPI
  • Spec-Kit = 编码规范 + 架构规范
  • Kiro = 单元测试 + 静态扫描

这是“企业级 AI 工程体系”的标准组合。

七、哪一个会成为行业主流？

如果从长期趋势看：

  • OpenSpec → 几乎确定会成为 AI 工程领域的“OpenAPI 标准”

  • Spec-Kit & Kiro → 会在工程团队中长期并存

    • Spec-Kit 更偏重“规约驱动开发（SDD）”
    • Kiro 更偏“模型产出的质量工程（QE for LLM）”

你可以把它看成：

OpenSpec 是“云”，Spec-Kit 与 Kiro 是“地基”。

八、结语：AI 开发已经从“写提示词”变成“写规范”

未来几年 AI 开发最大的变化是：

“Prompt 不再是主角，规范才是。”

三剑客解决的是：

  • 可靠性
  • 可维护性
  • 一致性
  • 工程规约

真正把 AI 变成「可控的工程能力」。

如果你要打造 AI 驱动的自动化测试平台、AI 代码生成器、AI 运维平台、AI 中台—— 这套组合会是必须要的底座。

如果你愿意，我还能帮你写：

  • 三剑客的更深技术原理
  • 三者的示例规范文件
  • 如何用它们构建一个企业级 SDD 流水线
  • 你正在打造的自动化测试平台如何整合三者

你需要哪个？

参考资料

https://mybatis.org/mybatis-3/zh_CN/sqlmap-xml.html#Parameters