OpenSpec 轻量化 SDD 原理拆解 —— 完整整理版

2026-07-01

一句话摘要：本教程把讲师木鱼在 6 场直播中现场演示的 OpenSpec 与 Spec-Kit 全流程完整落盘，含 SDD 三大框架对照、四/七命令详解、propose → apply → verify → archive 实操、AI 学习助手全栈 demo、Spec-Kit 宪法五铁律。可直接作为团队引入 SDD 的启动手册。

TL;DR · 5 分钟速览

最短上手命令（30 秒版）：

# OpenSpec
npm install -g openspec        # Node.js ≥ 20.19.0
cd your-project && openspec init
# 然后在 Claude Code / Cursor 里说："propose 一个 change 叫 xxx, 我要..."

# Spec-Kit
uv tool install specify-cli
specify init --here --ai claude-code
# 然后依次: /constitution → /specify → /plan → /tasks → /implement

阅读路径

• 👣 零基础：0 → 1 → 2 → 4，跳读 3；再看 5 → 6
• 🚀 已会 OpenSpec，只想升 Spec-Kit：直接从第 5 章开始
• 🎯 只想抄宪法模板：跳到 6.4 + 附录 A
• 📚 只查命令：跳到附录 A / B

目录

• TL;DR · 5 分钟速览
• 阅读路径
• 第 0 章 · 前言：为什么要学 SDD
• 第 1 章 · SDD 三大框架全景
• 第 2 章 · OpenSpec 从零入门
• 第 3 章 · OpenSpec 进阶：Custom Profile 七命令
• 第 4 章 · 全流程实战：AI 学习助手
• 第 5 章 · OpenSpec 三大短板 + Spec-Kit 全景架构
• 第 6 章 · Spec-Kit 宪法怎么写
• 附录 A · 命令速查表
• 附录 B · OpenSpec ↔ Spec-Kit 概念对照
• 附录 C · 术语表
• 附录 D · 编者补注 / STT 口误校正
• 附录 E · 讲师个人观点摘录

第 0 章 · 前言：为什么要学 SDD

本章适合：完全没听过 SDD、或曾用 AI 编程但被“聊崩了”的同学 读完能做到：说清楚 SDD 与手写 prompt 的差异，判断自己是否该用

0.1 手写 prompt 踩过的三个坑

讲师木鱼在直播中反复复盘了自己前 4 周带学员手写 prompt 做的四个项目（chatbot / NL-to-SQL / OpenCore 二次开发 / RAG 文档审核）。手写 prompt 有两副面孔：

一个典型的联调坑（讲师直播 04 大约 12:00 处）：

“写好前端后让大模型串后端联调，如果不明确以谁为准约束另一方，大模型会在你不知情的情况下自己给你补一堆’补丁功能’——没有文档、没有痕迹，项目一扩大，随便一个 diff 就把你之前做好的功能覆盖掉。”

三个坑合起来就是“AI 写代码 → 项目失控”的根本原因：

1. 需求全堆在聊天框——上下文一多，AI 直接失忆
2. 架构和功能细节转头就忘——改新需求会冲烂老代码
3. 迭代必须手动维护规范文档——项目一复杂就无法交接、无法复盘

0.2 SDD 的核心价值主张

SDD（Spec-Driven Development，文档驱动开发）的定位一句话：

在 AI 编程时代，代码不再值钱，真正值钱的是那份不断迭代、可追溯的规范文档。

它的三大价值：

第 1 章 · SDD 三大框架全景

本章适合：想搞清楚 OpenSpec / Spec-Kit / Superpowers 到底怎么选 读完能做到：说清楚三者的定位差异，画出它们在开发流程时间线上的分工

1.1 三个框架的定位

三者常被并列讨论，但并非竞争关系，而是互补关系——你甚至可以把三个组合起来用：

1.2 盖房子比喻：思考 / 流程 / 变更

讲师给了一个高度形象化的类比：

1.3 开发流程时间线上的分工

沿着“想法 → 规范文档 → 技术设计 → 任务拆解 → 编码 → 审查 → 归档”这条时间线看：

想法 ──▶ 规范文档 ──▶ 技术设计 ──▶ 任务拆解 ──▶ 编码 ──▶ 审查 ──▶ 归档
                    ├─── OpenSpec ───┤
         ├────────────────────── Spec-Kit ──────────────────────┤
                              ├────── Superpowers ──────┤

