速查卡 A · OpenSpec + Spec-Kit 命令对照表

规范驱动开发（OpenSpec / Spec-Kit）第 4 / 5 篇

完整原理与实战详见：OpenSpec+SpecKit 完整整理版

写作日期：2026-07-01｜复核：2026-09-07

📌 复核：表里的 /opsx: 命令仍与上游 README 一致，未改。

🚨 速查卡这种体裁，过期的代价比长文更大 —— 读者是照着敲的， 不会像读教程那样顺带看上下文。而这张表 2026-08-27 恰好出过一次错： 命令曾被写成 shell 子命令（openspec propose）， 而正确写法是 AI 工具里的斜杠命令 /opsx:propose。

🔔 判据与新手教程共用， 跑那篇顶部的两条即可（零成本）。 ⚠️ 判读时注意：三条命令都查到 ≠ 判据有效 —— 还要拿一个编造的（opsx:frobnicate）去查一次，必须查不到。 否则上游 README 一改结构，「全中」和「正则恒真」长得一模一样。

30 秒上手

# OpenSpec（Node.js ≥ 20.19.0）
npm install -g @fission-ai/openspec
cd your-project && openspec init

# Spec-Kit
uv tool install specify-cli
specify init --here --ai claude-code

OpenSpec 命令表

⚠️ 两种命令不要混。OpenSpec 的日常工作流不是在终端敲的， 是在 AI 编程工具里输入的斜杠命令（和下方 Spec-Kit 的 /specify 同理）。 终端里的 openspec xxx 只负责装配与查询。核对于 v1.11.0。

终端命令（shell 里敲）

命令 用途 分组
openspec init 项目初始化（选 IDE） 环境
openspec update 把当前 profile 的命令文件写入 AI 工具 环境
openspec config list 查看当前 profile 与它启用的工作流 模式切换
openspec config profile <core|custom> 切换 core / custom 模式（改完要跑 openspec update） 模式切换
openspec list / openspec show <name> 列出 / 查看变更与规格 查询
openspec validate <name> 校验变更与规格 验证
openspec archive <name> 归档到主 spec 生命周期

斜杠命令（在 AI 编程工具里输入）

命名形态随工具而变：Claude Code / Codex 用 /opsx:propose， Cursor 与 GitHub Copilot 用 /opsx-propose，Amazon Q 用 @opsx-propose。 openspec init 结束时会打印你所选工具的正确形态。

命令 用途 分组 core profile
/opsx:propose <name> 一键生成 proposal + design + spec + task 创建 ✅
/opsx:explore 只对话不落盘（决策型 / 开放型 / 约束型） 创建 ✅
/opsx:new <name> 只建目录 创建（精细化） 需 custom
/opsx:continue [msg] 逐步生成下一份制品（proposal→design→spec→task） 创建（精细化） 需 custom
/opsx:apply <name> 根据 spec 生成代码 实现 ✅
/opsx:verify <name> 三维验证（正确性 / 完整性 / 一致性） 验证 需 custom
/opsx:sync <name> 同步中间态但不归档（长期开发用） 生命周期 ✅
/opsx:archive <name> 归档到主 spec 生命周期 ✅
/opsx:onboard 官方 10–30 分钟引导教程 引导 需 custom

📌 core profile 默认启用 6 个：propose、explore、apply、update、sync、archive （openspec config list 可直接看到这一行）。其余要切到 custom。

Spec-Kit 命令表（默认全命令模式）

命令 用途 MVP 必需
specify init --here --ai <tool> 项目初始化 ✅
/constitution 生成 / 编辑项目宪法 ✅
/specify 写需求规格 ✅
/clarify 引导式提问、盲点发现 可跳过
/plan 生成技术方案 ✅
/tasks 拆分子任务 ✅
/analyze 一致性分析 可跳过
/implement 执行代码 ✅
specify extension search 搜索插件市场 —
specify preset search 搜索主题包 —
specify preset add lean 切换到 Lean 精简模式（skill 压缩 80%+） —

概念对照

概念 OpenSpec Spec-Kit
项目宪法 openspec.yaml .specify/memory/constitution.md
需求提案 propose /specify
技术方案 内嵌 propose 生成的 design.md /plan（独立一步）
任务拆分 内嵌 propose 生成的 task.md /tasks（独立一步）
代码执行 apply /implement
一致性校验 verify + 用户自定义规则 /analyze（内置 workflow）
盲点发现 ❌（需自己 explore） /clarify
归档 archive（内置） ❌（需装 archive 扩展）
中间态 think Git 分支天然管理
默认模式 Core（3 命令） 全命令（9 命令）
精简模式切换 profile update preset add lean
插件生态 无独立市场 Extension（加法）+ Preset（替换）

三条精细化路径（OpenSpec Custom Profile）

路径 A（Core 模式，默认）：
    propose  →  一键生成全部 4 份文件

路径 B（精细化，逐步审查）：
    new                      # 只建目录
    continue "..."           # 第 1 次: 生成 proposal（可注入自定义描述）
    continue                 # 第 2 次: 生成 design
    continue                 # 第 3 次: 生成 spec
    continue                 # 第 4 次: 生成 task

路径 C（快速前进，早期版本）：
    new
    ff "<需求描述>"          # 一次性触发内部 propose 流程

该选哪条：新手 → A；工程化 → B；已弃用 → C。

Spec-Kit 完整工作流

①  /constitution     ← 项目宪法（对标 openspec.yaml）
       ↓
②  /specify          ← 写需求规格
       ↓
③  /clarify（可跳过） ← 引导式提问、盲点发现
       ↓
④  /plan             ← 生成技术方案
       ↓
⑤  /tasks            ← 按 Phase 拆分子任务
       ↓
⑥  /analyze（可跳过） ← 一致性分析
       ↓
⑦  /implement        ← 执行代码

关键差异 vs OpenSpec：Spec-Kit 每一步默认停下等人工审核（Gate）——推崇“每一步产出必须人类确认”。

选型决策树

你的情况？
├── 完全没写过项目 / 需求都提不清
│   └── 用 Spec-Kit（有 clarify 引导式提问）
│
├── 有一定技术判断力，想快速跑通 MVP
│   └── 用 OpenSpec Core 模式（4 命令搞定）
│
├── 有一定技术判断力，工程要长期迭代
│   └── 用 OpenSpec Custom Profile（7 命令精细化）
│
├── 团队协作 / 多人开发 / 强规范要求
│   └── 用 Spec-Kit（Constitution 硬约束）
│
└── 已经很懂技术，只想让 AI 少乱写
    └── 用 Superpowers（约束 Agent 行为）或干脆手写 prompt

← 返回 Agent 开发