三个规范驱动SDLC工具实测报告
我针对同一个真实功能评估了三款规范驱动型 AI SDLC 工具：对一个现有的无服务器 Python 服务进行中等规模的后端扩展，涉及安全性、身份验证和 IaC。
微信 ezpoda免费咨询：AI编程 | AI模型微调| AI私有化部署
AI模型价格对比 | AI工具导航 | ONNX模型库 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo
如果你正在使用 AI 编码工具但还没有考虑结构化方法，你很快就会了。
AI 编码工具让你更快。但缺乏结构的速度意味着你在大规模地交付模糊性。规范驱动的工作流解决了这个问题：在 AI 编写一行代码之前，就商定你要构建什么。
我针对同一个真实功能评估了三款规范驱动型 AI SDLC 工具：对一个现有的无服务器 Python 服务进行中等规模的后端扩展，涉及安全性、身份验证和 IaC。
这篇文章分解了每款工具的功能、它们的对比情况，以及如何选择——这样你就能为你的 AI 开发工作流增加结构、速度和可预测性。
1、什么是规范驱动型 AI 开发？
规范驱动的理念很简单。在生成一行代码之前，你先以书面规范的形式定义和完善你要构建的内容。你带着一个工单或粗略的想法，与 AI 合作将其转化为结构化的规范，涵盖行为、边界、边界情况和系统适配。它会暴露出你没有想到的缺口。你进行反驳、添加约束，然后签字确认。然后 AI 基于规范进行实现，而不是基于你最初那半成品的提示词。
这些工具引导任何 AI 编码智能体完成 SDLC 各个阶段，无论 IDE 是什么。Ran Isenberg 的 AI-Driven SDLC 文章涵盖了更广泛的框架：治理、安全控制以及各个部分如何组合在一起。
2、正在评估的三款规范驱动型 AI 工具
我从企业角度研究了三款工具。不过，市场上还有其他工具，但它们要么处于早期阶段，要么面向个人开发者，要么缺乏团队协作所需的结构。以下三款达到了标准：
BMAD（v6.0.3）是一个全生命周期框架，具有专门的需求获取和路线修正工作流。我测试了两种模式：适用于复杂功能的完整流程，以及直接跳转到实现的快速流程。规划规范工件会合并到项目文档目录中，作为标准文档，而不是特定于工具的工件树。
Spec-Kit（v0.1.6）是 GitHub 的规范优先工具。你定义一次项目级别的"宪法"，每个规范都会继承这些规则。模板会将未知项标记为"需要澄清"，而不是猜测。
OpenSpec（v1.2.0）拥有最轻量的足迹。你编写增量规范：只描述发生变化的部分。完成的规范会被归档并合并到一个随项目增长的真相来源文档中。
所有版本均于 2026 年 2 月评估。这些工具发展迅速；在做出决定前请核实最新文档。
荣誉提名
AI-DLC，AWS 对此领域的尝试。纯 Markdown 规则，无 CLI。还处于早期阶段，无法评估。
GSD，单人氛围编码工具。过于简单，不适合结构化团队评估。
SDD，完全披露，我参与了其构思。尚未成熟。
3、评估执行摘要
我在同一个功能、同一个代码库、同一个 IDE 上运行了所有四个流程：Cursor + Claude Sonnet 4.5。每次运行涵盖了从高层设计到 PR 的完整过程。生成代码的质量取决于工具之外的许多因素：仓库技能、上下文、模型、开发者。工具能控制的是规范和计划。
我定义了 13 个类别，每款工具打分从 1 到 5 分，5 分为最佳，1 分为最差。
请对这些分数持保留态度，因为它们带有很强的主观性，并且符合我个人的需求。
| 维度 | BMAD | BMAD 快速 | Spec-Kit | OpenSpec |
|---|---|---|---|---|
| 规范质量 | 4 | 3 | 2 | 4 |
| 适应性 | 4 | 4 | 2 | 3 |
| 到达 PR 的时间 | 2 | 5 | 5 | 5 |
| 开发者体验 | 2 | 3 | 3 | 4 |
| 迭代优化 | 5 | 3 | 2 | 3 |
| 人工审查检查点 | 2 | 5 | 3 | 5 |
| AI 编码工具兼容性 | 4 | 4 | 4 | 5 |
| 并行开发支持 | 2 | 2 | 5 | 5 |
| 工作流可见性 | 5 | 5 | 2 | 4 |
| 安装和升级体验 | 4 | 4 | 2 | 4 |
| 项目健康度 | 4 | 4 | 2 | 3 |
| 成本 | 4 | 5 | 5 | 5 |
| 功能中期路线修正 | 5 | 3 | 2 | 4 |
| 最终得分 | 3.65 | 3.74 | 2.77 | 4.00 |
OpenSpec 总体得分最高，但这个数字会随着不同的优先级而变化。如果你更看重迭代优化或路线修正而非 BMAD，那就让 BMAD 领先。
下面，你将看到类别细分和我的评分理由。
想直奔主题？跳转到决策指南。
3.1 规范质量
规范的可读性如何，与现有架构的契合度如何，以及是否涵盖了足够的测试规划内容。
| BMAD | BMAD 快速 | Spec-Kit | OpenSpec | |
|---|---|---|---|---|
| 规范质量 | 4 | 3 | 2 | 4 |
该功能的授权设计在各工具之间存在最大差距。BMAD 和 BMAD 快速添加了权限检查；Spec-Kit 和 OpenSpec 信任调用者提供的上下文。两者在规划期间都没有标记此问题。可通过自定义规则或技能缓解。
BMAD 完整版产生了最深的规划工件：完整的 PRD、架构文档和故事分解。代价是：工件集过于沉重，难以审查。
BMAD 快速使用单个合并的规范文档。更易于审查，但规划深度较浅。
Spec-Kit 的规划工件结构良好，但差距在于实现：生成的代码未能忠实地映射到规范意图。
OpenSpec 的增量规范使每个文档保持简洁且可审查。跟踪保持准确，便于验证实现与计划的一致性。
3.2 日常摩擦
步骤的清晰度、上手速度、能否了解你在工作流中的位置，以及审查检查点和 IDE 集成的表现。
| BMAD | BMAD 快速 | Spec-Kit | OpenSpec | |
|---|---|---|---|---|
| 开发者体验 | 2 | 3 | 3 | 4 |
| 工作流可见性 | 5 | 5 | 2 | 4 |
| 人工审查检查点 | 2 | 5 | 3 | 5 |
| AI 编码工具兼容性 | 4 | 4 | 4 | 5 |
BMAD 完整版在可见性方面得分很高，因为 /bmad-help 可以读取你的项目状态并告诉你下一步该做什么。但它主要的存在意义是把你从 BMAD 自身的复杂性中拯救出来。十二个智能体、沉重的工件集和陡峭的学习曲线。
BMAD 快速的启动门槛最低：两步、一份文档，需求获取质量与完整流程相同。/bmad-help 可用但很少需要。流程本身就足够简单。
Spec-Kit 生成执行内部的工件（研究笔记、状态文件），它们与源代码一起落在项目根目录中，并非用于人工审查。没有帮助命令或状态视图：该工具不会告诉你当前处于什么位置或下一步该做什么。
OpenSpec 提供清晰的消息提示，并始终建议下一步操作。openspec status 显示工件状态，/opsx:continue 显示依赖关系图。它还拥有最丰富的 IDE 集成，默认在 24 个工具中安装了技能。摩擦在于信任：它有时会假设上下文，并为你没有做出的决定添加理由。
3.3 需求获取、审查和路线修正
工具是强制执行澄清循环和对抗性审查，还是仅仅使它们成为可能，以及你是否可以在功能进行中修改方向而不必从头开始。
| BMAD | BMAD 快速 | Spec-Kit | OpenSpec | |
|---|---|---|---|---|
| 迭代优化 | 5 | 3 | 2 | 3 |
| 功能中期路线修正 | 5 | 3 | 2 | 4 |
BMAD 完整版在此获得了 5/5 分。对抗性代码审查（/bmad-bmm-code-review）在通过之前就暴露问题；在测试中，它发现了标准审查会遗漏的问题。Party Mode（派对模式）在实现之前通过多个智能体角色来审查设计。对于合适的项目来说，复杂性代价是值得的。
BMAD 快速共享了完整流程的需求获取。实现审查是自我检查，而不是单独的对抗性循环。没有路线修正命令：编辑 tech-spec.md 并重新运行 /bmad-bmm-quick-dev。对于小工作量来说，这已经足够了。
Spec-Kit 没有内置的代码审查步骤。迭代止步于规划阶段。改变方向意味着重新运行受影响的命令，每个命令都会重新生成完整的文档。你的团队已经审查过的计划会被完全替换，没有仅显示变更部分的差异对比。
OpenSpec 通过流畅性来处理路线修正：随时编辑任何工件，运行 /opsx:apply，它会从你停下的地方继续。迭代无摩擦但非强制。各阶段之间没有审查关卡。
3.4 安装、升级和适应性
前置条件、升级工作量、对现有自定义配置的风险，以及你可以在多大程度上推动模板和工作流自定义以满足组织需求。
| BMAD | BMAD 快速 | Spec-Kit | OpenSpec | |
|---|---|---|---|---|
| 安装和升级体验 | 4 | 4 | 2 | 4 |
| 适应性 | 4 | 4 | 2 | 3 |
BMAD 通过 .customize.yaml 在升级时保留自定义配置。尚不支持工作流级别的覆盖。
Spec-Kit 存在已知的升级问题，会覆盖自定义文件。
OpenSpec 拥有最干净的升级路径：用户内容和工具文件位于单独的目录中。任何超出轻度自定义的需求都需要分叉工作流。
3.5 速度、成本和并行工作
从工单到开启 PR 的总时间（不包括团队审查）、美元成本，以及工件结构是否隔离了并行功能开发。
| BMAD | BMAD 快速 | Spec-Kit | OpenSpec | |
|---|---|---|---|---|
| 到达 PR 的时间 | 2 | 5 | 5 | 5 |
| 成本 | 4 | 5 | 5 | 5 |
| 并行开发支持 | 2 | 2 | 5 | 5 |
这些分数背后的原始时间和成本明细：
| BMAD | BMAD 快速 | Spec-Kit | OpenSpec | |
|---|---|---|---|---|
| 规划时间 | 2 天 | 5 小时 | 4 小时 | 3 小时 |
| 实现时间 | 4 天 | 1.5 天 | 1 天 | 1 天 |
| 规划成本 | $50 | $30 | $30 | $25 |
| 实现成本 | $150 | $55 | $45 | $70 |
BMAD 完整版是异类。按每天 33 美元计算，成本是合理的，但总共六天的时间累积起来不少。当设计的正确性至关重要时，它值得投入。对于直接了当的功能很难证明其合理性。
BMAD 快速、Spec-Kit 和 OpenSpec 在速度和成本上处于同一水平。差异可以忽略不计。
对于并行工作，Spec-Kit 和 OpenSpec 为每个功能提供独立的目录。两名工程师不会触及相同的文件——这是设计使然。BMAD 默认将所有输出放入一个共享目录。隔离是可配置的，但并非开箱即用。
3.6 开源健康度
巴士因子、提交频率、问题响应速度和社区活跃度。
| BMAD | BMAD 快速 | Spec-Kit | OpenSpec | |
|---|---|---|---|---|
| 项目健康度 | 4 | 4 | 2 | 3 |
| BMAD | Spec-Kit | OpenSpec | |
|---|---|---|---|
| 提交数（90 天） | 458 | 37 | 158 |
| 开放问题 / 关闭率 | 44 / 94.3% | 533 / 36.8% | 201 / 24.2% |
| PR 积压（开放 / 中位年龄） | 6 / 1 天 | 94 / 62 天 | 37 / 30 天 |
| 巴士因子 | 2 | 2 | 1 |
BMAD 是最健康的项目，拥有响应迅速的 Discord 支持。Spec-Kit 有陈旧的 PR 队列且没有社区渠道。OpenSpec 由一人构建。你在选这些工具的同时也是在选它们的团队。
4、决策指南：如何选择你的工具
以下是如何根据你的情况匹配工具。
如果你想要最低摩擦的起点： OpenSpec。最佳的开箱即用体验，默认支持并行工作。增量规范适用于现有代码库，无需描述整个系统。代价是锁定：它对规范存放位置有强烈看法，而且 CLI 不会妥协。一位维护者，一个愿景。如果这不适合你的组织，你很快就会碰壁。
如果设计的正确性至关重要： 使用 BMAD 完整版。对抗性代码审查、Party Mode 和路线修正工作流能在设计错误累积之前捕获它们。当错误决策的修正成本很高时，规划的深度会物有所值。
如果你交付的是小型、范围明确的工作： BMAD 快速版适用：两步、一份文档，相同的需求获取质量。但对于这么小的工作，Plan Mode 就足够了。规范驱动的工作流会为简单的功能增加不必要的开销。
如果你需要深度定制，或者以上都不适合： 使用 BMAD。通过 .customize.yaml 进行的智能体覆盖在升级后仍然保留，Builder 可以生成自定义智能体和工作流，并且定制是持久的。BMAD 是唯一一款当"它不按我想要的方式工作"时可以通过配置来解决的工具。
5、早期采用需要付出代价
这些工具中没有一款不经修改就能准备好被大型企业采用。至少在我评估时是这样，但该领域在不断发展。
当我在评估 Spec-Kit 时，他们发布了扩展钩子支持——发布时无法使用，然后在我完成写作前修复了它。功能在上线、崩溃和在评估周期之间得到修补。这里的一切在你阅读时可能已经过时了。
当你推广你的选择时，一款新工具可能已经领先了。如果你正在运行一个大型研发平台，我会优先考虑减少锁定，而不是选择"最好"的工具。
以下是一些黄金建议：
- 封装工具的安装和设置。掌握治理层：安装什么、如何配置、跨仓库强制执行的参数。不要让每个团队运行带不同标志的 init。
- 设计你想要的体验，而不是工具自带的体验。决定你的组织所需的工作流步骤、工件、格式和审查关卡。工具实现这种体验，但它不定义它。
- 用自定义技能抽象用户交互。像 /my-company-sdd start feature TICKET-123 这样的命令指向底层任何工具特定的工作流。开发者学习的是你公司的命令，而不是工具的命令。当你更换引擎时，习惯不会被打断。
这不会使工具完全可互换。更换工具仍然会改变开发者在工作流中的体验。但它控制了影响范围。入口点、工件结构和审查流程保持不变。这足以让迁移变得可管理。
原文链接: I Tested Three Spec-Driven AI Tools. Here's My Honest Take.
汇智网翻译整理，转载请标明出处