• OpenSpec 覆盖“规范文档 → 技术设计”这一段
• Spec-Kit 从“规范文档”贯穿到“归档”全生命周期
• Superpowers 从“技术设计”开始约束 Agent 行为，直到代码归档

1.4 选型决策树

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

💡 讲师个人偏好：“我不太喜欢这些框架，更倾向自己手写维护文档规范。Spec-Kit 和 Superpowers 我用得比较多。”（04 直播中回答观众提问）

第 2 章 · OpenSpec 从零入门

本章适合：完全没用过 OpenSpec，想第一次跑通“从 0 到部署” 读完能做到：本地装好 OpenSpec、跑完 init → propose → apply → archive 四命令闭环、部署一个可访问的个人品牌站

2.1 OpenSpec 是什么

一句话：架在你和 AI 编程工具（Claude Code、Cursor、Codex 等）中间的一层“轻量层”，把所有对话中出现的架构、功能、技术栈自动结构化成 Markdown 图纸。

• 开源项目，通过 npm 全局安装
• Node.js 要求：≥ 20.19.0
• 兼容 24 种主流 AI 编程工具：Claude Code / Codex / Cursor / Windsurf / Google Antigravity / Copilot / Trae 等（讲师原话：“基本上主流工具都完美兼容”）

2.2 三大核心特性

额外亮点：专为已有项目设计。如果你想拉取一个开源项目（比如 OpenClaude）二次开发，又不想让上游更新覆盖自己已改的代码——OpenSpec 的文档驱动机制天然适合这种“选择性合并”。

2.3 四命令核心工作流

“像 Git 管理代码一样管理文档的变更”——记住这一张图：

openspec init            ← 项目初始化（选 IDE / 编程工具）
openspec propose <name>  ← 生成提案：落盘 proposal / design / spec / task
openspec apply <name>    ← 让 AI 编程工具按 spec 生成代码
openspec archive <name>  ← 完成后归档到主 spec

对齐的心智模型：

两种模式（讲师直播原话）：

• Core 模式：propose → apply → archive 三命令（本章讲这个）
• Custom Profile 模式：七命令精细化（第 3 章讲这个）

两种模式之间可通过 openspec profile preview 生成完整命令文件，再用 openspec profile update 切换。

2.4 项目目录结构

执行完 openspec init 后，会在项目根目录生成：

your-project/
└── openspec/
    ├── changes/          # 活跃变更区（新增/修改/删除的功能提案）
    │   └── <feature>/    # 每个功能一个子目录
    │       ├── proposal.md   # 为什么做 / 做什么 / 不做什么
    │       ├── design.md     # 技术设计
    │       ├── spec.md       # 系统规格（含 Given/When/Then）
    │       └── task.md       # 任务清单
    ├── specs/            # 完整规格库（归档后合并到这里）
    │   └── archive/      # 归档区（默认空）
    └── openspec.yaml     # 全局配置（对标 Claude 的 CLAUDE.md / Cursor 的 .cursorrules）

openspec.yaml 是最核心的控制文件，每次请求时都会被自动注入。你可以在里面写各种硬约束——具体写什么由你决定。讲师直播中自己项目的示例包含（这是讲师个人示范，不是框架默认）：

• context ≥ 200 words
• 每个 spec 场景数 ≤ 5（超出必须精简：删除历史背景、保留领域特定约束和非标准做法）
• 单文件 ≤ 2000 词
• 所有 API 行为必须用 Given / When / Then 场景描述

2.5 Delta 规格系统（New / Modify / Delete）

OpenSpec 用**“像 Git diff 一样精确描述变更”**管理三类修改：

changes/<feature>/ 目录里的每份 spec 都会明确标注属于哪一类，归档时才知道如何合并到主 specs/。

2.6 实战：个人品牌站从 0 到部署

目标：用 React + Vite + TypeScript + Tailwind CSS 做个人品牌展示站，通过 GitHub Pages 免费部署。

讲师直播用 Claude Code CLI 一步一步演示（时间戳约 15:00 – 30:00）。以下是可复用的提示词模板：

Step 1 · 环境搭建

# 先创建项目文件夹并进入
mkdir openspec-my-website && cd openspec-my-website
claude              # 打开 Claude Code CLI

在 Claude Code 里发送：

帮我全局安装 openspec 最新版本，地址是 https://github.com/tenshis/openspec，
使用 npm 安装方式。注意，安装完需要确认 Node.js 版本必须大于等于 20.19.0，
如果版本不够请提醒我升级。

