跳转到主要内容
markhuang.ai
教程

Dev Buddy：为 Claude Code 构建多 AI 开发流水线

一篇面向实践的 Dev Buddy 指南：这个开源 Claude Code 插件通过结构化开发流水线编排多个 AI 模型，支持基于任务的约束、并行专家分析，以及自动修复后重新评审的循环。

11 分钟阅读
claude-codeAI 工具代码质量多 AI开源
分享：
AI 驱动

AI 驱动 · 每小时限 20 次请求

让一个 AI 自己写代码、自己 review，问题很明显：它倾向于验证自己的假设，而不是推翻自己。数据也印证了这一点——单模型工作流产出的代码，漏洞率高出 2.74 倍（CodeRabbit 2025），45% 的 AI 生成代码存在安全缺陷（Veracode 2025）。

Dev Buddy 是一个开源的 Claude Code 插件，核心思路是：用多个 AI 模型跑结构化流水线——需求梳理、方案设计、编码实现、代码审查，每个阶段可以分配不同的模型，各自带着独立视角来审视。它隶属于 VCP (Vibe Coding Protocol) 项目，在 VCP 的代码标准执行能力之上，叠加了多模型流水线编排。

下面从头走一遍：怎么装 Dev Buddy、怎么配流水线，以及实际跑功能开发和 Bug 修复的完整输出示例。

Dev Buddy 到底干什么

Dev Buddy 把 AI 模型编排进基于任务的流水线，核心约束是任何阶段都不能跳过——阶段间的依赖靠数据约束来强制，而不是靠 prompt 里写一句"请不要跳过"。

功能流水线:
  需求 → 规划 → 方案审查 → 实现 → 代码审查
       ↑              ↑           ↑              ↑              ↑
   5 个专家       架构师      sonnet/opus      实现者       sonnet/opus
   并行探索       设计方案      审查方案          写代码       审查实现

目前内置两条流水线：

流水线命令阶段
功能开发/dev-buddy-feature-implement需求 → 规划 → 方案审查 → 实现 → 代码审查
Bug 修复/dev-buddy-bug-fix根因分析 → 汇总 → 方案验证 → 实现 → 代码审查

每个阶段可以指定不同的模型或 provider。审查不通过的话，会自动生成修复任务和复审任务，循环往复，直到所有 reviewer 都放行。

前置条件

如果想用团队模式做需求梳理（5 个专家并行），需要先设置环境变量：

bash
export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

Step 1: 安装 Dev Buddy

如果还没添加 VCP marketplace：

bash
/plugin marketplace add Z-M-Huang/vcp

安装两个插件：

bash
/plugin install vcp@vcp
/plugin install vcp@dev-buddy

项目还没初始化过的话，跑一下：

bash
/vcp-init

Step 2: 看懂默认流水线配置

Dev Buddy 自带一套默认配置。首次运行后可以查看 ~/.vcp/dev-buddy.json，也可以直接沿用默认值：

json
{
  "feature_pipeline": [
    { "type": "requirements", "provider": "anthropic-subscription", "model": "opus" },
    { "type": "planning", "provider": "anthropic-subscription", "model": "opus" },
    { "type": "plan-review", "provider": "anthropic-subscription", "model": "sonnet" },
    { "type": "plan-review", "provider": "anthropic-subscription", "model": "opus" },
    { "type": "plan-review", "provider": "anthropic-subscription", "model": "sonnet" },
    { "type": "implementation", "provider": "anthropic-subscription", "model": "sonnet" },
    { "type": "code-review", "provider": "anthropic-subscription", "model": "sonnet" },
    { "type": "code-review", "provider": "anthropic-subscription", "model": "opus" },
    { "type": "code-review", "provider": "anthropic-subscription", "model": "sonnet" }
  ],
  "bugfix_pipeline": [
    { "type": "rca", "provider": "anthropic-subscription", "model": "sonnet" },
    { "type": "rca", "provider": "anthropic-subscription", "model": "opus" },
    { "type": "plan-review", "provider": "anthropic-subscription", "model": "sonnet" },
    { "type": "implementation", "provider": "anthropic-subscription", "model": "sonnet" },
    { "type": "code-review", "provider": "anthropic-subscription", "model": "sonnet" },
    { "type": "code-review", "provider": "anthropic-subscription", "model": "opus" },
    { "type": "code-review", "provider": "anthropic-subscription", "model": "sonnet" }
  ]
}

