OpenSpec的概念与基本使用

🧠 Vibe Coding 的痛点和 Spec-Driven Development 的优势

现在用 Cursor、Claude Code 这类 AI 编码助手已经是日常了。大家应该都有一个共同感受：AI 确实能写代码，但要让它持续、稳定地写出你想要的东西，没那么容易。理想状态下，我们希望自己的角色能逐步转变——从纯粹的“代码执行者”，更多地转向“指挥者”和“把关人”：AI 负责具体的代码产出，人负责架构决策、逻辑审批和质量把关。听起来很美好，对吧？但现实往往很骨感。如果在实际操作中缺乏规范，这种协作很容易退化成一种非常随意的状态，也就是现在常说的 “Vibe coding”（凭感觉编程）——脚踩西瓜皮，想到哪写到哪。人边想边写，AI 边猜边生成。这种缺乏约束的开发方式，很快就会暴露出几个致命痛点：

痛点	具体表现	后果
上下文丢失	聊天记录太长，AI 开始"失忆"	反复解释同一件事，心智负担重
AI 自由发挥	没有明确约束，AI 按自己的喜好补全	代码风格混乱，逻辑容易跑偏
需求偏移	边聊边做，缺乏锚点，做着做着就变形了	频繁返工、疯狂 debug
无法追溯	只有最终代码，不知道当初为什么这么设计	维护和交接都很困难

Spec-Driven Development（规范驱动开发） 的核心思想很简单：先写规范，再写代码，用规范约束 AI 的行为边界。

更具体地说，两者的差异可以总结为下面这张表：

维度	传统 AI 编程 (Vibe Coding)	OpenSpec (SDD)
核心驱动	基于对话和感觉	基于结构化规范文档
上下文管理	依赖聊天记录，易丢失	单一真相源 (Single Source of Truth)
可追溯性	难以审计变更原因	完整的提案与决策日志
执行精度	AI 自由发挥空间大	严格按任务清单 (Tasks) 执行

用一个比喻来说：传统的 AI 编程像是"口头协议"——你说一句，AI 做一句，做完就忘；而 SDD 像是"签合同"——先把需求、设计、任务清单白纸黑字写下来，AI 严格按合同执行，执行完还要归档备查。

🏗️ OpenSpec 的核心定位与设计哲学

📚 OpenSpec是什么

OpenSpec 是由 Fission-AI 开源的一套 Spec-Driven Development 框架 + CLI 工具。它形态非常轻量，它通过一套结构化的文件组织方式和指令系统，让 AI 编程助手（如 Codex、CodeBuddy、Claude）能够在明确的"合同"约束下工作。

一组本地 Markdown 文档（openspec/specs/ 与 openspec/changes/）。
一组斜杠命令（/opsx:propose、/opsx:apply、/opsx:archive）。
一个 npm 包：@fission-ai/openspec。

和 Spec Kit 相比，OpenSpec 没有"Constitution 强制条款"那一层；和 Kiro 相比，OpenSpec 不绑定特定 IDE。一句话——它只做"把变更规格化"这一件事，并把这件事做到极致轻量。

🎯 核心口号：Align before code

OpenSpec 的官方口号是 “Align before code”（在写代码之前先对齐）。它强调的是：

需求是合约，不是注释。
规范是 AI 的上下文，不是给人看的文档。
变更必须可追溯、可审计、可回放。

整个工具的设计都围绕这一句话展开——所有功能都为了把"模糊意图"压缩成"AI 能直接消费的契约"。

⚖️ 与其他 SDD 工具的对比

维度	OpenSpec	GitHub Spec Kit	AWS Kiro
形态	本地 CLI + Markdown	Python CLI + Markdown	IDE 内置（基于 Code OSS）
工作流	propose → apply → archive	specify → plan → tasks → implement	requirements → design → tasks
产物	proposal / design / specs / tasks	spec / plan / tasks / constitution	requirements / design / tasks
强项	增量变更、归档	完整宪法、跨工具兼容	IDE 原生、EARS 格式、Agent Hooks
弱项	无项目级强制条款	流程相对重	绑死 IDE、生态封闭
适合	增量功能、长期维护	团队级、企业级	多人协作、复杂项目

一句话选型：想轻、想快、想要变更可追溯，用 OpenSpec；想严肃、想统一、想给 AI 立宪法，用 Spec Kit；想 IDE 全家桶、用 Kiro。

