使用示例：多代理协作代码审核

本文档演示如何使用 Vibe Kanban 编排多个 AI 代理进行全面的代码审核，检测 Bug、安全漏洞和性能问题，并生成带有完整解决方案的中文审核报告。

场景背景

代码审核是保证代码质量的重要环节。使用多个 AI 代理协作审核可以：

从不同角度发现问题
交叉验证减少误报
并行处理提高效率
生成全面的审核报告

核心约束：

⛔ 禁止修改任何源代码 - 所有代理只能读取代码
✅ 只能在 .code_review/ 目录下生成审核报告
🔄 所有问题必须经过二次确认验证
📝 报告使用中文 Markdown 格式
💡 必须提供完整的解决方案

审核报告结构

.code_review/
├── 2024-01-20_143052/                    # 审核时间戳目录
│   ├── 00_审核摘要.md                    # 总体摘要
│   ├── 01_Bug分析报告.md                 # Bug 详细报告
│   ├── 02_安全漏洞报告.md                # 安全问题报告
│   ├── 03_性能问题报告.md                # 性能问题报告
│   ├── 04_二次验证报告.md                # 验证确认报告
│   └── 05_最终审核报告.md                # 整合后的最终报告
└── latest -> 2024-01-20_143052/          # 指向最新报告的软链接

工作流设计

整体流程图

┌─────────────────────────────────────────────────────────────────────────┐
│                    Vibe Kanban - 代码审核工作流                          │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│  阶段 1: 准备          阶段 2: 并行审核          阶段 3: 验证            │
│  ┌──────────┐         ┌──────────────┐         ┌──────────┐            │
│  │ 代码结构 │────────▶│   并行审核   │────────▶│ 二次确认 │            │
│  │   分析   │         │              │         │   验证   │            │
│  └──────────┘         └──────────────┘         └──────────┘            │
│       │                      │                       │                  │
│       ▼                      ▼                       ▼                  │
│  Claude Code           ┌─────────────┐          Claude Code            │
│  (只读分析)            │ Claude Code │ Bug      (交叉验证)             │
│                        │ Gemini CLI  │ Security                        │
│                        │ Codex CLI   │ Perf                            │
│                        └─────────────┘                                  │
│                                                                         │
│  阶段 4: 报告生成                                                        │
│  ┌──────────────────────────────────────────────────────────┐          │
│  │              生成最终中文 Markdown 报告                    │          │
│  │              包含问题描述 + 完整解决方案                   │          │
│  └──────────────────────────────────────────────────────────┘          │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘

代理分工策略

阶段	任务	代理	模式	说明
1	代码结构分析	Claude Code	Plan (只读)	建立代码地图
2.1	Bug 检测	Claude Code	Plan (只读)	逻辑错误、边界问题
2.2	安全漏洞扫描	Gemini CLI	Plan (只读)	OWASP Top 10、注入攻击
2.3	性能问题分析	Codex CLI	Plan (只读)	算法复杂度、资源泄漏
3	二次验证	Claude Code	Plan (只读)	交叉验证所有发现
4	报告生成	Claude Code	Build	生成中文 Markdown 报告

MCP 服务配置

json

{
  "mcp": {
    "servers": {
      "filesystem": {
        "type": "local",
        "command": ["mcp-server-filesystem"],
        "args": ["--root", "/path/to/project"],
        "enabled": true,
        "permissions": {
          "read": ["**/*"],
          "write": [".code_review/**/*"],
          "deny_write": [
            "src/**/*",
            "lib/**/*",
            "include/**/*",
            "app/**/*",
            "tests/**/*",
            "*.ts",
            "*.js",
            "*.py",
            "*.go",
            "*.java",
            "*.cpp",
            "*.c",
            "*.h",
            "*.rs"
          ]
        }
      }
    }
  },
  "constraints": {
    "protected_paths": ["**/*.ts", "**/*.js", "**/*.py", "**/*.go", "**/*.java", "**/*.cpp", "**/*.c", "**/*.h", "**/*.rs", "**/*.vue", "**/*.jsx", "**/*.tsx"],
    "writable_paths": [".code_review/**/*"],
    "on_violation": "block_and_abort",
    "violation_message": "⛔ 代码审核模式禁止修改任何源代码！只能在 .code_review/ 目录下生成报告。"
  }
}

