OpenSpec 技术

1. 一句话本质

OpenSpec 是一个命令行工具，给你的 AI 编程助手（如 Claude Code、Cursor）加一层"先把需求写成文档、人和 AI 都认可了再动手写代码"的流程；这些需求文档以 Markdown 形式存放在项目仓库里，可以被 Git 追踪、被人审查、被 AI 在新会话里重新读取，而不是只存在于一次性的聊天记录中。

---

2. 背景与根本矛盾

历史背景

AI 编程助手的代码生成能力很强，但存在一个结构性问题：需求如果只存在于聊天历史中，一旦上下文窗口被清空或换了一次会话，AI 就"失忆"了，团队不得不反复在对话里重新解释"这个项目是做什么的、之前做过哪些决定"。这种纯靠对话驱动编码的方式被称为"vibe coding"——能快速出原型，但在严肃项目或存量代码库（brownfield）上容易出现"代码能跑但不是你想要的东西"的问题。

2025 年 9 月，GitHub 开源了 Spec Kit，将"规范驱动开发"（SDD, Spec-Driven Development）这一理念系统化为一套带有严格阶段门（Specify → Plan → Tasks → Implement）的工具链，引发了行业对 SDD 的关注。OpenSpec（由 Fission-AI 团队发起）是同一时期出现的另一条技术路线：它认同"先对齐需求再写代码"的核心理念，但在工程实现上选择了更轻量、更少强制约束的设计。

根本矛盾（Trade-off）

OpenSpec 的核心设计在两组对立约束之间做取舍：

• 流程的确定性/可审查性 vs 迭代的灵活性/低开销：Spec Kit 用严格的四阶段门保证每一步都"达标才能往下走"，确定性强但启动成本高（环境依赖 Python 3.11+、uv、Git，配置耗时约 30 分钟）；OpenSpec 放弃强制阶段门，5 分钟即可初始化完成，代价是流程合规性更依赖团队自律，而不是工具强制。
• 单一真相源的稳定性 vs 变更历史的可追溯性：如果每次改动都直接重写整份 Spec，文档会失去"谁在什么时候因为什么原因改了什么"的可追溯性；OpenSpec 用"Delta Spec（增量规格）"机制解决——specs/ 永远是当前真相，changes/ 是尚未合并的提案，归档后变更文件夹连同完整决策上下文被保留，既保证了主 Spec 的整洁，又不丢失历史。

---

3. 核心概念与领域模型

关键术语表

术语	费曼式定义	正式定义
Spec（规格）	系统现在到底是怎么运作的说明书	openspec/specs/ 目录下的 Markdown 文件，用 Requirement + Scenario 结构描述系统当前行为，是项目的"源头真相"（source of truth）
Change（变更）	一个还没被正式采纳的功能提案文件夹	openspec/changes/ 下的自包含文件夹，包含 proposal.md、design.md（可选）、tasks.md 和针对相关 Spec 的 Delta
Delta Spec（增量规格）	只写"这次改了什么"，不用把整份文档抄一遍	Change 文件夹内的 Spec 片段，用 ADDED / MODIFIED / REMOVED 三种 section 表达相对当前 Spec 的变化
Requirement（需求条目）	系统必须/应该/可以做到的某件事	用 RFC 2119 关键词（MUST/SHALL/SHOULD/MAY）表达约束强度的具体行为描述
Scenario（场景）	用一个具体例子说明这条需求在什么情况下应该怎样	Given/When/Then 格式的可验证示例，理论上可以直接转化为一条自动化测试
Schema（工件图）	这套工作流里有哪些文档类型、谁依赖谁	YAML 配置，定义一组 artifact（proposal/specs/design/tasks 等）及其依赖关系，默认内置 spec-driven schema
Archive（归档）	把"草稿"正式转正，存进历史	把 Change 的 Delta 合并进主 Spec、并将整个 Change 文件夹移动到 changes/archive/ 的过程