每个条目指定三样东西：

  • type — 流水线阶段（requirements、planning、plan-review、implementation、code-review、rca）
  • provider — 用哪个 AI 服务商
  • model — 该服务商下的具体模型

条目数量直接决定流水线有多少个任务。想多审几轮？多加几个 plan-review 或 code-review 条目就行。觉得流程太长？删掉几个条目即可。

Step 3: 跑第一个功能流水线

启动功能开发流水线：

bash
/dev-buddy-feature-implement 给 /api/login 接口加限流

Phase 1: 需求梳理（团队模式）

Dev Buddy 会拉起 5 个专家角色，并行扫描你的代码库：

流水线: pipeline-myproject-a1b2c3
已创建包含 5 个专家的团队:
​
  技术分析员     → 探索代码库结构、依赖和既有模式
  UX/领域分析员  → 分析用户工作流、最佳实践和可访问性
  安全分析员     → 威胁建模、OWASP 分析、VCP 标准检查
  性能分析员     → 负载分析、扩展性和资源约束
  架构分析员     → 设计模式、SOLID 原则和可维护性
​
专家正在探索...（大约需要 1-2 分钟）

每个专家各输出一份分析文件：

专家输出
技术分析员.vcp/task/analysis-technical.json
UX/领域分析员.vcp/task/analysis-ux-domain.json
安全分析员.vcp/task/analysis-security.json
性能分析员.vcp/task/analysis-performance.json
架构分析员.vcp/task/analysis-architecture.json

协调者可能会根据专家发现向你追问几个问题。所有专家完成后，需求梳理 agent 会把各方意见综合成一份 .vcp/task/user-story.json：

json
{
  "id": "story-20260225-143022",
  "title": "给登录接口加限流",
  "requirements": {
    "functional": [
      "每个 IP 在 15 分钟窗口内最多尝试 /api/login 5 次",
      "超限返回 429 Too Many Requests，带 Retry-After header",
      "登录成功后重置计数器"
    ],
    "non_functional": [
      "限流状态必须跨服务重启保留（Redis/数据库）",
      "每个请求的额外延迟低于 1 毫秒"
    ]
  },
  "acceptance_criteria": [
    "AC-1: 15 分钟内第 6 次登录尝试返回 429",
    "AC-2: Retry-After header 包含距窗口重置的秒数",
    "AC-3: 登录成功会重置尝试计数器",
    "AC-4: 限流状态能跨服务重启保留"
  ]
}

Phase 2: 方案设计

架构师 agent 读取 user story，设计实现方案：

任务: 规划 1 (opus)
读取: .vcp/task/user-story.json
​
正在设计实现方案...

输出是 .vcp/task/plan-refined.json，包含技术方案、实现步骤、测试计划和风险评估。

Phase 3: 方案审查

配置里有几个 plan-review 条目，就会生成几个审查任务。默认串行执行——前一个 reviewer 通过了，下一个才开始：

任务: 方案审查 1 (sonnet) — 审查 plan-refined.json
  检查: 可行性、完整性、验收标准覆盖
  结论: approved
​
任务: 方案审查 2 (opus) — 审查 plan-refined.json
  检查: 架构合理性、安全影响
  结论: needs_changes
  问题:
    - 没有考虑多实例部署下的分布式限流
    - Redis 不可用时缺少降级方案
