VM0 开发工作流：像管理团队一样管理 AI 智能体

在 VM0 开发团队中，每位开发者都会同时运行多个 Claude Code 实例，通常超过八个。

我们像对待真正的开发者一样对待 Claude Code。（没错，我们公司半开玩笑地叫做 AI Colleagues Co！）

正因如此，VM0 开发工作流背后的设计理念，与软件工程中经典的团队管理实践一脉相承。

我们用 GitHub Issues 追踪工作，用 Pull Request 进行代码审查和合并，用 GitHub Actions 处理自动化任务。在两个月内，这套体系帮助我们发布了 404 个版本，编写了超过 230,000 行代码。

这篇文章将解释我们是如何让这一切运转起来的，以及为什么核心问题从来不是 AI 的能力，而是人的协调。

AI 驱动的开发工作流实践

当你并行协调多个 AI 智能体时，瓶颈并不在于模型能否写出代码，真正的瓶颈是人的认知负荷。

这套工作流由 14 条斜杠命令组成，分为三个层次：深度探索（Deep Dive）、Issue 管理和 PR 管理。

先来看看我的工作流是什么样的，以及一个功能通常是如何构建出来的。

需求对齐

由人类开启一个 Claude 会话，并以 /deep-research 开始。Claude 从代码库、文档和相关上下文中收集信息。我们讨论发现的内容，并就我们实际要解决的问题达成共识。
方案探索

使用 /deep-innovate，Claude 提出几个可能的方向，并附上各自的权衡分析。我们讨论、缩小范围，并选定一个方向。
创建 Issue

使用 /issue-create 创建一个 GitHub Issue。人类审查该 Issue，确保需求被清晰记录。
规划与审批

使用 /issue-plan 让 Claude 继续推进工作。Claude 会自动运行完整的深度探索工作流，并将结果发布到 Issue 中，包括：
1. /deep-research 的调研发现
2. /deep-innovate 的方案对比
3. /deep-plan 的具体实施计划
实施

审批通过后，/issue-action 让 Claude 执行计划、编写测试、开启 PR，并确保 CI 通过。
审查与合并

我们使用 /pr-review 进行结构化审查，然后由人类进行最终审查后合并。

人类在三个检查点介入：需求、方向和验收。其余一切均自主运行。

思维转变：你在领导一支 AI 开发者团队

我意识到需要一套结构化工作流的那一刻，是当增加更多 Claude 会话反而让事情变得更糟的时候。并行运行的实例越多，就越难追踪每个实例在做什么、工作处于什么状态，以及哪些决策已经做出。

没有外部工具，我根本无法同时管理那么多 Claude 实例。就在那时我恍然大悟：这不是 AI 的问题，而是管理问题。

GitHub 本就是软件开发中天然的协作工具，所以我没有另起炉灶，而是开始像对待人类队友一样对待 Claude。一旦这样做，我的管理带宽便骤然扩展。

十年的项目和团队管理经验，在这个全新的语境下终于有了用武之地。将 Claude 视为团队成员，将 GitHub 作为共享的沟通与管理空间，整个系统再次变得可控。

一位优秀的团队领导者懂得何时介入、何时放手：

检查点	我做什么	AI 做什么
需求	对齐问题，明确范围	调研代码库，收集上下文
方向	审查发现，批准方案	提出 2-3 个方案，评估权衡
验收	审查 PR，验证质量	实施、测试、修复 CI

这与高效软件团队的运作方式如出一辙。我不会对开发者进行微观管理，而是设定清晰的需求、审查关键决策、验证最终输出。同样的原则适用于管理 AI 智能体。

深度探索流程强制执行结构化的慢思考

深度探索工作流在实施之前强制进行深思熟虑。有时 Claude 会陷入死胡同，这时我们会强制 Claude 停下来思考，然后一起讨论。它分为三个阶段：

阶段	命令	目的	输出
调研	/deep-research	收集事实，理解上下文	research.md
创新	/deep-innovation	探索多种方案	innovate.md
规划	/deep-plan	定义具体步骤	plan.md

每个阶段都有严格的边界。

调研：不提建议
创新：不涉及细节
规划：不进行实施

这些约束迫使 Claude 进行缓慢、深思熟虑的推理，而不是直接跳到写代码。没有这些约束，边界情况和架构问题往往会被忽略！

使用示例

/deep-research investigate the authentication flow, I'm seeing token expiration issues

[Claude researches, analyzes 12 related files, finds 3 similar patterns]

/deep-innovate what are our options for fixing this?

[Claude presents 3 approaches with trade-offs, you pick one]

/issue-create let's track this fix

对于简单任务，你可以跳过深度探索，直接使用 /issue-create。

对于存在技术不确定性的复杂任务，深度探索阶段有助于确保你和 Claude 在实施开始前达成一致。

将 GitHub 用作共享记忆