领域模型

OpenSpec 在文件系统层面的实体关系可以表示为：

openspec/
├── specs/                          ← 源头真相（当前系统行为）
│   ├── auth/spec.md
│   ├── payments/spec.md
│   └── ui/spec.md
│
└── changes/                        ← 提案区
    ├── add-dark-mode/              ← 一个 Change = 一个文件夹
    │   ├── proposal.md             （为什么 + 做什么，含 in scope / out of scope）
    │   ├── design.md                （怎么做，技术方案，可选）
    │   ├── tasks.md                 （实现任务清单，带 checkbox）
    │   └── specs/ui/spec.md         （Delta：相对 specs/ui/spec.md 的增量）
    │
    └── archive/
        └── 2025-01-23-add-dark-mode/   ← 归档后的完整历史快照

可以类比理解：specs/ 相当于数据库当前的"已提交状态"，changes/{name}/ 相当于一个尚未提交的"事务"，openspec archive 相当于 COMMIT——事务里的增量被合并进主状态，同时保留一份完整的变更记录用于审计。

工件之间还存在一条依赖链（Artifact Flow）：

proposal ──► specs ──► design ──► tasks ──► implement
   │            │          │         │
  为什么       改什么      怎么做     具体步骤
 + 范围

---

4. 对比与选型决策

同类工具横向对比

维度	OpenSpec	Spec Kit（GitHub）	Kiro（AWS）	无规范（“vibe coding”）
运行环境依赖	Node.js ≥ 20.19.0	Python 3.11+、uv、Git	绑定 AWS Kiro IDE	无
启动成本	约 5 分钟（npm install + openspec init）	约 30 分钟（环境搭建 + CLI 初始化）	安装 IDE 即用	0
流程刚性	无强制阶段门（action-based，工件依赖图）	四阶段强制门：Specify → Plan → Tasks → Implement	三阶段：需求 → 设计 → 任务	无
支持的 AI 工具数量	20+（Claude Code、Cursor、Copilot、Codex、Windsurf 等）	GitHub Copilot、Claude Code、Gemini CLI 等	仅限 Claude 系模型	任意
适用阶段	棕地（存量项目）优先，绿地同样可用	绿地、棕地、遗留系统迁移均有专门场景设计	取决于 IDE 内工作流	任意
协议	MIT，开源	MIT，开源	闭源，绑定 AWS 生态	N/A

⚠️ 存疑：上表"启动成本"是基于官方文档自述的口径（OpenSpec 官网称"5-minute setup vs 30 minutes"），未经过本文独立计时验证，实际耗时会因网络环境、操作熟练度有所浮动。

选型决策树

• 团队已经深度绑定某个 IDE 生态（例如全员用 AWS 相关工具链） → 优先考虑该生态自带方案（如 Kiro），除非有明确的"工具解耦"诉求。
• 需要严格的、可审计的四阶段流程（强监管行业、大型架构重构、跨团队协作） → 倾向 Spec Kit，或 OpenSpec 中针对高风险变更的 Full Spec 模式。
• 团队成员使用多种不同的 AI 编程助手，希望共享同一套规格而不被某个工具锁死 → OpenSpec 更合适，它本身就是为"工具无关"设计的。
• 团队规模较小、希望尽快落地、能够接受流程上有一定自由裁量空间 → OpenSpec 的 Lite Spec 模式。
• 纯原型验证、一次性脚本、没有维护诉求的代码 → 不需要任何 SDD 工具，直接对话编码即可，引入流程反而是负收益。

与上下游技术的配合关系

OpenSpec 不替代 AI 编程助手本身，而是在编码助手"动手写代码"之前插入一层"需求对齐层"。下游天然对接 Git：每个 Change 是一个普通文件夹，可以正常走 PR 审查流程；上游可以与任务管理系统（如通过 MCP 集成 Linear）打通，让 Proposal 与团队既有的 Backlog 保持同步。

---

