Vibe — 多智能体产品迭代框架

面向通用 AI 编程环境的多智能体协作框架，通过角色分工自动驱动产品迭代流程（规划 → 设计 → 开发 → 测试 → 验收），在关键决策点保留人类审批。

架构概览

                    ┌─────────────────┐
                    │     人类决策    │
                    └────────▲────────┘
                             │
              ┌──────────────┴──────────────┐
              │                             │
              │      ┌────────▼────────┐    │
              │      │   Supervisor    │    │
              │      │  (Skill 调度)   │    │
              │      └────────┬────────┘    │
              │               │             │
    ┌─────────┴───────────────┴─────────────┴──────────┐
    │               核心执行 Agent 层                  │
    ├──────────────────────────────────────────────────┤
    │  产品线          │  技术线          │  测试线    │
    │  ┌────────────┐  │  ┌────────────┐  │ ┌────────┐ │
    │  │ 产品经理   │  │  │ 技术骨干   │  │ │测试专员│ │
    │  └────────────┘  │  └──────┬─────┘  │ └────────┘ │
    │                  │         ▼        │            │
    │                  │  ┌────────────┐  │            │
    │                  │  │ 开发专员   │  │            │
    │                  │  └────────────┘  │            │
    ├──────────────────────────────────────────────────┤
    │          按需调用（完整模式 / 升级时）           │
    │  ┌──────────┐  ┌──────────┐  ┌──────────┐        │
    │  │ 产品总监 │  │ 技术总监 │  │ 测试总监 │        │
    │  └──────────┘  └──────────┘  └──────────┘        │
    └──────────────────────────────────────────────────┘

核心特性

• 角色分工 — 7 个专业 Agent（产品总监、产品经理、技术总监、技术骨干、开发专员、测试总监、测试专员），职责明确、边界清晰
• 多种迭代模式 — 完整 / 快速 / 修复 / 探索，按需求规模选择最优流程
• 文档驱动协作 — 所有角色通过 .vibe/docs/ 下的文档进行协作，全程可追溯
• 人类在环 — 关键节点（PRD 审批、架构决策、发布评估）自动暂停，等待人类决策
• 质量铁律 — 证据优先、根因优先、3 次失败升级、禁止 Workaround
• 自动调度 — Supervisor 根据 Agent 返回的结构化 JSON 自动推进流程

迭代模式

流程图示（Mermaid）

完整模式流程（规划→设计→开发→测试→验收）

flowchart LR
    A[规划] --> B[设计]
    B --> C[开发]
    C --> D[测试]
    D --> E{通过率≥95%\n且无P0 Bug?}
    E -->|是| F[验收]
    E -->|否| C
    F --> G{人类确认?}
    G -->|是| H[迭代完成]
    G -->|否| B

快速模式流程（设计→开发→测试）

flowchart LR
    A[需求确认] --> B[快速设计]
    B --> C[开发实现]
    C --> D[测试验证]
    D --> E{通过?}
    E -->|是| F[完成]
    E -->|否| C

修复模式流程（分析→修复→验证）

flowchart LR
    A[问题输入] --> B[技术骨干根因分析]
    B --> C[开发专员修复]
    C --> D[测试专员验证]
    D --> E{验证通过?}
    E -->|是| F[修复完成]
    E -->|否| G[进入 supervisor-fix 循环]
    G --> B

探索模式流程（调研→验证→总结）

flowchart LR
    A[技术调研] --> B[形成调研文档]
    B --> C{需要PoC验证?}
    C -->|是| D[开发专员实现PoC]
    D --> E[结果验证]
    C -->|否| F[汇总结论]
    E --> F
    F --> G[输出调研总结]
    G --> H[人类决策下一步]

测试-修复闭环（supervisor-fix）

flowchart LR
    A[静态检测] --> B[动态测试]
    B --> C[四重验证\nIssues/Output/Dataflow/Workaround]
    C --> D{四项全部通过?}
    D -->|是| E[通过并结束]
    D -->|否| F[技术骨干根因分析]
    F --> G[开发专员修复]
    G --> A

关键协作时序图（完整模式）

