实战：用 Multica 搭建 4 人 AI 智能体流水线，30 分钟完成斗地主游戏开发

从零搭建 Leader → Architect → Developer → Tester 四角色协作流水线，用 AI Agent 自动化完成需求分析、架构设计、编码实现、代码审查、浏览器测试的全流程。

一、背景

Multica 是一个开源的 AI Agent 协作平台，可以将 Claude Code、Cursor、OpenCode、Copilot 等 AI 编程工具接入同一个工作区，组成 Squad（小分队），像管理人类团队一样管理 AI 智能体。

本文将分享一个完整的实践案例：用 Multica 搭建 4 人智能体小队，在 30 分钟内完成一个斗地主单机版纸牌游戏的完整开发流程。

二、架构设计

2.1 核心问题

最初的流水线设计是简单的链式接力：

Leader → Planner → Developer → Tester → Done

但在实践中暴露了三个致命问题：

1. 队员完工不通知：Developer 写完了代码没 @Leader，导致流水线卡住
2. Tester 发现 bug 不知道 @谁：应该 @Developer 修复？还是 @Leader 决策？
3. Leader 沦为传话筒：每次都要 Leader 手动 @下一个人，没有增值

2.2 最终架构：Leader 作为状态路由器

                  ┌─────────────────────────────────┐
                  │      ① Claude Leader (状态机)    │
                  │  收报告 → 判断阶段 → 派发下一个    │
                  │  Tester 说 bug → 精准 @Developer  │
                  │  Developer 修完 → 再派给 Tester   │
                  └──────┬──────────┬──────────────┘
                         │          │
              ┌──────────┘          └──────────┐
              ▼                                ▼
    ② Cursor Architect               ③ OpenCode Developer
    出 DESIGN.md                      写全部代码
              │                                │
              └──────────┬─────────────────────┘
                         ▼
              ④ Copilot Tester
              代码审查 → 浏览器 E2E → 报告 Leader

核心规则只有两条：

• 任何人完成工作 → 统一 @Leader 报告状态（不直接 @下一个人）
• Leader 收到报告 → 判断当前阶段 → 派发正确的人

这样 Tester 发现 bug 时不需要纠结 @谁——统一 @Leader，Leader 负责追踪状态、精准调度。

三、智能体人设配置

3.1 ① Claude Leader — 状态机 + 路由器 + 终审

You are the Team Leader. You are the state machine that drives the pipeline.

## STATE TRACKING
- STAGE_DESIGN → Architect is working
- STAGE_CODE → Developer is working
- STAGE_TEST → Tester is working
- STAGE_DONE → issue closed

## DISPATCH RULES
- Tester reports FAIL → dispatch to Developer with EXACT failure details
- After Developer fixes → dispatch to Tester AGAIN

## VERIFICATION
Before accepting any report:
  cd D:/demo/doudizhu && git log --oneline -5

关键设计：Leader 不写代码、不设计、不测试，只做状态管理和调度。所有队员完工后统一向 Leader 汇报。

3.2 ② Cursor Architect — 架构设计

You are the System Architect.

## COMPLETION REPORT (always use this format)
@Claude Leader
DESIGN.md 已完成并提交到 git，commit: <hash>。
技术栈: <stack>. 分 <N> 个阶段实施。

## RULES
- NEVER write implementation code
- ALWAYS @Claude Leader when done

Cursor CLI 运行，模型设为 auto，让 Cursor 自动选择最优模型。输出物：DESIGN.md。

3.3 ③ OpenCode Developer — 编码实现

You are the Developer.

## COMPLETION REPORT (always use this format)
@Claude Leader
代码完成。全部 <N> 个阶段已实现，最新 commit: <hash>。

## RULES
- NEVER design architecture
- NEVER do testing
- ALWAYS @Claude Leader when done
- If Leader sends you back with bug report → fix ONLY those bugs

模型使用 deepseek/deepseek-chat，性价比高。每完成一个 Phase 就 git commit。

3.4 ④ Copilot Tester — 审查 + 浏览器测试

You are the QA Tester.

## WORKFLOW
1. STEP 1: CODE REVIEW — check every file
   If issues found → STOP and report FAIL
2. STEP 2: BROWSER TESTING (only if review passed)
   Start dev server, open browser, click through as a real user

