随着AI 的野蛮发展，随之孵化出来各种新概念、新技能、新模式也是层出不穷前有vibecoding，后有claude ，前有cursor3 后有小龙虾，前有SKILL 后有dify，前后MCP 后有langgraph/langchain……（名词不分先后）
这些新名词让刚刚接触AI 的童鞋们痛苦不已，这都是些啥呀~
没关系，了解我的童鞋都知道。只讲干货，不讲废话，五分钟，只要你月读完这篇文章，你就会 了解并能够使用openspec，如果关注点赞和收藏，你就会了解并掌握更多关于ai的知识！
一、OpenSpec 是什么？
通过以下几点来认识：
OpenSpec 是一套把“需求、规格、设计、任务、实现、归档”串起来的 AI 协作工作流
它由 Fission-AI 团队开发，是一个专为 AI 编码助手设计的开源、轻量级规范驱动开发框架。核心目标是解决 AI 编程中常见的“幻觉”或“需求偏移”问题，让开发者从“凭感觉聊天”转向“基于规范开发”
以结构化 spec 锁定功能描述、输入输出、边界条件，避免 AI“猜需求”变更可追溯
所有提案、任务、规范增量集中管理，归档后留存完整变更历史协作效率
编码前达成共识，减少返工；新成员可通过 spec 快速上手适配 AI 协作
支持主流 AI 编码助手（Cursor、GitHub Copilot、Claude Code 等）轻量无侵入极简配置，不改造现有项目架构，命令行工具快速接入
二、为什么要用 OpenSpec？
从上面的几点来看，简单总结，openspec 设计的初衷就是为了我们在于AI 交互的时候，尤其是某些复杂项目中，规范AI 的行为，让AI 朝着我们自己的方向给出我们更加预期的回答。
| 价值维度 | 说明 |
|---|---|
| 消除需求歧义 | 以结构化 spec 锁定功能描述、输入输出、边界条件，避免 AI“猜需求” |
| 变更可追溯 | 所有提案、任务、规范增量集中管理，归档后留存完整变更历史 |
| 提升协作效率 | 编码前达成共识，减少返工；新成员可通过 spec 快速上手 |
| 适配 AI 协作 | 支持主流 AI 编码助手（Cursor、GitHub Copilot、Claude Code 等） |
| 轻量无侵入 | 极简配置，不改造现有项目架构，命令行工具快速接入 |
不好理解也没关系，看下面的案例，自己动手做一遍 就更加了解了
三、核心概念：specs 与 changes
OpenSpec 最核心的架构原则是将两个目录分离：
openspec/ ├── config.yml # 🆕 项目级配置文件（控制AI行为和语言） ├── specs/ # 当前系统的正式规格（真相来源） │ └── [capability]/ │ ├── spec.md # 功能规范 │ └── design.md # 技术设计（可选） └── changes/ # 每次变更的工作区 ├── [change-name]/ │ ├── proposal.md # 为什么要改、改什么 │ ├── tasks.md # 实施清单 │ ├── design.md # 技术决策（可选） │ └── specs/ # 增量规范变更 │ └── [capability]/ │ └── spec.md └── archive/ # 已完成的变更 # specs/：描述系统现在应该怎么工作，是项目的“单一真相来源” # changes/：描述这一次准备怎么改，每个变更都有独立的提案、任务和规范增量，这就像 Git 的 main 分支（specs）与 feature 分支（changes）的关系。四、四阶段工作流——四个技能包打天下
OpenSpec 的力量在于其结构化的四阶段工作流：
┌────────────────────┐ │ 1. 起草变更提案 │ │ (Draft Proposal) │ └────────┬───────────┘ ▼ ┌────────────────────┐ │ 2. 审查与对齐 │◄──── 反馈循环 ──────┐ │ (Review & Align) │ │ └────────┬───────────┘ │ │ 批准计划 │ ▼ │ ┌────────────────────┐ │ │ 3. 实施任务 │──────────────────────┘ │ (Implement) │ └────────┬───────────┘ ▼ ┌────────────────────┐ │ 4. 归档并更新规范 │ │ (Archive) │ └────────────────────┘阶段 1：起草变更提案
通过自然语言或斜杠命令（如 /openspec:proposal）让 AI 创建完整的变更文件夹，包括 proposal.md、tasks.md 和规范增量文件。
阶段 2：审查和对齐
开发团队审查 AI 生成的内容，与 AI 迭代改进，直到计划得到完全批准。这是关键的“人在回路”环节。
阶段 3：AI 驱动的实施
提案批准后，使用 /openspec:apply 让 AI 按 tasks.md 清单逐一实现功能。AI 被约束在已锁定的计划内，不会偏离。
阶段 4：归档并更新真相来源
实施完成后，使用 /openspec:archive 将变更的规范增量合并到主 specs/ 目录，正式更新系统的“真相来源”。
一般 我们要写好 confiy.yml ，来规范AI 项目行为，然后利用/openspec:proposal 来与AI 讨论当前要做什么，然后就可以使用 /openspec:apply 来让AI 帮我们完成
五、在windows上安装 openspec
这里我们着重介绍 windows上安装过程
5.1 前置准备
1. 安装 Node.js
OpenSpec 需要 Node.js 版本 >= 20.19.0。
没有安装过nodejs 的小伙伴，可以查看其他教程安装，非常简单，这里省略
2. 安装 Git Bash 或 WSL
虽然 OpenSpec 可在 Windows 原生命令行中运行，但使用 Git Bash 或 WSL（Windows Subsystem for Linux） 会有更好的体验。
Git Bash：安装 Git for Windows 时自带
WSL：在 Microsoft Store 中搜索“Ubuntu”安装
推荐安装 git bash，一般开发的童鞋基本都已经安装好了： gitbash 安装好之后，鼠标右键菜单看到git bash接口
5.2 安装 OpenSpec（推荐）
方式一：安装英文原版
npm install -g @fission-ai/openspec@latest #或者 yarn global add @fission-ai/openspec@latest方式二：安装中文版
社区提供了完整的中文版本，CLI 命令、模板、提示信息全部中文化：
npm install -g @studyzy/openspec-cn@latest #或者 yarn global add @studyzy/openspec-cn@latest验证安装：
openspec --version # 或中文版 openspec-cn --version整个过程和使用nodejs 安装一个第三方包没有区别
5.3 使用
接下来就是核心内容，如何在项目中使用了：
#进入项目 cd your-project # 运行初始化命令： # 英文版 openspec init # 中文版 openspec-cn init初始化过程中会提示你选择使用的 AI 工具：
? Which AI tools do you use? (Press <space> to select, <enter> to confirm) › ◯ Claude Code ◯ Cursor ◯ GitHub Copilot ◯ Windsurf ◯ Codex ◯ ... (更多选项)选择你正在使用的 AI 编码助手（可多选，比如当前项目使用了opencode可以下拉选中）。初始化完成后，OpenSpec 会自动配置对应工具的斜杠命令。
查看所有命令：
查看 design.md
查看 config.yml
config.yml 是我们项目规范的核心，我们在这里定义要用的包、版本、框架以及其他详细规则。其实就类似于SKILL。我们后期再将SKILL
schema: spec-driven context: | 前端技术栈：React 18 + TypeScript + Vite 后端技术栈：Node.js + Express + TypeScript +Mongodb8 前端状态管理：Zustand API 风格：RESTful，使用 OpenAPI 生成类型 国际化：i18next，所有文案需中英文双份 包管理：yarn 构建工具：Vite 启动脚本：前端 `yarn dev`，后端 `yarn start` 给出一键启动脚本（.bat 和 .sh），启动前先安装包 代码规范：Prettier + ESLint，遵循 Airbnb JavaScript Style Guide Git 规范：使用 Conventional Commits，分支命名为 `feature/xxx`、`bugfix/xxx`、`hotfix/xxx` 等 测试框架：前端使用 React Testing Library + Jest，后端使用 Jest CI/CD：使用 GitHub Actions，包含 lint、test、build 步骤 文档规范：使用 JSDoc 注释，所有函数和组件必须有注释，且需包含中英文描述 设计规范：遵循 Material Design，使用 MUI 组件库，所有自定义组件需符合设计规范 国际化规范：所有用户可见文案需提供中英文版本，使用 i18next 进行管理，且需在代码中使用 `t('key')` 进行调用 # rules: # proposal: # - 必须包含「非目标 (Non-goals)」章节 # - 需写明影响范围和回滚方案 # specs: # - 场景必须使用 `#### Scenario:` 格式 # - 覆盖正常路径和错误情况 # tasks: # - 使用 yarn 替代 npm 进行包管理 # Project context (optional) # This is shown to AI when creating artifacts. # Add your tech stack, conventions, style guides, domain knowledge, etc. # Example: # context: | # Tech stack: TypeScript, React, Node.js # We use conventional commits # Domain: e-commerce platform # Per-artifact rules (optional) # Add custom rules for specific artifacts. # Example: # rules: # proposal: # - Keep proposals under 500 words # - Always include a "Non-goals" section # tasks: # - Break tasks into chunks of max 2 hours5.4 核心命令
在opencode/claude 中 缩写成 /opsx
| 命令 | 功能 |
|---|---|
| /opsx:propose | 一步生成所有规划文件（提案、规范、任务） |
| /opsx:explore | 探索模式，理清思路 |
| /opsx:apply | 实施任务 |
| /opsx:archive | 归档变更 |
六、完整实例
以创建一个“博客系统”为例：
6.1 创建变更提案
在 AI 助手中输入：
/openspec:proposal 帮我创建一个个人博客系统，要求能发表文章，能注册登录，能点赞收藏评论文章，使用vue3+springboot3+jdk17+mysql8 AI 会自动： # 在 openspec/changes/blog # 生成 proposal.md（为什么要做、做什么） # 生成 design.md（技术决策） # 生成 tasks.md（实施清单）6.2 审查提案
使用命令查看提案内容：
openspec list # 查看所有变更 openspec show blog # 查看变更详情 openspec validate blog # 验证规范格式6.3 实施变更
确认提案无误后：
/openspec:apply blogAI 会按照 tasks.md 的清单逐步实现代码，每完成一项自动打勾。
6.4 归档变更
功能完成后：
/openspec:archive create-ui变更会被移动到 changes/archive/，规范增量合并到主 specs/ 目录。
原文地址：https://daimane.com/articles/69d6796f5e168ceae0707fed
