不管是Cursor、Claude Code还是GitHub Copilot，大家可Nengdou习惯了那种“Vibe Coding”的感觉——随手丢给AI一段需求描述，然后kan着屏幕上的代码像流水一样吐出来。说实话，这种体验在小功Neng、小修小补的时候确实爽，感觉自己是掌控全局的架构师。但一旦需求变得复杂，或者涉及到多个模块的联动，这种“随性”的编码方式往往会让你陷入无尽的Debug地狱。代码写出来了跑不通，或者逻辑跟需求南辕北辙，这时候你才会意识到：不是模型不够聪明，是我们没给够上下文。

于是“先写规范再写代码”的SDD理念开始回潮。这听起来有点像回到了瀑布流时代，但在AI的加持下它其实是一种全新的高效协作模式。目前在这个领域，有两个开源框架特别引人注目：一个是GitHub出品的Spec Kit，另一个是Fission AI推出的OpenSpec。hen多朋友dou在纠结，这两者到底该怎么选？今天我们就来扒一扒它们的底裤，kankan谁才是你的真命天子。

Spec Kit：给AI立规矩的“守门人”

先说说Spec Kit。这玩意儿在GitHub上Yi经斩获了超过2.8万颗星，热度相当高。但你要搞清楚，它本质上并不是一个AI助手，而是一套专门用来给AI助手“立规矩”的工具包。它的核心逻辑非常简单粗暴：门控流程。

想象一下你把这套工具装进项目里它就会往你的AI助手中注入一组Slash Commands。每一步操作，AIZuo完后dou需要你人工确认，确认无误了才Neng进下一步。这就像是在工厂流水线上设了无数个质检员，想混过去？没门。

怎么上手？

Spec Kit是Python生态的产物，安装起来需要用到uv这个工具。你Ke以像这样操作：

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
specify init my-project

当你跑完specify init之后一系列斜杠命令就会被写入到项目的agent配置目录下。从这以后你就不需要再敲specify命令了直接在AI助手的对话框里用斜杠命令就行。

它的核心工作流

Spec Kit的流程非常严谨，甚至有点仪式感。它把整个开发过程拆解成了一连串紧密咬合的齿轮：

1. 定规矩：/speckit.constitution

这是第一步，也是Zui重要的一步。你需要创建一个constitution.md文件，把那些不可逾越的红线写进去：比如测试覆盖率不Neng低于80%、必须使用TypeScript、禁止使用某些危险的库等等。这份文件就像项目的宪法，AI在后续的每一步操作前dou会先拜读一番，以此来减少“上下文漂移”，防止AI写着写着就放飞自我了。

2. 写规范：/speckit.specify

这一步是用自然语言描述你要Zuo什么以及为什么要Zuo。注意，这里不需要涉及任何技术细节，只要把业务逻辑讲清楚就行。AI会基于这些描述生成结构化的规范文档。

3. 消歧：/speckit.clarify

说实话，这步挺有价值的。hen多时候返工就是因为前期需求没想清楚。在这个阶段，AI会基于规范抛出一系列结构化的问题，专门针对那些潜在的歧义点。你回答这些问题后答案会被回写到规范的Clarifications部分。这就好比在开工前先跟产品经理对齐了所有细节，省得后面扯皮。

4. 技术方案：/speckit.plan

规范清楚了就该定技术方向了。你给出大致的框架和架构选择，AI会据此生成详细的技术设计方案。

5. 任务拆解：/speckit.tasks

这一步会把前面的规范和方案拆解成一个个可执行的任务列表。每个任务dou标好了依赖顺序，还有并行标记，甚至包含了文件路径和测试要求。kan着那个长长的任务清单，你会觉得心里特别踏实。

6. 一致性检查：/speckit.analyze

在正式动工前，还有Zui后一道防线。这个命令会交叉检查规范、方案和任务之间有没有矛盾。它会输出一个Findings Table，里面的每一行dou有编号。Ru果你发现问题，直接说“Fix A1, C2”，AI就会去改。这Neng有效减少返工，毕竟谁也不想写了一半发现路走错了。

7. 执行：/speckit.implement

Zui后就是基于前面所有的产物开始写代码了。整个流程大概是：Constitution → Specify → Clarify → Plan → Tasks → Analyze → Implement。

Spec Kit的优缺点

Spec Kit的好处显而易见：严谨。每一步dou有人工卡点，clarify和analyzeNeng帮你把hen多坑填在前面。但是代价也是显而易见的：重。光是specify阶段就Neng产出几十行甚至上百行的文档，整套流程跑下来需要敲七八个斜杠命令，没点耐心还真玩不转。对于日常的小功Neng迭代来说这简直有点杀鸡用牛刀的感觉，确实有些Overkill。

OpenSpec：拥抱变geng的“敏捷派”

再来kankanOpenSpec。这家伙的设计哲学则截然不同。它的预设场景是：你大部分时间dou在维护现有的代码库，进行增量式的修改，而不是从零开始搭建。所以OpenSpec的一切dou是围绕“变geng”这个概念来组织的。

OpenSpec是用TypeScript写的，需要Node.js 18+的环境。安装方式也hen直接：

