OpenSpec 与 Spec Kit：为 AI 代理开发选择规格驱动框架

AI 编码代理编写代码的速度比任何人类都快。瓶颈已经转移：规格现在就是产品。 如果你的代理没有清晰、结构化的规格可循，它就会臆造架构、捏造需求，并产出通过没人要求的测试的代码。

两款框架应运而生以解决这个问题：OpenSpec（约 28k GitHub Star）和 GitHub 的 Spec Kit（约 75k Star）。两者均为 MIT 许可。两者都生成供 AI 代理直接使用的 slash command。但它们在速度与治理之间做出了根本不同的权衡——选错会让你的团队付出数周的返工代价。

下面介绍如何选择。

核心分歧：流畅迭代 vs. 结构化治理

OpenSpec 是一个 Node.js CLI（@fission-ai/openspec），将规格视为轻量级、仓库原生的工件。它将工作组织到包含提案、规格、设计和任务文件的变更文件夹中。其哲学是尽量减少繁文缛节——快速把规格送到代理面前，迭代，完成后归档。

Spec Kit（GitHub 的框架，以 specify CLI 和 /speckit.* 命令为核心）将一切锚定到一份章程（constitution）——一份项目级文档，编码了约束、编码标准、TDD 要求和合规规则。每个特性都流经一个结构化的阶段流水线，每个关卡都有模板和检查清单。

差异并非表面文章。它决定了你的团队在每个特性上吸收多少开销、代理在每次提示中消耗多少上下文，以及你的审计轨迹是否能满足合规审查者的要求。

工作流比较

OpenSpec：四条命令，最小摩擦

OpenSpec 的工作流刻意简短：

graph LR
    A["/opsx:propose"] --> B["/opsx:explore"]
    B --> C["/opsx:apply"]
    C --> D["/opsx:archive"]

1. /opsx:propose —— 创建一个包含提案文档的变更文件夹
2. /opsx:explore —— 在该文件夹内迭代规格和设计
3. /opsx:apply —— 基于最终规格执行实现
4. /opsx:archive —— 将完成的工作移至归档

就是这样。没有章程。没有强制的澄清阶段。没有任务拆解关卡。你提案、探索、应用、归档。如果你需要从 apply 回到 explore，直接做即可——没有阶段门拦着你。

OpenSpec 强制执行 50KB 上下文限制以防止提示膨胀。这是一个刻意的设计选择：使用 OpenSpec 规格的代理不会因过大的上下文窗口而窒息，这在跨 monorepo 运行多个代理时很重要。

Spec Kit：六个阶段，锚定章程

Spec Kit 的流水线更为丰富：

graph LR
    A["/speckit.constitution"] --> B["/speckit.specify"]
    B --> C["/speckit.clarify"]
    C --> D["/speckit.plan"]
    D --> E["/speckit.tasks"]
    E --> F["/speckit.implement"]
    G["/speckit.analyze"] -.-> B

1. /speckit.constitution —— 定义项目级的规则、约束和标准
2. /speckit.specify —— 创建详细的特性规格
3. /speckit.clarify —— 解决歧义和开放问题
4. /speckit.plan —— 生成实现计划
5. /speckit.tasks —— 将计划拆分为可分配的离散任务
6. /speckit.implement —— 通过 TDD 关卡和检查清单验证执行任务
7. /speckit.analyze（可选）—— 在指定变更前分析现有代码

章程是关键差异点。它是一份被后续所有命令尊重的活文档。如果你的章程写着"所有数据库变更都需要迁移脚本"或"没有重试逻辑不得直接进行 API 调用"，代理会在每个阶段自动执行这些规则。对于受监管行业——医疗、金融、政府——这正是你将合规要求编码到开发工作流本身所需的机制。

正面对比

上下文税问题

Spec Kit 的能力伴随着代价。每个已安装的 slash command、每个模板、每条章程规则都会向代理的上下文窗口添加令牌。运行带多个扩展的 Spec Kit 的团队报告了显著的上下文税——代理将令牌花在解析框架指令上，而非对你的代码进行推理。