详细任务设计与提示词

阶段 1：代码结构分析

任务：建立代码地图

markdown

## 任务描述
分析项目代码结构，建立完整的代码地图，为后续审核提供基础信息。

## 🔒 严格约束（必须遵守）
- ⛔ **绝对禁止**修改任何源代码文件
- ⛔ **绝对禁止**创建、编辑、删除 .code_review/ 目录以外的任何文件
- ✅ 此阶段为**纯分析阶段**，只读取和分析代码
- ✅ 将分析结果保存在内存中，传递给下一阶段

## 交付物
1. 项目技术栈识别
2. 目录结构分析
3. 核心模块依赖关系
4. 入口点和关键路径识别
5. 第三方依赖清单

## 提示词

```
你是一个专业的代码结构分析师。你的任务是分析项目代码结构，为后续的代码审核提供基础信息。

【绝对约束 - 违反将导致任务失败】
1. 你只能读取代码，绝对不能修改任何文件
2. 你不能创建任何文件（此阶段不生成报告）
3. 你不能执行任何可能改变代码的操作

【分析任务】
请对项目进行全面的结构分析：

1. **技术栈识别**
   - 编程语言和版本
   - 框架和库
   - 构建工具和包管理器

2. **目录结构分析**
   - 源代码目录布局
   - 配置文件位置
   - 测试代码位置
   - 静态资源位置

3. **模块依赖分析**
   - 核心模块识别
   - 模块间依赖关系
   - 外部服务依赖

4. **关键路径识别**
   - 应用入口点
   - 核心业务流程
   - 数据流向

5. **第三方依赖**
   - 依赖清单
   - 版本信息
   - 已知漏洞依赖（如有）

【输出格式】
以结构化的方式整理分析结果，供后续审核任务使用。不需要生成文件。
```

指派代理：Claude Code (Plan 模式) 约束：只读模式

阶段 2.1：Bug 检测

任务：深度 Bug 检测分析

markdown

## 任务描述
对代码进行深度 Bug 检测，识别逻辑错误、边界问题、异常处理缺陷等。

## 🔒 严格约束（必须遵守）
- ⛔ **绝对禁止**修改任何源代码文件
- ⛔ **绝对禁止**尝试"修复"你发现的任何问题
- ✅ 只读取和分析代码
- ✅ 将发现的问题记录下来，传递给验证阶段

## Bug 检测清单
- [ ] 空指针/未定义引用
- [ ] 数组越界访问
- [ ] 整数溢出
- [ ] 资源泄漏（内存、文件句柄、连接）
- [ ] 竞态条件
- [ ] 死锁风险
- [ ] 异常处理缺陷
- [ ] 逻辑错误
- [ ] 边界条件处理
- [ ] 类型转换错误

## 提示词

```
你是一个资深的 Bug 猎人和代码质量专家。你的任务是对代码进行深度 Bug 检测。

【绝对约束 - 违反将导致任务失败】
1. 你只能读取代码进行分析，绝对不能修改任何文件
2. 你不能尝试"修复"任何发现的问题
3. 你不能执行任何写入操作
4. 发现问题后，只记录不修改

【检测范围】
请对代码进行以下类型的 Bug 检测：

## 1. 内存和资源问题
- 空指针解引用风险
- 未初始化变量使用
- 内存泄漏
- 资源未释放（文件句柄、数据库连接、网络连接）
- 双重释放

## 2. 逻辑错误
- 条件判断错误（off-by-one、边界条件）
- 循环终止条件错误
- 短路求值误用
- 逻辑运算符混淆（&& vs &, || vs |）
- 比较运算错误（== vs ===, = vs ==）

## 3. 并发问题
- 竞态条件
- 死锁风险
- 数据竞争
- 原子性违反
- 线程安全问题

## 4. 异常处理
- 未捕获的异常
- 空的 catch 块
- 异常吞没
- 错误的异常类型捕获
- 资源清理缺失（finally/defer）

## 5. 数据处理
- 类型转换错误
- 精度丢失
- 编码问题
- 数据截断
- 溢出风险

## 6. API 使用
- 废弃 API 使用
- API 误用
- 返回值未检查
- 参数校验缺失

【输出要求】
对于每个发现的问题，请记录：
1. 问题位置（文件路径:行号）
2. 问题类型（从上述分类中选择）
3. 严重程度（Critical/High/Medium/Low）
4. 问题描述（清晰描述问题是什么）
5. 触发条件（在什么情况下会触发此 Bug）
6. 潜在影响（此 Bug 可能造成什么后果）

【注意】
- 只记录高置信度的问题，避免过多误报
- 优先关注 Critical 和 High 级别问题
- 记录足够的上下文信息以便后续验证
```