5. 工作原理与实现机制

静态结构

• 核心实现：CLI 用 TypeScript 编写（仓库代码占比约 99.2%），通过 npm 包 @fission-ai/openspec 分发安装。
• 目录结构：specs/（当前真相）与 changes/（提案区，含 archive/ 子目录）构成项目内最核心的两个数据区。
• Schema 系统：用 YAML 文件定义一组 artifact 及其依赖关系，决定"能创建什么、需要先有什么"。默认内置的 spec-driven schema 长这样：

# openspec/schemas/spec-driven/schema.yaml
name: spec-driven
artifacts:
  - id: proposal
    generates: proposal.md
    requires: []              # 无依赖，可最先创建

  - id: specs
    generates: specs/**/*.md
    requires: [proposal]      # 需要先有 proposal

  - id: design
    generates: design.md
    requires: [proposal]      # 可以和 specs 并行创建

  - id: tasks
    generates: tasks.md
    requires: [specs, design] # 需要 specs 和 design 都完成

为什么用依赖图而不是数据表或线性队列：依赖关系表达的是"可能性"（proposal 做完之后，specs 和 design 才有意义），而不是"必须性"（specs 和 design 之间没有先后强制，design 甚至可以跳过不写）。这是 Trade-off 的体现——相比 Spec Kit 的线性阶段门，依赖图给了"可以跳过某个 artifact、可以并行创建多个 artifact"的自由度，但代价是如果团队没有共识，容易出现"该写的 design 被随意跳过"的情况。

动态行为：一次典型变更的时序

以"新增暗色模式"为例，使用核心命令集（core profile）的完整流程：

1. 发起提案：用户在 AI 编程助手里输入 /opsx:propose add-dark-mode，AI 分析需求后在 openspec/changes/add-dark-mode/ 下生成 proposal.md（为什么做、范围是什么）、specs/ui/spec.md（Delta）、design.md（技术方案）、tasks.md（任务清单）。
2. 实现：用户输入 /opsx:apply，AI 按 tasks.md 逐项实现代码，每完成一项就把对应 checkbox 勾选为完成。
3. 校验（可选）：用户输入 /opsx:verify，AI 对照 specs/ 和 tasks.md 检查实际实现是否与规格一致。
4. 归档：用户输入 /opsx:archive，CLI 将 Delta Spec 合并进主 Spec（openspec/specs/ui/spec.md），并把整个 Change 文件夹移动到 openspec/changes/archive/{日期}-add-dark-mode/。

关键设计决策

决策一：用 Delta 而不是全量 Spec 描述变更。 棕地项目的改动通常只涉及系统的一小部分，如果每次提案都要重写整份 Spec，既要重复抄写不变的部分，又难以一眼看出"到底改了什么"。用 ADDED/MODIFIED/REMOVED 三类 section 表达相对变化后，两个并行的 Change 只要不修改同一个 Requirement，归档时就不会冲突。Trade-off：Delta 牺牲了"打开一份文件就能看到完整画面"的直观性，需要靠 openspec show / openspec view 等命令做合并视图来弥补。

决策二：从线性阶段门改为工件依赖图（1.0 的核心重构）。 早期版本的 OpenSpec 也是类似 Spec Kit 式的 propose → apply → archive 顺序流程，1.0 版本将其重构为"工件依赖图 + 任意时刻可编辑任意 artifact"的 action-based 模型。原因是实际开发中需求理解会在设计阶段才加深，回头修改 proposal 或 spec 是常态，强制的阶段门反而制造摩擦。Trade-off：放弃了"流程合规性由工具强制保证"，转而依赖团队约定和 openspec validate 之类的校验命令。