sequenceDiagram
    participant U as 人类
    participant S as Supervisor
    participant PD as 产品总监
    participant PM as 产品经理
    participant TD as 技术总监
    participant TL as 技术骨干
    participant DEV as 开发专员
    participant TEST as 测试专员
    participant QD as 测试总监

    U->>S: 下达迭代目标
    S->>PD: 制定产品规划
    PD-->>S: 产品规划
    S->>U: 请求规划确认
    U-->>S: 确认

    S->>PM: 编写PRD
    PM-->>S: PRD
    S->>PD: PRD审批
    PD-->>S: 审批结果

    S->>TD: 设计技术方案
    TD-->>S: 技术方案
    S->>TL: 输出详细设计
    TL-->>S: 详细设计
    S->>U: 请求设计确认
    U-->>S: 确认

    S->>QD: 制定测试计划
    QD-->>S: 测试计划
    S->>DEV: 开发实现
    DEV-->>S: 代码提交
    S->>TL: 两阶段代码审查
    TL-->>S: 审查结果

    S->>TEST: 执行测试
    TEST-->>S: 测试报告
    S->>QD: 质量评估
    QD-->>S: 质量报告

    S->>PM: 发起产品验收
    PM-->>S: 验收报告
    S->>U: 提交验收结果

项目结构

vibe/
├── agents/                     # Agent 定义（YAML frontmatter + 角色提示词）
│   ├── 产品总监.md
│   ├── 产品经理.md
│   ├── 技术总监.md
│   ├── 技术骨干.md
│   ├── 开发专员.md
│   ├── 测试总监.md
│   └── 测试专员.md
│
├── skills/                     # Skill 定义（可复用能力模块）
│   ├── supervisor/             # 主调度逻辑
│   ├── supervisor-fix/         # 测试-修复循环
│   ├── developer/              # 开发工作流
│   ├── tester/                 # 测试工作流
│   ├── product-manager/        # 产品管理
│   ├── product-director/       # 产品战略
│   ├── tech-director/          # 架构决策
│   ├── tech-lead/              # 技术分析
│   ├── test-director/          # 测试策略
│   ├── command-executor/       # 命令执行防阻塞
│   ├── shared/                 # 共享原则
│   └── templates/              # 文档模板

快速开始

前置要求

• 已配置支持 Agent / Skill 调度的 AI 编程环境
• 具备可访问项目工作区的终端能力（用于执行构建、测试、验证命令）

使用方式

方式：Skill 调度

1. 在 .vibe/docs/迭代计划.md 中写明迭代目标和任务
2. 在你的 AI 编程环境中调用 Supervisor Skill 启动调度
3. Supervisor 自动按流程调用各角色 Agent 执行任务
4. 在人类决策点进行审批或调整

角色说明

文档产出清单（基于 skills）

以下为流程中可能产生的文档（按角色分为：总体 / 产品 / 开发 / 测试）：

总体

产品

开发

测试

说明：skills/templates/通用模板.md 提供了「版本化报告」「复盘报告」「计划/任务列表」三类通用结构；上述文档可按角色必填字段进行裁剪。

核心原则

流程铁律

1. 证据优先于声明 — 任何完成声明必须有新鲜的验证证据，禁止"已完成"“应该没问题”
2. 根因优先于修复 — 未找到根因前不得提出修复方案，禁止猜测修复
3. 3 次失败质疑架构 — 同一问题修复 3 次仍失败 → 立即停止 → 升级上报
4. 禁止 Workaround — 不创建空文件、不注释测试、不硬编码绕过

编码原则（基于 Andrej Karpathy 观察）

来源：andrej-karpathy-skills

5. 先思考再编码 — 显式声明假设，不隐藏困惑；存在歧义时呈现多种解释
6. 简洁优先 — 最小代码解决问题，拒绝过度工程；如果 200 行可以变成 50 行，就重写
7. 手术式修改 — 仅修改必须改动的内容；每一行更改都应直接追溯到用户请求
8. 目标驱动执行 — 先定义成功标准（测试），再循环实现；不要告诉 AI 做什么，给它成功标准

API 设计原则

9. 参数默认即是最优 — 默认值即推荐用法，零配置即可用对
10. 接口命名意图驱动 — 命名表达做什么、解决什么问题，不暴露实现细节
11. 大声报错，且自带解药 — 错误明确可定位，并附带可执行建议或排查指引

升级路径

开发专员 → 技术骨干 → 技术总监 → 人类
测试专员 → 测试总监 → 人类
产品经理 → 产品总监 → 人类

定制

• 添加角色：在 agents/ 下新建 .md 文件，配置 YAML frontmatter（name / model / tools / agentMode）
• 添加 Skill：在 skills/ 下新建目录，编写 SKILL.md 定义工作流
• 调整流程：修改 skills/supervisor/SKILL.md 中的阶段定义和调度逻辑

License

MIT