指派代理：Claude Code (Plan 模式) 约束：只读模式

阶段 2.2：安全漏洞扫描

任务：安全漏洞深度扫描

markdown

## 任务描述
对代码进行安全漏洞扫描，识别 OWASP Top 10 及其他常见安全问题。

## 🔒 严格约束（必须遵守）
- ⛔ **绝对禁止**修改任何源代码文件
- ⛔ **绝对禁止**尝试"修复"安全漏洞
- ✅ 只读取和分析代码
- ✅ 将发现的漏洞记录下来，传递给验证阶段

## 安全检测清单（OWASP Top 10 + 其他）
- [ ] A01: 访问控制失效
- [ ] A02: 加密失败
- [ ] A03: 注入攻击（SQL、NoSQL、OS、LDAP）
- [ ] A04: 不安全设计
- [ ] A05: 安全配置错误
- [ ] A06: 易受攻击和过时的组件
- [ ] A07: 身份认证失败
- [ ] A08: 软件和数据完整性失败
- [ ] A09: 安全日志和监控失败
- [ ] A10: 服务端请求伪造 (SSRF)
- [ ] XSS 跨站脚本攻击
- [ ] CSRF 跨站请求伪造
- [ ] 敏感信息泄露
- [ ] 不安全的反序列化
- [ ] 路径遍历

## 提示词

```
你是一个专业的安全审计专家，精通 OWASP Top 10 和各类安全漏洞检测。你的任务是对代码进行全面的安全审计。

【绝对约束 - 违反将导致任务失败】
1. 你只能读取代码进行分析，绝对不能修改任何文件
2. 你不能尝试"修复"任何安全漏洞
3. 你不能执行任何写入操作
4. 发现漏洞后，只记录不修改

【安全审计范围】

## 1. 注入类漏洞 (Injection)
检查以下注入风险：
- **SQL 注入**：字符串拼接 SQL、未使用参数化查询
- **NoSQL 注入**：MongoDB 查询构造、JSON 注入
- **命令注入**：shell 命令执行、exec/system 调用
- **LDAP 注入**：目录服务查询
- **XPath 注入**：XML 查询
- **表达式注入**：模板引擎、EL 表达式

关注点：
- 用户输入直接拼接到查询/命令中
- 缺少输入验证和转义
- 动态代码执行

## 2. 身份认证和会话管理
- 硬编码凭证
- 弱密码策略
- 明文存储密码
- 不安全的会话管理
- 缺少多因素认证
- 会话固定攻击风险
- JWT 实现缺陷

## 3. 敏感数据暴露
- 敏感信息明文传输
- 敏感信息明文存储
- 日志中记录敏感信息
- 错误信息泄露敏感数据
- API 响应包含过多信息
- 硬编码的 API 密钥/密码

## 4. 访问控制
- 垂直越权（普通用户访问管理功能）
- 水平越权（用户A访问用户B数据）
- 缺少权限检查
- 不安全的直接对象引用 (IDOR)
- 路径遍历

## 5. XSS 跨站脚本
- 反射型 XSS
- 存储型 XSS
- DOM 型 XSS
- 缺少输出编码
- 不安全的 innerHTML 使用

## 6. 不安全的配置
- 调试模式在生产环境启用
- 默认凭证未修改
- 不必要的服务/端口暴露
- 错误的 CORS 配置
- 缺少安全 HTTP 头

## 7. 加密问题
- 使用弱加密算法（MD5、SHA1、DES）
- 不安全的随机数生成
- 密钥管理不当
- 缺少 HTTPS
- 证书验证禁用

## 8. 其他安全问题
- 不安全的反序列化
- SSRF 服务端请求伪造
- XXE XML 外部实体注入
- 文件上传漏洞
- 开放重定向

【输出要求】
对于每个发现的漏洞，请记录：
1. 漏洞位置（文件路径:行号）
2. 漏洞类型（OWASP 分类或其他）
3. 严重程度（Critical/High/Medium/Low）
4. CVSS 评分估算（如适用）
5. 漏洞描述（清晰描述漏洞是什么）
6. 攻击向量（攻击者如何利用此漏洞）
7. 潜在影响（成功利用后的后果）
8. 相关 CWE 编号（如 CWE-89 SQL注入）

【注意】
- 优先关注 Critical 和 High 级别漏洞
- 提供足够的上下文以便验证
- 避免误报，只记录高置信度的发现
```

