随着 Claude Code、Cursor、GitHub Copilot 等 AI 编程助手的普及，越来越多的开发者开始依赖 AI 来生成代码。然而，一个核心问题始终困扰着团队：AI 生成的代码经常偏离预期，尤其在处理复杂的存量项目时，上下文丢失和输出不可控让"Vibe Coding"（凭感觉编码）变得不可靠。OpenSpec 应运而生——它通过"先定义规范，再编写代码"的方式，为 AI 编程助手建立了一套结构化的工作框架，短短半年内在 GitHub 上收获了超过 28K 星标。
什么是 OpenSpec？
OpenSpec 是由 Fission AI 开发的一个开源、轻量级的规范驱动开发（Spec-Driven Development, SDD）框架。它的核心理念很简单：在人类和 AI 之间建立一个"规范层"，确保双方在动手写代码之前就对需求达成一致。
与传统的瀑布式文档流程不同，OpenSpec 遵循五个核心设计原则：
- 流动而非僵化：迭代式工作流，没有严格的阶段门禁
- 迭代而非瀑布：支持随时更新任何工件
- 简单而非复杂：通过斜杠命令即可完成所有操作
- 存量优先：专为已有代码库的演进设计，而非仅适用于新项目
- 可扩展：从个人项目到企业级团队都适用
# 安装 OpenSpec
npm install -g @fission-ai/openspec@latest
# 在项目中初始化
cd your-project
openspec init
安装后，OpenSpec 会在项目中创建一个 openspec/ 目录，用于存放所有规范相关的文件。它要求 Node.js 20.19.0 或更高版本，支持 npm、pnpm、yarn、bun 等主流包管理器。
核心工作流：提议 → 规划 → 实现 → 归档
OpenSpec 的工作流围绕一个清晰的循环展开。每次变更都会在 openspec/changes/ 目录下创建一个独立的文件夹，包含以下结构化工件：
- proposal.md — 变更的理由和范围说明
- specs/ — 详细的需求规范和测试场景
- design.md — 技术方案设计
- tasks.md — 实现任务清单
最基本的工作流只需要三条命令：
# 1. 提出一个变更提案
/opsx:propose add-dark-mode
# 2. AI 根据规范实现代码
/opsx:apply
# 3. 完成后归档变更
/opsx:archive
扩展工作流还提供了更多命令，包括 /opsx:new（创建新变更）、/opsx:continue（继续未完成的工作）、/opsx:verify（验证实现）、/opsx:sync（同步配置）等。
这种结构化的方式带来的最大好处是上下文持久化——规范文件与代码一起存储在仓库中，不会像聊天记录一样随对话结束而消失。当你下次打开 AI 助手时，它可以直接读取这些规范文件来理解项目当前状态。
为什么存量项目最需要 OpenSpec？
OpenSpec 的"存量优先"（Brownfield-First）策略是其与众不同的核心价值。大多数 AI 编程工具都聚焦于从零开始构建新应用（greenfield, 0→1），而现实中的大部分开发工作是在已有代码库上进行迭代演进（1→n）。
在没有规范约束的情况下，AI 在处理存量代码时经常出现以下问题：
- 上下文丢失：AI 不了解项目的历史决策和架构约束
- 过度修改：本该只改一个函数，结果重构了半个模块
- 风格不一致：生成的代码与项目现有风格不匹配
- 幻觉输出：编造不存在的 API 或依赖
OpenSpec 通过规范文件为 AI 设定了明确的边界和约束。一个定义清晰的任务，配合明确的范围限制，产出的代码质量远远好于一个模糊的开放式提示。
v1.2.0 新特性：Profiles 与更广泛的工具支持
2026 年 2 月发布的 v1.2.0 版本带来了多项重要更新：
Profiles 配置：允许用户选择不同的工作流子集。core 配置包含 4 个核心工作流，适合快速上手；也可以创建自定义配置来安装特定的技能集。
更广泛的工具支持：目前已支持超过 21 种 AI 工具，包括：
| 工具类别 | 支持列表 |
|---|---|
| IDE 集成 | Cursor、Windsurf、AWS Kiro、Continue |
| CLI 工具 | Claude Code、Gemini CLI、Amazon Q |
| 平台 | GitHub Copilot、Pi (pi.dev) |
AI 工具自动检测：安装时自动扫描项目中已有的工具目录，预选检测到的工具，减少手动配置。
配置漂移警告：当全局配置与当前项目不同步时发出警告，帮助团队保持一致。
# 使用 core profile 初始化
openspec init --profile core
# 同步配置，清理未选择的工作流
/opsx:sync
与 AI 高推理模型的配合实践
OpenSpec 官方建议搭配高推理能力的模型使用，如 Claude Opus 4.5 或 GPT 5.2 等。这是因为规范驱动开发的关键在于 AI 能够理解并遵循结构化的约束——推理能力越强的模型，在理解规范意图、保持输出一致性方面的表现越好。
一个实用的建议是注重"上下文卫生"（Context Hygiene）：在从规划阶段进入实现阶段时，清理 AI 的对话上下文。这样 AI 会从规范文件中重新加载项目状态，而不是依赖可能已经混乱的对话历史。
# 实际使用建议
1. 使用 /opsx:propose 创建提案时，让 AI 充分理解需求
2. 审核 proposal.md 和 design.md，确保方案合理
3. 清理上下文（新建对话窗口）
4. 使用 /opsx:apply 让 AI 基于规范文件实现代码
5. 使用 /opsx:verify 验证实现是否符合规范
总结
OpenSpec 代表了 AI 辅助编程领域的一个重要转变：从"让 AI 猜测你想要什么"到"让 AI 按照明确的规范执行"。它不是一个替代 AI 编程助手的工具，而是一个让 AI 编程助手更加可靠的协作框架。
对于正在使用 AI 编程助手的团队来说，OpenSpec 值得一试的理由有三个：一是它足够轻量，三条命令就能跑起来；二是它专为存量项目设计，解决了 AI 编程中最痛的上下文丢失问题；三是它不绑定任何特定工具，支持 21 种以上的 AI 编程助手。
随着 AI 编程从"辅助工具"向"核心生产力"演进，规范驱动开发的重要性只会越来越高。OpenSpec 半年 28K 星标的增长速度也说明，开发者社区已经意识到了这一点。
评论