如何构建云软件工厂——规格驱动开发技能

这是我关于如何构建全自动化云软件工厂系列文章的第二篇。在这篇文章中，我将展示如何为那些过于复杂或模糊、无法一次性完成的问题引入规格驱动开发。本系列的目标是构建一个能够覆盖整个软件开发生命周期（SDLC）的完整工作工厂。

在上一篇文章中，我们从简单的「分类 → 实现」流程开始：一个智能体审核问题质量、提出澄清性问题，如果问题范围足够明确且可一次性完成，则作为草稿 PR 实现。这种方法适用于简单的 bug 和小型功能，但对于存在更多歧义或技术复杂性的问题则无法胜任。

为了让工厂智能体能够处理这类问题，我们将新增一个智能体：规格智能体（Spec agent）：

• 如果问题简单，则标记为“ready-to-implement”→ 实现智能体运行
• 如果问题复杂但符合路线图，则标记为“ready-to-spec”→ 规格智能体运行
• 如果问题存在歧义，则标记为“needs-info”
• 否则，标记为“wait-to-implement”

我们在之前已经实现了基础版本，但现在将细化“ready-to-spec”步骤。

要使其正常工作，第一个改动是更新分类技能，使其在决定何时创建规格时拥有更好的逻辑。当一个问题满足以下条件时，应标记为“ready-to-spec”：

• 符合我们的路线图和愿景
• 我在示例图像编辑器项目中添加了“roadmap.md”和“vision.md”文件，描述了我们希望它变成什么样以及我们计划朝哪个方向构建，以帮助智能体做出判断
• 具有足够的复杂性或歧义性，从而受益于一份规格说明。为简化起见：
  • “歧义”意味着存在多种潜在的产品或技术实现方案，且这些方案差异显著，需要人工判断哪种最佳
  • “复杂性”意味着实现代码将超过几百行。

我们示例应用的路线图

以下是分类技能的更新版本，用于处理规格制定：

更新后的分类技能

如果问题存在歧义或复杂性，但符合路线图和愿景，分类智能体将应用“ready-to-spec”标签，从而触发一个新的 GitHub Action，调用新的规格智能体。

规格 Action

我正在复用第一篇文章中建立的所有基础设施，这意味着你需要一个包含代码和工具链的 Docker 镜像、一个运行环境（我们的示例使用 Oz，Warp 的云自动化平台），以及设置 GitHub Actions 的能力。

规格 Action 会生成两份规格文档：

• PRODUCT.md：负责定义智能体需要实现的产品行为
• TECH.md：负责定义技术架构和代码结构

这两份文档都存放在“specs”目录下，该目录与要修复的问题编号相关联。

示例图像编辑应用中某个功能的 PRODUCT.md 示例

示例图像编辑应用中某个功能的 PRODUCT.md 示例

TECH.md 示例

TECH.md 示例

我建议将这些规格文档作为实现 PR 的一部分一并检入，不过你也可以先单独检入它们，待合并后再进行实现。检入后，你会保留一份智能体所追求的“做什么”和“怎么做”的记录，后续可以对照验证。我将在后续文章中介绍如何添加验证智能体（使用 /validate-changes-match-specs 命令）时展示具体做法。

智能体会生成规格文档的初始版本，但通常最好将它们拉取到本地工作空间，并通过交互式细化流程来对齐你与智能体的期望。我推荐使用类似 Matt Pocock 的 /grill-me 技能来完成此步骤。

一旦规格文档看起来不错，让你的智能体将底层问题标记为 ready-to-implement（或者直接在 GitHub 中手动标记）。这会触发我们的实现智能体开始构建符合规格的版本。为此，我更新了实现技能，使其能够查找规格文档并在实现时遵循它们。

指示实现智能体遵循规格

一旦你完成了所有这些设置，你就拥有了一个能够接受问题、实现简单问题、为较复杂问题制定规格文档，并在必要时让你介入审查和迭代的流程。

下一步是添加审查和验证智能体来确保实现的质量——这将是我下一篇文章的主题。

如果你想亲自尝试，请按照以下说明操作：https://github.com/warpdotdev-demos/cloud-factory-demo/ 并使用 Warp 云平台或你选择的编码智能体运行 /oz-cloud-factory-demo 技能。

试试看，然后告诉我效果如何。如果你错过了上一篇关于创建分类智能体的文章，也请阅读：

Zach Lloyd @zachlloydtweets · 6 月 26 日
文章
如何构建云软件工厂——自动分类技能
这是我关于如何使用技能和循环设置你自己的云软件工厂系列文章的第一篇。启动一个简单而有效的系统比你想象的要容易…
4121 41 10K