指派代理：Gemini CLI (Plan 模式) 约束：只读模式

阶段 2.3：性能问题分析

任务：性能问题深度分析

markdown

## 任务描述
对代码进行性能问题分析，识别算法复杂度问题、资源使用效率问题等。

## 🔒 严格约束（必须遵守）
- ⛔ **绝对禁止**修改任何源代码文件
- ⛔ **绝对禁止**尝试"优化"代码
- ✅ 只读取和分析代码
- ✅ 将发现的问题记录下来，传递给验证阶段

## 性能检测清单
- [ ] 算法复杂度问题（O(n²) 或更高）
- [ ] N+1 查询问题
- [ ] 不必要的循环/递归
- [ ] 内存使用效率
- [ ] 缓存缺失或无效
- [ ] 同步阻塞操作
- [ ] 资源池配置不当
- [ ] 大对象频繁创建
- [ ] 字符串拼接效率
- [ ] 正则表达式性能

## 提示词

```
你是一个性能优化专家，精通各种编程语言的性能分析和优化。你的任务是对代码进行全面的性能审计。

【绝对约束 - 违反将导致任务失败】
1. 你只能读取代码进行分析，绝对不能修改任何文件
2. 你不能尝试"优化"任何代码
3. 你不能执行任何写入操作
4. 发现问题后，只记录不修改

【性能审计范围】

## 1. 算法复杂度问题
- 嵌套循环导致的 O(n²) 或更高复杂度
- 不必要的重复计算
- 可以用哈希表优化的线性查找
- 递归没有记忆化
- 排序算法选择不当

检查模式：
```
# O(n²) 模式
for item1 in list1:
    for item2 in list2:  # 可能需要优化
        if item1 == item2:
            ...
```

## 2. 数据库性能
- N+1 查询问题
- 缺少索引的查询
- 全表扫描
- 过度查询（SELECT *）
- 缺少分页
- 未使用连接池
- 事务范围过大

## 3. I/O 性能
- 同步阻塞 I/O 在关键路径
- 频繁的小文件读写
- 缺少缓冲
- 未使用流式处理大文件
- 网络请求未并发

## 4. 内存使用
- 大对象频繁创建销毁
- 内存泄漏风险
- 缓存无界增长
- 字符串拼接在循环中（应用 StringBuilder/Buffer）
- 不必要的数据复制

## 5. 并发性能
- 锁粒度过大
- 锁竞争严重
- 线程/协程创建过多
- 线程池配置不当
- 异步操作未正确使用

## 6. 缓存问题
- 可缓存的重复计算
- 缓存命中率低
- 缓存过期策略不当
- 缓存穿透/雪崩风险
- 本地缓存 vs 分布式缓存选择不当

## 7. 序列化/反序列化
- 频繁的 JSON 解析
- 大对象序列化
- 不必要的深拷贝
- 反射使用过度

## 8. 资源管理
- 连接池大小不合理
- 连接未正确关闭
- 线程池配置不当
- 资源泄漏

【输出要求】
对于每个发现的问题，请记录：
1. 问题位置（文件路径:行号）
2. 问题类型（从上述分类中选择）
3. 严重程度（Critical/High/Medium/Low）
4. 性能影响估算（如：O(n) -> O(n²)、响应时间增加 X%）
5. 问题描述（清晰描述问题是什么）
6. 触发场景（在什么数据量/并发下会出现问题）
7. 潜在影响（对系统性能的具体影响）

【注意】
- 关注实际会影响性能的问题，避免过度优化建议
- 优先关注热点路径上的性能问题
- 提供足够的上下文以便验证
```