大多数 AI 工具将上下文视为临时性的。会话结束，记忆消失。

VM0 将 GitHub 用作持久化记忆：

GitHub 功能	存储内容
Issue 正文	需求与决策
Issue 评论	调研、选项、计划
PR 评论	审查与摘要
标签	工作流状态

这同样解决了一个人的问题：上下文恢复。

当我管理 8 个以上的 Claude 实例时，我会收到工作完成的通知。但我无法从 Claude 的对话中还原它在做什么、做出了哪些决策，或者当前状态是什么。

GitHub Issues 解决了这个问题。每个 Issue 都会显示：

原始需求
调研发现（发现了什么）
创新阶段（考虑了哪些选项）
已批准的计划（将要实施什么）

这种结构化格式让审查变得高效。我可以快速浏览各个阶段，理解方案，批准或请求修改，而无需回忆最初的对话。

工作完成后，我不需要记住聊天窗口里发生了什么。我可以打开 Issue，看到完整的故事，结构清晰，白纸黑字。

智能体之间的交接

由于所有上下文都存储在 GitHub 中，工作可以在智能体之间无缝流转：

一个智能体创建 Issue 或 PR
另一个智能体稍后使用 /deep-research issue 123、/issue-plan 123 或 /deep-research PR 124 继续工作

对于较长的讨论，/issue-compact 会将所有内容整合成一个简洁的 Issue 正文。这让人类和 AI 的交接都变得轻松。

工作流模式总结

说了这么多，让我总结几个实用技巧。

简单任务

/issue-create → /issue-plan → /issue-action → /pr-check-and-merge

当需求明确、工作直接时使用此流程。

复杂任务

/deep-research → discussion → /deep-innovate → discussion →
/issue-create → /issue-plan → /issue-action →
/pr-review → /pr-check

这可以防止在错误的方向上浪费精力。

并行工作

多个智能体可以同时工作，而人类则审查已完成的检查点。这是工作流扩展效果最好的场景。

Agent 1: /issue-plan #123
Agent 2: /issue-plan #124
Agent 3: /pr-review #100
Agent 4: /deep-research new feature requirements

命令参考

深度探索命令

命令	目的
`/deep-research`	收集信息，理解代码库。不允许提出建议。
`/deep-innovate`	探索 2-3 种方案，评估权衡。不允许写代码。
`/deep-plan`	创建具体的实施步骤。不允许进行实施。

Issue 命令

命令	目的
`/issue-create`	根据对话上下文创建 Issue
`/issue-bug`	创建包含复现步骤的 Bug 报告
`/issue-feature`	创建以需求为核心的功能请求
`/issue-plan`	执行完整的深度探索工作流，将结果发布到 Issue
`/issue-action`	在人类批准后继续实施
`/issue-compact`	整合 Issue 正文与评论，便于交接

PR 命令

命令	目的
`/pr-check`	监控 CI 流水线，自动修复，最多重试 3 次
`/pr-review`	按提交逐一审查 PR，对照项目标准
`/pr-comment`	将对话讨论摘要发布为 PR 评论

快速上手

从简单开始：用 /issue-create → /issue-plan → /issue-action 完成你的第一个任务
为复杂任务添加深度探索：当需求不明确或技术复杂时，从 /deep-research 开始
逐步扩展：随着你对审查节奏越来越熟悉，逐渐增加 Claude 实例数量
信任流程：让 Claude 在检查点之间自主工作

这套工作流的设计支持渐进式采用。你不需要从第一天就使用全部 14 条命令。先从基本的 Issue 流程开始，随着信心增长，再加入深度探索阶段和并行工作。

扩展考量：当你拥有更多智能体时该怎么做

这套工作流已在 10 个以上并发 Claude 实例的场景下经过测试。我们的建议：

最多 10 个智能体：可以与每个智能体进行深度协作，较为舒适
超过 10 个：不推荐

限制因素不是工作流本身，而是人的注意力和决策质量。当管理超过 10 个智能体时，你可能会在审查检查点成为瓶颈，决策质量也会开始下降。

经典的"两个披萨团队"原则在这里同样适用。限制人类团队规模的约束，同样限制着一个人能有效管理的 AI 智能体数量。

我目前正在探索一种 8×8 的两级团队结构，以突破 10 个智能体的限制，但尚未形成有效的实践方法。有了具体成果后，我会进一步分享……

VM0 开发工作流改变了我们在 AI 成为团队一员时对软件开发的思考方式。

当你将 AI 智能体视为团队成员而非工具时，一切都会水到渠成。GitHub 成为团队的共享记忆，Issue 成为工作项，PR 成为可交付成果，而你则成为团队领导者，专注于架构、方向和质量，让你的 AI 团队负责实施。

这就是我们在两个月内发布 404 个版本的方式。也是你用 AI 扩展自己开发能力的方式。