Step 2 · 创建前端脚手架

帮我先创建一个 React + Vite + TypeScript 的项目，项目名叫 my-website。
创建完成后，安装配置 Tailwind CSS V4 版本。
确保项目可以正常启动，通过 npm run dev 启动后告诉我启动网址。

讲师本机 5173 端口被占，让 AI 改成 3000 端口后跑通。

Step 3 · 初始化 OpenSpec

⚠️ 这一步必须先退出 Claude Code，回到普通终端：

cd my-website
openspec init
# → 弹出编程工具选择框
# → 用空格选中 "Claude Code"，回车
# → 生成 openspec/ 目录

Step 4 · Propose 提案

回到 Claude Code CLI 继续对话：

帮我 propose 一个 change，名字叫 add-hero-section。
我要做一个个人品牌站的英雄区，包含头像、标题、简介、社交链接四个部分。
技术栈：React + Vite + TypeScript + Tailwind V4。
不做：不做后台管理，不做用户登录。

Step 5 · Apply

apply add-hero-section 这个提案，生成对应代码。

Step 6 · Archive

我验证过了功能都正常，请 archive add-hero-section。

Step 7 · 部署：git push 到 GitHub → 开启 Pages → 拿到访问链接。

打开 openspec 生成的项目文件推荐用 Cursor 或 VS Code（讲师个人习惯）。虽然 Claude Code CLI 里也能全流程操作，但一个可视化 IDE 便于快速检查生成的项目目录。

第 3 章 · OpenSpec 进阶：Custom Profile 七命令

本章适合：跑通了 Core 三命令，但被“AI 一口气自动开发全部内容”坑过 读完能做到：理解 core / custom 两种模式差异、七命令的功能分组、三条不同精细度的路径

3.1 Core 模式的三个短板

propose → apply → archive 跑通没问题，但真上工程会露馅：

3.2 七命令按功能的五个分组

讲课版本已从早期更多命令精简到 7 个，按功能分五组：

早期版本有 ff（快速前进）、batch archive（批量归档 + 冲突检测）等命令，最新版精简掉或归入其他命令。本教程口径以七命令为准，实际使用请以你安装的 OpenSpec 版本自带 help 为准。

3.3 三条精细化路径：Propose vs New→Continue vs New→FF

想生成一份 change 的四份制品（proposal / design / spec / task），可以选三条不同路径：

路径 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

长期开发用 think：

• 假设一个功能干三天才做完
• 每次收工前跑 openspec think <name> 同步中间态但不归档
• 明天继续 apply / continue 时能识别活跃变更、接着往下走

批量归档冲突处理（老版本有）：多个 change 同时修改相似功能，归档会根据实际代码实现决定最终技术方案回填主 spec —— 也就是“冲突时以代码为准”。

3.4 Explore 的三种提问类型

explore 命令不只是“和大模型对话”，讲师提到它支持三种提问模式（直播 04 约 4:00 处）：

具体命令语法请以最新版 openspec explore --help 为准。讲师直播中最常演示的是决策型。

第 4 章 · 全流程实战：AI 学习助手

本章适合：会跑 Core 模式了，想看进阶命令怎么在真项目里工作 读完能做到：用 explore 做方案对比、用 propose 写规范的三段结构、用 new + continue 逐步生成、用 verify 做三维验证

4.1 项目目标与技术栈

项目：前后端全栈的个人 AI 学习助手，包含四大模块：

技术栈（各模块用的栈略有不同）：

4.2 决策型 Explore：让 AI 给方案 A / B 打分

讲师演示了 explore 命令决策型提问的用法：

你现在要把「个人品牌站」改造成「个人学习助手」。请你比较：

方案 A：保留 Hero 骨架，内部重新布局
方案 B：新建 Dashboard 组件，将品牌站替换

考虑核心因素：
1. 已有代码功能的复用程度
2. 后续添加新功能的便捷性
3. 前端样式的迁移成本

给我推荐方案，强调 ASCII 展示新旧对比。

AI 会回复：

• 量化每个组件的耦合度（哪些能复用、哪些能改造、哪些完全用不到）
• 明确告诉你“真正能复用的代码不到总量的 1/3”
• 直接推荐“方案 A 是假复用，走方案 B 重构”

4.3 Propose 的三段结构：Why / What / Not doing

讲师强调 Propose 时必须写明三段，尤其是 not doing：

