破局 AI 编码乱象：SDD 规范驱动 + OpenSpec+SuperPowers 双框架，让 AI 写对每一行可追溯代码

在AI编码助手飞速迭代的今天，越来越多的开发者习惯把需求丢给AI，看着屏幕上瞬间生成的几百行代码，难免会产生一种"开发效率翻倍"的错觉。但只有真正上手落地才会发现，"写代码"从来都不是软件开发中最难的环节，写对代码、写出符合设计意图、覆盖所有场景且无冗余的代码，才是困扰大多数团队的核心痛点。

AI能快速响应需求输出代码，却无法自动理解项目的设计边界、业务场景和技术规范，更不会主动规避潜在的技术债。如果没有一套完善的规范驱动工作流来约束AI的行为，所谓的"AI写代码"，最终很可能变成"AI制造技术债"，不仅无法提升效率，反而会在后期维护中投入更多的时间和人力成本。

这就是规范驱动开发（SDD，Spec-Driven Development）应运而生的原因。它的核心逻辑很简单，就是"先想清楚再动手"，在让AI写代码之前，先明确需求规范、设计标准和验收条件，用规范文档约束AI的每一步行为，再通过验证环节确保代码符合预期。今天我们就来详细拆解两个落地SDD理念的核心框架，OpenSpec和Superpowers，看看它们如何解决AI编码的"不规范"痛点，以及如何在实际开发中灵活运用。

一、先搞懂：什么是规范驱动开发（SDD）

在聊具体框架之前，我们先厘清SDD的核心逻辑，以及它和传统AI辅助编码的本质区别。很多开发者之所以用不好AI编码助手，核心问题就在于没有建立"先规范后编码"的意识，陷入了"需求→写代码→返工"的恶性循环。

1.1 传统AI辅助编码的痛点

传统的AI辅助编码流程非常简单粗暴，大致可以分为四步：用户模糊描述需求，AI直接输出代码，用户手动检查代码，发现不符合预期后重新提交需求让AI改写。这个流程看似高效，却存在三个致命问题。

首先是需求传递偏差。用户对需求的描述往往是碎片化的，比如"写一个后台服务启动检查功能"，没有明确启动失败的处理逻辑、是否需要阻塞主程序、兼容哪些服务类型等细节。AI只能根据字面意思猜测，输出的代码很可能偏离实际需求。

其次是缺乏可追溯性。如果代码出现问题，无法追溯到最初的设计意图，不知道为什么要这么写，也不知道当时的技术选型逻辑，后期维护时只能逐行排查代码，效率极低。

最后是技术债积累。AI生成的代码可能存在冗余、不规范、兼容性差等问题，一次两次的返工或许可以接受，但长期下来，这些不规范的代码会不断积累，形成难以清理的技术债，严重影响项目的可扩展性和稳定性。

1.2 SDD的核心逻辑与优势

SDD的思路完全颠覆了传统AI辅助编码的模式，它把"规范"放在了编码之前，形成了一套闭环工作流：用户描述需求，生成规范文档，AI按规范实现代码，最后按规范验证代码。整个流程的核心就是"用文档约束行为，用验证确保正确"。

相比于传统模式，SDD有三个非常明显的优势。第一，需求传递更精准。规范文档会把模糊的需求拆解成明确的目标、场景、验收条件，AI只需严格按照文档执行，就能减少需求偏差。第二，开发过程可追溯。每一步变更都有规范文档支撑，后期出现问题时，能快速定位到设计环节，找到问题根源。第三，减少技术债。规范文档会明确代码标准、技术选型和测试要求，AI生成的代码更规范，后期维护成本大幅降低。

简单来说，SDD不是否定AI的效率，而是用规范给AI"立规矩"，让AI的高效发挥在正确的轨道上，实现"高效且规范"的开发目标。而OpenSpec和Superpowers，就是将SDD理念落地的两个核心工具，它们虽然侧重点不同，但都能有效解决AI编码不规范的问题。

二、OpenSpec：规格驱动的变更管理框架