指派代理：Codex CLI (Plan 模式) 约束：只读模式

阶段 3：二次确认验证

任务：交叉验证所有发现

markdown

## 任务描述
对前面阶段发现的所有问题进行二次验证，确认真实性，过滤误报。

## 🔒 严格约束（必须遵守）
- ⛔ **绝对禁止**修改任何源代码文件
- ✅ 只读取和分析代码
- ✅ 对每个发现进行独立验证

## 提示词

```
你是一个资深的代码审核验证专家。你的任务是对其他审核员发现的问题进行独立的二次验证。

【绝对约束 - 违反将导致任务失败】
1. 你只能读取代码进行验证，绝对不能修改任何文件
2. 你必须独立验证每个问题，不能假设前面的发现都是正确的
3. 你不能执行任何写入操作

【验证任务】
你将收到以下类型的问题报告：
1. Bug 检测报告
2. 安全漏洞报告
3. 性能问题报告

对于每个报告的问题，请执行以下验证步骤：

## 验证流程

### 步骤 1：定位验证
- 确认问题所在的文件和行号是否正确
- 确认代码是否确实存在于该位置

### 步骤 2：问题存在性验证
- 独立分析该代码段
- 确认问题是否真实存在
- 检查是否有被忽略的上下文（如：已有的防护措施）

### 步骤 3：严重程度验证
- 评估问题的实际影响
- 确认严重程度评级是否合理
- 如有必要，调整严重程度

### 步骤 4：可利用性验证（针对安全问题）
- 分析攻击路径是否真实可行
- 检查是否有其他防护层
- 评估实际风险

### 步骤 5：影响范围验证
- 确认影响范围是否准确
- 检查是否有遗漏的影响点

## 验证结果分类

对于每个问题，给出以下验证结论之一：

1. **✅ 确认 (Confirmed)**
   - 问题真实存在
   - 严重程度评估准确
   - 无需修改原报告

2. **⚠️ 部分确认 (Partially Confirmed)**
   - 问题存在但需要调整
   - 说明需要调整的内容（如严重程度、影响范围）

3. **❌ 误报 (False Positive)**
   - 问题不存在或已有防护
   - 详细说明为什么是误报

4. **🔍 需要更多信息 (Need More Info)**
   - 无法确定问题是否存在
   - 说明需要什么额外信息

## 输出格式

对于每个验证的问题：

```
### 问题 ID: [原报告中的问题编号]
- 原始位置: [文件:行号]
- 原始类型: [Bug/Security/Performance]
- 原始严重程度: [Critical/High/Medium/Low]

**验证结论**: [✅ 确认 / ⚠️ 部分确认 / ❌ 误报 / 🔍 需要更多信息]

**验证说明**:
[详细说明验证过程和结论依据]

**调整建议**（如适用）:
[如需调整严重程度或描述，在此说明]
```

【注意】
- 保持客观，不要因为想减少问题数量而轻易判定为误报
- 也不要因为想显得严格而确认不存在的问题
- 如有疑问，倾向于保留问题并标注需要更多验证
```

指派代理：Claude Code (Plan 模式) 约束：只读模式

阶段 4：生成最终报告

任务：生成中文 Markdown 审核报告

markdown

## 任务描述
基于所有验证后的发现，生成完整的中文 Markdown 格式审核报告，包含问题描述和完整解决方案。

## 🔒 约束条件
- ⛔ **绝对禁止**修改任何源代码文件
- ✅ 只能在 `.code_review/` 目录下创建报告文件
- ✅ 报告必须使用中文
- ✅ 报告必须使用 Markdown 格式
- ✅ 每个问题必须提供完整的解决方案

