AI原生开发——speck-kit vs openspec

1. 开篇：AI编程的"失控"与"收束"

想象你请了一位能力超强但有点"自由发挥"的建筑师。你跟他说"我要一个温馨的家"，结果他可能给你建了个玻璃房——技术上很美，但冬冷夏热完全不实用。这就是当前AI编程的真实写照。

AI编程助手（如Cursor、Claude Code、GitHub Copilot）确实强大，但有个致命问题：它们擅长生成代码，却不擅长理解你的真实意图。研究显示，AI生成的代码中，漏洞率高达9.8%到42.1%，而且往往只关注功能正确，忽视架构一致性和安全规范。

规范驱动开发（Specification-Driven Development，简称SDD）应运而生。它的核心理念很简单：先写清楚"要什么"，再让AI去"怎么做"，并且这个规范是可执行、可验证的。

如果把传统编程比作"边做边改装修"，SDD就是"先画好施工图，再严格按图施工"。在AI时代，这不再是束缚创造力，而是防止"AI自由发挥"导致项目失控的必要护栏。

---

2. SDD的两种哲学：蓝图派 vs 园丁派

在SDD生态中，目前有两个代表性工具：GitHub Spec Kit（简称speck-kit）和OpenSpec。它们就像两位风格迥异的建筑师：

• speck-kit 是"蓝图派"——强调从零开始的完整规划，适合新建大楼
• OpenSpec 是"园丁派"——擅长在现有花园中修剪、嫁接，适合改造老院子

这个比喻背后，是两种截然不同的设计理念。

---

3. speck-kit：企业级的"四阶段蓝图法"

speck-kit由GitHub推出，是一套完整的规范驱动开发框架。它的工作流分为四个严格阶段：

3.1 核心工作流程

阶段	指令	通俗解释
Specify（定义）	/speckit.specify	写需求说明书，明确"要做什么"
Plan（规划）	/speckit.plan	制定施工计划，拆解任务
Tasks（任务）	/speckit.tasks	生成具体待办清单
Implement（实现）	/speckit.implement	AI按图施工，编写代码

这个过程就像建造房屋：先出设计图（Specify），再排工期（Plan），然后分派工单（Tasks），最后工人进场（Implement）。

3.2 企业级特性

speck-kit的设计明显偏向大型企业和新项目（0→1开发）：

• 宪法约束（Constitution）：可以定义"架构宪法"，比如"所有API必须RESTful"、“禁止直接操作数据库”。这相当于给AI戴上紧箍咒，防止它违反企业架构规范。

• 多仓库协调：支持跨22个以上AI代理平台，适合大规模团队协作。

• 合规审计：生成完整的规范与实现对应记录，满足欧盟AI法案等监管要求——违规罚款可能高达全球营收的7%或3500万欧元。

3.3 实际体验：理想丰满，现实骨感？

一位开发者在2025年底的实测中分享了真实体验：使用speck-kit重建一个业余项目功能时，遇到了"海量Markdown文档、漫长的AI运行时间和意外的摩擦"。他形容这种体验像是"重新发明了瀑布模型"——前期规划过重，反而拖慢了开发节奏。

这揭示了一个关键问题：speck-kit的严格四阶段流程，对于小团队和快速迭代场景可能过于沉重。

---

4. OpenSpec：轻量级的"变更追踪术"

OpenSpec由Fission AI开发，走的是另一条路。它的核心理念是**“Brownfield-first”（存量优先）**——不是假设你在空地上建新楼，而是假设你在已有建筑上改造。

4.1 独特的"三件套"结构

OpenSpec的文件夹设计非常直观：

openspec/
├── specs/              # 当前真相——活文档（现有系统）
│   └── auth-session/
│       └── spec.md
└── changes/            # 拟议修改（新功能）
    └── add-2fa/
        ├── proposal.md    # 变更提案
        ├── tasks.md       # 任务清单
        ├── design.md      # 设计方案（可选）
        └── specs/         # 规格差异（ADDED/MODIFIED/REMOVED）
            └── auth-session/
                └── spec.md

这个设计的巧妙之处在于：它把"现在是什么样"和"要改成什么样"完全分开。就像装修时的"原始户型图"和"改造方案图"，对比一目了然。

4.2 三大核心指令

OpenSpec简化了流程，只有三个关键动作：

指令	作用	生活比喻
/openspec-proposal	创建变更提案	“我想把厨房改成开放式”
/openspec-apply	按提案实施	工人按方案施工
/openspec-archive	归档合并	完工后更新房产证