决策三：Spec 只描述行为契约，不描述实现细节。 官方文档明确规定 Spec 中不应出现具体的类名/函数名、库框架选型、分步实现细节，这些内容应放进 design.md 或 tasks.md。原因是实现会变，但行为契约相对稳定；如果实现细节也混进 Spec，每次重构内部实现都要连带修改 Spec，Spec 就失去了"稳定真相源"的价值。判断标准（Quick Test）：如果实现方式变了但外部可观察行为没变，这部分内容大概率不该出现在 Spec 里。

---

6. 工程治理可靠性保障

⚠️ 维度说明：OpenSpec 是开发期工具而非运行时服务，不存在节点故障、网络分区、副本选举等传统分布式系统意义上的高可用问题，本节将"高可靠性"重新诠释为流程治理层面的可靠性——即如何保证规格与实现不漂移、变更历史可追溯、协作不冲突。

• 一致性校验：openspec validate 命令检查 Spec 格式合规性（例如 SHALL/MUST 关键词是否出现在正确位置、Scenario 结构是否完整），支持 --all / --changes / --specs 做批量校验，可以接入 CI 流水线作为门禁。
• 并行协作的冲突规避：多个 Change 可以同时存在于 changes/ 下互不干扰；只要它们不修改同一个 Requirement，归档时不会产生冲突。注意这不是自动的三方语义合并，而是"按粒度规避"。
• 审计追溯：归档后的 Change 文件夹连同完整上下文（proposal/design/tasks/delta）原样保留在 changes/archive/，按日期前缀排序，构成完整的决策历史链，可以随时回溯"某条规则为什么会变成现在这样"。
• 配置容灾：openspec update 可以重新生成各 AI 工具的配置文件（如自 1.0 起统一为 .claude/skills/ 之类的 YAML-front-matter Markdown），配置丢失或损坏时可直接重建；核心数据（specs/、changes/）始终是项目仓库内的明文 Markdown 文件，天然受 Git 版本控制保护，没有额外的单点存储依赖。
• 可观测性命令：
  • openspec list：列出活跃 Change，展示任务完成比例（如 2/5 tasks）和最近活动时间。
  • openspec show <change>：查看某个 Change 的完整详情。
  • openspec status：查看 artifact（proposal/specs/design/tasks）各自的完成状态。
  • openspec view：交互式 dashboard，可视化全局 Change/Spec 状态。
• 不适用项说明：本节不讨论传统意义的 SLA、副本数、故障转移时间等指标，因为 OpenSpec 不是常驻运行的系统组件，这些维度对它没有意义。

---

7. 使用实践与故障手册

7.1 典型使用方式

生产级安装与初始化（Node.js ≥ 20.19.0）：

# 全局安装最新版本
npm install -g @fission-ai/openspec@latest

# 进入项目目录后初始化
cd your-project
openspec init

# CI/CD 或脚本化场景：跳过交互式选择，显式指定要配置的 AI 工具
openspec init --tools claude,cursor
# 配置所有受支持的工具
openspec init --tools all
# 仅生成 openspec/ 目录骨架，不生成任何工具特定配置
openspec init --tools none

# 切换工作流档位：core（默认，含 propose/explore/apply/sync/archive）
# 或 expanded（额外含 new/continue/ff/verify/bulk-archive/onboard）
openspec config profile

# 升级 CLI 后，在项目内重新生成最新的 AI 工具指令与 slash 命令
openspec update

关键配置项说明：

配置项	默认值	作用	默认值风险
openspec config profile	core	决定生成哪一组 slash 命令/skills	团队未达成一致就切换到 expanded，会增加命令数量和学习成本，导致部分成员仍在用旧命令习惯
OPENSPEC_TELEMETRY	1（开启）	是否上报匿名命令使用统计（仅命令名+版本号，不含路径/内容/PII）	无功能性风险，企业合规场景可通过 export OPENSPEC_TELEMETRY=0 或 export DO_NOT_TRACK=1 关闭，CI 环境下默认自动禁用

7.2 故障模式手册