## 报告文件结构
```
.code_review/
└── YYYY-MM-DD_HHMMSS/
    ├── 00_审核摘要.md
    ├── 01_Bug分析报告.md
    ├── 02_安全漏洞报告.md
    ├── 03_性能问题报告.md
    ├── 04_二次验证报告.md
    └── 05_最终审核报告.md
```

## 提示词

```
你是一个专业的技术文档撰写专家。你的任务是将所有经过验证的审核发现整理成完整、专业的中文 Markdown 格式报告。

【绝对约束 - 违反将导致任务失败】
1. 绝对不能修改任何源代码文件
2. 只能在 .code_review/ 目录下创建文件
3. 报告必须使用中文
4. 每个问题必须提供完整、可执行的解决方案

【创建报告目录】
首先，创建以当前日期时间命名的目录：
.code_review/YYYY-MM-DD_HHMMSS/

【报告模板】

## 00_审核摘要.md

```markdown
# 代码审核摘要报告

## 基本信息

| 项目 | 信息 |
|------|------|
| 项目名称 | [项目名] |
| 审核时间 | YYYY-MM-DD HH:MM:SS |
| 审核范围 | [涵盖的目录/模块] |
| 代码行数 | [总代码行数] |
| 审核工具 | Vibe Kanban 多代理协作审核 |

## 审核结果概览

| 问题类型 | Critical | High | Medium | Low | 总计 |
|----------|----------|------|--------|-----|------|
| Bug | X | X | X | X | X |
| 安全漏洞 | X | X | X | X | X |
| 性能问题 | X | X | X | X | X |
| **总计** | **X** | **X** | **X** | **X** | **X** |

## 风险评估

### 整体风险等级: [高/中/低]

[简要说明整体风险评估依据]

## 优先处理建议

按优先级排序的待处理问题：

1. 🔴 **[Critical]** [问题简述] - [文件位置]
2. 🔴 **[Critical]** [问题简述] - [文件位置]
3. 🟠 **[High]** [问题简述] - [文件位置]
...

## 审核团队

| 审核阶段 | 负责代理 | 状态 |
|----------|----------|------|
| 代码结构分析 | Claude Code | ✅ 完成 |
| Bug 检测 | Claude Code | ✅ 完成 |
| 安全漏洞扫描 | Gemini CLI | ✅ 完成 |
| 性能问题分析 | Codex CLI | ✅ 完成 |
| 二次验证 | Claude Code | ✅ 完成 |
| 报告生成 | Claude Code | ✅ 完成 |
```

## 01_Bug分析报告.md / 02_安全漏洞报告.md / 03_性能问题报告.md

每个问题报告使用以下模板：

```markdown
# [类型]分析报告

## 概述

- **发现问题总数**: X 个
- **Critical**: X 个
- **High**: X 个
- **Medium**: X 个
- **Low**: X 个

---

## 问题详情

### 问题 #1: [问题标题]

#### 基本信息

| 属性 | 值 |
|------|-----|
| 严重程度 | 🔴 Critical / 🟠 High / 🟡 Medium / 🟢 Low |
| 问题类型 | [具体类型] |
| 文件位置 | `path/to/file.ts:123` |
| 发现阶段 | [Bug检测/安全扫描/性能分析] |
| 验证状态 | ✅ 已确认 |

#### 问题描述

[详细描述问题是什么，用通俗易懂的中文解释]

#### 问题代码

```[language]
// 文件: path/to/file.ts
// 行号: 120-130

[展示有问题的代码片段]
```

#### 触发条件

[描述在什么情况下会触发这个问题]

#### 潜在影响

[描述这个问题可能造成的后果]

#### ✅ 解决方案

**方案概述**: [一句话概述解决思路]

**修复步骤**:

1. [步骤1]
2. [步骤2]
3. [步骤3]

**修复后代码**:

```[language]
// 文件: path/to/file.ts
// 修改行号: 120-130

[展示修复后的完整代码]
```

**验证方法**:

