我的AI优先规范驱动开发经验

梯形图转SCL | 博途AI辅助编程文档 | AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

此前，我对规范驱动开发（SDD）方法进行了理论探讨，该方法获得了相当大的关注。我有很多关于它的看法，但一直等到我和团队在生产系统中获得了实际经验。几个月后，我准备好分享一些见解和关于应用SDD的思考。

如果你是完全的新手，建议你先阅读我关于将需求迁移到源代码以进行端到端管理的文章。SDD基本上通过AI代理来生成源代码并与规范保持同步来解决这个问题。

1、为什么选择OpenSpec

我的团队将一个门户网站的需求委托给了OpenSpec，该门户的UI和后端都在一个git仓库中。该门户是一个独立的应用程序，不与其他系统绑定。这使其成为SDD的理想候选者。

为什么选择OpenSpec而不是其他候选者如SpecKit、Kiro、BMAD等？答案很简单：我们只是使用组织中已有的工具。所以我无法评论其他工具或进行比较分析。

如果可以的话，我们会选择另一个工具吗？可能吧，但多年的经验告诉我，团队之间使用多种工具的混乱通常会在以后造成问题。

在团队内部，我们同意将门户的开发转移到AI轨道上，并使用AI生成需求工件。

2、工作流程

从一开始，流程是这样的：

• 作为PO（PM、BA或任何人），我在Jira工单中编写一个简短的描述，主要关注业务意图和预期结果。
• 准备好后，我为该功能在仓库中创建一个新分支，并启动一个OpenSpec变更：/opsx-new <工单号+功能名>。
• 然后我运行/opsx-continue，添加Jira工单的内容，以生成第一个工件：proposal.md。
• 我审查文档几次，提交它，并将分支推送到远程。
• 开发部分从审查proposal.md开始，提出问题，生成design.md和task.md，同时讨论和澄清细节。
• 然后开发人员继续使用/opsx-apply并审查生成的解决方案。
• 之后，该分支被部署到开发环境进行测试（手动或如果涉及聊天机器人则使用AI评估）。
• 如果一切正常，该分支被合并到主分支。如果不正常，开发人员重复解决方案生成循环。
• 然后我运行一个自定义技能，根据OpenSpec变更工件生成发布说明和用户文档。由于我们将发布说明和用户文档都存储在同一仓库中，这非常方便。
• 之后，我运行/opsx-archive，它同步变更，将其添加到规范中，并归档变更。

总体而言，正常路径并不困难，只是你需要一些git技能。流程可能有变体，例如一次生成提案、设计和任务工件（/opsx-propose），但团队协议是逐步生成所有内容。

3、Jira和Confluence会怎样

这种简化的流程使得之前的需求来源（如Jira和Confluence及其类似物）变得冗余。我们仍然需要需求和围绕它们的整个流程，但工件及其存储方式现在发生了变化。我们可能仍然需要PRD，因为我不指望某些利益相关者访问我们的git仓库并从那里读取Markdown文件。但在SDD工件和其他管理系统之间重复信息似乎不合逻辑。

为此，我们将几乎所有文档都迁移到了源代码中，以告别Confluence（不幸的是，并非完全如此）。Jira稍微复杂一些。我们需要它作为工单跟踪器，具有Sprint、Epic和其他Scrum衍生的运营方式，所以没有它我们就无法让管理层满意。

主要产品经理的职责之一就是让管理层满意。起初，在实现之后但在归档之前，我生成了具有功能范围和验收标准的最新Jira描述。

我的思维自然地抵制在系统之间毫无意义地重复数据。我也提醒自己一个绝对真理：没有人会阅读那些工单。

最终我们得到的工单没有描述，只是作为跟踪工作状态和遵守组织规则的占位符。OpenSpec的变更文件夹包含工单引用，因此它是可追溯的。

我可能会因此惹上麻烦，但之后我可以事后从规范生成工单描述。我认为事先这样做是浪费token。

所以现在我直接进入代理应用（Codex、Claude Desktop、OpenCode）并运行/opsx-explore，带上我拥有的所有信息。之后，我创建proposal.md并遵循后续步骤。

4、为什么有效

我们已经使用OpenSpec、SDD和AI优先开发几个月了。我认为这个实验是成功的，原因如下：

1. 我们是一个有多个优先级的小团队。我们可以继续使用AI工具以良好的速度开发门户，同时专注于其他优先级。
2. 我们没有专门的业务分析师来仔细研究需求和编写规范。作为产品经理，同时还要处理多个其他优先级，我将此委托给了OpenSpec。
3. 这个产品是一个独立的、尚未成为遗留系统的门户，由一个小团队维护，所有内容都在一个仓库中。

如你所见，我们并没有完全依赖AI，而是在每个阶段都保留人工参与。但有一些事情我们不使用SDD流程：

• 对于AI聊天机器人，我在没有OpenSpec的情况下进行小的提示调整以处理回归问题。
• 一些错误，特别是UI方面的，在没有OpenSpec的情况下修复。
• 安全性在OpenSpec之外处理。
• 评估也在外部处理。

OpenSpec的SDD是一个重量级流程的主要原因是，与你已经确切知道要修复什么和在哪里修复的情况相比，它消耗了大量的时间和token。

这增加了偏差的风险，但到目前为止我们还没有遇到这个问题。也许考虑到产品的适度范围，我们根本不会遭受这种问题。

5、可能不适用的情况

OpenSpec和/或SDD可能不适用的原因与使其在我案例中成功的原因相反：

• 我不知道如何为具有多个微服务的分布式系统扩展它。
• 我不知道如何在职责在多个域/团队之间共享的monorepo中处理它。
• 我不知道如何有效地构建规范，一旦它增长到开始污染上下文的程度。
• 我不知道它如何处理一次性无法处理的过大变更。

原文链接：My Experience with AI-First Spec-Driven Development

汇智网翻译整理，转载请标明出处