【未初始化导致命令报错】
- 现象：执行 openspec list / openspec show 等命令时报"找不到 openspec 目录"类错误
- 根本原因：项目尚未执行过 openspec init，缺少 openspec/ 目录骨架
- 预防措施：在 CI 流水线中显式加入 openspec init --tools none 作为前置步骤，确保目录结构始终存在
- 应急处理：手动运行 openspec init 补建目录结构；已有的手写 spec.md 不需要重写，直接放入 openspec/specs/{domain}/spec.md 对应路径即可

【并行 Change 修改同一 Requirement 产生冲突】
- 现象：两个并行的 Change 都改动了同一个 Requirement，归档其中一个之后，另一个 Change 的 Delta 在归档时与主 Spec 出现语义不一致
- 根本原因：Delta 合并是按"整条 Requirement 替换"的粒度执行的，不具备自动三方语义合并能力
- 预防措施：在 proposal.md 阶段就明确写清楚 in scope / out of scope，沟通避免多个 Change 触碰同一 Requirement；定期执行 openspec validate --all 做静态扫描
- 应急处理：人工比对两个 Change 的 Delta 内容，决定先归档哪一个、后归档的那个手动调整 Delta 内容后再归档

【实现阶段 AI 生成的代码偏离 Spec/Tasks】
- 现象：/opsx:apply 阶段产出的代码与 tasks.md、spec.md 描述不一致，/opsx:verify 校验未通过
- 根本原因：会话上下文被历史对话或大量无关文件"污染"，模型没有严格依据当前 Change 的 Spec 生成代码；官方文档明确建议保持"Context Hygiene"
- 预防措施：进入实现阶段前清空对话上下文，仅携带当前 Change 相关文件；优先选用高推理能力模型（官方文档建议 Codex 5.5 / Opus 4.7 级别模型用于规划与实现）
- 应急处理：运行 /opsx:verify 定位具体偏差点，针对偏差部分做局部 reprompt，而不是推倒重新生成整个 Change

7.3 边界条件与局限性

• OpenSpec 对 AI 行为的约束力本质上依赖模型"主动遵守"提示词指令，不像编译器那样能强制阻止 AI 写出脱离 Spec 的代码。⚠️ 存疑：模型遵从度与具体模型版本、提示词工程质量密切相关，官方文档未给出可量化的"遵从率"数据，本文也不做编造。
• Lite Spec 模式下默认省略 design.md，如果需求本身复杂（跨团队/跨仓库改动、API 兼容性变更、安全/隐私相关），官方建议主动切换为 Full Spec 模式，否则容易出现"规格写了，但具体怎么做没人说清楚"的断层。
• 多个 Change 涉及同一 Requirement 时仍需人工裁决合并顺序，没有自动化的三方语义合并能力（见 7.2 故障手册）。
• CLI 本身基于 Node.js 生态（TypeScript 实现，要求 Node.js ≥ 20.19.0）。⚠️ 存疑：在完全离线或受限网络环境下首次 npm install 需要提前准备好私有 npm registry 镜像，官方文档未对该场景给出专门指引。
• Workspace / Context Store（跨仓库协同）功能仍处于 beta 阶段，官方文档明确说明其命令行为和 JSON 输出格式仍可能变化，不建议在外部自动化系统中对其行为做强假设。

---

8. 协作效率调优指南

维度说明：OpenSpec 不是一个有吞吐量/延迟概念的运行时系统，本节的"性能"指团队使用 OpenSpec 进行规范驱动开发的协作效率，包括返工率、流程认知负担、上下文质量等维度。

效率瓶颈识别

• 如果团队反馈"流程拖慢了交付速度"，优先检查是否对所有变更都套用了 Full Spec 模式——官方文档明确指出"大多数变更应停留在 Lite 模式"，只有跨团队/高风险变更才需要升级到 Full 模式。
• 如果 AI 生成代码经常与 Spec 不一致，问题大概率出在上下文管理（见 7.2 故障三），而不是 OpenSpec 工具本身的缺陷。

调优步骤（按优先级排序）

