在AI辅助开发过程中，许多团队都有一个共同体会：快速编写代码并不难，真正的挑战在于不让项目偏离方向。需求边界反复变动、设计进行到一半就调整目标、实现阶段临时增加需求、交付后没人能说清楚本次到底改了哪些内容——这些才是真正令人头疼的核心问题。
OpenSpec正是针对这一痛点而生。它提出了一种简单却高效的协作机制：先将“要做什么、为什么做、怎么做”固化为规格，再让AI与团队严格依照这份规格推进执行。下面将为你详细解析它究竟解决了哪些问题、为何值得关注，以及如何通过Explore → Propose → Design → Tasks → Apply → Archive这六大阶段，完整走通一次变更流程。
一、概念：OpenSpec 到底在解决什么
OpenSpec 把一件事放在最优先的位置：先对齐规格，再进入实现阶段。一次变更通常会产出四类资产：
proposal.md：为什么做、要做什么、影响哪些方面。design.md：怎么做、有哪些取舍、为何这样设计。specs/：变更后的行为规格。tasks.md：可执行的任务清单。
它们并非孤立的文件，而是一个完整的闭环：Explore → Propose → Design → Tasks → Apply → Archive。简单来说，OpenSpec 的意义不在于增加流程，而是让AI、产品、研发、测试四方都能站在同一份规格上协作沟通。
二、安装说明：先把环境准备好
官方安装前提是Node.js 20.19.0或更高版本。请先确认环境满足要求：
node --version
openspec --version你可以根据自己习惯的包管理器选择安装方式：
npm install -g @fission-ai/openspec@latest或者：
pnpm add -g @fission-ai/openspec@latest安装完成后，进入项目目录并初始化：
cd your-project
openspec init这一步的目标很简单：先让工具运行起来，之后再考虑流程重构。
三、入门指南：从 0 到 1 的最短路径
如果今天就要上手使用，建议优先体验最小可行流程：
- 用
/opsx:explore把问题阐述清楚； - 用
/opsx:propose创建变更并生成规划资产； - 用
/opsx:apply按照任务推进实现； - 用
/opsx:sync和/opsx:archive完成收尾。
流程走向：/opsx:explore → /opsx:propose → /opsx:apply → /opsx:sync → /opsx:archive
这里有一个关键判断点：如果还不确定范围、方案或约束，那就先进行Explore，不要急于开工。反之，如果需求已经明确、边界也基本清晰，直接进入提案也没有问题。
团队落地时，可以先只要求三件事：中等以上需求必须先有proposal；进入开发前必须有design和tasks；实现阶段禁止口头改需求，任何变更都必须回写规格。这三条执行到位后，协作质量便会明显提升。
四、工作流程：六阶段闭环怎么跑
1）Explore
输入是问题背景、初始想法、未确定的边界。关键动作是澄清目标、识别未知项、收敛范围。输出探索结论和候选方向，最后判断是否进入提案。退出条件只有一个：问题清晰到可以写提案。
2）Propose
输入是Explore的结论。关键动作是写清楚背景、目标、范围、影响面。输出proposal.md。退出条件是提案可评审，也可能被拒绝。常用命令示例：/opsx:propose rewrite-openspec-full-process-article配合/opsx:explore。
3）Design
输入是已确认的proposal。关键动作是解释方案结构、约束、边界和取舍。输出design.md。退出条件是设计足以指导任务拆解。
4）Tasks
输入是design.md。关键动作是拆分为可执行任务，并明确依赖顺序。输出tasks.md。退出条件是任务可以逐条执行和验收。
5）Apply
输入是tasks.md。关键动作是按照任务推进实现，必要时同步修正文档。输出是完成后的变更资产。退出条件是任务完成，且文档与实现保持一致。这里有一条强约束值得注意：需求变更必须先回写规格；实现偏差要先修正实现再同步文档；缺陷修复属于当前实现修正，不应包装成新需求。常用命令示例：/opsx:apply rewrite-openspec-full-process-article配合/opsx:sync。
6）Archive
输入是已完成的变更。关键动作是归档、同步规格、保留复盘信息。输出是可追溯的归档记录。退出条件是变更可查、可回看、可复用。常用命令示例：/opsx:archive rewrite-openspec-full-process-article。
五、常用命令：按阶段记忆，不要死记硬背
| 阶段 | 命令 | 作用 |
|---|---|---|
| Explore | /opsx:explore | 澄清问题、探索方案 |
| Propose | /opsx:propose | 创建变更并产出规划资产 |
| Apply | /opsx:apply | 按任务实施变更 |
| Sync | /opsx:sync | 合并delta specs到主规格 |
| Archive | /opsx:archive | 归档完成的变更 |
| 扩展工作流 | /opsx:new//opsx:continue//opsx:ff//opsx:verify | 分步或快速生成规划、校验实现 |
记住命令有一个最直接的逻辑：先判断当前处于哪个阶段，再选择对应命令，最后确认是否需要同步、验证或归档。不要反过来死记硬背。
六、实战案例分析：为什么规格驱动能少返工
以“新增文章发布流水线”这个场景为例。没有规格时，你说“加个发布流程”，AI可能会自动补充出一整套你并未要求的逻辑：草稿状态如何流转、谁能审核、审核失败如何回退、线上发布如何回滚。结果是你以为在做功能，而AI却在猜测，最终大家对齐的不是目标，而是返工。
有了规格，OpenSpec会把问题拆解为六段：Explore确认要解决什么；Propose写清变更意图；Design决定状态机、数据模型、权限和回滚方案；Tasks拆分成顺序明确的任务；Apply按规格实施；Archive保留复盘结果。这个过程中最关键的好处是：需求不会在实现中偷偷改变；任务之间有清晰的依赖顺序；任何偏差都能回溯到文档；上线后还能说清楚“这次到底改了哪些内容”。
当然，常见的坑也不少：把OpenSpec当成“写文档任务”；proposal写得太抽象；design只写怎么做而不写为什么；tasks缺少依赖关系；上线后不归档。这些坑归根结底是一个问题：规格并没有真正成为协作契约。
七、总结：一套可直接复制的落地清单
如果想记住最少的关键点，这7条就够了：先探索再提案；proposal说清为什么做、做什么、影响什么；design说清怎么做以及为何这么做；tasks按依赖顺序拆解；Apply阶段不临时改需求；变更完成后先sync再archive；归档不是形式，而是团队知识沉淀。
OpenSpec不是为了增加流程，而是为了减少返工。它把“模糊需求”转化为“可执行规格”，把“个人经验”沉淀为“团队资产”。如果你的团队已经在用AI编写需求、设计和实现，那么它值得尽早引入；如果目前还依赖口头对齐，也可以从最小变更开始，把这套流程跑起来。