OpenSpec是一个结构化的开发工作流框架，它的核心思想是"每次变更都有完整的设计文档可追溯"。需要注意的是，它不是一个独立的工具，而是一套可以嵌入在任何AI编码助手中的工作流规范，通过简单的命令就能驱动整个开发流程，尤其适合需要长期维护、注重变更追溯的项目。

2.1 OpenSpec快速上手：安装与初始化

OpenSpec基于Node.js开发，安装和初始化过程非常简单，只需两步就能完成。

首先是安装，打开终端，执行以下命令，全局安装最新版本的OpenSpec：

npm install -g @fission-ai/openspec@latest

安装完成后，进入你的项目目录，执行初始化命令，生成OpenSpec所需的基础目录结构：

cd your-project
openspec init

初始化完成后，项目根目录会生成一个名为"openspec"的文件夹，里面包含了规范文档、变更记录等核心目录，后续所有的规范编写和变更管理都将在这个文件夹中进行。

2.2 核心概念：Artifact链，让每一步变更都可追溯

OpenSpec的核心是一条"Artifact依赖链"，所谓Artifact，就是每一个环节生成的规范文档，这些文档相互关联、层层细化，形成了一套完整的变更追溯体系。这条依赖链的完整流程如下：

proposal.md → design.md → specs/*.md → tasks.md → 代码实现 → 归档

这条链条上的每一个Artifact都有明确的职责，缺一不可，我们逐个拆解它们的核心作用。

（1）proposal.md：变更提案，明确"为什么做"

proposal.md是整个变更的起点，核心作用是阐述"为什么要做这次变更"，相当于变更的"立项报告"。它不需要太复杂的技术细节，重点包含三个核心内容：变更的原因、变更的目标与非目标、变更的影响范围。

比如我们要做"启动时检查并拉起后台服务"的变更，proposal.md中就需要明确：当前后台服务可能存在未启动的情况，导致核心功能无法正常使用，这是变更的原因；变更的目标是启动项目时自动检查服务状态，未启动则自动拉起，非目标是不改变服务本身的运行逻辑；影响范围是项目启动流程、后台服务依赖模块，不影响其他业务模块。

（2）design.md：设计决策，明确"怎么做"

有了提案之后，就需要明确"怎么做"，这就是design.md的核心作用。它主要记录技术方案的选择、替代方案的对比，以及潜在的风险评估，确保技术选型的合理性和可行性。

还是以"启动时检查并拉起后台服务"为例，design.md中需要明确：选择复用项目中已有的ServiceUtils工具类，减少代码冗余；替代方案是重新编写检查逻辑，对比后发现复用工具类更高效、更稳定；潜在风险是ServiceUtils版本兼容问题，解决方案是先验证工具类的可用性，必要时进行版本适配。

（3）specs/*.md：需求规格，明确"做成什么样"

specs目录下的文件是整个规范的核心，它明确了变更的具体需求和验收条件，也是AI实现代码的主要依据。每个spec文件都采用"Requirements + Scenarios"的格式，其中Scenarios用"WHEN/THEN"的句式，明确不同场景下的预期行为。

比如针对后台服务启动检查的spec文件，会包含4个核心场景：WHEN后台服务未注册，THEN提示服务未注册，不执行拉起操作；WHEN后台服务已运行，THEN不执行任何操作，输出服务正常提示；WHEN后台服务未运行但已注册，THEN自动拉起服务，输出拉起成功提示；WHEN服务拉起失败，THEN输出失败提示，不阻塞主程序启动。

（4）tasks.md：任务清单，明确"分几步做"

specs文件明确了"做成什么样"，而tasks.md则将需求拆解成可执行的具体任务，每个任务都是一个可勾选的checkbox，确保AI能按步骤实现，不遗漏任何细节。

比如后台服务启动检查的tasks.md，会拆解成3个核心任务：第一步，在项目启动入口添加服务检查逻辑，调用ServiceUtils工具类；第二步，实现4个场景的判断逻辑，对应specs中的场景要求；第三步，添加日志输出，记录服务检查和拉起的结果。

（5）代码实现与归档：确保变更可追溯

完成上述所有Artifact文档后，就可以让AI按tasks.md中的任务逐步实现代码。代码实现完成后，通过验证环节确认符合specs要求，最后进行归档，将所有Artifact文档和代码变更归档到指定目录，形成完整的变更历史，方便后续查询和追溯。

2.3 OpenSpec工作流程：用命令驱动全流程

OpenSpec提供了一组简单的命令，无需复杂操作，就能驱动整个SDD流程，从需求探索到变更归档，每一步都有对应的命令支撑，我们整理了常用命令的作用和说明，方便大家快速查阅。

命令	作用	说明
/opsx:explore	探索模式	自由讨论需求、技术方案，不写代码，只聚焦于"为什么做"和"怎么做"
/opsx:propose	提案	生成proposal.md，并自动规划后续需要的所有Artifact文档
/opsx:ff	快速通道	一次性生成所有Artifact文档，适合简单需求，节省时间
/opsx:apply	实现	按照tasks.md中的任务，逐一步骤实现代码，每完成一个任务自动验证
/opsx:verify	验证	对照所有Artifact文档，检查代码是否符合规范和需求
/opsx:archive	归档	将完成的变更（所有Artifact文档+代码）归档，形成可追溯的历史记录

2.4 典型使用流程：以"启动时检查并拉起后台服务"为例

理论不如实践，我们以"启动时检查并拉起UniCloudService后台服务"为例，完整演示OpenSpec的使用流程，让大家更直观地理解如何用它约束AI编码。

第一步：快速生成所有Artifact文档

由于这个需求相对简单，我们可以使用快速通道命令，一次性生成所有规范文档。在AI编码助手中输入以下命令：

/opsx:ff 启动时检查并拉起 UniCloudService 后台服务

执行命令后，AI会自动在openspec/changes目录下生成一个活跃变更文件夹，里面包含了4个核心Artifact文档：

1. proposal.md：阐述为什么需要这个变更，比如"当前UniCloudService可能存在未启动状态，导致依赖该服务的功能无法正常使用，需要在项目启动时自动检查并拉起，提升系统稳定性"。

2. design.md：确定技术方案，比如"复用项目中已有的ServiceUtils工具类，调用其checkService和startService方法；启动失败时不阻塞主程序，仅输出日志提示；替代方案为重新编写工具类，对比后选择复用，提升开发效率"。

3. specs/unicloud-service-startup/spec.md：明确4个核心场景，覆盖未注册、已运行、未运行、启动失败四种情况，每个场景都用WHEN/THEN句式描述预期行为。

4. tasks.md：拆解3个可执行任务，每个任务都有明确的执行要求，比如"任务1：在项目启动入口（src/index.js）导入ServiceUtils，添加服务检查触发逻辑；任务2：实现场景判断逻辑，对应specs中的4个场景；任务3：添加日志输出，记录检查结果和拉起状态"。

第二步：让AI按任务实现代码

生成所有规范文档后，输入以下命令，让AI按tasks.md中的任务逐步实现代码：

/opsx:apply

执行这个命令后，AI会逐个处理tasks.md中的任务，每个任务完成后，会自动对照specs文件中的场景要求进行验证，确保代码符合预期。比如完成任务2（场景判断逻辑）后，AI会自动检查是否覆盖了所有4个场景，是否符合每个场景的预期行为，若有遗漏或错误，会自动修正。

第三步：变更归档，形成可追溯记录

代码实现和验证完成后，输入以下命令进行归档：

/opsx:archive

执行命令后，OpenSpec会将当前的活跃变更文件夹，归档到openspec/changes/archive目录下，并以"日期-变更描述"的格式命名，比如"2026-03-25-start-unicloud-service"。归档完成后，这个变更的所有规范文档、代码实现都被完整保存，后续如果需要查询这个变更的设计思路、实现步骤，直接查看归档目录即可，实现了变更的全流程可追溯。

2.5 独特设计：主spec + delta spec体系，实现知识积累

OpenSpec最具特色的设计，就是它的"主spec + delta spec"体系，这套体系能实现项目级规格知识库的长期积累，让规范文档越用越完善，避免重复编写。我们先来看一下它的目录结构：

openspec/
├── specs/                          # 主 specs（项目级知识库）
│   └── disk-mount/spec.md
│
└── changes/                        # 变更目录
    ├── start-unicloud-service/     # 活跃变更
    │   ├── proposal.md
    │   ├── design.md
    │   ├── specs/                  # delta specs（变更级）
    │   │   └── unicloud-service-startup/spec.md
    │   └── tasks.md
    │
    └── archive/                    # 已归档变更
        └── 2026-03-25-start-unicloud-service/

从目录结构可以看出，OpenSpec的spec分为两类：主spec和delta spec。

主spec位于openspec/specs目录下，是项目级的规格知识库，按功能模块组织，比如disk-mount（磁盘挂载）、user-auth（用户认证）等，包含了项目中所有核心功能的规范，是团队共享的基础规范。

delta spec位于每个变更的specs目录下，是针对本次变更新增或修改的规范，只包含与本次变更相关的内容，不需要重复编写主spec中已有的规范。当变更归档时，OpenSpec会自动将delta spec中的内容同步到主spec中，更新项目级知识库。

这种体系的优势非常明显，一方面，每次变更只需编写与自身相关的delta spec，节省规范编写时间；另一方面，主spec会随着每次变更不断完善，形成可查询、可复用的知识积累，后续新的开发需求可以直接参考主spec，避免重复设计，提升团队协作效率。

三、Superpowers：多代理协作的完整开发工作流

如果说OpenSpec侧重"变更追溯和知识积累"，那么Superpowers则侧重"执行质量和自动化审查"。Superpowers是由Jesse Vincent开发的开源项目，它为AI编码代理提供了一套完整的软件开发工作流，支持Claude Code、Cursor、Codex、Gemini CLI等多个平台，核心特色是"子代理驱动开发"和"强制TDD"，能让AI像有纪律的开发团队一样工作。

3.1 核心概念：Skills组合，定义AI的每一步行为

Superpowers的核心是"Skills组合"，所谓Skills，就是一组可组合的指令文件，每个Skill都是一份Markdown格式的文档，定义了AI在特定开发阶段应该做什么、怎么做。这些Skills按功能分类，相互配合，构成了完整的开发工作流。

我们整理了Superpowers的核心Skills分类、具体内容和职责，方便大家快速理解：

类别	Skills	职责
协作	brainstorming	通过苏格拉底式对话，提问引导需求梳理，对比不同方案，输出完整设计文档
规划	writing-plans	将需求拆分为2-5分钟可完成的bite-sized tasks，确保任务可执行、无遗漏
执行	subagent-driven-development	为每个task派遣独立子代理，负责代码实现和自审查
测试	test-driven-development	强制遵循RED-GREEN-REFACTOR循环，确保代码有完善的测试覆盖
审查	requesting-code-review	两阶段审查，先检查Spec合规性，再审查代码质量
Git	using-git-worktrees	创建隔离工作空间，验证编译基线，避免影响主分支
收尾	finishing-a-development-branch	负责分支合并、创建PR、保留或丢弃分支，完成开发收尾
这些Skills可以根据需求灵活组合，比如简单需求可以组合brainstorming、writing-plans、subagent-driven-development三个Skills，复杂需求则可以添加test-driven-development、requesting-code-review等Skills，确保开发质量。

3.2 Superpowers完整工作流程：从需求到收尾的全闭环

Superpowers的工作流程非常清晰，从需求梳理到分支收尾，每个阶段都有对应的Skill驱动，形成了完整的闭环。我们用流程图的形式，直观展示整个流程：

brainstorming → using-git-worktrees → writing-plans → subagent-driven-dev → finishing-branch

下面我们逐个拆解每个阶段的核心工作，让大家清楚AI在每个阶段的具体行为。

（1）brainstorming：苏格拉底式对话，梳理需求与设计

这是整个流程的起点，核心目的是梳理清楚需求和设计方案。AI会以苏格拉底式对话的方式，不断向用户提问，引导用户明确需求细节、技术选型、潜在风险等内容。

比如用户提出"实现一个用户登录接口"，AI会依次提问：登录方式有哪些（账号密码、短信验证码）、是否需要记住密码功能、密码是否需要加密存储、登录失败的错误提示有哪些、是否需要防刷机制等。通过一系列提问，逐步完善需求细节，最终输出一份完整的设计文档，明确接口的请求参数、响应格式、业务逻辑、异常处理等内容。

（2）using-git-worktrees：创建隔离工作空间，确保基线稳定

需求梳理完成后，AI会执行using-git-worktrees Skill，创建一个隔离的Git工作空间（git worktree）。这个工作空间独立于主分支，不会影响主分支的代码，同时AI会验证当前工作空间的编译基线，确保依赖安装完整、代码可正常编译，为后续开发做好准备。

这种隔离工作空间的设计，能有效避免开发过程中对主分支的污染，尤其是在多人协作项目中，每个开发者的变更都在独立工作空间中进行，测试通过后再合并到主分支，提升代码稳定性。

（3）writing-plans：拆分bite-sized tasks，确保可执行

设计文档确定后，AI会执行writing-plans Skill，将需求拆分为多个"2-5分钟可完成"的bite-sized tasks。这种拆分方式的核心是"小步快跑"，每个任务都足够小，能快速完成和验证，避免出现大任务无法推进、难以验证的问题。

比如实现用户登录接口，会拆分为以下几个tasks：第一步，定义登录接口的路由（2分钟）；第二步，编写请求参数校验逻辑（3分钟）；第三步，实现密码加密比对逻辑（4分钟）；第四步，编写登录成功和失败的响应逻辑（3分钟）；第五步，编写单元测试（5分钟）。每个task都有明确的时间预估和执行目标，AI能按步骤逐步完成。

（4）subagent-driven-dev：子代理隔离实现，提升执行质量

这是Superpowers最核心的阶段，也是它与其他框架的最大区别------子代理驱动开发。AI会扮演"Controller（编排者）"的角色，为每个task派遣独立的子代理，每个子代理负责特定的工作，且拥有独立的上下文，避免上下文污染。

每个task的执行过程如下：

1. Controller派遣Implementer子代理：负责代码实现，首先会检查当前task的需求细节，如有疑问会向用户提问，确认后开始编写代码，同时按照TDD要求编写测试用例，完成后进行自审查，最后向Controller报告状态（DONE/ DONE_WITH_CONCERNS/ BLOCKED/ NEEDS_CONTEXT）。

2. Controller派遣Spec Reviewer子代理：负责对照plan和设计文档，检查Implementer子代理的实现是否符合需求，重点关注需求覆盖、场景遗漏、过度实现等问题。如果通过，就进入下一阶段；如果发现问题，会反馈给Implementer子代理，让其修复后重新审查。

3. Controller派遣Code Quality Reviewer子代理：负责审查代码质量，重点关注代码规范、架构合理性、安全性、测试覆盖率等问题，将问题分为Critical（严重）、Important（重要）、Minor（次要）三个等级，反馈给Implementer子代理修复，修复完成后重新审查，直到通过。

这种子代理隔离的设计，最大的优势是"客观性"。Implementer子代理负责实现，Reviewer子代理负责审查，审查者不会有"这是我写的代码"的心理包袱，能更客观地发现问题，同时独立的上下文能避免长对话导致的AI逻辑漂移，提升代码实现质量。

（5）finishing-branch：收尾工作，完成变更合并

所有tasks完成并通过审查后，AI会执行finishing-a-development-branch Skill，完成开发收尾工作。具体包括：检查分支代码是否通过所有测试，创建PR（Pull Request），填写PR描述（包含变更内容、测试结果、影响范围），根据项目要求决定保留或丢弃当前分支，确保变更能顺利合并到主分支。

3.3 核心特色1：强制TDD，确保代码可测试

Superpowers的一大核心特色是"强制TDD（测试驱动开发）"，它会在Plan阶段就把TDD的步骤写进每个task中，要求Implementer子代理必须遵循"RED-GREEN-REFACTOR"循环，不先写测试就无法开始编写代码。

每个task中的TDD步骤如下：

• Step 1: 写失败测试（RED）：编写单元测试，此时代码未实现，测试会失败；

• Step 2: 运行确认失败：执行测试用例，确认测试失败，确保测试用例有效；

• Step 3: 写最小实现代码：编写能让测试通过的最小代码，不添加多余功能；

• Step 4: 运行确认通过（GREEN）：执行测试用例，确认测试通过；

• Step 5: 提交：将代码和测试用例一起提交，完成该task。

如果Implementer子代理没有先写测试就开始编写代码，Spec Reviewer子代理会直接拒绝审查，要求其补充测试用例。这种强制TDD的设计，能确保每一行代码都有测试覆盖，减少线上bug，提升代码的可维护性。

3.4 核心特色2：两阶段审查，双重保障代码质量

Superpowers的另一大特色是"两阶段审查"，每个task完成后，必须经过两轮独立审查，才能进入下一个task，确保代码既"做对了"，又"做好了"。

我们用表格清晰展示两阶段审查的细节：

阶段	审查者	关注点	输出
第一阶段	Spec Reviewer子代理	做对了吗？需求覆盖、场景遗漏、过度实现、是否符合设计文档	✅ 通过 / ❌ 问题 + 具体修改建议
第二阶段	Code Quality Reviewer子代理	做好了吗？代码规范、架构合理性、安全性、测试覆盖率	Critical / Important / Minor 分级问题 + 修改建议
需要注意的是，第二阶段审查必须在第一阶段通过后才能开始。因为如果代码做的事情本身就不符合需求，即使代码质量再高，也没有意义，这种先后顺序的设计，能避免无效审查，提升审查效率。

四、OpenSpec与Superpowers深度对比：该选哪个？

OpenSpec和Superpowers都是SDD理念的优秀实践，但它们的侧重点、核心能力和适用场景有很大差异，很多开发者会纠结该选择哪个框架。下面我们从多个维度进行深度对比，帮大家快速找到适合自己项目的框架。

4.1 核心定位与哲学对比

两者的核心定位和设计哲学有本质区别，这也决定了它们的侧重点不同：

维度	OpenSpec	Superpowers
一句话定位	规格驱动的变更管理框架	多代理协作的完整开发工作流
核心理念	先写Spec再实现，变更可追溯	先设计再编码，TDD + 子代理分工
哲学	Proposal → Design → Spec → Tasks	Brainstorm → Plan → TDD + Subagent → Review
侧重点	决策追溯 + 知识积累	执行质量 + 自动化审查

4.2 工作流程对比

两者的工作流程虽然都遵循SDD理念，但每个阶段的具体内容和侧重点有很大差异：

OpenSpec流程：explore → proposal → design → specs → tasks → apply → verify → archive

Superpowers流程：brainstorming → git-worktree → writing-plans → subagent-dev → finishing-branch

我们进一步拆解每个阶段的差异：

阶段	OpenSpec	Superpowers
探索/需求	explore + proposal，明确变更原因和目标	brainstorming，苏格拉底式一问一答，梳理需求和设计
设计	design.md，记录技术方案决策和风险评估	融合在design doc中，通过对话确定技术方案
规格	独立specs/目录，有主spec + delta spec同步体系	无独立spec，融合在design doc和plan中
任务拆分	tasks.md，按功能粒度拆分	Plan，按2-5分钟/step拆分，含完整测试步骤
实现	单代理逐task实现，自验证	子代理隔离实现 + 两阶段审查
测试	不强制TDD，以编译通过和行为验证为准	强制TDD，RED-GREEN-REFACTOR循环
审查	自审查checklist	独立子代理审查，上下文隔离
Git	不强制分支策略	强制git worktree隔离
收尾	archive，归档所有Artifact文档	finishing-branch，合并/PR/丢弃分支

4.3 核心能力差异对比

除了流程差异，两者在核心能力上也有明显区别，主要集中在代理模式、Spec管理和测试策略三个方面。

（1）子代理 vs 单代理

维度	Superpowers（子代理）	OpenSpec（单代理）
执行模式	Controller + Implementer + Reviewer × 2，分工明确	同一个AI全程负责，从规范生成到代码实现
上下文	每个子代理独立上下文，精确裁剪，避免漂移	共享上下文，长对话可能出现逻辑漂移
审查客观性	高，审查者与实现者分离，无心理包袱	中，需要AI角色切换，模拟审查者
平台依赖	高，需要支持子代理派遣（如Claude Code）	低，任何AI编码助手均可使用

（2）Spec管理

维度	OpenSpec	Superpowers
独立Spec体系	✅ 主spec + delta spec + 自动同步	❌ 无独立spec，融合在design doc和plan中
长期积累	specs按功能组织，可查询、可复用，形成知识库	plan/design平铺在docs目录，难以长期积累和查询
变更追溯	archive按日期归档，含完整Artifact文档，追溯性强	依赖Git历史，追溯性较弱

（3）测试策略

维度	Superpowers	OpenSpec
TDD	强制，严格遵循RED-GREEN-REFACTOR循环	不强制，以编译通过和行为验证为准
Plan中的测试	每个step包含完整测试代码和执行步骤	tasks中不含测试代码，需单独编写

4.4 适用场景对比：选对框架才是关键

没有最好的框架，只有最适合的框架。结合两者的核心差异，我们整理了不同场景下的框架推荐，帮大家快速决策：

场景	推荐框架	原因
全新项目 / 绿地开发	Superpowers	TDD + git worktree + 子代理协作，端到端自动化，能快速搭建规范的开发流程，确保代码质量
大型企业项目改动	OpenSpec	spec追溯 + 变更归档，适合团队review，能清晰记录每一次变更的设计思路和实现过程，满足企业合规要求
需要长期维护specs	OpenSpec	主spec + delta spec + 自动同步 + 归档，能形成项目级知识库，长期维护更高效
有严格测试要求	Superpowers	内置强制TDD，每个step都包含测试，能确保代码有完善的测试覆盖，减少线上bug
不支持子代理的平台	OpenSpec	天然单代理模式，无需子代理支持，任何AI编码助手都能使用
多代理协作环境	Superpowers	核心设计就是子代理驱动，分工明确，能提升执行质量和审查客观性

五、总结：SDD的终极目标，让AI写对每一行代码

通过对OpenSpec和Superpowers的详细介绍和对比，我们不难发现，两者虽然侧重点不同，但都围绕SDD的核心理念------"先规范后编码"，解决AI编码不规范、不可追溯、质量参差不齐的痛点。

OpenSpec的核心优势在于"Spec驱动 + 变更追溯 + 知识积累"，它能让每一次变更都有完整的设计文档可追溯，形成项目级的规格知识库，适合需要长期维护、注重变更管理的项目；Superpowers的核心优势在于"子代理隔离 + TDD强制 + 自动化审查"，它能让AI像有纪律的开发团队一样工作，确保代码执行质量，适合全新项目、有严格测试要求的项目。

需要强调的是，OpenSpec和Superpowers并不是竞争关系，而是互补关系。在实际开发中，我们可以将两者结合使用，发挥各自的优势：用OpenSpec做spec管理和变更追溯，确保每一次变更都有据可查；从Superpowers中提取审查和git worktree能力，强化spec合规审查，提升代码执行质量。

在AI编码普及的今天，越来越多的开发者开始依赖AI提升效率，但我们不能忘记，AI只是工具，规范才是保证开发质量的核心。SDD的终极目标，从来不是否定AI的效率，而是用规范给AI"立规矩"，让AI的高效发挥在正确的轨道上，让AI写的每一行代码，都有据可查、有规可循。