ARTICLE · 1030368
AI 编程新范式:OpenSpec 和 Spec Kit 如何重塑 AI 编程工作流
如果你也在用 AI 编程，大概率经历过这样的循环：
一开始：“哇，AI 真香，几句话就帮我写好页面。”
项目变大后：“怎么又改坏了？这个接口怎么又冲突了？”
最后：“算了，还是我自己重写吧。”
上下文丢失：AI 忘了前面写过什么，同一个函数改了 N 个版本，自己跟自己打架。 文档与代码脱节：需求、设计、代码各说各话，新人接手如同读天书。 技术债累积：今天为了赶进度随便写，明天为了修复 Bug 又随便改，代码越来越难维护。
问题的根源不在于 AI 不够聪明，而在于我们缺少一套工程化的玩法。
🤔 为什么需要规范驱动开发 (SDD)？
需求模糊：直接丢给 AI 一句“做个登录页面”，结果 AI 理解的和你想要的南辕北辙。 缺乏约束：AI 不知道你项目的编码规范、架构模式，只能凭“感觉”生成代码。 无据可查：当需求变更时，你不知道从何下手，只能“猜”着改，很容易破坏现有逻辑。
规范即真相 (Source of Truth)：所有决策都先沉淀为规范文档（Spec），代码只是规范的实现。 先慢后快：前期花时间把规范写清楚，后期 AI 可以高效、稳定地执行，减少返工。 人机协作：人负责定义“做什么”和“为什么”，AI 负责实现“怎么做”。
简单来说，SDD 的目标是把 AI 编程从“艺术创作”变成“按图施工”。
🛠️ Spec Kit：严谨的“项目宪法”与全流程门控
核心工作流
/speckit.constitution：创建项目“宪法”，定义技术栈、编码规范、测试覆盖率等不可动摇的原则。 /speckit.specify：生成核心需求文档 spec.md，明确“做什么”和“为什么”。 /speckit.clarify：AI 基于规范抛出一系列结构化问题，帮你消除需求歧义。 /speckit.plan：生成详细的技术方案 plan.md，明确“怎么做”。 /speckit.tasks：将方案拆解为可执行的任务清单 tasks.md。 /speckit.analyze：交叉检查规范、方案和任务之间的一致性，输出 Findings 报告。 /speckit.implement：基于所有产物，开始生成代码。
特点与适用场景
优点：流程严谨，文档详尽，能有效避免返工，适合需要高合规性的企业级项目。 缺点：流程“重”，文档产出量大，对简单功能迭代来说可能“杀鸡用牛刀”。 适用场景：从 0 到 1 的新项目、需求不明确的探索性项目、需要明确角色分工的大型团队。
你可以把 Spec Kit 想象成一个严谨的“项目宪法”和全流程门控系统，适合在项目初期就把规矩立好。
🚀 OpenSpec：轻量的“变更管理”与增量迭代专家
核心概念与工作流
产物依赖图 (Artifact Graph)：每个变更包含 proposal、specs、design、tasks四个产物，它们之间存在依赖关系，AI 会根据状态自动判断下一步该做什么。 变更隔离：所有变更都在独立的 changes/目录下进行，只有在归档时才会合并到主规范库，避免多人协作冲突。 Delta Spec：变更中的规范使用 ADDED、MODIFIED、REMOVED等标记增量，清晰记录每次修改。
/opsx:new ：创建一个变更，在 openspec/changes//下搭好脚手架。 /opsx:ff(Fast-Forward)：一键生成 proposal、specs、design、tasks四个产物。 /opsx:apply：按照 tasks.md里的任务逐个实现代码。 /opsx:archive：验证通过后，将变更移到 archive/目录，并将增量规范合并到主规范库。
特点与适用场景
优点：流程轻量，文档简洁，变更隔离，适合在现有项目上快速迭代。 缺点：不擅长从 0 到 1 的探索性开发，假设需求已经比较明确。 适用场景：已有代码库的增量功能开发、小团队日常迭代、需要清晰变更追踪的项目。
你可以把 OpenSpec 想象成一个轻量的“变更管理”和增量迭代专家，适合在项目稳定后，高效地处理各种新需求。
⚖️ OpenSpec vs Spec Kit：全方位对比
维度 | Spec Kit | OpenSpec |
|---|---|---|
出品方 | GitHub | Fission AI |
技术栈 | Python / | TypeScript / |
设计哲学 | 严谨的“项目宪法”与全流程门控 | 轻量的“变更管理”与增量迭代 |
核心流程 | 7 步门控流程，文档详尽 | 4 步核心流程，文档精简 |
适用场景 | 0→1 新项目、需求模糊的探索性项目、需要高合规性的企业级项目 | 1→N 存量项目迭代、小团队日常迭代、需要清晰变更追踪的项目 |
学习成本 | 较高，需要系统学习文档 | 较低，10 分钟上手 |
文档产出 | 较重，单阶段可达 800+ 行 | 较轻，文档约 250 行 |
协作友好度 | 直接改主规范，多人易冲突 | 变更隔离，archive 时合并，冲突少 |
变更追踪 | 无内建机制，靠 Git | Delta Spec + 归档历史，追踪清晰 |
Token 消耗 | 较高 | 较低 |
一句话定位 | 产品经理 + 架构师 + 程序员的三合一工作台 | 存量项目的需求管理专家 |
💡 如何选择？组合使用或许是最佳答案
新项目启动阶段：使用Spec Kit，把架构和规范敲定，产出一份详尽的“项目宪法”和“设计蓝图”。 项目稳定迭代阶段：切换到OpenSpec，用它来管理日常的功能迭代，享受轻量、高效的变更管理体验。
总结一下：
如果你正在从 0 到 1 搭建一个新项目，或者团队需要高度结构化和规范化的流程，那么 Spec Kit 是你的不二之选。
如果你主要在维护一个已有项目，需要高效地处理各种增量需求，那么 OpenSpec 会让你事半功倍。
如果你两者都需要，那就两个都装上，按场景灵活切换。
猜您喜欢：
【开源】Vibe Coding已过时？35.9K Star！一个人顶一个团队：这个AI开发框架把PRD、架构、代码全包了
【开源】26.3K star，AI 写代码越来越乱？我们如何用 OpenCode + OpenSpec 把 AI 编程拉进“工业化时代”
【开源】34.7K star，Claude Code该下岗了？这款AI编程神器，把Claude Code按在地上摩擦