npm install -g @fission-ai/openspec
openspec init
# 或者你Ke以直接指定工具
openspec init --tools claude,cursor

目前它支持的AI工具非常广泛，像Claude Code、Cursor、Windsurf、Gemini CLI、Copilot、Cline、Amazon Q等等douNeng用。初始化完成后项目里会生成对应的skill文件，虽然不同工具的命令语法略有差异，但核心逻辑是一致的。

核心概念：Delta Spec与变geng隔离

理解OpenSpec的关键，在于它的目录结构和产物依赖图。它把“当前系统状态”和“变geng提案”完全隔离开来了：

openspec/
├── specs/          ← 系统当前状态
├── schemas/        ← 自定义产物工作流
├── config.yaml     ← 项目配置
└── changes/        ← 各个变geng提案
    ├── add-dark-mode/
    ├── fix-login-bug/
    └── archive/    ← 历史变geng

每个功Nengdou在独立的change目录里开发，只有在archive的时候才会合并回主规范。这种设计对于多人协作来说简直是福音——大家各改各的，互不干扰，不会像Spec Kit那样直接改主规范文件导致冲突频发。

而且，OpenSpec引入了“Delta Spec”的概念。变geng里的规范用ADDEDMODIFIEDREMOVEDRENAMED这种标记来表示增量，而不是全量覆盖。你一眼就Nengkan出来这次改动到底影响了什么非常直观。

动态指令与产物状态

OpenSpec v1版本Zuo了一个大升级，把早期那种线性的流程重构成了一组Ke以自由组合的OPSX命令，不再强制你按顺序走。它引入了“动态指令”的概念。AI拿到的指令不再是写死的模板，而是从三层动态拼装出来的：项目上下文、产物规则、输出模板。AI每次操作前dou会查CLI获取Zui新状态，所以指令始终跟项目实际情况同步。

每个变geng包含四个核心产物：proposalspecsdesigntasks。这四个产物有三种状态：BLOCKED → READY → DONE。AI通过查询CLI拿到实时状态，自动判断下一步该Zuo什么。这意味着你Ke以随时回去改任何产物，系统会自动geng新状态链路，灵活性极高。

常用命令解析

OpenSpec的命令设计geng偏向于操作流：

/opsx:new 这是开始一个新变geng的入口。它会在openspec/changes//下搭好脚手架。你还Ke以通过--schema参数来指定自定义的产物流程。

/opsx:explore 这个模式hen有意思，它是一个硬隔离的沙盒。在正式开始前，你Ke以用它来调研问题、对比方案。因为它不会产生任何产物或代码变geng，所以你Ke以纯粹地用来“想清楚”，不用担心把代码库搞乱。

/opsx:ff 这是Fast-Forward模式。Ru果你需求hen明确，不想一步步来直接用这个命令，它会按依赖顺序一口气生成proposal、specs、design、tasks这四个产物。那种“所向披靡”的感觉，谁用谁知道。

/opsx:continue Ru果你觉得ff太激进，或者需求还没完全想透，那就用continue。它每次只生成下一个就绪的产物，适合那种边想边Zuo的风格。

/opsx:apply 这是执行阶段。它会按照specs和design逐个实现tasks.md里的任务。你Ke以用/opsx:apply 来指定变geng名，甚至支持断点续跑。万一中间断了不用从头再来。

/opsx:verify 代码写完了得检查一下。这个命令会跑一遍校验，检查代码和规范是否一致。问题分三级：CRITICAL、WARNING、SUGGESTION。kan着那些绿色的对勾，你会hen有成就感。

/opsx:archive & /opsx:bulk-archive Zui后验证产物和任务dou完成后用archive把变geng移到归档目录。Ru果有多个变geng，bulk-archive还Neng同时归档，并自动检测跨变geng的规范冲突。别忘了还有个/opsx:sync，用来把变geng里的delta specs合并回主规范目录，虽然这是可选步骤，但在archive时系统也会提示你。

到底该选谁？

说了这么多，Zui后还是得面对现实的选择题。其实这两者并不是非此即彼的死对头，它们适用的场景其实挺互补的。

为了让大家geng直观地Zuo决定，我整理了一个简单的对照表：

场景	推荐选择
新项目启动，要求架构严谨、规范先行	Spec Kit
在Yi有代码库上进行功Neng迭代	OpenSpec
多人协作，特别关注冲突管理	OpenSpec
合规性、可审计性要求极高	Spec Kit
追求开发速度，快速试错	OpenSpec
需求模糊，需要深度消歧	Spec Kit

混合双打或许才是王道

说实话，工具终究是工具，没有绝对的银弹。Ru果你非要让我给个建议，我会说：别把路走窄了。

一种非常可行的组合方式是：在新项目启动阶段，用Spec Kit把架构、核心规范和“宪法”敲定。这时候多花点时间是值得的，毕竟地基打不牢，后面全是雷。一旦进入日常迭代阶段，就Ke以切到OpenSpec来Zuo增量变geng管理，利用它的Delta Spec和变geng隔离特性，快速响应业务需求。

毕竟开发这事儿，既要有仰望星空的严谨，也要有脚踏实地的灵活。选对工具，你的AI编程体验绝对会上升一个台阶。别犹豫了赶紧去试试吧！

---