OpenSpec02-辅助命令

坐吃山猪2026-11-12 13:18

OpenSpec02-辅助命令

1-找一个功能性的项目-Nimbus Salvagers云海拾荒者-纯前端项目：https://gitee.com/enzoism/ai_game_nimubs

2-上集回顾-OpenSpec01常用命令：OpenSpec 的 3 个核心命令，对应一个变更的完整生命周期

复制代码 
Propose（提案） → Apply（执行） → Archive（归档）

/opsx:propose 添加暗黑模式支持，用户可以切换深色/浅色主题 -> AI 会创建变更目录并生成全部规划产物
    openspec/changes/add-dark-mode/
    ├── proposal.md    # 为什么做 & 做什么 & 验收标准
    ├── specs/         # 需求 & 验收场景（Delta 增量规范）
    ├── design.md      # 技术实现方案
    └── tasks.md       # 实现任务清单（带复选框）
/opsx:apply		-> AI 读取 `tasks.md` 逐个完成任务、写代码，每完成一项自动勾选 `[x]`，中断后可恢复
/opsx:archive  -> 完成后归档变更，Delta 规范会合并进主规范目录 `openspec/specs/`，变更目录移入 `changes/archive/`

3-本集内容-3个辅助命令：它们不直接写一行实现代码，负责生命周期里「想清楚（前）、改方案（中）、先同步（后）」三件事

复制代码 
/opsx:explore	-> 进入思考模式：读代码库、讨论方案、画图对比；只思考不实现，想清楚后再 /opsx:propose
/opsx:update	-> 修订已有规划产物 proposal/specs/design/tasks 并保持四件套一致；只改文档、永不改代码，改完再 /opsx:apply
/opsx:sync		-> 把变更目录的 Delta 规范智能合并进主规范 openspec/specs/，变更保持 active 不归档

4-OpenSpec指令使用对象：

  • 三个辅助命令和三个核心命令一样，都是 openspec init 默认生成的 command（本项目 .claude/commands/opsx/ 下共 6 个：apply、archive、explore、propose、sync、update），无需开启扩展 profile
  • 三者的 frontmatter 都带 Experimental（实验性）标记，且 allowed-tools 都是 Bash(openspec:*) ------ 它们对系统的影响力全部来自 openspec CLI

5-：OpenSpec对比sync和archive： /opsx:archive = /opsx:sync + 变更目录移入 changes/archive/

archive 内部就是先 inline 执行同一套「Delta → 主规范」同步逻辑，然后再移目录结束变更