propose 一个 change：将品牌站重构为 Study Dashboard，包含：
  - 左侧导航栏
  - 学习数据统计卡片
  - 每日目标清单
  - AI 建议学习面板
  - 周月趋势图

out of scope（不做）：
  - 后端 API（后面单独做）
  - AI 功能
  - 用户认证

要求：使用 mock 数据。

为什么反复强调 not doing？ —— 大模型发散能力很强，你不明确排除，它会在你不知情的情况下自己“补开发”一堆你根本不需要的东西。

4.4 精细化路径演示：new → 四次 continue → apply

以“用户认证”模块为例，讲师完整演示了路径 B。

Step 1 · new 建目录

openspec new user-auth
# → openspec/changes/user-auth/ 只创建了空目录 + 一个骨架 openspec.yaml
# → 不生成任何 markdown 文件

Step 2 · 第一次 continue（生成 proposal）

continue：为 study-dashboard 实现一个 FastAPI 后端 + JWT 的用户认证，需包含：
  - 用户注册和登录（JWT）
  - Token 刷新
  - 用户 Profile（头像、连续学习天数、用户等级）

技术方案：FastAPI + SQLAlchemy + MySQL（数据库迁移用 Alembic）

out of scope（不做）：后台管理

→ 生成 proposal.md

Step 3 – 5 · 后续三次 continue

openspec continue   # 第 2 次: 生成 design.md
openspec continue   # 第 3 次: 生成 spec.md（含 Given/When/Then 场景）
openspec continue   # 第 4 次: 生成 task.md（按 phase 拆分）

生成的 spec 里，每个 API 都有场景驱动的描述：

Scenario: 登录成功
  Given: 用户输入正确的邮箱和密码
  When: 提交登录请求
  Then: 返回 access_token 和 refresh_token

Scenario: 未携带 token 获取 profile 成功  # ← 讲师直播原文这么写的
Scenario: Token 过期刷新
...

Step 6 · 校验 + Apply + Archive

请对刚生成的 spec 进行校验，检查：
  1. 单个文件是否超过 2000 词
  2. 所有 API 行为是否使用了 Given/When/Then 模式
  3. 每个 spec 场景是否超过 5 个
     - 若超出：删除历史背景，保留领域特定约束和非标准做法

建议在生成 proposal 之后、apply 之前进行过度设计检查。

校验通过后：

执行 apply user-auth，然后 archive。

4.5 三维验证（正确性 / 完整性 / 一致性）

Verify 的三个维度：

这一步为什么在 OpenSpec 里比较简陋：三维验证的检查项必须由你在 prompt 里明确列出。如果你没写“检查是否走 Given/When/Then”，它就不会主动发现。

讲师提到的实用做法：把项目的校验规则提炼成一个“skills 提示词模板”或 skills 文件，每次生成新模块时都调用一次做前置校验。

4.6 最终效果

Dashboard 页面产出（讲师直播 04 约 28:00 处截图）：

┌──────────┬─────────────────────────────────────┐
│  概览    │                                     │
│  学习目标 │   [ 学习数据统计卡片 ]              │
│  AI建议  │                                     │
│  趋势    │   学习任务目标                      │
│          │                                     │
│  [ user] │   AI 学习建议                       │
│          │                                     │
│          │   [ 周和月趋势图 ]                  │
└──────────┴─────────────────────────────────────┘

用户认证走通后能完成注册 → 登录 → 拿到 Dashboard 访问权限的完整闭环。

第 5 章 · OpenSpec 三大短板 + Spec-Kit 全景架构

本章适合：会用 OpenSpec 了，遇到复杂项目或多人协作场景想升级 读完能做到：说清楚 OpenSpec 的结构性短板、Spec-Kit 五大子系统各是什么、五命令 MVP 和九命令全流程的差异

5.1 OpenSpec 的三大短板

学完 OpenSpec 反过来看，它有三个结构性问题（不是使用问题，而是设计定位的限制）：

5.2 Spec-Kit 的核心工作流（7 步）

Spec-Kit 是可插拔的完整 SDD 脚手架，社区生态广泛。核心流程：

①  Constitution     ← 项目宪法（对标 OpenSpec 的 openspec.yaml）
       ↓
②  Specify          ← 写需求规格（对标 OpenSpec 的 propose）
       ↓
③  Clarify（可跳过） ← 引导式提问、盲点发现
       ↓
④  Plan             ← 生成技术方案（含技术栈选型、模块拆分）
       ↓