1. 默认使用 core profile，只保留 propose/explore/apply/sync/archive 五个核心命令，避免团队成员被 expanded profile 下的 new/continue/ff/verify/bulk-archive/onboard 等更多命令分散认知负担；确有需要再针对性开启。
2. 进入实现阶段前清空对话上下文，只携带当前 Change 目录下的文件，减少模型注意力被无关历史对话稀释，降低代码与 Spec 不一致导致的返工。
3. 优先选用高推理能力模型做规划与实现（官方建议 Codex 5.5、Opus 4.7 一级的模型），用于降低规格理解偏差带来的返工率。
4. 多 Change 并行时定期执行 openspec validate --all + openspec list，及早发现潜在的 Requirement 冲突，避免归档阶段集中爆发合并成本。

调优参数速查表

参数	默认值	推荐调整方向	调整风险
openspec config profile	core	团队达成共识、确实需要分步骤精细控制 artifact 创建时再切到 expanded	切换后命令集变多，未同步培训会导致团队内命令使用不统一
Spec 严格度（Lite vs Full）	Lite（文档约定，非 CLI 参数）	仅对高风险/跨团队/API 变更的 Change 升级为 Full Spec	全员默认用 Full 会显著拖慢日常小改动的交付节奏
OPENSPEC_TELEMETRY	1	企业合规要求下设为 0	无功能影响，仅影响匿名使用统计上报

---

9. 演进方向与未来趋势

结合官方 Release 记录与 CHANGELOG 可以观察到两个值得关注的演进方向：

1. 从"线性阶段"持续走向"动作驱动 + 工件依赖图"：1.0 版本已经完成了从 propose → apply → archive 固定顺序到 action-based 工作流的核心重构，并统一了配置文件形态（旧版分散在 CLAUDE.md、.cursorrules、AGENTS.md 等多个工具特定文件中，新版统一收敛为 .claude/skills/ 之类的 YAML-front-matter Markdown 目录）。对使用者的实际影响：从旧版本升级时，运行 openspec init 会清理过时的配置文件（会有确认提示），但 specs/、changes/ 等核心数据不受影响，可以放心升级。
2. Workspace / Context Store（beta）支持多仓库协同：引入"局部视图"（workspace，机器本地的链接视图，不进 Git）和"Initiative"（跨仓库的持久共享上下文）概念，目标是让横跨多个仓库的功能能够共享同一份 planning 和归档流程。对使用者的实际影响：目前该能力仍标注为 beta，官方文档明确建议外部自动化（脚本、CI 集成）不要对其命令行为和 JSON 输出格式做强假设，团队若有跨仓库协作的强需求可以关注，但暂不建议作为核心依赖。

---

10. 面试高频题

【基础理解层】（考察概念掌握）
Q：OpenSpec 的 openspec/specs/ 和 openspec/changes/ 分别存放什么内容？
A：specs/ 存放"当前系统行为的真相"（source of truth），changes/ 存放"尚未合并的提案"，每个 Change 是一个独立文件夹，包含 proposal/design/tasks 和针对相关 Spec 的 Delta。
考察意图：考察候选人是否理解 OpenSpec 最基础的目录语义和"真相源 vs 提案"的二分设计，这是后续所有讨论的前提。

Q：什么是 Delta Spec，为什么不直接在变更里写一份完整的 Spec？
A：Delta Spec 只描述相对当前 Spec"新增/修改/删除"了什么（ADDED/MODIFIED/REMOVED 三个 section），而不是重写整份 Spec；这样多个并行 Change 互不冲突（只要不动同一个 Requirement），审查者也只需要关注变化部分，而不用人工 diff 整份文档。
考察意图：考察对"增量设计"这一核心理念的理解，能否说出至少两点好处（冲突规避 + 审查效率）。

