SpecKit、OpenSpec与Superpowers三大AI编码框架深度对比，绿地与棕地项目如何选型

AI辅助编程已从概念走向落地，但工程师普遍面临一个现实困境：模型生成的代码常偏离预期，返工成本甚至高于手写。问题根源并非模型能力不足，而是需求定义模糊、约束缺失与验证机制缺位。近期，Spec Kit、OpenSpec与Superpowers三套开源框架因聚焦“规范驱动开发”（SDD）而引发关注——它们试图通过结构化流程弥补自然语言指令的先天缺陷。

这三者并非同类工具，其设计哲学与适用场景存在本质差异。根据2026年7月的GitHub星标数据，Spec Kit（~118K stars）由GitHub官方维护，OpenSpec（~58K stars）由Fission-AI开发，Superpowers（~245K stars）由开源社区领袖Jesse Vincent主导。它们共同指向同一目标：让AI写出可交付、可维护的生产级代码，但路径截然不同。

核心理念分野：图纸、审批与规程

可将三者类比为建筑施工中的不同管理范式：

OpenSpec 是“边改图纸边施工”，强调增量迭代。它以Delta Spec为核心，专为已有代码库（即“棕地项目”）设计，主张“描述对已有行为的改动”而非重写全局规范；
Spec Kit 是“先审批再施工”，采用规范先行、阶段门控模式。它要求AI先产出PRD与设计文档，再生成代码，适用于从零构建的“绿地项目”；
Superpowers 则是“不管图纸，按规矩施工”，依赖一套强制性工程纪律（如测试覆盖率、接口契约、提交规范），通过铁律约束AI输出行为。

这种区分至关重要。现实中，企业80%以上的开发属于棕地场景——在遗留系统上叠加新功能，技术债与隐性约定构成真实约束。若用绿地思维驱动棕地开发，极易导致范围外溢与兼容性断裂。

OpenSpec：棕地友好的增量规范引擎

OpenSpec v1.5.0的工作流最轻量灵活，核心命令仅四步：explore → propose → apply → archive。其中explore为只读探索阶段，不生成任何文件，作用是扫描现有代码结构，避免后续提案因误解上下文而偏航——在棕地项目中，这一步不可或缺。

propose命令会一次性输出四份文档：proposal.md（需求动机）、delta specs（变更清单）、design.md（实现方案）与tasks.md（执行顺序）。Delta Spec支持ADDED、MODIFIED、REMOVED、RENAMED四类操作，统一解析并按固定顺序合并（RENAMED → REMOVED → MODIFIED → ADDED），确保变更可追溯、无冲突。

例如，将JWT过期时间从30分钟改为2小时，只需声明一条MODIFIED规则；新增用户登录功能则用ADDED条目。无需重写整套规范，极大降低维护成本。

该框架的“Brownfield-first”原则使其在存量系统改造中优势突出。某订单服务接入新支付通道时，若直接让AI生成“加幂等键”代码，模型可能擅自修改库存逻辑；而OpenSpec通过explore理解当前仓储层调用链后，propose阶段即可明确约束：仅允许修改下单接口与缓存层，禁止触碰库存服务——边界清晰，返工率显著下降。

Spec Kit：规范先行的阶段门控体系

Spec Kit由GitHub推动，强调“先有说明书，再动一行代码”。其流程更接近传统软件工程：需求→设计→评审→实现。AI首先被要求撰写PRD（产品需求文档）与架构设计，经人工确认后才进入编码阶段。

这一模式适合全新系统构建（绿地项目），尤其当业务逻辑复杂、跨模块依赖多时。例如开发一个金融风控中台，需明确定义数据血缘、异常熔断策略与审计日志格式——这些无法靠模型自行推断，必须前置固化。

但其短板在于对棕地项目的适应性较弱。若强行用于已有系统，需先补全缺失的规范文档，成本高昂；且阶段门控易造成流程阻塞，不适合快速迭代场景。

Superpowers：纪律驱动的质量保障框架

Superpowers走的是另一条路：不预设需求细节，而是通过工程铁律约束AI行为。它内置一套可配置的“质量保证书”，包括：

所有变更必须附带单元测试（覆盖率≥80%）
接口变更需同步更新OpenAPI Schema
禁止直接修改第三方依赖源码
提交信息必须包含Jira ID与影响范围声明

这套机制对团队纪律要求极高，但一旦建立，能有效防止“模型自由发挥”。某电商团队曾用Superpowers重构商品详情页，AI在生成代码前自动校验：是否覆盖了SKU切换、库存异步加载、SEO元标签三项核心路径？若缺失，拒绝生成——从而避免上线后出现关键路径断裂。

工程实践启示：没有银弹，只有适配

三者并无绝对优劣，关键在于匹配项目类型与组织成熟度：

绿地项目 + 强架构师主导 → 优先Spec Kit，确保顶层设计不跑偏；
棕地增量 + 快速交付压力大 → OpenSpec更高效;
高可靠性要求 + 已有CI/CD规范 → Superpowers可无缝嵌入现有质量门禁。

更进一步，实践中常采用组合策略：例如在棕地系统中，先用OpenSpec完成局部模块重构，再将新模块纳入Spec Kit管理；或以Superpowers的检查清单作为各框架的补充验证层。

值得注意的是，工具价值最终取决于“问题定义质量”。正如一位后端负责人所言：“一句‘加幂等支持’换来十次重生成，不是模型不行，是我们没说清边界。”真正提升效率的，是将能力圈判断（哪些能交给AI）与检查清单（哪些必须人工确认）转化为可执行的校验脚本与CI规则。

随着开源模型调用量持续攀升（OpenRouter数据显示2026年10月初周调用量达166万亿tokens），AI编程正从“能写”迈向“可靠写”。三大框架的分化发展，恰恰印证了这一趋势：通用大模型提供能力基座，而领域专用的工作流框架才是落地关键。

未来，这类SDD工具或将与IDE深度集成，成为开发者默认工作流的一部分。但无论技术如何演进，清晰的需求契约与可验证的交付标准，始终是AI编程不可绕过的基石。