OpenSpec评测：终结AI自由发挥，团队协作不跑偏

在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。

五、常用命令：按阶段记忆，不要死记硬背

记住命令有一套最直接的逻辑：先判断当前处在哪个阶段，再选择对应命令，最后确认是否需要同步、验证或归档。切忌倒着硬背。

六、实战案例分析：为什么规格驱动能少返工

以“新增文章发布流水线”为例。没有规格时，你说“加个发布流程”，AI可能会自动补全一整套你没想过的逻辑：草稿状态如何流转、谁有审核权限、审核失败怎样回退、线上发布如何回滚。结果就是，你以为在做一个功能，AI却在做大量猜测，最终大家对不齐目标，只能返工。

有规格时，OpenSpec会将问题拆解成六个阶段：Explore确认究竟要解决什么；Propose写清楚变更意图；Design决定状态机、数据模型、权限控制和回滚策略；Tasks拆解为依赖有序的任务；Apply按规格逐步实施；Archive保留复盘记录。这个过程中最关键的收益是：需求不会在实现中偷偷变形；任务之间有明确的依赖顺序；任何偏差都能回到文档溯源；上线之后也能清楚回答“这次到底改了哪些内容”。

当然，常见陷阱也不少：把OpenSpec当成“写文档任务”来对待；proposal写得太抽象；design只写怎么做却不写为什么；tasks没有依赖关系；上线后不做归档。这些陷阱归根结底是同一个问题：规格没有真正成为团队协作的契约。

七、总结：一套可直接复制的落地清单

如果想记住最少的关键点，这7条就够了：先探索再提案；proposal说清为什么做、做什么、影响什么；design说清怎么做和为什么这么做；tasks按依赖顺序拆解；Apply阶段不临时改需求；变更完成后先sync再archive；归档不是形式，而是团队知识的沉淀。

OpenSpec的目的不是增加流程，而是减少返工。它将“模糊的需求”转化为“可执行的规格”，把“个人经验”沉淀为“团队资产”。如果团队已经在用AI写需求、写设计、写实现，那么它值得尽早引入；如果目前还依赖口头对齐，也可以从最小变更开始，先把这套流程跑起来。