[描述如何验证修复是否成功]

---

### 问题 #2: [问题标题]
...
```

## 04_二次验证报告.md

```markdown
# 二次验证报告

## 验证概述

| 指标 | 数量 |
|------|------|
| 总审核问题数 | X |
| ✅ 确认 | X |
| ⚠️ 部分确认 | X |
| ❌ 误报 | X |
| 🔍 待定 | X |
| **有效问题数** | **X** |

## 验证详情

[列出每个问题的验证结果]
```

## 05_最终审核报告.md

```markdown
# 最终代码审核报告

[整合所有报告的完整版本，包含：]
1. 执行摘要
2. 所有确认的问题（按严重程度排序）
3. 每个问题的完整解决方案
4. 修复优先级建议
5. 预估修复工作量
6. 后续建议
```

【解决方案要求】
每个问题的解决方案必须包含：

1. **明确的修复步骤** - 具体到每一步操作
2. **完整的修复代码** - 可以直接复制使用的代码
3. **代码解释** - 解释为什么这样修复
4. **验证方法** - 如何确认修复成功
5. **注意事项** - 修复时需要注意的点

【输出要求】
1. 创建 .code_review/YYYY-MM-DD_HHMMSS/ 目录
2. 生成所有 6 个报告文件
3. 更新 .code_review/latest 软链接指向最新报告目录
4. 所有报告使用中文
5. 所有报告使用 Markdown 格式
```

指派代理：Claude Code (Build 模式) 约束：只能写入 .code_review/ 目录

完整工作流配置文件

yaml

# vibe-kanban-code-review.yaml
name: "Multi-Agent Code Review"
description: "多代理协作代码审核工作流"

# 全局约束配置 - 绝对禁止修改源代码
constraints:
  protected_paths:
    - "**/*.ts"
    - "**/*.js"
    - "**/*.tsx"
    - "**/*.jsx"
    - "**/*.py"
    - "**/*.go"
    - "**/*.java"
    - "**/*.cpp"
    - "**/*.c"
    - "**/*.h"
    - "**/*.rs"
    - "**/*.vue"
    - "**/*.rb"
    - "**/*.php"
    - "**/*.swift"
    - "**/*.kt"
    - "src/**/*"
    - "lib/**/*"
    - "app/**/*"
    - "include/**/*"
  writable_paths:
    - ".code_review/**/*"
  on_violation: "block_and_abort"
  violation_message: "⛔ 代码审核模式严禁修改源代码！任务已终止。"

# 报告配置
report:
  output_dir: ".code_review"
  format: "markdown"
  language: "zh-CN"
  timestamp_format: "YYYY-MM-DD_HHMMSS"
  create_latest_link: true

stages:
  - name: structure-analysis
    description: "代码结构分析"
    agent: claude-code
    mode: plan
    timeout: 15m
    constraints:
      read_only: true

  - name: parallel-review
    description: "并行代码审核"
    parallel: true
    depends_on: [structure-analysis]
    tasks:
      - name: bug-detection
        description: "Bug 检测"
        agent: claude-code
        mode: plan
        timeout: 30m
        constraints:
          read_only: true

      - name: security-scan
        description: "安全漏洞扫描"
        agent: gemini-cli
        mode: plan
        timeout: 30m
        constraints:
          read_only: true

      - name: performance-analysis
        description: "性能问题分析"
        agent: codex-cli
        mode: plan
        timeout: 25m
        constraints:
          read_only: true

  - name: verification
    description: "二次验证"
    agent: claude-code
    mode: plan
    depends_on: [parallel-review]
    timeout: 20m
    constraints:
      read_only: true

  - name: report-generation
    description: "生成审核报告"
    agent: claude-code
    mode: build
    depends_on: [verification]
    timeout: 30m
    constraints:
      writable_paths: [".code_review/**/*"]
    outputs:
      - ".code_review/${timestamp}/00_审核摘要.md"
      - ".code_review/${timestamp}/01_Bug分析报告.md"
      - ".code_review/${timestamp}/02_安全漏洞报告.md"
      - ".code_review/${timestamp}/03_性能问题报告.md"
      - ".code_review/${timestamp}/04_二次验证报告.md"
      - ".code_review/${timestamp}/05_最终审核报告.md"