⑤  Tasks            ← 按 Phase 拆分子任务
       ↓
⑥  Analyze（可跳过） ← 一致性分析
       ↓
⑦  Implement        ← 执行代码

关键差异 vs OpenSpec：Spec-Kit 每一步之间默认停下等人工审核（Gate）——推崇“每一步产出必须经过人类确认”，因为 web coding 本身是黑盒，Spec 需要人来掌控。

5.3 五大内置子系统全景

Spec-Kit 内部由五个子系统协作：

                   用户命令行
                       ↓
              ┌────────────────┐
              │  CLI 主体（调度）│  ← 唯一面向用户的入口
              └────────────────┘
                ↓            ↓
        (workflow 引擎)   (手动 workflow)
              ↓                 ↓
      ┌──────────────────────────────┐
      │      Agent 注册中心           │
      │  ↓ 集成 Claude Code / Codex   │
      │  ↓ Cursor / Windsurf / etc.   │
      └──────────────────────────────┘
              ↑                 ↑
       Extension 系统      Preset 系统
       （插件市场：加法）   （主题包：替换）

5.4 五命令 MVP vs 九命令全流程

注意默认行为：讲师直播中提到 Spec-Kit 默认是全命令模式（和 OpenSpec 相反）。要切到 Lean 精简模式需要手动切换（见 5.5）。

5.5 Preset（Lean 精简）与 Extension 生态

切换到 Lean 精简模式：

specify preset add lean

前后对比（讲师直播实测）：

Preset 抽取每个 skill 的精华、大幅压缩输入 token，适合简单任务不需要大量指令的场景。

Extension 搜索与安装：

specify extension search      # 搜索社区插件
specify preset search         # 搜索主题包

装了心仪的插件后，直接告诉 AI 编程工具“帮我把 XX 装到本地”就行。OpenSpec 有但 Spec-Kit 缺失的 archive 命令，可以通过插件市场补齐。

项目初始化：

# 先退出 Claude Code / Cursor 等编程工具，回到普通终端
specify init --here --ai claude-code
# → 生成两个目录：.claude/  和  .specify/
# → .specify/memory/constitution.md 是空宪法模板，需要你填内容

第 6 章 · Spec-Kit 宪法怎么写

本章适合：已经初始化了 Spec-Kit，卡在 constitution.md 不知道写什么 读完能做到：知道好宪法的五铁律六原则，手上有一份可以直接改的 V1.0 模板

6.1 Constitution 是给 AI 看的，不是给人看的

划重点：

Constitution 是写给 AI 在执行代码时看的约束，不是给人看的产品文档。

因此：术语要精确、边界要清楚、大白话要转成专业用词。如果你不懂专业术语，先和大模型多聊几轮，让它把你的表达“转译”成 AI 能识别的技术语言。

宪法通常写这四类内容：

1. AI 行为边界（能做什么 / 不能做什么）
2. 禁止项（把红线写死，避免 AI 发散）
3. 纠偏落到技术细节（每一步可能踩的坑用技术语言标出来）
4. 代码复用策略（AI 天然倾向新建函数/类，不复用旧代码 —— 必须显式强制）

6.2 好宪法 vs 坏宪法：五条铁律

讲师提炼的五条铁律（06 直播 25:00–28:00 处，为便于对照编者编号）：

6.3 写作六原则

6.4 实战：AI 写作助手宪法 V1.0

注意：以下模板是编者根据讲师直播中的口头描述整合的完整 Markdown（讲师直播中是分段说明约束、然后让 Claude Code 一次性生成），不是从视频画面 OCR 出的原文。可作为开箱即用的模板参考，实际请根据自己项目调整。

讲师直播中给出的完整需求 prompt（06 大约 31:00 处，逐字保留）：

帮我先去写一份 constitution，这个项目就是我们的这个 AI 的写作助手。
先说清楚我们要做什么、不做什么。我们做的是一个纯前端的文本运算工具，
希望用户能够贴一段文字，选一个场景，然后我们使用这个 DeepSeek
可以去返回润色后的结果。只有这么一件事，它不是一个 CMS，也不是一个
协作的平台，不处理敏感数据，也不需要注册登录。

紧接着讲师逐条列出的硬约束（06 大约 32:00–34:00 处）：

• 技术栈硬约束：React 19 + Vite + Tailwind CSS V4；不允许其他 CSS 框架 / CSS Modules
  • Why：Tailwind 原子类已覆盖样式需求