​
  → 创建修复任务: "修复方案审查 2 v1"
  → 创建复审任务: "方案审查 2 v2"

reviewer 返回 needs_changes 后，Dev Buddy 会自动：

  1. 把具体问题写进修复任务
  2. 创建复审任务，阻塞到修复完成
  3. 由同一个 reviewer 验证修复结果，通过后流水线才继续往下走

这个循环会一直转，要么审过，要么达到最大迭代次数。

Phase 4: 编码实现

方案审查全部通过后，实现 agent 开始写代码：

任务: 实现 1 (sonnet)
读取: .vcp/task/plan-refined.json
正在实现限流逻辑...
​
已修改文件:
  + src/middleware/rate-limit.ts (新增)
  M src/api/routes.ts (添加中间件)
  + src/__tests__/rate-limit.test.ts (新增)
​
输出: .vcp/task/impl-result.json

Phase 5: 代码审查

代码审查和方案审查同样的套路——默认串行，不通过就自动进修复循环：

任务: 代码审查 1 (sonnet)
  检查: 功能正确性、测试覆盖、错误处理
  结论: approved
  已验证验收标准: AC-1 ✓, AC-2 ✓, AC-3 ✓, AC-4 ✓
​
任务: 代码审查 2 (opus)
  检查: 安全、性能、架构
  结论: approved
​
任务: 代码审查 3 (sonnet)
  检查: 代码质量、可维护性
  结论: approved
​
流水线完成！所有审查均已通过。

Step 4: 跑一个 Bug 修复流水线

Bug 修复流水线的前半段换了一套更适合问题诊断的流程：

bash
/dev-buddy-bug-fix 用户反馈购物车超过 50 件商品时 /api/checkout 返回 500 错误

根因分析

多个 RCA agent 各自独立诊断问题：

任务: RCA 1 (sonnet)
  正在调查: /api/checkout handler、购物车处理逻辑
  根因: calculateTotals 里的 Array.map 在处理大购物车折扣组合时
    产生了 O(n²) 的嵌套循环
  证据: stack trace 显示 cart.service.ts:142 超时
​
任务: RCA 2 (opus)
  正在调查: 数据库查询、内存 profiling
  根因: 确认 O(n²) 复杂度。另外发现每个商品都会单独发一次
    DB 查询来检查库存
    （cart.repository.ts:89 存在 N+1 查询问题）

诊断汇总

编排者把各方诊断结果合并：

正在汇总 RCA 发现...
  RCA 1: O(n²) 折扣计算 — 两个 agent 均确认
  RCA 2: N+1 库存查询 — opus 额外发现的问题
​
合并诊断已写入 .vcp/task/user-story.json
修复方案已写入 .vcp/task/plan-refined.json
  - 用 Map 查找替换嵌套循环，复杂度降为 O(n)
  - 用 WHERE IN 子句批量查库存

之后流水线进入方案验证、编码实现、代码审查——和功能流水线的后半段一样。

Step 5: 配置 AI Provider

Dev Buddy 支持三种 provider 类型。

订阅模式（默认）

走 Claude Code 内置的 Task tool，直接用你的 Claude 订阅，不需要 API key：

json
{ "type": "code-review", "provider": "anthropic-subscription", "model": "opus" }

可选模型：opus、sonnet、haiku。

API Provider

接入兼容 API 协议的外部服务——OpenRouter、MiniMax、自部署模型都行：

bash
/dev-buddy-manage-presets

会打开一个交互式预设管理器：

Dev Buddy — AI 预设管理器
​
当前预设:
  1. anthropic-subscription (subscription) — 内置
​
操作:
  [1] 添加新预设
  [2] 更新预设
  [3] 删除预设
​
> 1
​
预设名称: openrouter
类型: api
Base URL: https://openrouter.ai/api/v1
API Key: sk-or-***
模型: anthropic/claude-sonnet-4, anthropic/claude-opus-4
​
预设 "openrouter" 已保存。

