三个规范驱动SDLC工具实测报告

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