跟AI聊了5轮，它还在跑偏？不是它不够聪明，是你没给它画好图纸。
用过AI编程助手的，一定经历过这个场景：
你说“加个用户登录功能”，它写出来了，但没加密码加密。你补充“要加密”，它加了，但忘了加登录失败次数限制。你又说“加限制”，它加了，但把之前确认好的邮箱验证搞没了……
来回折腾五六轮，代码终于勉强能用，但谁也说不出最终到底实现了什么。
这就是典型的“vibe coding”——凭感觉编程。AI像个充满热情但缺乏方向的新手，想到哪写到哪。
OpenSpec就是来解决这个问题的。它不是让AI更聪明，而是给AI画好施工图纸，让它照着干。
OpenCode（GitHub仓库：anomalyco/opencode）是一个完全开源的 AI 编程代理，拥有 132K+ GitHub Stars，每月活跃开发者超过 500 万。
核心特点：
-
✅ 100% 开源（MIT License） -
✅ 不绑定任何模型提供商（支持 Claude、GPT、Gemini 或本地模型，共 75+ 提供商） -
✅ TUI（终端用户界面）优先，开箱即用 -
✅ 支持Slash Commands（斜杠命令）和Skills（技能）系统
安装方式：
OpenSpec（GitHub仓库：Fission-AI/OpenSpec，35K+ Stars）是一个规范驱动开发（Spec-Driven Development，SDD）框架，专为 AI 编程助手设计。
核心思想：
-
在写代码之前，先写清楚"要构建什么" -
规格说明书（Spec）是真相来源，代码是衍生产品 -
适用于现有项目（Brownfield），而非仅新项目
解决的问题：
-
“Vibe Coding”（随意编码）：描述需求 → AI 生成代码 → 运行有问题 → 修改提示 → AI 修复一个 bug 又引入另一个 bug -
上下文丢失：多轮对话后，AI 忘记架构决策 -
安全漏洞：约 45% 的 AI 生成代码包含安全漏洞（在支付/订单系统中是合规问题）
OPSX是 OpenSpec 的标准工作流（v1.0 版本引入）。
关键革新：从刚性阶段→弹性动作
依赖关系图：
简单说：
- OpenCode
是 AI 助手运行的平台 - OpenSpec
是规范开发框架（通过CLI和 slash commands 工作） - OPSX
是 OpenSpec 的工作流（10 个命令）
- Node.js 20.19.0 或更高版本
- 任意
包管理器 -
npm、pnpm、yarn、bun 均可 - AI 编程助手
（推荐以下任一） -
OpenCode -
Claude Code -
GitHubCopilot -
Windsurf -
或其他支持 slash commands 的工具
验证安装：
假设我们有一个早餐小程序项目：
这个命令会做：
-
创建 openspec/目录 -
生成配置文件（ openspec/config.yaml） -
创建 AGENTS.md文件（AI 助手的说明文档） -
设置变更管理文件夹结构
初始化后，你的项目结构如下：
编辑openspec/config.yaml：
作用：
context：自动注入到所有 artifact 的指令中 rules：确保团队一致性
/opsx:explore— 探索模式
用途：需求不明确、需要调查问题、比较技术方案时使用。
示例（内容太长，只截取部分）：
关键点：探索模式不会创建变更文件夹，纯思考阶段。准备好后再用/opsx:new。
/opsx:new— 创建变更
用途：开始任何新功能或修改。
示例：
注意：这个命令只创建文件夹，不会生成任何文档。后续配合/opsx:ff或/opsx:continue。
/opsx:apply— 实施任务
用途：开始编码实现。
示例：
/opsx:verify— 验证实现
用途：检查实现是否符合规格。
示例：
推荐：每次完成编码后运行一次，确保没有遗漏需求。
/opsx:sync— 预览规格合并
用途：归档前预览 delta specs 如何合并到主 specs。
示例：
可选命令，/opsx:archive需要时也会提示。
/opsx:archive— 归档变更
用途：完成功能开发后归档。
示例：
会做：
-
将 delta specs 合并到主 specs（ openspec/specs/） -
将变更文件夹移到归档目录 -
保留完整变更历史
/opsx:bulk-archive— 批量归档
用途：累积多个已完成的变更时批量归档。
示例：
AI 会自动检测并解决spec冲突。
/opsx:onboard— 新手引导
用途：第一次使用 OpenSpec，或带团队成员入门。
示例：
使用真实代码库练习，约 15 分钟完成整个流程。
使用现有变更（更新 proposal/specs）当：
-
✅ 相同的意图（“还是那个功能，只是细节调整”） -
✅ >50% 范围重叠 -
✅ 原变更无法"完成"而不包含这些修改
创建新变更当：
-
✅ 意图根本改变（“Add auth” → “Add completeRBACsystem”） -
✅ <50% 范围重叠 -
✅ 原变更可以单独标记为"完成"
决策树：
OPSX 的核心优势：可以随时更新任何 artifact。
Delta Specs 规则：
-
每个 requirement 使用 ## Requirement: -
每个 scenario 使用 ### Scenario: -
MODIFIEDrequirements 必须包含完整内容（不是 diff） -
REMOVED requirements 必须包含原因和迁移计划
示例：
openspec/config.yaml：
作用：
context自动注入到所有 artifact 的 <context>标签rules只注入到匹配的 artifact（如design.md）的 <rules>标签
推荐 Git 分支策略：
协作最佳实践：
- 每个功能一个变更文件夹
：避免多个功能混在一起 -
PR中包含 spec：proposal、specs、design 作为 PR 描述 - 更新规格时审查
PR：增量规格像代码一样审查
/opsx:ffvs./opsx:continue？
示例：
归档前：
归档后：
更好的方法：使用 Git！
调整模板：
-
编辑模板文件：
-
添加更具体的指令：
-
在项目配置中添加规则：
-
重新生成：
使用tasks.md的复选框：
在实施期间检查：
快速路径：
创建simpleschema：
- 灵活性
：随时创建、实施、更新、归档 -
透明度：所有决策记录在 artifact 中 - 迭代性
：边学边改，无需一次性完美 - 可定制性
：自定义 schema 适应团队工作流
-
✅从小开始：先用简单功能理解流程 -
✅审查规格：在实施前审查 proposal 和 specs -
✅自由迭代：随时更新任何 artifact -
✅保持上下文卫生：实施前清除上下文
你用过OpenSpec吗？或者还在用vibe coding硬扛？评论区聊聊。
记住：完美的实践是通过迭代实现的，不是一次性做对所有事情。