【原理深挖层】（考察内部机制理解）
Q：OpenSpec 的 Schema 是如何决定 artifact 创建顺序的？它和 Spec Kit 的 Phase Gate 有什么本质区别？
A：Schema 用 YAML 定义每个 artifact 的 requires 依赖（例如 tasks 依赖 specs 和 design），这是一个依赖图而非线性流程；依赖只规定"可能性"（proposal 做完才能做 specs）而非"必须性"（specs 和 design 可以并行，design 甚至可以跳过）。Spec Kit 则是四个阶段（Specify/Plan/Tasks/Implement）依次门控，不达标不能进入下一阶段。
考察意图：考察对两种 SDD 工具底层设计哲学差异的理解，能否准确表述"依赖图（enabler）"与"阶段门（gate）"的本质区别，而不仅是停留在"一个严格一个宽松"的表面认知。

Q：Archive 过程中，ADDED/MODIFIED/REMOVED 这三种 Delta 分别是如何应用到主 Spec 的？
A：ADDED 的 Requirement 被追加到主 Spec；MODIFIED 的 Requirement 替换主 Spec 中同名的现有 Requirement；REMOVED 的 Requirement 从主 Spec 中直接删除。三者都以"整条 Requirement"为最小合并粒度，不做更细粒度（如单个 Scenario 级别）的合并。
考察意图：考察对底层合并机制粒度的理解，是否清楚 OpenSpec 目前不支持自动三方语义合并，这直接关联到第 7.2 节的冲突故障模式。

【生产实战层】（考察工程经验）
Q：在棕地（brownfield）项目中引入 OpenSpec 时，应该如何渐进式落地，避免一次性为整个存量系统补全 Spec？
A：不需要一次性补全所有历史模块的 Spec；可以从下一个要做的功能开始写第一个 Change Proposal，随着 Change 被陆续归档，Spec 会"有机生长"出对应模块的内容。对于历史遗留但暂不改动的模块，可以保持 Spec 缺失，等到真正要改它的时候再补，这正是官方"brownfield-first"哲学的体现。
考察意图：考察候选人是否理解"brownfield-first"在实际落地中的路径，而非教条式认为"必须先补全全部文档才能开始使用工具"。

Q：团队多人并行开发时，如何预防并应对 Delta Spec 合并冲突？
A：预防层面，在 proposal.md 阶段明确写清楚 in scope / out of scope，提前沟通减少多个 Change 触碰同一 Requirement 的概率，并定期执行 openspec validate --all 做静态扫描；应急层面，由于 OpenSpec 不支持自动三方语义合并，出现冲突时需要人工判断保留哪个版本，或者重新拆分变更范围后再分别归档。
考察意图：考察候选人是否有真实的多人协作经验，能否同时给出预防和应急两层方案，而不只是停留在理论层面。

参考资料

官方文档：
- GitHub 仓库：https://github.com/Fission-AI/OpenSpec
- Concepts（核心概念）：https://github.com/Fission-AI/OpenSpec/blob/main/docs/concepts.md
- CLI 参考：https://github.com/Fission-AI/OpenSpec/blob/main/docs/cli.md
- Commands（Slash 命令参考）：https://github.com/Fission-AI/OpenSpec/blob/main/docs/commands.md
- Getting Started：https://github.com/Fission-AI/OpenSpec/blob/main/docs/getting-started.md
- Supported Tools：https://github.com/Fission-AI/OpenSpec/blob/main/docs/supported-tools.md
- 官网：https://openspec.dev/

核心源码：
- 仓库根目录（TypeScript 实现）：https://github.com/Fission-AI/OpenSpec/tree/main/src
- CHANGELOG：https://github.com/Fission-AI/OpenSpec/blob/main/CHANGELOG.md

延伸阅读：
- GitHub 官方博客《Spec-driven development with AI》（介绍同类工具 Spec Kit 及 SDD 理念背景）：
  https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/
- Awesome OpenSpec 社区资源列表：https://github.com/wearetechnative/awesome-openspec

如有纰漏，欢迎指正！