然后在流水线配置里直接引用：

json
{ "type": "code-review", "provider": "openrouter", "model": "anthropic/claude-opus-4" }

CLI Provider

接入命令行 AI 工具，比如 OpenAI Codex：

json
{
  "name": "codex",
  "type": "cli",
  "command": "codex",
  "args_template": "--model {model} --prompt {prompt} --output-file {output_file}",
  "one_shot_args_template": "--model {model} --prompt {prompt}",
  "models": ["o3-mini"]
}

这样就能把 Codex 当成一个独立的最终把关者——不同的 AI 家族，往往能抓到 Claude 看不到的问题。

Step 6: 自定义流水线

直接编辑 ~/.vcp/dev-buddy.json，按需调整流水线。

精简审查（快速迭代）

json
{
  "feature_pipeline": [
    { "type": "requirements", "provider": "anthropic-subscription", "model": "opus" },
    { "type": "planning", "provider": "anthropic-subscription", "model": "opus" },
    { "type": "plan-review", "provider": "anthropic-subscription", "model": "sonnet" },
    { "type": "implementation", "provider": "anthropic-subscription", "model": "sonnet" },
    { "type": "code-review", "provider": "anthropic-subscription", "model": "opus" }
  ]
}

并行审查

加上 "parallel": true，审查就可以并发跑：

json
{
  "feature_pipeline": [
    { "type": "requirements", "provider": "anthropic-subscription", "model": "opus" },
    { "type": "planning", "provider": "anthropic-subscription", "model": "opus" },
    { "type": "plan-review", "provider": "anthropic-subscription", "model": "sonnet", "parallel": true },
    { "type": "plan-review", "provider": "anthropic-subscription", "model": "opus", "parallel": true },
    { "type": "implementation", "provider": "anthropic-subscription", "model": "sonnet" },
    { "type": "code-review", "provider": "anthropic-subscription", "model": "sonnet", "parallel": true },
    { "type": "code-review", "provider": "anthropic-subscription", "model": "opus", "parallel": true }
  ]
}

同一组里的并行审查会同时启动，下一阶段会等这组全部完成后再开始。

混合 Provider（跨模型审查）

不同阶段用不同 provider，获取真正独立的视角：

json
{
  "feature_pipeline": [
    { "type": "requirements", "provider": "anthropic-subscription", "model": "opus" },
    { "type": "planning", "provider": "anthropic-subscription", "model": "opus" },
    { "type": "plan-review", "provider": "anthropic-subscription", "model": "sonnet" },
    { "type": "plan-review", "provider": "openrouter", "model": "anthropic/claude-opus-4" },
    { "type": "implementation", "provider": "anthropic-subscription", "model": "sonnet" },
    { "type": "code-review", "provider": "anthropic-subscription", "model": "opus" },
    { "type": "code-review", "provider": "codex", "model": "o3-mini" }
  ]
}

Step 7: 一次性任务

有些小活儿用不着跑完整流水线，直接 /dev-buddy-once：

bash
/dev-buddy-once use anthropic-subscription model opus 审查这个 PR 的安全问题
bash
/dev-buddy-once use openrouter model anthropic/claude-opus-4 重构认证模块

指定 provider 和模型，跑完就完事——没有流水线，没有审查循环，纯粹的单次执行。

Web 配置面板

不想改配置文件的话，有可视化界面：

bash
/dev-buddy-config

会在本地起一个 Web UI，三个 tab：

  • AI Presets — 增删改 provider 配置
  • Pipeline Config — 拖拽调整流水线阶段，设置并行组
  • Session Managers — 查看正在运行的会话和状态

任务驱动的执行机制

Dev Buddy 保证流水线不被跳过的秘诀是数据约束，而不是靠 prompt 指令。

传统做法：