success_criteria:
  source_code_unchanged: true
  reports_generated: true
  all_issues_have_solutions: true

最佳实践

1. 代码保护策略（最重要）

yaml

# 四层防护机制
protection:
  # 层级 1：MCP 文件系统权限
  mcp_permissions:
    deny_write: ["**/*.ts", "**/*.js", "**/*.py", "src/**/*"]
    allow_write: [".code_review/**/*"]

  # 层级 2：工作流约束
  workflow_constraints:
    all_stages_read_only: true  # 除报告生成外
    on_violation: "block_and_abort"

  # 层级 3：Git 预检查
  git_hooks:
    pre_commit: |
      # 检查是否有源代码被修改
      if git diff --name-only | grep -vE '^\.code_review/' | grep -qE '\.(ts|js|py|go|java|cpp)$'; then
        echo "❌ 错误：检测到源代码被修改！代码审核不应修改任何源代码。"
        git diff --name-only | grep -vE '^\.code_review/'
        exit 1
      fi

  # 层级 4：审核后验证
  post_review:
    verify_no_changes: true
    command: "git diff --exit-code src/ lib/ app/"

2. 二次验证的重要性

不同代理可能有不同的误报率
交叉验证可以显著提高准确性
确保每个报告的问题都是真实存在的
减少开发者处理误报的时间浪费

3. 解决方案质量标准

每个解决方案必须达到以下标准：

标准	要求
完整性	提供可直接使用的完整代码
可执行性	开发者可以直接复制修复
解释性	说明为什么这样修复
可验证性	提供验证修复成功的方法
无副作用	修复不会引入新问题

4. 报告语言规范

使用准确、专业的中文技术术语
避免中英文混杂（专有名词除外）
代码注释使用中文
问题描述要通俗易懂

预期成果

指标	说明
问题覆盖率	发现 80%+ 的代码问题
误报率	经二次验证后 < 10%
解决方案完整性	100% 问题提供解决方案
源代码完整性	0 文件被修改

审核报告示例输出

.code_review/
└── 2024-01-20_143052/
    ├── 00_审核摘要.md           (2KB)
    ├── 01_Bug分析报告.md        (15KB, 12个问题)
    ├── 02_安全漏洞报告.md       (18KB, 8个问题)
    ├── 03_性能问题报告.md       (10KB, 6个问题)
    ├── 04_二次验证报告.md       (8KB)
    └── 05_最终审核报告.md       (45KB, 完整报告)

下一步

多代理协作编写单元测试 - Node.js 测试示例
C++ Google Test 单元测试 - C++ 测试示例
多代理编排 - 深入了解代理编排配置

使用示例：多代理协作代码审核 ​

场景背景 ​

审核报告结构 ​

工作流设计 ​

整体流程图 ​

代理分工策略 ​

MCP 服务配置 ​

详细任务设计与提示词 ​

阶段 1：代码结构分析 ​

阶段 2.1：Bug 检测 ​

阶段 2.2：安全漏洞扫描 ​

阶段 2.3：性能问题分析 ​

阶段 3：二次确认验证 ​

阶段 4：生成最终报告 ​

完整工作流配置文件 ​

最佳实践 ​

1. 代码保护策略（最重要） ​

2. 二次验证的重要性 ​

3. 解决方案质量标准 ​

4. 报告语言规范 ​

预期成果 ​

审核报告示例输出 ​

下一步 ​

使用示例：多代理协作代码审核

场景背景

审核报告结构

工作流设计

整体流程图

代理分工策略

MCP 服务配置

详细任务设计与提示词

阶段 1：代码结构分析

阶段 2.1：Bug 检测

阶段 2.2：安全漏洞扫描

阶段 2.3：性能问题分析

阶段 3：二次确认验证

阶段 4：生成最终报告

完整工作流配置文件

最佳实践

1. 代码保护策略（最重要）

2. 二次验证的重要性

3. 解决方案质量标准

4. 报告语言规范

预期成果

审核报告示例输出

下一步