## REPORT FORMAT
FAIL:
  @Claude Leader
  代码审查未通过 ❌。<N> 个问题。<file:line details>

PASS:
  @Claude Leader
  审查通过 ✅ + 测试通过 ✅。
  单元测试: <N>/<N> passed。建议标记 done。

关键设计：先审查代码，通过后才打开浏览器实测。确保不浪费时间在不合格的代码上。

四、开发过程实录

4.1 创建 Issue，启动流水线

在 Multica 中创建一个 Issue「开发斗地主游戏」，分配给 Claude Leader。

23:08  ─ 我 @Claude Leader 启动开发
23:08  ─ Leader 分析需求 → @Cursor Architect

4.2 架构设计阶段（7 分钟）

23:08  ─ Architect 接手，阅读需求
23:09  ─ 开始写 DESIGN.md
23:15  ─ DESIGN.md 完成，commit: f85bc1d

DESIGN点md 包含：技术栈选型（Vite + React 18 + TypeScript + Zustand）、目录结构、核心类型、12 种牌型检测器设计、AI 策略、8 个 Phase 的分阶段实施计划。

4.3 编码实现阶段（10 分钟）

Leader 审阅 DESIGNd点md 后，派发给 OpenCode Developer：

23:19  ─ Leader 审阅通过 → @Developer：「按 DESIGN.md 实施 8 个 Phase」
23:19  ─ Developer 接到任务，读 DESIGN.md
23:20  ─ Phase 1: Vite 脚手架 + 核心类型定义
23:22  ─ Phase 2: 12 种牌型检测器 + 42 条单测
23:24  ─ Phase 3: 游戏状态机 + 13 条集成测试
23:26  ─ Phase 4: AI 对手（手牌评估、叫分、出牌策略）
23:28  ─ Phase 5-6: React UI 组件（牌桌、卡牌、操作栏）
23:29  ─ Phase 7-8: 积分系统 + 构建验证 + README
23:29  ─ 全部 8 个 Phase 完成，6 个 commit

4.4 测试验收阶段（5 分钟）

23:31  ─ Leader 审阅 git log → @Tester
23:31  ─ Tester 开始代码审查（逐文件对照 DESIGN.md）
23:33  ─ 审查通过，启动浏览器测试
23:35  ─ 浏览器 E2E：发牌 → 叫分 → 出牌 → 结算 → 积分记录
23:36  ─ 76/76 单元测试全部通过

4.5 最终交付

23:38  ─ Leader 终审：全部 76 条测试通过，TypeScript 编译零错误
23:38  ─ 标记 done ✅

总计 30 分钟，完成一个包含完整牌型系统、AI 决策、React UI、积分记录的斗地主游戏。

五、交付物

D:/demo/doudizhu/
├── src/core/           # 核心逻辑（类型、洗牌、牌型检测、状态机）
├── src/ai/             # AI 对手（手牌评估、叫分、出牌策略）
├── src/store/          # Zustand 状态管理
├── src/components/     # React 组件（牌桌、卡牌、操作栏、积分板）
├── tests/              # 76 条单元 + 集成测试
├── DESIGN.md           # 完整技术方案
└── README.md           # 游玩指南

技术栈：Vite 5 + React 18 + TypeScript 5 + Zustand + CSS Modules

六、关键经验总结

6.1 三个「绝对规则」

6.2 坑和解决方案

6.3 配置持久化

所有 4 个智能体的完整配置（名称、模型、指令、运行时、Autopilot）已保存到：

https://gitcode.com/deli007/multica-admin

在任意新电脑上，只需克隆这个仓库，按照 agents.json 在 Multica 中创建对应的 Agent 和 Squad 即可复现整个流水线。

七、下一步

这套 4 人流水线不局限于游戏开发。任何软件开发项目——Web 应用、后端 API、数据分析、文档写作——都可以复用同样的架构：

1. 创建 Issue → 分配给 Leader
2. Leader 调 Architect 出方案
3. Leader 调 Developer 写代码
4. Leader 调 Tester 审查 + 测试
5. Leader 终审 → Done

只需在 Leader 的指令中修改项目路径和验收标准即可。

工具与资源

• Multica: https://github.com/multica-ai/multica
• Agent 配置模板: https://gitcode.com/deli007/multica-admin
• 本案例项目: D:/demo/doudizhu/