这在规模化时很重要。如果你在大型代码库上以 Spec Kit 的完整命令集运行 Claude Code 或 Codex，你就在为框架开销燃烧上下文。一些团队报告需要修剪扩展或拆分章程以保持在实用的令牌预算内。

OpenSpec 用其 50KB 上下文限制避开了这一点。它是一种粗粒度手段——你无法编码同等深度的治理——但它让代理聚焦于实际规格而非框架元数据。

企业要点：如果你的代理已经受上下文约束（大型代码库、复杂系统提示、多文件变更），在承诺之前衡量 Spec Kit 命令集的令牌成本。OpenSpec 的上限较低但可预测。

何时使用 OpenSpec

在以下情况选择 OpenSpec：

• 你在做快速原型或概念验证，速度比流程更重要
• 你的团队使用多种 AI 代理工具，希望有一个跨所有工具通用的轻量级规格层
• 你需要在执行中迭代——在实现开始后更改规格而无需对抗阶段门
• 你的代码库足够大，上下文预算是真实约束
• 你想要规格驱动开发，但不想采用完整的治理框架

OpenSpec 的"核心"配置文件是进入规格驱动 AI 开发的最低摩擦入口。安装 CLI、创建变更文件夹，你的代理就有了结构化规格可循。无需编写章程，无需维护扩展目录。

何时使用 Spec Kit

在以下情况选择 Spec Kit：

• 你在构建生产系统，治理和可重复性证明开销是值得的
• 你的组织在受监管领域（医疗、金融、政府）运营，需要将合规规则编码到开发工作流中
• 你希望 TDD 强制执行内建于框架中，而非事后拼凑
• 你的团队受益于结构化阶段门——规划前先澄清、实现前先规划
• 你需要通过钩子和精心策划的扩展目录为组织特定工作流提供扩展性

Spec Kit 的章程模型在企业环境中确实强大。将"每个 API 端点都需要 OpenAPI 文档"或"所有状态变更都需要事件溯源"编码为章程规则，意味着代理每次都会自动执行它们。那不是治理作秀——而是真正会执行的治理。

混合方式：从轻量起步，逐步加结构

这些框架在哲学上并非互斥。许多企业团队的实用路径：

1. 以 OpenSpec 起步进行初步探索和原型。在不承担开销的情况下养成规格习惯。
2. 当项目走向生产、需要治理、合规编码和可重复阶段工作流时转向 Spec Kit。
3. 为副业项目、内部工具和快速实验保留 OpenClaw——在这些场景下 Spec Kit 的繁文缛节会拖慢你。

最坏的结果是完全没有规格框架——代理从模糊提示工作，产出无人对照需求审查的代码，而那些需求也从未被写下来。

可行要点

1. 规格驱动开发已不再可选。 如果你的 AI 代理没有结构化规格，你就在调试臆造的需求。选一个框架。

2. 先衡量你的上下文预算。 在加载 Spec Kit 完整命令集的情况下运行代理，检查有多少令牌用于框架开销。如果超过上下文窗口的 15-20%，考虑 OpenSpec 或精简的 Spec Kit 配置。

3. 对受监管行业，Spec Kit 的章程物有所值。 编码代理自动执行的合规规则，值得额外的工件开销。替代方案是对每个代理生成的变更进行人工监管合规审查。

4. 对快速原型，OpenSpec 在速度上胜出。 四条命令、50KB 上下文限制、无需维护章程。快速把规格送到代理面前。

5. 不要跳过归档/清理步骤。 两个框架都支持归档已完成的工作。仓库中的陈旧规格会在未来运行中混淆代理。积极归档。

6. 针对你的实际栈评估两者。 克隆每个框架的示例仓库，用你偏好的 AI 代理针对你的代码库运行，比较输出质量和令牌成本。正确选择取决于你团队的治理需求，而非 GitHub Star 数。