OpenSpec 是一款开源的 Spec 管理工具，支持集成到 22 种辅助编程工具中，避免因工具切换导致迁移成本过高。与 Kiro、Cursor 等商业工具不同，OpenSpec 纯粹专注于规范管理，由社区驱动开发，适合团队内不同开发者根据习惯选择工具的同时保持统一的开发规范。OpenCode 同样开源，支持自定义接入多种大语言模型，无需购买官方套餐，适合作为团队主力工具。

一、什么是OpenSpec

OpenSpec 是一个专为 AI 智能体（如 Claude Code、Cursor、OpenCode 等）设计的开源、轻量级规范驱动开发（Spec-Driven Development, SDD）框架和命令行工具（CLI）。

它的核心目标是通过"提案-审查-实施-归档"四阶段工作流，将模糊的自然语言提示转化为机器可读的正式规范，从而解决 AI 编程中的需求偏移与不可预测性问题，帮助开发团队从"氛围编程"转向工程化的规范开发模式。

OpenSpec 的四阶段工作流构成完整闭环：起草变更提案将自然语言意图转化为结构化计划；审查对齐阶段通过"人在回路"确保需求准确捕获；AI 驱动实施阶段严格锁定已批准规范，消除创造性偏离；归档更新阶段将增量规范合并至主目录，形成持续演进的项目文档。

这种规范的工作流提供了一系列战略优势，提升了 AI 辅助开发的实践。

二、OpenSpec 安装和初始化

开始使用 OpenSpec 需要两个简单的命令行操作。

首先，CLI 全局安装：

npm install -g @fission-ai/openspec@latest

接下来，OpenSpec 在现有项目仓库中初始化：

openspec init

根据实际使用的 AI Coding 工具，比如这里选择OpenCode。

openspec init 是 OpenSpec 项目初始化的核心命令，负责在当前目录下创建规范驱动开发所需的标准目录结构和配置文件。

openspec init 的主要功能是一键初始化 OpenSpec 项目环境，具体包括：

• 创建 .openspec/ 或 openspec/ 标准目录结构
• 新版本生成 openspec/config.yaml 配置文件（老版本是生成 project.md（项目上下文文档）和 AGENTS.md（AI 行为说明书））
• 提示选择你使用的 AI 编程助手（OpenCode、Cursor、Claude Code、GitHub Copilot 等）
• 自动为所选 AI 工具生成对应的配置文件（如斜杠命令定义文件）

简单来说，该命令将你的项目从“普通代码仓库”升级为支持“规范先行”的可追溯开发环境。

关键文件作用：

• openspec/config.yaml 项目的唯一配置入口，定义 schema（工作流模板）、context（全局背景信息）、rules（附加规则）
• openspec/specs/ 存储所有已批准的规范，是项目的"单一事实来源"
• openspec/changes/ 存放进行中的变更提案，每个提案是一个独立文件夹
• commands/opsx/ AI 工具的斜杠命令定义文件，使 AI 能够执行 /opsx:proposal、/opsx:apply 等标准操作

如下是OpenCode 中生成的文件：

这种 specs/ 和 changes/ 的分离是核心架构原则，使可预测的 AI 驱动修改成为可能。

它为 AI 提供了两个不同的上下文：用于稳定参考的不可变、系统范围的"真相来源"（specs/），以及用于即时任务的沙盒化、聚焦的"提议更新"（changes/）。

这防止了困扰基于提示工作流的上下文漂移和范围蔓延。使用版本控制的类比，specs/ 像 Git 中的主分支一样工作——稳定的真相——而 changes/ 内的每个目录就像功能分支或拉取请求——一个提议的、隔离的更新。

三、工作流程

OpenSpec 的工作流围绕一个清晰的四步循环展开，将每一次功能迭代都置于管理之下。

1. 起草提案：开发者通过自然语言或斜杠命令（如 /openspec:proposal）提出需求。AI 会据此在 openspec/changes/ 目录下自动生成结构化的变更提案，包括：

• proposal.md：说明“为什么”要改和“改什么”。
• design.md：解释如何实现，记录高层次的技术决策和架构设计。
• specs/：包含具体的需求规范和验收场景 (通常使用 GIVEN-WHEN-THEN 格式)。
• tasks.md：一个详细的实施任务清单。

2. 审查与对齐：开发者和团队审查 AI 生成的提案和规范。这是关键的人工介入环节，确保方向正确后才允许 AI 动手。使用 openspec validate 命令可以确保规范格式无误。

3. AI 实施：规范锁定后，使用 /openspec:apply 命令让 AI 严格按照 tasks.md 和实施计划来编写代码。这极大地约束了 AI 的自由度，保证输出不偏离预定轨道。

4. 归档并更新：功能完成并通过验证后，使用 /openspec:archive 命令。该操作会将本次的规范增量合并到主规范库中，并归档变更记录，使项目规范始终保持最新。

openspec init 默认启用包含基础命令（propose、apply、archive）的快速工作流。如需启用扩展命令（如 /opsx:ff 快速通道），后续可通过 openspec config profile 切换工作流配置。

OpenCode 中的 OpenSpec 相关功能通过 /opsx-* 命令使用，具体命令如下：

在 Desktop 中输入 /，会弹出命令提示，输入 /opsx- 即可看到所有可用命令：

通过将 OpenSpec 集成到开发工作流中，团队对其与 AI 的协作施加了必要的工程纪律。这种结构化方法超越了"vibe coding"的限制，在代码质量、项目效率和整体治理方面提供了显著、可衡量的改进。组织内所有角色都能感受到这些好处。

四、团队采用实用指南

集成 OpenSpec 被设计为一个增量过程，立即提供价值，而不需要对现有工作流进行破坏性大修。团队可以通过几个简单的步骤采用这种方法。

1. 初始化仓库：第一步是在项目根目录中运行 openspec init。此单个命令创建 openspec/ 结构并为团队首选的 AI 助手配置必要的集成。

2. 从新功能开始：开始的最简单方法是将 OpenSpec 用于即将到来的工作。团队成员可以要求其 AI 助手为新功能或增强生成变更提案。这允许团队在明确定义的任务上熟悉工作流。

3. 增量增长：随着每个实施和归档的变更，openspec/specs/ 目录有机地增长。随着时间的推移，此过程构建整个系统的全面、活的文档。此规范存储库成为越来越有价值的资产，为所有未来的 AI 辅助开发提供更丰富的上下文。

4. 保持工具灵活性：OpenSpec 在不强制工具统一的情况下促进一致性。团队成员可以自由使用其首选的、兼容的 AI 工具——如 Cursor、OpenCode、Claude Code 或 GitHub Copilot。因为所有工具都从同一个中央 OpenSpec 存储库工作，无论个人工具选择如何，跨团队一致性都得到维护。

#openspec##sdd##opencode##上头条 聊热点#