SDD 三大框架对比

1 三大框架核心信息

2 三框架核心差异（互补不互斥）

1. OpenSpec：负责「为什么做这个变更」——管理变更上下文，适配遗留项目与轻量迭代

2. spec-kit：负责「该构建什么」——管理规格说明，为大型新项目提供完整流程与约束

3. Superpowers：负责「代码写对了吗」——管理质量保证，通过自动化流程保障交付质量

OpenSpec

OpenSpec 项目架构 & 工作流

核心定位：类 Git 逻辑，管理需求规格变更

1 项目架构（src/ 目录）

核心文件速记：init 控核心流程、archive 管归档、specs-apply 是 Delta 算法核心

2 核心工作流（标准四步）

3 两种工作流模式

4 Delta 规格系统（类 Git diff）

OpenSpec 安装 & 目录拆解

核心定位：三步安装，快速搭建 AI 协作基础设施

1 安装三步流程

2 目录结构拆解（openspec/）

3 命令 Profile 类型

4 跨工具语法差异

config.yaml · 项目的「AI 宪法」

核心定位：替代传统 project.md，以 主动注入 替代 被动读取，保障 AI 协作确定性

1 为什么用 config.yaml？

2 三层结构（从基础到核心）

3 context 三铁律（核心准则）

4 核心结论

主动注入 > 被动读取 context 每一字节都是 token 成本 → 精炼是优化性能的第一步

CLAUDE.md 分阶段交互

核心目标：通过分阶段控制，防止 AI 「错上加错」，大幅降低修复成本

1 核心规则

每完成一个 Phase → 暂停总结 → 等待用户确认 → 再继续下一个阶段

2 两种交互模式对比

3 关键结论

• 分阶段控制是 AI 协作的“刹车”，能把错误扼杀在早期阶段

• 修复成本差异巨大：50 行 vs 1000 行，本质是「小修小改」和「推倒重来」的区别

• CLAUDE.md 规则的核心，就是强制 AI 进入「暂停-确认-继续」的循环，避免一次性写死

OpenSpec 三步核心工作流 + 四件制品

核心目标：用「先设计、后编码」的方式，把返工时间压到最低

1 完整工作流（含可选步骤）

• 关键节点：propose 阶段生成全部四件制品，是整个流程的核心输入

2 四件制品详解（核心交付物）

3 效率对比：直接写代码 vs OpenSpec 流程

4 核心认知

• propose 不是写代码，而是交出设计方案给你审查

• 审查几十行的设计，比审查几百行的代码容易 10 倍

• 上游花 10 分钟打磨 proposal，能省下下游 2 小时返工

• 工程实践：先结构化需求 + 总结架构，再进行 propose

out-of-scope 关键点 & Review 不可跳过

核心原则：明确“不做什么” + 严格执行评审，杜绝 AI 越界与返工

1 AI 的「善意」陷阱

2 out-of-scope 实操

3 Review 不可跳过

4 反模式 #2：跳过提案打磨，直接 apply

5 完整 OpenSpec 闭环

完整 OpenSpec = in-scope 清单 + out-of-scope 清单 + review 通过 → AI 精准执行，绝不越界

/opsx:verify 三维验证 · 一页速记清单

核心定位：事后验证（代码写完后），通过 3C 模型查漏补缺，确保交付质量，而非“唯一防线”

1 三维验证框架（3C Model）

2 真实输出样例

3 输出三级判定

4 关键认知与边界

5 核心原则

1. verify 不阻止归档：即使存在 WARNING，用户仍可选择归档，拥有最终决定权

2. 第一道防线：verify 是质量把关的首要环节，但不是唯一防线

3. 省返工：通过早期校验，把问题扼杀在归档前，降低后期维护成本

Delta Spec——只写变化，不重写整个需求

1 全量 Spec vs Delta Spec 对比

2 Delta Spec 三种变更类型

• ADDED：新增需求

• MODIFIED：修改已有需求

• REMOVED：删除需求

3 归档行为

• ADDED：追加到主 spec

• MODIFIED：替换对应部分

• REMOVED：从主 spec 删除

4 为什么高效

• 每个 change spec 文件很小 → AI token 消耗少

• 不容易「丢东西」

• 精准聚焦当前变化

5 MODIFIED vs 新建 spec 决策规则

• 扩展已有模块 → 使用 MODIFIED

• 全新业务域（首次） → ADDED 新文件

• 判断依据：主 spec 里有没有对应内容？

6 核心结论

项目：开发一个可部署的个人品牌站

初始项目环境搭建+ OpenSpec 初始化

Step 1 全局配置 OpenSpec

Step 2 创建前端项目脚手架

Step 3 配置 OpenSpec 的 宪法

Step 4 创建项目宪法（CLAUDE.md）

Change 1 ：开发品牌站的 Hero-Section

Step 5 使用 Open Spec 的探索模式

Step 6 确定 Change 1的 提案

Step 7 开始分阶段执行Change 1的 代码生成

Step 8 针对 Change 1的apply 结果进行三维校验

Step 9 针对 Change 1 完成Spec归档

Change 2 ：开发品牌站的 navigation

Step 10 确定 Change 2的 提案

Step 11 确定 Change 2的 提案并开始构建代码！

Step 12 针对 Change 2的apply 结果进行三维校验

Step 13 针对 Change 2 完成Spec归档

Change 3 ：OpenSpec Delta Spec 的功能标记

Step 14 Change 3 提案 并 测试 修改的功能标记

Step 15 一次性完成 Change 3 的所有变更流程

Step 16 针对 Change 3 完成Spec归档

Change 4 ： 配置 About Section + SEO优化 + 部署上线

Step 17 Change 4 继续丰富个人品牌站

Step 18 Change 4 添加网站的 SEO优化策略

Step 19 单次执行多步的提案文件

Step 20 个人品牌站部署上线

项目升级-全栈

项目初始化，OpenSpec 配置

📎 参考文章

• 一些引用

• 引用文章