规范优先的智能体开发：AI 驱动工程的新工作流
规范优先开发的核心原则
规范优先的智能体开发将 AI 编程的范式从迭代式提示词（prompting）转变为结构化的、带有门控检查的流程。通过要求智能体在实现之前生成基于 YAML 的规范，该工作流确保了目标、约束和“完成”定义能够针对现有代码库进行明确审查。这种方法旨在消除“感觉编程”（vibe coding）中常见的模糊性，强制智能体引用特定的文件和代码行作为其提议变更的证据。
四阶段生命周期
每一项工作都遵循严格的四阶段流程，旨在维护系统完整性：
- create-spec：智能体定义目标、所需步骤和事实（带有文件/行引用），而不编写任何应用程序代码。
- review-spec：一个新的智能体实例（不具备之前的对话历史）根据当前代码库评估规范，以识别潜在冲突或缺失的需求。
- apply-spec：智能体严格基于已审查的规范实现代码、连接和测试。
- deliver-spec：变更通过提交门控（commit gate），在打开拉取请求（pull request）之前验证所有测试和构建阶段是否通过。
并行执行与状态管理
为了扩展开发，系统为每个规范使用独立的分支和工作树（worktrees）。由于 ID 是根据系统时钟生成的，并发的智能体可以在不冲突的情况下处理不同的功能。状态持久化在 context.yaml 文件中，允许智能体在中断后恢复工作。对于较大的功能，deliver-series 命令允许开发者将多个规范分组，在依赖关系允许的情况下并行构建，并将它们合并为一个拉取请求。
作为副作用的文档
这种方法的主要优势之一是自动生成项目历史记录。当智能体进行构建时，它会将每一个非显而易见的决策记录在 YAML 文件中，捕获架构选择背后的基本原理（例如，为什么选择某个特定库而不是另一个）。这创建了一个与代码并存的项目演进实时记录，消除了维护单独且过时的 Wiki 文档的需要。
社区观点与批评
虽然这种方法为管理智能体工作流提供了一种结构化方式，但社区讨论强调了关于规范驱动开发在现实环境中有效性的几个常见担忧：
- “代码即规范”论点：一些开发者认为，一个真正精确的规范实际上就是代码，试图在单独的文档中定义复杂系统会引入不必要的开销。
- 发现与迭代：批评者指出，在许多产品环境中，需求并非预先完全可知。一位用户评论道：> "问题在于，对于大多数基于产品的决策，你通常预先不知道自己不知道什么。在规范中反复修改以解决问题是一个巨大的错误。" — @handle
- 替代方法：支持“感觉编程”的人建议，先生成一个快速且粗糙的原型是发现需求的更有效方式，然后可以将其用作最终完善实现的基础。
- 工具比较：用户将此方法与 Spec Kit 和 BMAD 等现有框架进行了比较，质疑该实现相对于既定替代方案的具体优势。维护者强调，他们系统的独特价值在于预构建审查门控和提交阶段检查的自动化强制执行。