4.3 差异化优势

① 轻量无负担

• 无需API密钥，几行命令即可启动
• 支持20+ AI工具（Cursor、Claude、Copilot、Windsurf等）

② 变更即差异（Delta）
OpenSpec使用ADDED/MODIFIED/REMOVED标记来展示变更。这就像Git的diff功能，但针对的是"业务意图"而非"代码行"。人类和AI都能一眼看出：“哦，这次是在原有登录功能上新增了双因素认证”。

③ 单一真相源（Single Source of Truth）
与speck-kit的多文件分散不同，OpenSpec坚持一个能力一份规格书。所有变更最终合并回openspec/specs/，避免"规格碎片化"导致的理解困难。

---

5. 直接对比：speck-kit vs OpenSpec

为了更直观理解，我们用一张表对比两者的核心差异：

维度	speck-kit	OpenSpec
最佳场景	新项目（0→1）、大型企业	存量改造（1→n）、中小团队
流程复杂度	四阶段严格流程	三阶段轻量流程
规格组织	分散式（多文件）	统一式（单真相源+变更差异）
架构约束	强（宪法级约束）	中（项目级规范）
合规审计	强（企业级治理）	中（变更历史追踪）
上手门槛	较高（需CI/CD集成）	低（npm安装即用）
AI工具支持	22+平台	20+平台
存量代码支持	较弱	核心优势

关键洞察

• 如果你是CTO，要启动一个涉及多团队、需合规审计的新核心系统 → 选speck-kit。它的宪法约束和治理框架能防止架构腐化。

• 如果你是独立开发者或小团队，要在现有项目上快速迭代 → 选OpenSpec。它的"变更差异"设计让AI不会淹没在已有代码中，而是聚焦于"这次改什么"。

---

6. 深层思考：SDD不是银弹，而是新契约

两种工具的差异，本质上反映了AI编程的两个深层挑战：

6.1 规范 vs 灵活性的永恒张力

speck-kit代表了**“强规范”**路线——通过前置的严格规划来约束AI。这类似于传统软件工程中的"瀑布模型"，在AI时代以新的形式回归。风险是：过度规划可能扼杀AI的创造性，且前期投入成本高。

OpenSpec代表了**“轻规范”**路线——通过追踪变更来管理AI。这更接近敏捷开发，承认"需求会变"的现实。风险是：长期可能积累技术债务，需要定期整理规格。

6.2 从"Vibe Coding"到"Spec Coding"

业界有个新词叫"Vibe Coding"（氛围编程）——完全凭感觉让AI写代码，享受流畅的创造感。但研究表明，这种方式会让代码复杂度增加41%，静态分析警告增加30%。

SDD（无论是speck-kit还是OpenSpec）都代表了一种纠偏：从"生成代码再祈祷"转向"先对齐意图再生成"。这不是限制AI，而是给AI装上了方向盘和刹车——让它开得快，但不翻车。

6.3 未来趋势：多智能体协作的"通用语言"

随着AI助手种类增多（Claude、Cursor、Copilot、Gemini等），规格正在成为人类与AI、AI与AI之间的通用语言。想象一个场景：产品经理用自然语言写需求，AI A翻译成OpenSpec格式，AI B根据规格生成代码，AI C进行测试验证——全程可追溯、可审计。

speck-kit和OpenSpec都在争夺这个"通用协议"的位置。目前看，speck-kit偏向企业级封闭生态，OpenSpec偏向开放轻量生态。

---

7. 结语：选择你的"AI缰绳"

回到开头的比喻：AI是那位能力超强但有点"自由发挥"的建筑师。SDD就是拴住他的缰绳——不是不让他跑，而是确保他跑向正确的方向。

• speck-kit 是企业级的钛合金缰绳——沉重但坚固，适合驯服大型野兽
• OpenSpec 是创客的皮革缰绳——轻便趁手，适合日常骑行

对于没有技术背景的读者，记住这个简单原则：如果你要改造现有东西，选OpenSpec；如果你要从零建造且怕AI乱来，选speck-kit。

但无论选哪个，核心思想是一样的：在AI时代，写清楚"要什么"比"怎么做"更重要。规格不再是死文档，而是活的生产力工具。这或许是AI给我们上的最重要一课——清晰的思考，永远先于高效的执行。

---

参考资源：

• speck-kit官方指南
• OpenSpec文档与GitHub仓库
• 开发者实测对比
• ArXiv相关研究论文