🛠️ OpenSpec 的安装和使用

环境要求:OpenSpec 基于 Node.js 开发，安装前请确保你的环境满足：Node.js：版本 >= 20.19

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
# 1. 全局安装最新版
npm install -g @fission-ai/openspec@latest

# 2. 验证安装
openspec --version

# 3. 进入你的项目目录，初始化 OpenSpec
cd /path/to/your/python/project
openspec init

# 4. 在交互式菜单中选择你使用的编辑器

🧩 OpenSpec 工作目录

🗂️ 整体结构

这是理解 OpenSpec 的关键部分。用下面这张图来展示整体架构：

执行 openspec init 后，会在项目根目录创建 openspec/ 文件夹，这是整个框架的"大本营"：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
openspec/
├── config.yaml          ← 🌐 全局配置（影响所有新变更，归档不动它）
├── specs/               ← 📚 主规范库（真相源，已归档的功能规范）
└── changes/             ← 🔥 活跃变更区
    ├── my-feature/      ← 当前正在开发的变更
    │   ├── .openspec.yaml   ← 变更元数据（schema + 创建日期）
    │   ├── proposal.md      ← 为什么做（背景/目标）
    │   ├── design.md        ← 怎么做（技术方案）
    │   ├── tasks.md         ← 任务清单（To-Do）
    │   └── specs/           ← 增量规范（Delta Specs）
    └── archive/         ← 📦 归档区
        └── 2026-04-07-my-feature/  ← 归档后的变更（整个目录原封不动搬过来）

用一张表把这三个区域的分工与状态总结一下：

区域	路径	作用	状态
真相源	`specs/`	存放已归档、稳定的功能规范	🟢 稳定
活跃变更区	`changes/xxx/`	正在开发的功能提案	🟠 活跃
归档区	`changes/archive/`	已完成变更的历史记录	⚪ 历史

这一设计借鉴了传统软件工程里的"主干 + 变更集“思想：

specs/ 是已经定稿的规范库，是 AI 读"系统当前是什么"的入口。
changes/ 是正在进行的"草稿区”，每一个子目录代表一个待合并的变更。

新功能先在 changes/ 里起草，完工后通过 /opsx:archive 合并到 specs/，整个生命周期都有完整的文件留痕。

🧾 核心工件

在 OpenSpec 工作流的语境中，Artifact（工件）是指在一个变更（Change）推进过程中，按步骤依次创建的结构化文档或文件。

每个变更包含四个核心工件，我把它们比作"合同的四个章节"：四个文件各司其职：形成一条 Artifact 依赖链，每个 artifact 都是前一个的细化：