• 代码复用：同一 UI 模式不出现两次；所有 API 走统一目录规范，不允许直接 fetch；场景 prompt 模板统一放某目录
• 项目规范：不加 React Router、不加多余框架
  • Why：项目体量不需要
• 质量约束：TypeScript 严格模式；一个组件一个文件；场景 map 配置化
• AI 接口：DeepSeek 固定模型（讲师原话“DC 固定用这个模型”未明确模型 ID）；开发环境需处理跨域；API Key 放环境变量
• 版本标识：V1.0；使用中文描述

由 AI 生成、编者整合的完整模板：

# AI Writer Constitution V1.0

## 项目定位
- 单页 SPA，纯前端文本润色工具
- 用户贴一段文字 → 选一个场景 → 用 DeepSeek 返回润色结果
- 不是 CMS、不是协作平台、不处理敏感数据、不需要注册登录

## 技术栈（硬约束，不可商量）
- React 19（不允许其他版本）
- Vite 构建
- 样式使用 Tailwind CSS V4
  Why: Tailwind 原子类已覆盖所需样式,禁止引入其他 CSS 框架/CSS Modules

## 代码复用原则
- 同一 UI 模式禁止出现两次;若出现,必须抽象为组件
- 所有 API 走统一目录规范,禁止直接 fetch
- 场景 prompt 模板统一放在 src/prompts/scenarios.ts

## 项目结构
- 不引入 React Router(项目体量不需要)
- 场景 map 配置化,一个组件一个文件

## 质量约束
- TypeScript strict 模式
- 每个组件一个文件
- 场景配置走 map,禁止 if-else 分支

## AI 接口
- DeepSeek 固定模型(具体模型 ID 待补充)
- 开发环境需处理跨域(Vite proxy)
- API Key 放在 .env.local,禁止硬编码

## 版本
- V1.0(2026-07-01)
- 描述语言:中文

这份宪法有效的五个理由（对照 6.2 五铁律）：

1. ✅ 前 4 行就把“不是什么”划完了（铁律 1）
2. ✅ 每条硬约束都写了 Why（铁律 3）
3. ✅ 明确列出版本号：React 19、Tailwind V4（铁律 4）
4. ✅ 有显式的“代码复用原则”专章（六原则之一）
5. ✅ 全文 200+ 字，非常精简（铁律 3 长度要求）

产出后：AI 会把内容写入 .specify/memory/constitution.md，后续所有 specify / plan / tasks / implement 命令都会自动注入这份宪法作为硬约束。

附录 A · 命令速查表

OpenSpec 命令

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

附录 B · OpenSpec ↔ Spec-Kit 概念对照

附录 C · 术语表

附录 D · 编者补注 / STT 口误校正

以下条目为讲师直播 STT 转录稿中的口误或不明处，整理时按最合理猜测处理。⚠️ 标记为“待确认”的项，实际以视频画面为准：

附录 E · 讲师个人观点摘录

以下是讲师木鱼在直播中透露的主观偏好，作为对客观教程的补充。不必照单全收，做参考：

• “我不太喜欢这些框架，更倾向自己手写维护文档规范”

  • 讲师有比较深的开发经验，能自己控制中间过程；框架对他反而是负担
  • 对新手 / 无经验开发者，讲师承认框架“是有价值的、有很多用户市场”

• “这三个框架里，Spec-Kit 和 Superpowers 我用得比较多”

  • OpenSpec 太轻，讲师个人觉得价值不够
  • Spec-Kit 生态更完整；Superpowers 直接约束 Agent 行为，讲师喜欢这种硬约束

• 对 explore 的评价：

  • “使用 open spec 它是可以协同或者是降低一下你在项目构建和管理文档的规范”
  • “如果你用的比较熟悉，其实你也会发现，可能自己在进行自定义的过程中会用得更加顺手”

• 对 Custom Profile 路径 B 的评价：

  • “使用 coding 好像也蛮累的，因为你需要不断的去进行一个介入”
  • 承认精细化是有代价的：细粒度控制 vs. 使用便捷性的权衡

系列后续：本文档整理自 SDD 系列前两个框架 —— OpenSpec 与 Spec-Kit。第三个框架 Superpowers（Agent 行为约束）在后续直播中展开。

反馈 / 修订：如发现术语错误或步骤缺失，欢迎标注对应“发言人 mm:ss”时间戳，便于回视频原文核对。