### 文章目录

  • [OpenSpec02-辅助命令](#文章目录 OpenSpec02-辅助命令 @[toc] 1-三个辅助命令总结 1. 总览对比表 2. 在生命周期中的位置 3. 它们底层调用的 CLI 4. 三个共同点 2-探索命令explore详解 1. 是什么 2. 最重要的红线：只思考，不实现 3. 输入可以是什么 4. 它会做的五类事 5. 它对 OpenSpec 的感知 6. 讨论中产生结论怎么办：只提议，不自动写入 7. 什么时候结束 8. Guardrails 红线清单 3-更新命令update详解 1. 是什么 2. 两种触发方式 3. 工作步骤 4. 绝对红线 5. Update vs 重新开一个变更（关键启发式） 6. 下一步指引（只指路，不代跑） 7. 典型使用场景 4-同步命令sync详解 1. 是什么 2. 和 archive 的关系（本篇核心对比） 3. 四种 Delta 操作怎么合 4. 智能合并三原则 5. 执行流程 6. 什么时候用 sync 而不是等 archive 5-对比总结与实战建议 1. 三命令大对比 2. 四个易混淆点 3. 实战建议)
  • [@toc](#文章目录 OpenSpec02-辅助命令 @[toc] 1-三个辅助命令总结 1. 总览对比表 2. 在生命周期中的位置 3. 它们底层调用的 CLI 4. 三个共同点 2-探索命令explore详解 1. 是什么 2. 最重要的红线：只思考，不实现 3. 输入可以是什么 4. 它会做的五类事 5. 它对 OpenSpec 的感知 6. 讨论中产生结论怎么办：只提议，不自动写入 7. 什么时候结束 8. Guardrails 红线清单 3-更新命令update详解 1. 是什么 2. 两种触发方式 3. 工作步骤 4. 绝对红线 5. Update vs 重新开一个变更（关键启发式） 6. 下一步指引（只指路，不代跑） 7. 典型使用场景 4-同步命令sync详解 1. 是什么 2. 和 archive 的关系（本篇核心对比） 3. 四种 Delta 操作怎么合 4. 智能合并三原则 5. 执行流程 6. 什么时候用 sync 而不是等 archive 5-对比总结与实战建议 1. 三命令大对比 2. 四个易混淆点 3. 实战建议)
  • [1-三个辅助命令总结](#文章目录 OpenSpec02-辅助命令 @[toc] 1-三个辅助命令总结 1. 总览对比表 2. 在生命周期中的位置 3. 它们底层调用的 CLI 4. 三个共同点 2-探索命令explore详解 1. 是什么 2. 最重要的红线：只思考，不实现 3. 输入可以是什么 4. 它会做的五类事 5. 它对 OpenSpec 的感知 6. 讨论中产生结论怎么办：只提议，不自动写入 7. 什么时候结束 8. Guardrails 红线清单 3-更新命令update详解 1. 是什么 2. 两种触发方式 3. 工作步骤 4. 绝对红线 5. Update vs 重新开一个变更（关键启发式） 6. 下一步指引（只指路，不代跑） 7. 典型使用场景 4-同步命令sync详解 1. 是什么 2. 和 archive 的关系（本篇核心对比） 3. 四种 Delta 操作怎么合 4. 智能合并三原则 5. 执行流程 6. 什么时候用 sync 而不是等 archive 5-对比总结与实战建议 1. 三命令大对比 2. 四个易混淆点 3. 实战建议)
  • [1. 总览对比表](#文章目录 OpenSpec02-辅助命令 @[toc] 1-三个辅助命令总结 1. 总览对比表 2. 在生命周期中的位置 3. 它们底层调用的 CLI 4. 三个共同点 2-探索命令explore详解 1. 是什么 2. 最重要的红线：只思考，不实现 3. 输入可以是什么 4. 它会做的五类事 5. 它对 OpenSpec 的感知 6. 讨论中产生结论怎么办：只提议，不自动写入 7. 什么时候结束 8. Guardrails 红线清单 3-更新命令update详解 1. 是什么 2. 两种触发方式 3. 工作步骤 4. 绝对红线 5. Update vs 重新开一个变更（关键启发式） 6. 下一步指引（只指路，不代跑） 7. 典型使用场景 4-同步命令sync详解 1. 是什么 2. 和 archive 的关系（本篇核心对比） 3. 四种 Delta 操作怎么合 4. 智能合并三原则 5. 执行流程 6. 什么时候用 sync 而不是等 archive 5-对比总结与实战建议 1. 三命令大对比 2. 四个易混淆点 3. 实战建议)
  • [2. 在生命周期中的位置](#文章目录 OpenSpec02-辅助命令 @[toc] 1-三个辅助命令总结 1. 总览对比表 2. 在生命周期中的位置 3. 它们底层调用的 CLI 4. 三个共同点 2-探索命令explore详解 1. 是什么 2. 最重要的红线：只思考，不实现 3. 输入可以是什么 4. 它会做的五类事 5. 它对 OpenSpec 的感知 6. 讨论中产生结论怎么办：只提议，不自动写入 7. 什么时候结束 8. Guardrails 红线清单 3-更新命令update详解 1. 是什么 2. 两种触发方式 3. 工作步骤 4. 绝对红线 5. Update vs 重新开一个变更（关键启发式） 6. 下一步指引（只指路，不代跑） 7. 典型使用场景 4-同步命令sync详解 1. 是什么 2. 和 archive 的关系（本篇核心对比） 3. 四种 Delta 操作怎么合 4. 智能合并三原则 5. 执行流程 6. 什么时候用 sync 而不是等 archive 5-对比总结与实战建议 1. 三命令大对比 2. 四个易混淆点 3. 实战建议)
  • [3. 它们底层调用的 CLI](#文章目录 OpenSpec02-辅助命令 @[toc] 1-三个辅助命令总结 1. 总览对比表 2. 在生命周期中的位置 3. 它们底层调用的 CLI 4. 三个共同点 2-探索命令explore详解 1. 是什么 2. 最重要的红线：只思考，不实现 3. 输入可以是什么 4. 它会做的五类事 5. 它对 OpenSpec 的感知 6. 讨论中产生结论怎么办：只提议，不自动写入 7. 什么时候结束 8. Guardrails 红线清单 3-更新命令update详解 1. 是什么 2. 两种触发方式 3. 工作步骤 4. 绝对红线 5. Update vs 重新开一个变更（关键启发式） 6. 下一步指引（只指路，不代跑） 7. 典型使用场景 4-同步命令sync详解 1. 是什么 2. 和 archive 的关系（本篇核心对比） 3. 四种 Delta 操作怎么合 4. 智能合并三原则 5. 执行流程 6. 什么时候用 sync 而不是等 archive 5-对比总结与实战建议 1. 三命令大对比 2. 四个易混淆点 3. 实战建议)
  • [4. 三个共同点](#文章目录 OpenSpec02-辅助命令 @[toc] 1-三个辅助命令总结 1. 总览对比表 2. 在生命周期中的位置 3. 它们底层调用的 CLI 4. 三个共同点 2-探索命令explore详解 1. 是什么 2. 最重要的红线：只思考，不实现 3. 输入可以是什么 4. 它会做的五类事 5. 它对 OpenSpec 的感知 6. 讨论中产生结论怎么办：只提议，不自动写入 7. 什么时候结束 8. Guardrails 红线清单 3-更新命令update详解 1. 是什么 2. 两种触发方式 3. 工作步骤 4. 绝对红线 5. Update vs 重新开一个变更（关键启发式） 6. 下一步指引（只指路，不代跑） 7. 典型使用场景 4-同步命令sync详解 1. 是什么 2. 和 archive 的关系（本篇核心对比） 3. 四种 Delta 操作怎么合 4. 智能合并三原则 5. 执行流程 6. 什么时候用 sync 而不是等 archive 5-对比总结与实战建议 1. 三命令大对比 2. 四个易混淆点 3. 实战建议)
  • [2-探索命令explore详解](#文章目录 OpenSpec02-辅助命令 @[toc] 1-三个辅助命令总结 1. 总览对比表 2. 在生命周期中的位置 3. 它们底层调用的 CLI 4. 三个共同点 2-探索命令explore详解 1. 是什么 2. 最重要的红线：只思考，不实现 3. 输入可以是什么 4. 它会做的五类事 5. 它对 OpenSpec 的感知 6. 讨论中产生结论怎么办：只提议，不自动写入 7. 什么时候结束 8. Guardrails 红线清单 3-更新命令update详解 1. 是什么 2. 两种触发方式 3. 工作步骤 4. 绝对红线 5. Update vs 重新开一个变更（关键启发式） 6. 下一步指引（只指路，不代跑） 7. 典型使用场景 4-同步命令sync详解 1. 是什么 2. 和 archive 的关系（本篇核心对比） 3. 四种 Delta 操作怎么合 4. 智能合并三原则 5. 执行流程 6. 什么时候用 sync 而不是等 archive 5-对比总结与实战建议 1. 三命令大对比 2. 四个易混淆点 3. 实战建议)
  • [1. 是什么](#文章目录 OpenSpec02-辅助命令 @[toc] 1-三个辅助命令总结 1. 总览对比表 2. 在生命周期中的位置 3. 它们底层调用的 CLI 4. 三个共同点 2-探索命令explore详解 1. 是什么 2. 最重要的红线：只思考，不实现 3. 输入可以是什么 4. 它会做的五类事 5. 它对 OpenSpec 的感知 6. 讨论中产生结论怎么办：只提议，不自动写入 7. 什么时候结束 8. Guardrails 红线清单 3-更新命令update详解 1. 是什么 2. 两种触发方式 3. 工作步骤 4. 绝对红线 5. Update vs 重新开一个变更（关键启发式） 6. 下一步指引（只指路，不代跑） 7. 典型使用场景 4-同步命令sync详解 1. 是什么 2. 和 archive 的关系（本篇核心对比） 3. 四种 Delta 操作怎么合 4. 智能合并三原则 5. 执行流程 6. 什么时候用 sync 而不是等 archive 5-对比总结与实战建议 1. 三命令大对比 2. 四个易混淆点 3. 实战建议)
  • [2. 最重要的红线：只思考，不实现](#文章目录 OpenSpec02-辅助命令 @[toc] 1-三个辅助命令总结 1. 总览对比表 2. 在生命周期中的位置 3. 它们底层调用的 CLI 4. 三个共同点 2-探索命令explore详解 1. 是什么 2. 最重要的红线：只思考，不实现 3. 输入可以是什么 4. 它会做的五类事 5. 它对 OpenSpec 的感知 6. 讨论中产生结论怎么办：只提议，不自动写入 7. 什么时候结束 8. Guardrails 红线清单 3-更新命令update详解 1. 是什么 2. 两种触发方式 3. 工作步骤 4. 绝对红线 5. Update vs 重新开一个变更（关键启发式） 6. 下一步指引（只指路，不代跑） 7. 典型使用场景 4-同步命令sync详解 1. 是什么 2. 和 archive 的关系（本篇核心对比） 3. 四种 Delta 操作怎么合 4. 智能合并三原则 5. 执行流程 6. 什么时候用 sync 而不是等 archive 5-对比总结与实战建议 1. 三命令大对比 2. 四个易混淆点 3. 实战建议)
  • [3. 输入可以是什么](#文章目录 OpenSpec02-辅助命令 @[toc] 1-三个辅助命令总结 1. 总览对比表 2. 在生命周期中的位置 3. 它们底层调用的 CLI 4. 三个共同点 2-探索命令explore详解 1. 是什么 2. 最重要的红线：只思考，不实现 3. 输入可以是什么 4. 它会做的五类事 5. 它对 OpenSpec 的感知 6. 讨论中产生结论怎么办：只提议，不自动写入 7. 什么时候结束 8. Guardrails 红线清单 3-更新命令update详解 1. 是什么 2. 两种触发方式 3. 工作步骤 4. 绝对红线 5. Update vs 重新开一个变更（关键启发式） 6. 下一步指引（只指路，不代跑） 7. 典型使用场景 4-同步命令sync详解 1. 是什么 2. 和 archive 的关系（本篇核心对比） 3. 四种 Delta 操作怎么合 4. 智能合并三原则 5. 执行流程 6. 什么时候用 sync 而不是等 archive 5-对比总结与实战建议 1. 三命令大对比 2. 四个易混淆点 3. 实战建议)
  • [4. 它会做的五类事](#文章目录 OpenSpec02-辅助命令 @[toc] 1-三个辅助命令总结 1. 总览对比表 2. 在生命周期中的位置 3. 它们底层调用的 CLI 4. 三个共同点 2-探索命令explore详解 1. 是什么 2. 最重要的红线：只思考，不实现 3. 输入可以是什么 4. 它会做的五类事 5. 它对 OpenSpec 的感知 6. 讨论中产生结论怎么办：只提议，不自动写入 7. 什么时候结束 8. Guardrails 红线清单 3-更新命令update详解 1. 是什么 2. 两种触发方式 3. 工作步骤 4. 绝对红线 5. Update vs 重新开一个变更（关键启发式） 6. 下一步指引（只指路，不代跑） 7. 典型使用场景 4-同步命令sync详解 1. 是什么 2. 和 archive 的关系（本篇核心对比） 3. 四种 Delta 操作怎么合 4. 智能合并三原则 5. 执行流程 6. 什么时候用 sync 而不是等 archive 5-对比总结与实战建议 1. 三命令大对比 2. 四个易混淆点 3. 实战建议)
  • [5. 它对 OpenSpec 的感知](#文章目录 OpenSpec02-辅助命令 @[toc] 1-三个辅助命令总结 1. 总览对比表 2. 在生命周期中的位置 3. 它们底层调用的 CLI 4. 三个共同点 2-探索命令explore详解 1. 是什么 2. 最重要的红线：只思考，不实现 3. 输入可以是什么 4. 它会做的五类事 5. 它对 OpenSpec 的感知 6. 讨论中产生结论怎么办：只提议，不自动写入 7. 什么时候结束 8. Guardrails 红线清单 3-更新命令update详解 1. 是什么 2. 两种触发方式 3. 工作步骤 4. 绝对红线 5. Update vs 重新开一个变更（关键启发式） 6. 下一步指引（只指路，不代跑） 7. 典型使用场景 4-同步命令sync详解 1. 是什么 2. 和 archive 的关系（本篇核心对比） 3. 四种 Delta 操作怎么合 4. 智能合并三原则 5. 执行流程 6. 什么时候用 sync 而不是等 archive 5-对比总结与实战建议 1. 三命令大对比 2. 四个易混淆点 3. 实战建议)
  • [6. 讨论中产生结论怎么办：只提议，不自动写入](#文章目录 OpenSpec02-辅助命令 @[toc] 1-三个辅助命令总结 1. 总览对比表 2. 在生命周期中的位置 3. 它们底层调用的 CLI 4. 三个共同点 2-探索命令explore详解 1. 是什么 2. 最重要的红线：只思考，不实现 3. 输入可以是什么 4. 它会做的五类事 5. 它对 OpenSpec 的感知 6. 讨论中产生结论怎么办：只提议，不自动写入 7. 什么时候结束 8. Guardrails 红线清单 3-更新命令update详解 1. 是什么 2. 两种触发方式 3. 工作步骤 4. 绝对红线 5. Update vs 重新开一个变更（关键启发式） 6. 下一步指引（只指路，不代跑） 7. 典型使用场景 4-同步命令sync详解 1. 是什么 2. 和 archive 的关系（本篇核心对比） 3. 四种 Delta 操作怎么合 4. 智能合并三原则 5. 执行流程 6. 什么时候用 sync 而不是等 archive 5-对比总结与实战建议 1. 三命令大对比 2. 四个易混淆点 3. 实战建议)
  • [7. 什么时候结束](#文章目录 OpenSpec02-辅助命令 @[toc] 1-三个辅助命令总结 1. 总览对比表 2. 在生命周期中的位置 3. 它们底层调用的 CLI 4. 三个共同点 2-探索命令explore详解 1. 是什么 2. 最重要的红线：只思考，不实现 3. 输入可以是什么 4. 它会做的五类事 5. 它对 OpenSpec 的感知 6. 讨论中产生结论怎么办：只提议，不自动写入 7. 什么时候结束 8. Guardrails 红线清单 3-更新命令update详解 1. 是什么 2. 两种触发方式 3. 工作步骤 4. 绝对红线 5. Update vs 重新开一个变更（关键启发式） 6. 下一步指引（只指路，不代跑） 7. 典型使用场景 4-同步命令sync详解 1. 是什么 2. 和 archive 的关系（本篇核心对比） 3. 四种 Delta 操作怎么合 4. 智能合并三原则 5. 执行流程 6. 什么时候用 sync 而不是等 archive 5-对比总结与实战建议 1. 三命令大对比 2. 四个易混淆点 3. 实战建议)
  • [8. Guardrails 红线清单](#文章目录 OpenSpec02-辅助命令 @[toc] 1-三个辅助命令总结 1. 总览对比表 2. 在生命周期中的位置 3. 它们底层调用的 CLI 4. 三个共同点 2-探索命令explore详解 1. 是什么 2. 最重要的红线：只思考，不实现 3. 输入可以是什么 4. 它会做的五类事 5. 它对 OpenSpec 的感知 6. 讨论中产生结论怎么办：只提议，不自动写入 7. 什么时候结束 8. Guardrails 红线清单 3-更新命令update详解 1. 是什么 2. 两种触发方式 3. 工作步骤 4. 绝对红线 5. Update vs 重新开一个变更（关键启发式） 6. 下一步指引（只指路，不代跑） 7. 典型使用场景 4-同步命令sync详解 1. 是什么 2. 和 archive 的关系（本篇核心对比） 3. 四种 Delta 操作怎么合 4. 智能合并三原则 5. 执行流程 6. 什么时候用 sync 而不是等 archive 5-对比总结与实战建议 1. 三命令大对比 2. 四个易混淆点 3. 实战建议)
  • [3-更新命令update详解](#文章目录 OpenSpec02-辅助命令 @[toc] 1-三个辅助命令总结 1. 总览对比表 2. 在生命周期中的位置 3. 它们底层调用的 CLI 4. 三个共同点 2-探索命令explore详解 1. 是什么 2. 最重要的红线：只思考，不实现 3. 输入可以是什么 4. 它会做的五类事 5. 它对 OpenSpec 的感知 6. 讨论中产生结论怎么办：只提议，不自动写入 7. 什么时候结束 8. Guardrails 红线清单 3-更新命令update详解 1. 是什么 2. 两种触发方式 3. 工作步骤 4. 绝对红线 5. Update vs 重新开一个变更（关键启发式） 6. 下一步指引（只指路，不代跑） 7. 典型使用场景 4-同步命令sync详解 1. 是什么 2. 和 archive 的关系（本篇核心对比） 3. 四种 Delta 操作怎么合 4. 智能合并三原则 5. 执行流程 6. 什么时候用 sync 而不是等 archive 5-对比总结与实战建议 1. 三命令大对比 2. 四个易混淆点 3. 实战建议)
  • [1. 是什么](#文章目录 OpenSpec02-辅助命令 @[toc] 1-三个辅助命令总结 1. 总览对比表 2. 在生命周期中的位置 3. 它们底层调用的 CLI 4. 三个共同点 2-探索命令explore详解 1. 是什么 2. 最重要的红线：只思考，不实现 3. 输入可以是什么 4. 它会做的五类事 5. 它对 OpenSpec 的感知 6. 讨论中产生结论怎么办：只提议，不自动写入 7. 什么时候结束 8. Guardrails 红线清单 3-更新命令update详解 1. 是什么 2. 两种触发方式 3. 工作步骤 4. 绝对红线 5. Update vs 重新开一个变更（关键启发式） 6. 下一步指引（只指路，不代跑） 7. 典型使用场景 4-同步命令sync详解 1. 是什么 2. 和 archive 的关系（本篇核心对比） 3. 四种 Delta 操作怎么合 4. 智能合并三原则 5. 执行流程 6. 什么时候用 sync 而不是等 archive 5-对比总结与实战建议 1. 三命令大对比 2. 四个易混淆点 3. 实战建议)
  • [2. 两种触发方式](#文章目录 OpenSpec02-辅助命令 @[toc] 1-三个辅助命令总结 1. 总览对比表 2. 在生命周期中的位置 3. 它们底层调用的 CLI 4. 三个共同点 2-探索命令explore详解 1. 是什么 2. 最重要的红线：只思考，不实现 3. 输入可以是什么 4. 它会做的五类事 5. 它对 OpenSpec 的感知 6. 讨论中产生结论怎么办：只提议，不自动写入 7. 什么时候结束 8. Guardrails 红线清单 3-更新命令update详解 1. 是什么 2. 两种触发方式 3. 工作步骤 4. 绝对红线 5. Update vs 重新开一个变更（关键启发式） 6. 下一步指引（只指路，不代跑） 7. 典型使用场景 4-同步命令sync详解 1. 是什么 2. 和 archive 的关系（本篇核心对比） 3. 四种 Delta 操作怎么合 4. 智能合并三原则 5. 执行流程 6. 什么时候用 sync 而不是等 archive 5-对比总结与实战建议 1. 三命令大对比 2. 四个易混淆点 3. 实战建议)
  • [3. 工作步骤](#文章目录 OpenSpec02-辅助命令 @[toc] 1-三个辅助命令总结 1. 总览对比表 2. 在生命周期中的位置 3. 它们底层调用的 CLI 4. 三个共同点 2-探索命令explore详解 1. 是什么 2. 最重要的红线：只思考，不实现 3. 输入可以是什么 4. 它会做的五类事 5. 它对 OpenSpec 的感知 6. 讨论中产生结论怎么办：只提议，不自动写入 7. 什么时候结束 8. Guardrails 红线清单 3-更新命令update详解 1. 是什么 2. 两种触发方式 3. 工作步骤 4. 绝对红线 5. Update vs 重新开一个变更（关键启发式） 6. 下一步指引（只指路，不代跑） 7. 典型使用场景 4-同步命令sync详解 1. 是什么 2. 和 archive 的关系（本篇核心对比） 3. 四种 Delta 操作怎么合 4. 智能合并三原则 5. 执行流程 6. 什么时候用 sync 而不是等 archive 5-对比总结与实战建议 1. 三命令大对比 2. 四个易混淆点 3. 实战建议)
  • [4. 绝对红线](#文章目录 OpenSpec02-辅助命令 @[toc] 1-三个辅助命令总结 1. 总览对比表 2. 在生命周期中的位置 3. 它们底层调用的 CLI 4. 三个共同点 2-探索命令explore详解 1. 是什么 2. 最重要的红线：只思考，不实现 3. 输入可以是什么 4. 它会做的五类事 5. 它对 OpenSpec 的感知 6. 讨论中产生结论怎么办：只提议，不自动写入 7. 什么时候结束 8. Guardrails 红线清单 3-更新命令update详解 1. 是什么 2. 两种触发方式 3. 工作步骤 4. 绝对红线 5. Update vs 重新开一个变更（关键启发式） 6. 下一步指引（只指路，不代跑） 7. 典型使用场景 4-同步命令sync详解 1. 是什么 2. 和 archive 的关系（本篇核心对比） 3. 四种 Delta 操作怎么合 4. 智能合并三原则 5. 执行流程 6. 什么时候用 sync 而不是等 archive 5-对比总结与实战建议 1. 三命令大对比 2. 四个易混淆点 3. 实战建议)
  • [5. Update vs 重新开一个变更（关键启发式）](#文章目录 OpenSpec02-辅助命令 @[toc] 1-三个辅助命令总结 1. 总览对比表 2. 在生命周期中的位置 3. 它们底层调用的 CLI 4. 三个共同点 2-探索命令explore详解 1. 是什么 2. 最重要的红线：只思考，不实现 3. 输入可以是什么 4. 它会做的五类事 5. 它对 OpenSpec 的感知 6. 讨论中产生结论怎么办：只提议，不自动写入 7. 什么时候结束 8. Guardrails 红线清单 3-更新命令update详解 1. 是什么 2. 两种触发方式 3. 工作步骤 4. 绝对红线 5. Update vs 重新开一个变更（关键启发式） 6. 下一步指引（只指路，不代跑） 7. 典型使用场景 4-同步命令sync详解 1. 是什么 2. 和 archive 的关系（本篇核心对比） 3. 四种 Delta 操作怎么合 4. 智能合并三原则 5. 执行流程 6. 什么时候用 sync 而不是等 archive 5-对比总结与实战建议 1. 三命令大对比 2. 四个易混淆点 3. 实战建议)
  • [6. 下一步指引（只指路，不代跑）](#文章目录 OpenSpec02-辅助命令 @[toc] 1-三个辅助命令总结 1. 总览对比表 2. 在生命周期中的位置 3. 它们底层调用的 CLI 4. 三个共同点 2-探索命令explore详解 1. 是什么 2. 最重要的红线：只思考，不实现 3. 输入可以是什么 4. 它会做的五类事 5. 它对 OpenSpec 的感知 6. 讨论中产生结论怎么办：只提议，不自动写入 7. 什么时候结束 8. Guardrails 红线清单 3-更新命令update详解 1. 是什么 2. 两种触发方式 3. 工作步骤 4. 绝对红线 5. Update vs 重新开一个变更（关键启发式） 6. 下一步指引（只指路，不代跑） 7. 典型使用场景 4-同步命令sync详解 1. 是什么 2. 和 archive 的关系（本篇核心对比） 3. 四种 Delta 操作怎么合 4. 智能合并三原则 5. 执行流程 6. 什么时候用 sync 而不是等 archive 5-对比总结与实战建议 1. 三命令大对比 2. 四个易混淆点 3. 实战建议)
  • [7. 典型使用场景](#文章目录 OpenSpec02-辅助命令 @[toc] 1-三个辅助命令总结 1. 总览对比表 2. 在生命周期中的位置 3. 它们底层调用的 CLI 4. 三个共同点 2-探索命令explore详解 1. 是什么 2. 最重要的红线：只思考，不实现 3. 输入可以是什么 4. 它会做的五类事 5. 它对 OpenSpec 的感知 6. 讨论中产生结论怎么办：只提议，不自动写入 7. 什么时候结束 8. Guardrails 红线清单 3-更新命令update详解 1. 是什么 2. 两种触发方式 3. 工作步骤 4. 绝对红线 5. Update vs 重新开一个变更（关键启发式） 6. 下一步指引（只指路，不代跑） 7. 典型使用场景 4-同步命令sync详解 1. 是什么 2. 和 archive 的关系（本篇核心对比） 3. 四种 Delta 操作怎么合 4. 智能合并三原则 5. 执行流程 6. 什么时候用 sync 而不是等 archive 5-对比总结与实战建议 1. 三命令大对比 2. 四个易混淆点 3. 实战建议)
  • [4-同步命令sync详解](#文章目录 OpenSpec02-辅助命令 @[toc] 1-三个辅助命令总结 1. 总览对比表 2. 在生命周期中的位置 3. 它们底层调用的 CLI 4. 三个共同点 2-探索命令explore详解 1. 是什么 2. 最重要的红线：只思考，不实现 3. 输入可以是什么 4. 它会做的五类事 5. 它对 OpenSpec 的感知 6. 讨论中产生结论怎么办：只提议，不自动写入 7. 什么时候结束 8. Guardrails 红线清单 3-更新命令update详解 1. 是什么 2. 两种触发方式 3. 工作步骤 4. 绝对红线 5. Update vs 重新开一个变更（关键启发式） 6. 下一步指引（只指路，不代跑） 7. 典型使用场景 4-同步命令sync详解 1. 是什么 2. 和 archive 的关系（本篇核心对比） 3. 四种 Delta 操作怎么合 4. 智能合并三原则 5. 执行流程 6. 什么时候用 sync 而不是等 archive 5-对比总结与实战建议 1. 三命令大对比 2. 四个易混淆点 3. 实战建议)
  • [1. 是什么](#文章目录 OpenSpec02-辅助命令 @[toc] 1-三个辅助命令总结 1. 总览对比表 2. 在生命周期中的位置 3. 它们底层调用的 CLI 4. 三个共同点 2-探索命令explore详解 1. 是什么 2. 最重要的红线：只思考，不实现 3. 输入可以是什么 4. 它会做的五类事 5. 它对 OpenSpec 的感知 6. 讨论中产生结论怎么办：只提议，不自动写入 7. 什么时候结束 8. Guardrails 红线清单 3-更新命令update详解 1. 是什么 2. 两种触发方式 3. 工作步骤 4. 绝对红线 5. Update vs 重新开一个变更（关键启发式） 6. 下一步指引（只指路，不代跑） 7. 典型使用场景 4-同步命令sync详解 1. 是什么 2. 和 archive 的关系（本篇核心对比） 3. 四种 Delta 操作怎么合 4. 智能合并三原则 5. 执行流程 6. 什么时候用 sync 而不是等 archive 5-对比总结与实战建议 1. 三命令大对比 2. 四个易混淆点 3. 实战建议)
  • [2. 和 archive 的关系（本篇核心对比）](#文章目录 OpenSpec02-辅助命令 @[toc] 1-三个辅助命令总结 1. 总览对比表 2. 在生命周期中的位置 3. 它们底层调用的 CLI 4. 三个共同点 2-探索命令explore详解 1. 是什么 2. 最重要的红线：只思考，不实现 3. 输入可以是什么 4. 它会做的五类事 5. 它对 OpenSpec 的感知 6. 讨论中产生结论怎么办：只提议，不自动写入 7. 什么时候结束 8. Guardrails 红线清单 3-更新命令update详解 1. 是什么 2. 两种触发方式 3. 工作步骤 4. 绝对红线 5. Update vs 重新开一个变更（关键启发式） 6. 下一步指引（只指路，不代跑） 7. 典型使用场景 4-同步命令sync详解 1. 是什么 2. 和 archive 的关系（本篇核心对比） 3. 四种 Delta 操作怎么合 4. 智能合并三原则 5. 执行流程 6. 什么时候用 sync 而不是等 archive 5-对比总结与实战建议 1. 三命令大对比 2. 四个易混淆点 3. 实战建议)
  • [3. 四种 Delta 操作怎么合](#文章目录 OpenSpec02-辅助命令 @[toc] 1-三个辅助命令总结 1. 总览对比表 2. 在生命周期中的位置 3. 它们底层调用的 CLI 4. 三个共同点 2-探索命令explore详解 1. 是什么 2. 最重要的红线：只思考，不实现 3. 输入可以是什么 4. 它会做的五类事 5. 它对 OpenSpec 的感知 6. 讨论中产生结论怎么办：只提议，不自动写入 7. 什么时候结束 8. Guardrails 红线清单 3-更新命令update详解 1. 是什么 2. 两种触发方式 3. 工作步骤 4. 绝对红线 5. Update vs 重新开一个变更（关键启发式） 6. 下一步指引（只指路，不代跑） 7. 典型使用场景 4-同步命令sync详解 1. 是什么 2. 和 archive 的关系（本篇核心对比） 3. 四种 Delta 操作怎么合 4. 智能合并三原则 5. 执行流程 6. 什么时候用 sync 而不是等 archive 5-对比总结与实战建议 1. 三命令大对比 2. 四个易混淆点 3. 实战建议)
  • [4. 智能合并三原则](#文章目录 OpenSpec02-辅助命令 @[toc] 1-三个辅助命令总结 1. 总览对比表 2. 在生命周期中的位置 3. 它们底层调用的 CLI 4. 三个共同点 2-探索命令explore详解 1. 是什么 2. 最重要的红线：只思考，不实现 3. 输入可以是什么 4. 它会做的五类事 5. 它对 OpenSpec 的感知 6. 讨论中产生结论怎么办：只提议，不自动写入 7. 什么时候结束 8. Guardrails 红线清单 3-更新命令update详解 1. 是什么 2. 两种触发方式 3. 工作步骤 4. 绝对红线 5. Update vs 重新开一个变更（关键启发式） 6. 下一步指引（只指路，不代跑） 7. 典型使用场景 4-同步命令sync详解 1. 是什么 2. 和 archive 的关系（本篇核心对比） 3. 四种 Delta 操作怎么合 4. 智能合并三原则 5. 执行流程 6. 什么时候用 sync 而不是等 archive 5-对比总结与实战建议 1. 三命令大对比 2. 四个易混淆点 3. 实战建议)
  • [5. 执行流程](#文章目录 OpenSpec02-辅助命令 @[toc] 1-三个辅助命令总结 1. 总览对比表 2. 在生命周期中的位置 3. 它们底层调用的 CLI 4. 三个共同点 2-探索命令explore详解 1. 是什么 2. 最重要的红线：只思考，不实现 3. 输入可以是什么 4. 它会做的五类事 5. 它对 OpenSpec 的感知 6. 讨论中产生结论怎么办：只提议，不自动写入 7. 什么时候结束 8. Guardrails 红线清单 3-更新命令update详解 1. 是什么 2. 两种触发方式 3. 工作步骤 4. 绝对红线 5. Update vs 重新开一个变更（关键启发式） 6. 下一步指引（只指路，不代跑） 7. 典型使用场景 4-同步命令sync详解 1. 是什么 2. 和 archive 的关系（本篇核心对比） 3. 四种 Delta 操作怎么合 4. 智能合并三原则 5. 执行流程 6. 什么时候用 sync 而不是等 archive 5-对比总结与实战建议 1. 三命令大对比 2. 四个易混淆点 3. 实战建议)
  • [6. 什么时候用 sync 而不是等 archive](#文章目录 OpenSpec02-辅助命令 @[toc] 1-三个辅助命令总结 1. 总览对比表 2. 在生命周期中的位置 3. 它们底层调用的 CLI 4. 三个共同点 2-探索命令explore详解 1. 是什么 2. 最重要的红线：只思考，不实现 3. 输入可以是什么 4. 它会做的五类事 5. 它对 OpenSpec 的感知 6. 讨论中产生结论怎么办：只提议，不自动写入 7. 什么时候结束 8. Guardrails 红线清单 3-更新命令update详解 1. 是什么 2. 两种触发方式 3. 工作步骤 4. 绝对红线 5. Update vs 重新开一个变更（关键启发式） 6. 下一步指引（只指路，不代跑） 7. 典型使用场景 4-同步命令sync详解 1. 是什么 2. 和 archive 的关系（本篇核心对比） 3. 四种 Delta 操作怎么合 4. 智能合并三原则 5. 执行流程 6. 什么时候用 sync 而不是等 archive 5-对比总结与实战建议 1. 三命令大对比 2. 四个易混淆点 3. 实战建议)
  • [5-对比总结与实战建议](#文章目录 OpenSpec02-辅助命令 @[toc] 1-三个辅助命令总结 1. 总览对比表 2. 在生命周期中的位置 3. 它们底层调用的 CLI 4. 三个共同点 2-探索命令explore详解 1. 是什么 2. 最重要的红线：只思考，不实现 3. 输入可以是什么 4. 它会做的五类事 5. 它对 OpenSpec 的感知 6. 讨论中产生结论怎么办：只提议，不自动写入 7. 什么时候结束 8. Guardrails 红线清单 3-更新命令update详解 1. 是什么 2. 两种触发方式 3. 工作步骤 4. 绝对红线 5. Update vs 重新开一个变更（关键启发式） 6. 下一步指引（只指路，不代跑） 7. 典型使用场景 4-同步命令sync详解 1. 是什么 2. 和 archive 的关系（本篇核心对比） 3. 四种 Delta 操作怎么合 4. 智能合并三原则 5. 执行流程 6. 什么时候用 sync 而不是等 archive 5-对比总结与实战建议 1. 三命令大对比 2. 四个易混淆点 3. 实战建议)
  • [1. 三命令大对比](#文章目录 OpenSpec02-辅助命令 @[toc] 1-三个辅助命令总结 1. 总览对比表 2. 在生命周期中的位置 3. 它们底层调用的 CLI 4. 三个共同点 2-探索命令explore详解 1. 是什么 2. 最重要的红线：只思考，不实现 3. 输入可以是什么 4. 它会做的五类事 5. 它对 OpenSpec 的感知 6. 讨论中产生结论怎么办：只提议，不自动写入 7. 什么时候结束 8. Guardrails 红线清单 3-更新命令update详解 1. 是什么 2. 两种触发方式 3. 工作步骤 4. 绝对红线 5. Update vs 重新开一个变更（关键启发式） 6. 下一步指引（只指路，不代跑） 7. 典型使用场景 4-同步命令sync详解 1. 是什么 2. 和 archive 的关系（本篇核心对比） 3. 四种 Delta 操作怎么合 4. 智能合并三原则 5. 执行流程 6. 什么时候用 sync 而不是等 archive 5-对比总结与实战建议 1. 三命令大对比 2. 四个易混淆点 3. 实战建议)
  • [2. 四个易混淆点](#文章目录 OpenSpec02-辅助命令 @[toc] 1-三个辅助命令总结 1. 总览对比表 2. 在生命周期中的位置 3. 它们底层调用的 CLI 4. 三个共同点 2-探索命令explore详解 1. 是什么 2. 最重要的红线：只思考，不实现 3. 输入可以是什么 4. 它会做的五类事 5. 它对 OpenSpec 的感知 6. 讨论中产生结论怎么办：只提议，不自动写入 7. 什么时候结束 8. Guardrails 红线清单 3-更新命令update详解 1. 是什么 2. 两种触发方式 3. 工作步骤 4. 绝对红线 5. Update vs 重新开一个变更（关键启发式） 6. 下一步指引（只指路，不代跑） 7. 典型使用场景 4-同步命令sync详解 1. 是什么 2. 和 archive 的关系（本篇核心对比） 3. 四种 Delta 操作怎么合 4. 智能合并三原则 5. 执行流程 6. 什么时候用 sync 而不是等 archive 5-对比总结与实战建议 1. 三命令大对比 2. 四个易混淆点 3. 实战建议)
  • [3. 实战建议](#文章目录 OpenSpec02-辅助命令 @[toc] 1-三个辅助命令总结 1. 总览对比表 2. 在生命周期中的位置 3. 它们底层调用的 CLI 4. 三个共同点 2-探索命令explore详解 1. 是什么 2. 最重要的红线：只思考，不实现 3. 输入可以是什么 4. 它会做的五类事 5. 它对 OpenSpec 的感知 6. 讨论中产生结论怎么办：只提议，不自动写入 7. 什么时候结束 8. Guardrails 红线清单 3-更新命令update详解 1. 是什么 2. 两种触发方式 3. 工作步骤 4. 绝对红线 5. Update vs 重新开一个变更（关键启发式） 6. 下一步指引（只指路，不代跑） 7. 典型使用场景 4-同步命令sync详解 1. 是什么 2. 和 archive 的关系（本篇核心对比） 3. 四种 Delta 操作怎么合 4. 智能合并三原则 5. 执行流程 6. 什么时候用 sync 而不是等 archive 5-对比总结与实战建议 1. 三命令大对比 2. 四个易混淆点 3. 实战建议)

1-三个辅助命令总结

OpenSpec 的核心三步走解决「一个变更从提案到归档」的主线，这三个辅助命令补齐主线之外的三个真实需求：

  1. 动手前想不清楚 → /opsx:explore：先和 AI 把问题聊透、把代码库摸清，再决定要不要提案
  2. 执行中途方案要改 → /opsx:update：修订已生成的规划产物，并让四件套保持一致
  3. 规范想提前合并 → /opsx:sync：不等归档，先把 Delta 规范合入主规范

1. 总览对比表

命令 生命周期位置 做什么 写实现代码 改哪些文件
/opsx:explore propose 之前 / 任何时候 思考伙伴：读代码、讨论方案、画图、对比选项 ❌ 永不 默认不改；经你确认后可把结论捕获进变更产物
/opsx:update propose 之后、apply 前后 修订已有规划产物并做一致性对账 ❌ 永不 只改已存在的四件套文档（逐项确认后写入）
/opsx:sync archive 之前 / archive 内部 把 Delta 规范智能合并进主规范 ❌ 永不 只改 openspec/specs/ 下的主规范

2. 在生命周期中的位置

复制代码 
 想法 / 问题 / 技术选型
      |
      v  /opsx:explore   思考模式: 读代码 + 讨论 + 画图 (不写码)
 想清楚了
      |
      v  /opsx:propose  -->  openspec/changes/<name>/
      |                       proposal.md / specs/ / design.md / tasks.md
      |                          ^
      |  /opsx:apply             |  /opsx:update
      v  (逐任务写代码,勾选[x])  |  (中途改方案: 只改四件套文档)
 代码实现中 ---------------------+
      |
      |  /opsx:sync   Delta 合入 openspec/specs/ 主规范 (变更保持 active)
      v
 /opsx:archive   (= sync 合并规范 + 变更目录移入 changes/archive/)

3. 它们底层调用的 CLI

三个辅助命令本质都是「写给 Agent 的工作流脚本」，底层复用同一组 openspec 命令：

bash 复制代码 
openspec list --json                                          # 在途变更清单（三个命令都先看它）
openspec list --specs                                         # 已有能力（主规范）清单
openspec status --change "<name>" --json                      # 变更内产物状态与真实路径（update/sync 用）
openspec instructions "<artifact>" --change "<name>" --json   # 产物写作规则与模板（update 大改时取）
openspec validate --specs                                     # 校验主规范（sync 合并后必跑）
openspec new change "<name>"                                  # 只搭变更目录脚手架（explore 捕获结论时用）

4. 三个共同点

  1. 都不写实现代码：explore 红线是「思考不实现」，update 红线是「只改规划文档」，sync 只碰主规范
  2. 都以 openspec CLI 报告为准 ：不假设文件路径、不硬编码产物名，一切以 openspec status 返回的 JSON 为准
  3. 模糊时都会让你选目标变更：命令后面不带变更名时，能从上下文推断就用，只有一个在途变更就自动选中，否则列出清单让你挑

2-探索命令explore详解

1. 是什么

/opsx:explore 让 AI 进入 explore mode：一个思考伙伴，帮你把想法、问题、技术选型聊清楚。

官方定义里最关键的一句：This is a stance, not a workflow（这是一种姿态，不是一套流程）------没有固定步骤、没有规定顺序、没有必需产物，AI 跟着对话走，而不是拿着脚本跑。

2. 最重要的红线：只思考，不实现

  • ✅ 可以：读文件、搜代码、调查代码库、跑只读命令------这些不需要你确认
  • ❌ 绝不 ：写代码、实现功能。你让它实现时，它会明确说 explore mode 不做实现，并把你指向 /opsx:propose
  • ⚠️ 唯一例外 ：经你逐次确认后，AI 可以把讨论结论「捕获」进 OpenSpec 变更产物（proposal/design/specs/tasks）------这算记录思考，不算实现。且每次只覆盖你确认的范围，扩大范围要重新问

所以上集博客表格里写的 explore「不动任何文件」更准确的表述是：不写任何实现代码；写入变更产物需要你先 yes/no 确认。

3. 输入可以是什么

命令后面跟什么都可以，甚至不跟：

复制代码 
/opsx:explore 实时协作                      # 模糊想法
/opsx:explore 认证系统越来越乱了怎么办       # 具体问题
/opsx:explore add-dark-mode                 # 已有变更名（在该变更的上下文里探讨）
/opsx:explore postgres vs sqlite 怎么选      # 技术选型对比
/opsx:explore                               # 什么都不带，直接进入思考模式

4. 它会做的五类事

类别 具体动作
探索问题空间 澄清式提问、挑战假设、重新框定问题、找类比
调查代码库 画出相关架构、找集成点、识别现有模式、暴露隐藏复杂度
对比选项 头脑风暴多方案、做对比表、权衡利弊（你要求时给推荐）
可视化 大量使用 ASCII 图：系统图、状态机、数据流、依赖图
暴露风险与未知 指出哪里可能出错、哪里理解有缺口、建议先做哪些验证

5. 它对 OpenSpec 的感知

进入模式后 AI 会先摸清项目现状，再开始讨论：

bash 复制代码 
openspec list --json    # 有哪些在途变更（changes）、各自任务进度
openspec list --specs   # 项目已经声称具备哪些能力（主规范清单）

还会读取 openspec/config.yaml 里的 context（技术栈、约定、约束）作为讨论的边界。如果你点名叫了某个变更，它会读取该变更的 proposal/design/specs/tasks，在对话里自然引用，比如「你的 design 写的是用 Redis，但我们刚发现 SQLite 更合适......」。

6. 讨论中产生结论怎么办：只提议，不自动写入

探索过程中一旦形成决策，AI 会提议「要不要记下来」，由你决定：

讨论中产生的结论 AI 提议捕获到
发现了新需求 specs/<capability>/spec.md
需求发生了变化 specs/<capability>/spec.md
做出了设计决策 design.md
范围变了 proposal.md
发现了新的工作项 tasks.md
原有假设被推翻 对应的相关产物

如果此时还没有变更目录，你说「把这个讨论固化成一个变更」，AI 会执行 openspec new change "<name>" 先搭脚手架（绝不手工建目录，保证 .openspec.yaml 等元数据完整），再按依赖顺序生成你点名的产物。

7. 什么时候结束

没有规定的结局，探索可能：

  • 流进提案：「想清楚了？跑 /opsx:propose，这个讨论就变成一个变更」
  • 落成产物更新：「已把这些决策更新进 design.md」
  • 只是带来清晰：你想明白了，直接去干活
  • 以后再继续：随时可以接着聊

8. Guardrails 红线清单

  • 不实现：连改工作流配置（schema、模板、config.yaml）都算「变更」而非「思考」
  • 不假装理解：不清楚就深挖
  • 不赶时间：探索是思考时间，不是任务时间
  • 不强加结构：让模式自然浮现
  • 不自动捕获：只提议保存洞察，你点头才写
  • 该做的：多用图、多查代码库、多质疑假设（包括 AI 自己的）

3-更新命令update详解

1. 是什么

/opsx:update 修订一个变更已经存在的规划产物（proposal.md / specs/ / design.md / tasks.md），并让它们保持互相一致。

两条天条：

  • 只改已有的 ：它不负责创建缺失产物------创建是 /opsx:propose、/opsx:new、/opsx:continue 的活
  • 永不编辑代码 ：修订后的计划如果意味着代码要变，它会停下来，指向 /opsx:apply

2. 两种触发方式

复制代码 
/opsx:update design 改用 SQLite，不用 Redis 了    # ① 具体修改要求：这就是起点编辑
/opsx:update                                      # ② 泛泛一句：按「一致性审查」处理

第 ② 种时，AI 会通读四件套，互相对照找矛盾、缺口、重复，把发现的问题逐个提出来。如果你手改过 proposal.md，导致 design.md/tasks.md 跟它对不上了，这种审查正好救场。

3. 工作步骤

步骤 做什么
1 选定变更（带名/从上下文推断/只有一个自动选/列出最近修改的前 3-4 个让你挑）
2 openspec status --change "<name>" --json 拿到产物清单、状态与真实路径
3 理解你的请求：具体修改 or 一致性审查
4 读产物 + 对账：修改先在对话里起草，不落盘 ；并双向检查其余产物要不要跟着改
5 逐个产物向你确认，确认一个写一个；你拒绝的修订绝不写入
6 指路下一步（只给建议，绝不代跑）

步骤 4 的「双向检查」值得注意：不只是「改了 proposal → design 跟着改」这个正向，改了后面的产物也可能要回头改前面的。构建顺序只是阅读顺序，不是修改方向的约束。

4. 绝对红线

  • 只碰规划产物，永不碰实现代码
  • 只编辑 openspec status 报告的 existingOutputPaths 里真实存在的文件
  • skipped 状态的产物一律不动
  • 每一处修改都要先展示、后确认、再写入

5. Update vs 重新开一个变更（关键启发式）

这是使用 /opsx:update 最重要的一条判断：

  • 修订是细化 （方案怎么实现的细节变了）→ 用 /opsx:update 改现有变更
  • 修订是改变意图/目标 （这个变更要做的事本身变了）→ 换一个没用过的新名字开新变更（openspec new change "<new-name>"），别硬把旧变更拧成另一个东西

6. 下一步指引（只指路，不代跑）

检查到的情况 它给你的建议
还有产物没生成（ready/blocked） 去看 openspec instructions 怎么补
变更已实施、但计划刚被修订 代码可能落后于新计划 → /opsx:apply
一切完成且已实施 → /opsx:archive

7. 典型使用场景

  1. /opsx:apply 执行到一半，发现 design 里的选型不对 → /opsx:update design 改用 X → 回头继续 apply
  2. 需求方砍掉了半个功能 → /opsx:update 一致性审查，AI 把 proposal/specs/design/tasks 里涉及的部分一并对齐
  3. 手改了 proposal.md 之后心里没底 → /opsx:update 让 AI 对账四件套

4-同步命令sync详解

1. 是什么

/opsx:sync 把变更目录里的 Delta 规范 （specs/ 下的增量）合并进主规范 openspec/specs/，但变更保持 active、不归档。

它是 agent-driven （智能体驱动）操作：不是程序化地整块覆盖，而是 AI 读懂 Delta 的意图后直接编辑主规范，做到智能合并------比如只给某个需求追加一个场景，而不是把整个需求抄一遍。

2. 和 archive 的关系（本篇核心对比）

/opsx:sync /opsx:archive
合并 Delta→主规范 ✅（就是它的全部工作） ✅（内部 inline 执行同一套同步逻辑）
变更目录 保持 active ，可继续 /opsx:apply 移入 changes/archive/，变更结束
适用时机 实现还没完，但规范要先行 实现完成，收尾归档

sync 跑完的固定结语就是证据：「Main specs are now updated. The change remains active - archive when implementation is complete.」（主规范已更新，变更仍活跃，实现完成后请归档。）

3. 四种 Delta 操作怎么合

Delta 规范里用四段式头声明增量意图：

Delta 段 合并行为
## ADDED Requirements 主规范没有该需求 → 新增；已有 → 按新内容更新（视为隐式 MODIFIED）
## MODIFIED Requirements 找到原需求，应用变化（新增场景 / 修改场景 / 改描述）；Delta 没提到的内容全部原样保留
## REMOVED Requirements 删除整个需求块；若要删光一个能力的全部需求（能力退役），需变更声明 retire_capabilities: true 等严格条件，否则停下报告
## RENAMED Requirements 把 FROM 需求改名为 TO

另外：主规范已有的 ## Purpose 是权威的，Delta 里就算带了也不覆盖（和 archive 行为一致）。

4. 智能合并三原则

  1. 合并不是覆盖：绝不把 Delta 文件原样拷进主规范
  2. 未提及即保留：Delta 没说的内容按主规范原有顺序原样保留（比如 MODIFIED 只加了 1 个场景，其余场景不动）
  3. 主规范永远干净 ：合并后的主规范里绝不允许出现 ## ADDED/MODIFIED/REMOVED/RENAMED Requirements 这些 Delta 操作头，所有需求统一住在 ## Requirements 一节下

5. 执行流程

复制代码 
/opsx:sync [变更名]
   |
   v  1. 选定变更 (能推断就推断, 只有一个就自动选, 模糊就列清单问你, 并播报 "Using change: <name>")
   v  2. openspec status 拿到主规范根路径 + Delta 规范文件清单 (只认 specs 的 existingOutputPaths)
   v  3. 逐个能力: 读 Delta + 读主规范 -> 按四类操作智能合并 (主规范不存在时, 仅 ADDED 可用于新建)
   v  4. openspec validate --specs 校验, 失败即报告, 绝不谎报成功
   v  5. 输出摘要: 哪些能力改了什么 / 新建的主规范是否有 TBD 占位 / 是否有能力被退役

两个工程细节：

  • 幂等：同一变更连续 sync 两次，结果一致
  • 路径唯一来源 ：只同步 openspec status 报告的 Delta 文件清单，绝不从其他产物「猜」Delta 在哪

6. 什么时候用 sync 而不是等 archive

  1. 规范先行：代码实现到一半，但希望主规范已经反映本次变更的真实意图
  2. 多变更并行：几个在途变更都在改同一个能力，增量 sync 比攒到最后一次性合并冲突小得多
  3. 下一个变更想基于最新规范开工 ：先 sync 让 openspec/specs/ 保持最新，再 propose 下一个变更

5-对比总结与实战建议

1. 三命令大对比

维度 /opsx:explore /opsx:update /opsx:sync
回答的问题 「这件事值不值得做、怎么做」 「计划变了，文档怎么跟上」 「规范怎么提前跟上」
触发时机 propose 之前 / 任何时候 propose 之后、apply 前后 apply 中后期、archive 之前
写入前提 每次写入都要你 yes/no 每个产物逐个确认 直接执行（可用 openspec validate 验收）
不碰什么 实现代码、工作流配置 实现代码、不存在的产物、skipped 产物 实现代码、变更目录、非 Delta 内容
结束后指向 /opsx:propose /opsx:apply 或 /opsx:archive /opsx:archive

2. 四个易混淆点

对比 一句话区分
sync vs archive archive = sync + 移目录；只要规范最新但变更还在进行 → sync
update vs explore explore 自由发散、可以不产出任何东西；update 必须针对已有产物做修订
update vs 手改 markdown update 改一处会反向对账其余三件套；手改极易造成四件套失配
explore vs propose explore 只讨论不动手；propose 一次性生成 proposal/specs/design/tasks

3. 实战建议

  1. 大需求先 explore 再 propose：需求含糊或涉及选型时，先花一轮对话把问题聊透，产物质量明显更高；小改动直接 propose
  2. apply 中途改方案，用 update 别手改：AI 会把四件套一并对账，避免「proposal 改了、tasks 忘了」的漂移
  3. 多变更并行改同一能力时用 sync 增量同步：比攒到 archive 一次性合并冲突小
  4. 日常简单变更三个都可以不用 ：修 bug、小功能直接走核心三步 propose → apply → archive

一句话总结：/opsx:explore 想清楚 → /opsx:propose 定方案 → /opsx:apply 写代码 → /opsx:update 中途改方案 → /opsx:sync 提前合规范 → /opsx:archive 收尾归档，三个辅助命令都不写一行实现代码，只保证「规范文档」始终和你的真实意图一致。

相关推荐
码哥字节3 个月前
我用两个开源框架，搓出一个让 AI 写代码不再失控的插件
openspec·ai编程工具·superpowers
一个儒雅随和的男子4 个月前
OpenSpec在SDD编程模式中的应用
openspec
我思故我在a4 个月前
AI编程之SDD新范式的自我探索实践
ai编程·openspec
嘛也学不会4 个月前
OpenSpec + Superpowers 的一个使用思路
教程·基础·skill·openspec·superpower
慌途L4 个月前
OpenSpec 深度指南：从原理到实战，让 AI 编程告别返工
ai·openspec
bboyzqh4 个月前
OpenSpec 规范驱动开发工作流：从提案到归档的完整闭环
sdd·openspec
码哥字节4 个月前
OpenSpec+Superpowers焊死后，AI编码工作流终于自洽了
ai编程·openspec·superpowers·spec-superflow
热门推荐
01国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）02如何新建文件夹？ 电脑新建文件夹的4种方法03历年考研数学一、数学二、数学三真题试卷及答案PDF04几个好用的ip纯净度检测网站05微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新06昇腾910B系列芯片完全指南：四款型号对比、服务器选型与大模型部署实战07GitHub 镜像站点08苹果iPA游戏软件资源下载网站09蜘蛛磁力 搜索引擎大全，如何使用蜘蛛磁力查找磁力链接10Dify：一站式AI应用开发平台全解析与Windows部署指南