1
2
proposal.md → design.md → specs/*.md → tasks.md → 代码实现 → 归档
   (为什么做)    (怎么做)     (做成什么样)   (分几步做)   (动手做)    (存档)

工件	文件	回答的问题	谁来读
提案	`proposal.md`	为什么要做？影响哪些模块？	人 + AI
设计	`design.md`	用什么技术方案？关键决策是什么？	人 + AI
规范	`specs/*.md`	具体怎么做	AI 实现时对齐
任务	`tasks.md`	具体要做哪些事？	AI 实施时逐项打勾

一个常见的反模式是把 proposal.md 写得很长、spec.md 写得很短。事实上 spec.md 才是 AI 实现时的"事实来源"——它写得越具体，AI 跑偏的概率越低。

📄 proposal.md：提案

proposal.md 主要分为：why、what changes、Capabilities（New Capabilities、Modified Capabilities）新增/改进的功能、Impact（新增文件、修改文件、依赖等）。这里记录了以下内容：

ai 对需求的理解，也就是为什么做这个需求。
增加这个需求，该模块等于是增加了什么能力。
需求的改动范围。

🎨 design.md：设计

design.md 里面记录需求改动的上下文、目标和决策。这个文档能够体现在设计结构时 AI 采取的一些思路和理由，通常有一些学习价值。主要分为：

Context 上下文背景信息
Goals / Non-Goals 目标 / 非目标
Decisions 决策与理由
Risks / Trade-offs 风险与权衡取舍

📑 tasks.md：任务清单

tasks.md 面向执行，将 design 拆解为有序的具体任务（checkbox 格式），按层次排列：例如 1. API 类型定义 → 2. API 函数 → 3. 路由 → 4. 子组件 → 5. 列表组件 → 6. 页面容器。AI 执行时按此顺序逐项完成，勾选进度。

📐 specs/*.md：行为规范

spec.md 面向验收，用 WHEN / THEN 格式描述每个功能点的预期行为：

➕ 变更的"delta"思想

传统规范系统的痛点在于：修改现有功能时，你需要阅读整个规范，然后搞清楚哪部分在变化。 OpenSpec 引入了"增量规范"的概念：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
# Delta for Auth

## ADDED Requirements

### Requirement: Two-Factor Authentication
The system MUST require a second factor during login.

#### Scenario: OTP required
- GIVEN a user with 2FA enabled
- WHEN the user submits valid credentials
- THEN an OTP challenge is presented

## MODIFIED Requirements

### Requirement: Session Timeout
The system SHALL expire sessions after 30 minutes of inactivity.
(Previously: 60 minutes)

## REMOVED Requirements

### Requirement: Remember Me
(Deprecated in favor of 2FA)

这种格式的好处是：

清晰：一眼就能看出什么在变化
可合并：归档时自动合并到主规范
可追溯：历史变更保存在 archive 中

specs/ 下的子目录是按"能力（capability）“组织的，例如 auth/spec.md、billing/spec.md。一次新变更只会产生"差异（delta）"——只描述**新增（ADDED）、修改（MODIFIED）、删除（REMOVED）**的能力，不重写整个文件。

1
2
3
4
openspec/changes/add-oauth-login/
└── specs/
    └── auth/
        └── spec.md   # 只描述 ADDED Requirements: OAuth 登录相关

归档时 OpenSpec 会自动把这些 delta 合并到 openspec/specs/auth/spec.md，形成活文档。这样既保留了变更历史，又让 specs/ 始终是当前系统的真实写照。

💻 关键指令

我按工作模式分为以下两类：

Core 模式
- /opsx:explore 开发前梳理思路、调研方案、明确需求，只分析不实现
- /opsx:propose 一步创建变更并生成所有规划制品
- /opsx:apply 执行变更任务，编写代码实现功能
- /opsx:archive 归档已完成的变更，留存审计痕迹
Expanded 模式
- /opsx:new 初始化新变更的基础脚手架
- /opsx:continue 按依赖关系逐步生成下一个制品
- /opsx:ff 一键式快速创建变更
- /opsx:sync 增量规范合并到主规范
- /opsx:bulk-archive 批量归档多个变更
- /opsx:onboard 新手引导，引导新手快速上手

🔍 探索模式 /opsx:explore

1
/opsx:explore [topic]

/opsx:explore 是使用频率最高的指令。它的核心特点是：只思考、只分析，不产出任何代码或文件。无结构化的探索式对话，AI会调研代码库、对比多种实现方案、绘制可视化图表，帮你明确需求和技术方案，调研完成后可无缝过渡到/opsx:propose（默认）或/opsx:new（扩展工作流）。

适用场景：

需求还比较模糊，想让 AI 帮忙梳理
技术方案不确定，想做可行性分析
想了解现有代码结构再动手

🗺️ 规划阶段

规划阶段有以下几个命令选择，其中：

/opsx:new 初始化新变更的基础脚手架
/opsx:ff 一键式快速创建变更
/opsx:continue 按依赖关系逐步生成下一个制品
/opsx:propose 是 /opsx:new + /opsx:ff 的组合

🆕 /opsx:new 初始化新变更的基础脚手架

1
/opsx:new <change-name>

只做一件事：创建 openspec/changes// 目录，不生成任何文件。输出类似：

1
openspec/changes/<change-name>/

单独用 /opsx:new 的场景很少，通常它是 /opsx:continue 或 /opsx:ff 的前置步骤。

⚡ /opsx:ff 一键式快速创建变更

1
/opsx:ff <change-name>

快进，一次生成所有 artifact。Fast-forward 的缩写。一口气把 proposal、specs、design、tasks 四个文件全部生成，中间不停顿：适合的场景：需求已经想得很清楚，或者这是个改动范围小、风险低的功能，不需要在每个 artifact 之间停下来审查。

⏭️ /opsx:continue 按依赖关系逐步生成下一个制品

按照proposal.md → design.md → specs/*.md → tasks.md的依赖关系，每次生成一个 artifact。每次调用只生成依赖链里下一个尚未创建的文件，然后停下来等你审查。第一次调用生成 proposal.md，你看完觉得没问题，再调用一次生成 specs/，依此类推：

用 /opsx:continue 的情况主要有三种。

需求本身还模糊，想边写 proposal 边理清思路，看完再决定 specs 怎么写
改动涉及多个域或者架构层面，specs 写完之后需要认真确认行为约束没有遗漏，再让 AI 去写 design
团队协作场景，proposal 由产品侧写，specs 由开发审查后再继续，每个阶段需要人工介入和确认

🎁 /opsx:propose 一键式创建变更

1
/opsx:propose <change-name-or-description>

核心功能：一步创建变更文件夹openspec/changes//，并生成实现前所需的所有规划制品（proposal.md、specs、design.md、tasks.md），生成完成后即可进入开发阶段。

执行完成后，openspec/changes// 目录里会出现：

1
2
3
4
5
6
7
openspec/changes/<change-name>/
├── proposal.md
├── specs/
│   └── <capability>/
│       └── spec.md       ← Delta Spec
├── design.md
└── tasks.md

这是端到端开发最快的方式。它等价于

依次执行 /opsx:new + /opsx:ff——先创建 change 文件夹，再快进生成全部 artifact
也可以用 /opsx:new + /opsx:continue 逐步生成，每次只创建一个文件，方便在中途审查和调整

🔨 实现阶段

1
/opsx:apply <change-name> #参数为非必填，上下文可推断时可省略。

/opsx:apply：执行变更任务，编写代码实现功能，读取变更文件夹中的tasks.md，识别未完成任务，逐个执行并编写代码、创建文件、运行测试，完成后会用[x]标记任务状态。

🔬 验证阶段

1
/opsx:verify <change-name>

这个指令会从三个维度审计你的实现：

完整性：tasks.md 中的任务是否全部完成、需求是否全部实现？
正确性：实现是否符合 specs/ 中的规范？
一致性：是否遵循 design 决策、代码风格是否统一？

这个指令会生成包含 CRITICAL/WARNING/SUGGESTION 三级问题的验证报告。建议归档前必执行，可发现代码与制品的“漂移”问题，警告不影响归档但建议修复，避免技术债务。

🏁 收尾阶段

🔃 /opsx:sync：规格合并

语法：/opsx:sync [change-name] 参数为非必填，上下文可推断时可省略。

核心功能：读取变更文件夹中的增量规格，解析增/删/改/重命名内容，合并到主规格目录openspec/specs/，保留未提及的原有内容，合并后变更仍处于活跃状态（不归档）。

技巧：此命令为可选，归档时会自动提示同步，仅在长周期变更、多并行变更需要最新主规格、需要单独预览合并效果时手动执行。

📦 /opsx:archive 归档变更

当功能开发完成并通过验证后，使用这个指令归档：

1
/opsx:archive <change-name>

归档操作会做以下操作：

检查制品和任务完成状态（任务未完成会警告但不阻塞），若增量规格未同步会提示同步
在你确认后，将未合并的增量规范 specs/ 合并到主规格库 specs/
将openspec/changes// 整个目录移动到 openspec/changes/archive/YYYY-MM-DD-/。

🏷️ /opsx:bulk-archive 批量归档变更

1
/opsx:bulk-archive <change-name-list>

列出所有已完成变更，验证每个变更的状态，检测跨变更的规格冲突（通过调研代码库解决），按创建时间顺序归档，解决冲突后会提示合并结果。通常团队协作、多并行变更时适用，冲突解决基于实际代码实现，归档前会主动提示确认，避免覆盖规格内容。

🔄 常用工作流

🎛️ 切换工作模式

OpenSpec 提供两种工作模式：

Core 模式（默认）：3 个核心命令够用，适合大多数项目。
Expanded 模式：解锁更多细粒度命令（/opsx:new、/opsx:continue、/opsx:ff、/opsx:verify、/opsx:bulk-archive、/opsx:onboard）。

切换方法：

1
2
3
4
5
6
# 查看当前配置
openspec config profile
# 选择 第一项："Delivery and workflows"，按回车
# 勾选需要的命令（例如 new、continue、ff、verify、bulk-archive、onboard）
# 然后让 AI 重新识别
openspec update

经验之谈：除非项目特别复杂，否则 Core 模式完全够用。命令越多，记忆负担越大，反而拖慢节奏。

🥇 Core 工作流

OpenSpec 默认是 Core 模式，专为需求明确、范围可控的中小变更设计。它以“行动而非阶段”为核心理念，通过 5 个高频指令，实现从提案到归档的闭环操作。

1
/opsx:propose  →  /opsx:apply  →  /opsx:archive

/opsx:propose <name>：根据自然语言需求，一键生成 proposal.md + design.md + specs/ + tasks.md。
/opsx:apply：按 tasks.md 逐项实现，每完成一项打勾。
/opsx:archive <name>：把变更归档，delta 合并到 specs/，整个目录从 changes/ 移除。

命令的边界极其清楚：

propose 阶段只动 Markdown，不动代码。
apply 阶段才真正写代码。
archive 阶段关闭变更，留下审计痕迹。

🧭 探索性工作流

在 Core 模式下，你可以选择探索性工作流：也就是在前面工作流的基础上，添加一个探索阶段。

1
/opsx:explore  →  /opsx:propose  →  /opsx:apply  →  /opsx:sync  →  /opsx:archive

/opsx:explore：只思考、只分析，不产出任何代码或文件。

实操经验：拿到一个不清晰的需求时，先 /opsx:explore 把问题问透；等需求清晰、边界明确后，再 /opsx:propose 生成正式规范。避免边探索边写规范，导致 spec 反复返工。

一个 OpenSpec 变更的完整生命周期是这样的：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
需求提出
   ↓
/opsx:explore（可选，需求不清时）
   ↓
/opsx:propose <name>     → 生成 proposal / design / specs / tasks
   ↓
人工 review + 修订规范
   ↓
/opsx:apply              → 按 tasks 逐项实现
   ↓
测试与验证
   ↓
/opsx:archive <name>     → 合并 delta 到 specs/，删除 changes/<name>/

这个流程里有两个**人在环路（Human-in-the-Loop）**的检查点：

propose 之后必须 review 规范。
archive 之前必须验证实现。

跳过任何一个检查点，OpenSpec 就退化为"自动写代码的脚手架”，失去意义。

🌐 Expanded 模式

OpenSpec 的 Expanded Workflow（扩展工作流）是专为复杂项目或需要精细控制的开发任务而设计的进阶模式（相比于默认的 Core 自动挡模式，它更像“手动挡”）。该工作流包含 6 个专属命令，让你能够分步审查制品、验证质量，并进行并行与批量管理。

1
/opsx:new(新建变更)  →  /opsx:continue(生成proposal.md)  →  完善/修正proposal.md  →  /opsx:continue(生成design.md)  →  完善/修正design.md  →  /opsx:continue(生成spec.md)  →  完善/修正spec.md  →  /opsx:continue(生成tasks.md)  →  完善/修正tasks.md  →  /opsx:apply(实现任务)  →  /opsx:verify(验证实现)  →  /opsx:sync(同步到主规格库)  →  /opsx:archive(归档变更)

🧪 基本使用：一个最小例子

下面用一个最小例子把整套流程跑通。需求是"做一个 CLI 工具，能把文本按行编号输出"。

💡 需求描述

在 Claude Code 对话框里输入：

帮我用 OpenSpec 写一个 CLI 工具，名字叫 linenumber，支持读取文件路径参数，把每一行加上行号后输出到标准输出。要求：空行也要编号；如果不传文件参数，从 stdin 读取。

📋 Step 1：发起提案

1
/opsx:propose linenumber

OpenSpec 会在 openspec/changes/linenumber/ 下生成四个文件。其中 tasks.md 大致长这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
## 1. 工程初始化
- [ ] 1.1 初始化 Node.js 项目（package.json、bin 入口）
- [ ] 1.2 解析命令行参数（支持文件路径或 stdin）

## 2. 核心逻辑
- [ ] 2.1 实现 `numberLines(input: string): string`
- [ ] 2.2 处理 stdin / 文件两种输入源
- [ ] 2.3 空行也要带行号

## 3. 测试
- [ ] 3.1 单元测试：numberLines 在空字符串、普通文本、含空行文本下的输出
- [ ] 3.2 集成测试：从文件读入、从 stdin 读入

## 4. 文档
- [ ] 4.1 写 README，给出 `linenumber file.txt` 和 `cat file.txt | linenumber` 两个示例

specs/cli/linenumber/spec.md 会长这样（节选）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
# Capability: linenumber

## ADDED Requirements

### Requirement: 给文本按行编号
系统 SHALL 读取输入文本（来自文件参数或 stdin），对每一行加上"行号 + 跳格 + 内容"格式的前缀，并把结果输出到 stdout。

#### Scenario: 来自文件的普通文本
- WHEN 用户执行 `linenumber sample.txt`，且 `sample.txt` 包含 3 行文本
- THEN stdout 输出形如 `1\t第一行\n2\t第二行\n3\t第三行`

#### Scenario: 空行也要带行号
- WHEN 输入包含空行
- THEN 空行也以行号占位（不跳过）

关键动作：在这个阶段，仔细 review 每一个 Scenario。如果验收条件不严密，AI 在 apply 阶段就会跑偏。

🔧 Step 2：执行实现

1
/opsx:apply

AI 会按 tasks.md 逐项推进，每完成一项就勾掉一项。期间你也可以随时打断，要求它重写或调整。

如果你有 TDD 习惯，可以叠加 Superpowers 的 test-driven-development 技能：

1
/superpowers:test-driven-development

它会强制 AI 走"红-绿-重构"循环，先写失败测试，再写最小实现。

🗃️ Step 3：归档变更

实现完成、测试通过后：

1
/opsx:archive linenumber

OpenSpec 会自动：

把 changes/linenumber/specs/cli/linenumber/spec.md 中的 ADDED Requirements 合并到 openspec/specs/cli/linenumber/spec.md。
删除 openspec/changes/linenumber/ 目录。
留下一条归档记录，方便日后回溯。

此时 openspec/specs/ 就成了这个 CLI 工具的活文档——任何人 onboarding 都可以直接读 spec.md 了解这个工具的全部行为。

📚 命令速查表

命令	阶段	作用	是否动代码
`openspec init`	初始化	初始化 OpenSpec，写入 AI 工具命令	✗
`openspec config profile`	配置	查看/切换工作模式	✗
`openspec update`	配置	让 AI 重新识别命令	✗
`/opsx:explore`	设计前	与 AI 梳理思路，不产生产物	✗
`/opsx:propose <name>`	设计	生成 proposal / design / specs / tasks	✗
`/opsx:apply`	实施	按 tasks.md 逐项实现	✓
`/opsx:archive <name>`	归档	合并 delta 到 specs/，删除变更目录	✗
`/opsx:bulk-archive`	归档	一次性归档多个已完成变更	✗
`/opsx:onboard`	学习	把现有代码反向生成 specs/ 草稿	✗
`/opsx:ff`	实施	Fast Forward，跳过部分审批	✓
`/opsx:verify`	验证	让 AI 自检当前实现是否符合 spec	✗

表中 openspec 前缀的是 CLI 命令（在终端跑），/opsx: 前缀的是 Skill 命令（在 AI 对话框里跑）。别把它们搞混。

⚠️ 适用场景与局限

✅ 适合用 OpenSpec 的场景

长期维护的项目：规范合并到 specs/ 后就是活文档，新成员 onboarding 直接读 spec 即可。
需要审计的变更：每次新功能都有完整的 proposal.md + specs/ + tasks.md 留痕。
多 Agent 协作：把 OpenSpec 仓库和任务交给多个 AI 工具，它们读同一份 specs/，行为是一致的。
跨会话延续：规范是文件系统级的，新开会话也能立刻接上——不依赖对话历史。

❌ 不适合用 OpenSpec 的场景

小修小补：改文案、修样式、hot fix 走完整流程反而拖慢节奏（参考 [Spec Coding 的踩坑实录](../Spec Coding的踩坑实录/index.zh-cn.md)）。
探索性 PoC：需求还没定型，频繁改 spec 成本太高。
只有一两人的小项目：维护 spec 的边际收益可能不够抵消写作成本。
强实时性的项目：spec 写完到代码合入有延迟，不适合需要快速响应的场景。

🔗 参考资料

OpenSpec 官方仓库：https://github.com/Fission-AI/OpenSpec
OpenSpec 官网：https://openspec.dev/
GitHub Spec Kit：https://github.com/github/spec-kit
AWS Kiro：https://kiro.dev/
Fission-AI 组织：https://github.com/Fission-AI