指令: "先跑 Sonnet 审查，再跑 Opus 审查，然后实现"
问题: AI 可能自作主张跳过它觉得"多余"的步骤，或者自己改顺序

Dev Buddy 的做法：

T1 = TaskCreate("方案审查 1")
T2 = TaskCreate("方案审查 2")  → blockedBy: [T1]
T3 = TaskCreate("实现")       → blockedBy: [T2]

编排者调用 TaskList() 时，被阻塞的任务根本不会出现在返回列表里。AI 只能看到、也只能领取下一个未阻塞的任务。这是数据查询层面的约束，不是"请你按顺序来"这种君子协定——从结构上就不可能跳步。

动态修复任务

当 reviewer 返回 needs_changes 时：

代码审查 2 (opus): needs_changes
  问题: 购物车商品数量缺少输入校验
​
  → TaskCreate("修复代码审查 2 v1")           blockedBy: [review_task]
  → TaskCreate("代码审查 2 v2")               blockedBy: [fix_task]
  → TaskUpdate(next_stage, addBlockedBy: [v2])    重接任务链

修复→复审循环会持续进行，直到通过或达到最大迭代次数（默认 10 次），超出后会交给你人工处理。

流水线产物

所有流水线输出都落在 .vcp/task/ 目录下：

文件内容
pipeline-tasks.json任务链，含 ID、配置快照、已解析的阶段
analysis-*.json各专家的探索发现（共 5 个文件）
user-story.json综合后的需求和验收标准
plan-refined.json技术方案、实现步骤、测试计划和风险
plan-review-N.json方案审查结论和反馈
impl-result.json实现摘要和变更文件列表
code-review-N.json代码审查结论和发现
rca-N.json根因分析发现（Bug 修复流水线）

这些产物构成了流水线中每个决策的完整审计链。

快速参考

命令用途
/dev-buddy-feature-implement [描述]启动功能开发流水线
/dev-buddy-bug-fix [描述]启动 Bug 修复流水线
/dev-buddy-once use <provider> [model <model>] <task>用指定 provider 跑单次任务
/dev-buddy-manage-presets增删改 AI provider 预设
/dev-buddy-config打开 Web 配置面板

Dev Buddy 是 VCP 项目 的一部分——和代码标准执行同一个 repo。VCP 负责主动执行规则，Dev Buddy 在此基础上叠加多模型审查。

许可

Article text © 2026 Mark Huang. Licensed under Creative Commons Attribution-NonCommercial 4.0 International (CC BY-NC 4.0) unless otherwise noted. 文章文本可在非商业场景下分享或翻译，但需标注原文 URL。商业使用需事先取得书面许可，并清楚引用原始来源。

代码片段、截图、第三方素材和网站源码可能适用单独条款。

建议署名： Based on "Dev Buddy：为 Claude Code 构建多 AI 开发流水线" by Mark Huang, originally published at https://markhuang.ai/zh/blog/dev-buddy-multi-ai-pipelines-with-claude-code.

相关文章

10 分钟阅读

VCP：在 Claude Code 中约束 AI 辅助开发的代码标准

一篇安装和使用 Vibe Coding Protocol（VCP）的分步指南：这个三层约束框架能在 Claude Code 内捕捉安全漏洞、执行架构标准，并编排多 AI 代码评审。

阅读文章
8 分钟阅读

多 AI 论

LLM 会在超过 90% 的情况下确认自己的答案，对自身错误还有 64.5% 的盲区率。跨模型家族的多 AI 流水线，让 Claude 评审 GPT、GPT 评审 Qwen，能打破自我评审的天花板。本文讨论研究、成本和真正有效的做法。

阅读文章
6 分钟阅读

5 分钟试用 Dense-Mem 托管演示

一篇快速教程：使用托管的 Dense-Mem 测试实例，把 Claude Code 和 Codex 接到同一份临时记忆，并观察共享上下文如何让 AI 更聪明地工作。

阅读文章