# 第 3 阶段手册 — 构建与迭代

> **时长**：2-12 周（视范围而定）| **智能体**：15-30+ | **守门人**：智能体编排者

---

## 目标

通过持续的开发-测试循环实现所有功能。每个任务都经过验证后才进入下一个。这个阶段是工作量最大的阶段——也是 NEXUS 编排价值发挥最大的地方。

## 前提条件

- [ ] 第 2 阶段质量门禁通过（基础已验证）
- [ ] Sprint 排序师的待办列表（含 RICE 评分）已就绪
- [ ] CI/CD 流水线可用
- [ ] 设计系统和组件库就绪
- [ ] API 骨架 + 认证系统就绪

## 开发-测试循环 — 核心机制

智能体编排者通过这个循环管理每一个任务：

```
对于 sprint_backlog 中的每个任务（按 RICE 分数排序）：

  1. 分配任务给合适的开发智能体（见分配矩阵）
  2. 开发者实现任务
  3. 证据收集者测试任务
     - 视觉截图（桌面、平板、手机）
     - 按验收标准做功能验证
     - 品牌一致性检查
  4. 如果判定 == 通过：
       标记任务完成
       进入下一个任务
     否则如果判定 == 不通过 且 重试次数 < 3：
       把 QA 反馈发给开发者
       开发者修复具体问题
       回到第 3 步
     否则如果 重试次数 >= 3：
       升级给智能体编排者
       编排者决定：重新分配、拆分、推迟或接受
  5. 更新流水线状态报告
```

## 智能体分配矩阵

### 主要开发分配

| 任务类型 | 主要智能体 | 备选智能体 | QA 智能体 |
|---------|-----------|-----------|----------|
| **React/Vue/Angular UI** | 前端开发者 | 快速原型师 | 证据收集者 |
| **REST/GraphQL API** | 后端架构师 | 高级开发者 | API 测试员 |
| **数据库操作** | 后端架构师 | — | API 测试员 |
| **移动端（iOS/Android）** | 移动应用开发者 | — | 证据收集者 |
| **ML 模型/管道** | AI 工程师 | — | 测试结果分析师 |
| **CI/CD/基础设施** | DevOps 自动化师 | 基础设施运维师 | 性能基准师 |
| **高级/复杂功能** | 高级开发者 | 后端架构师 | 证据收集者 |
| **快速原型/POC** | 快速原型师 | 前端开发者 | 证据收集者 |
| **WebXR/沉浸式** | XR 沉浸式开发者 | — | 证据收集者 |
| **visionOS** | visionOS 空间工程师 | macOS 空间/Metal 工程师 | 证据收集者 |
| **座舱控件** | XR 座舱交互专家 | XR 交互架构师 | 证据收集者 |
| **CLI/终端工具** | 终端集成专家 | — | API 测试员 |
| **代码智能** | LSP/索引工程师 | — | 测试结果分析师 |
| **性能优化** | 性能基准师 | 基础设施运维师 | 性能基准师 |

### 专家支持（按需激活）

| 专家 | 什么时候激活 | 触发条件 |
|-----|------------|---------|
| UI 设计师 | 组件需要视觉打磨 | 开发者请求设计指导 |
| 趣味注入师 | 功能需要趣味/个性 | UX 审查发现机会 |
| 视觉叙事师 | 需要视觉叙事内容 | 内容需要视觉素材 |
| 品牌守护者 | 品牌一致性有疑虑 | QA 发现品牌偏差 |
| XR 交互架构师 | 需要空间交互设计 | XR 功能需要 UX 指导 |
| 数据分析师 | 需要深度数据分析 | 功能需要数据分析集成 |

## 并行构建轨道

NEXUS-Full 部署时，四条轨道同时跑：

### 轨道 A：核心产品开发
```
管理者：智能体编排者（开发-测试循环）
智能体：前端开发者、后端架构师、AI 工程师、
        移动应用开发者、高级开发者
QA：证据收集者、API 测试员、测试结果分析师

Sprint 节奏：2 周一个 Sprint
每天：任务实现 + QA 验证
Sprint 结束：Sprint 回顾 + 复盘
```

### 轨道 B：增长与营销准备
```
管理者：项目牧羊人
智能体：增长黑客、内容创作者、社交媒体策略师、
        应用商店优化师

Sprint 节奏：与轨道 A 里程碑对齐
活动内容：
- 增长黑客 → 设计病毒式传播和推荐机制
- 内容创作者 → 准备上线内容管道
- 社交媒体策略师 → 规划跨平台活动
- 应用商店优化师 → 准备商店页面（如果是移动端）
```

### 轨道 C：质量与运营
```
管理者：智能体编排者
智能体：证据收集者、API 测试员、性能基准师、
        工作流优化师、实验追踪员

持续活动：
- 证据收集者 → 每个任务都做截图 QA
- API 测试员 → 每个 API 任务都做端点验证
- 性能基准师 → 定期压力测试
- 工作流优化师 → 发现流程改进机会
- 实验追踪员 → 为已验证的功能搭 A/B 测试
```

### 轨道 D：品牌与体验打磨
```
管理者：品牌守护者
智能体：UI 设计师、品牌守护者、视觉叙事师、
        趣味注入师

触发式活动：
- UI 设计师 → QA 发现视觉问题时做组件打磨
- 品牌守护者 → 定期品牌一致性审计
- 视觉叙事师 → 功能完成后做视觉叙事素材
- 趣味注入师 → 微交互和愉悦感设计
```

## Sprint 执行模板

### Sprint 规划（第 1 天）

```
Sprint 排序师激活：
1. 用更新后的 RICE 分数审查待办列表
2. 按团队速度选择 Sprint 内容
3. 把任务分配给开发智能体
4. 识别依赖和执行顺序
5. 设定 Sprint 目标和成功标准

产出：带任务分配的 Sprint 计划
```

### 每日执行（第 2 天到第 N-1 天）

```
智能体编排者管理：
1. 检查当前任务状态
2. 执行开发-测试循环
3. 识别并解决阻塞
4. 进度追踪和汇报

状态报告格式：
- 今天完成的任务：[列表]
- QA 中的任务：[列表]
- 开发中的任务：[列表]
- 被阻塞的任务：[列表 + 原因]
- QA 通过率：[X/Y]
```

### Sprint 回顾（第 N 天）

```
项目牧羊人主持：
1. 演示已完成的功能
2. 审查每个任务的 QA 证据
3. 收集利益相关方反馈
4. 根据学到的东西更新待办列表

参与者：所有活跃智能体 + 利益相关方
产出：Sprint 回顾总结
```

### Sprint 复盘

```
工作流优化师主持：
1. 哪些做得好？
2. 哪些可以改进？
3. 下个 Sprint 我们改什么？
4. 流程效率指标

产出：复盘行动项
```

## 编排者决策逻辑

### 任务失败处理

```
当任务 QA 不通过时：
  如果 重试次数 == 1：
    → 把具体的 QA 反馈发给开发者
    → 开发者只修被指出的问题
    → 重新提交 QA

  如果 重试次数 == 2：
    → 发送累计 QA 反馈
    → 考虑：这个开发智能体是不是合适的人选？
    → 开发者带着更多上下文修复
    → 重新提交 QA

  如果 重试次数 == 3：
    → 升级
    → 选项：
      a) 重新分配给另一个开发智能体
      b) 拆分成更小的子任务
      c) 换实现思路/架构
      d) 接受当前状态（记录已知限制）
      e) 推迟到后面的 Sprint
    → 记录决策和原因
```

### 并行任务管理

```
当多个任务之间没有依赖时：
  → 同时分配给不同的开发智能体
  → 每个跑独立的开发-测试循环
  → 编排者同时追踪所有循环
  → 按依赖顺序合并已完成的任务

当任务有依赖时：
  → 等依赖任务通过 QA
  → 然后分配依赖任务
  → 交接时带上依赖的上下文
```

## 质量门禁检查清单

| # | 标准 | 证据来源 | 状态 |
|---|------|---------|------|
| 1 | 所有 Sprint 任务通过 QA（100% 完成） | 每个任务的证据收集者截图 | |
| 2 | 所有 API 端点已验证 | API 测试员回归报告 | |
| 3 | 性能基线达标（P95 < 200ms） | 性能基准师报告 | |
| 4 | 品牌一致性已验证（95%+ 合规） | 品牌守护者审计 | |
| 5 | 没有严重 bug（零 P0/P1 开放） | 测试结果分析师摘要 | |
| 6 | 所有验收标准都满足 | 逐任务验证 | |
| 7 | 所有 PR 都做了 Code Review | Git 历史证据 | |

## 门禁决策

**守门人**：智能体编排者

- **通过**：功能完整的应用 → 激活第 4 阶段
- **继续**：还需要更多 Sprint → 继续第 3 阶段
- **升级**：系统性问题 → 工作室制片人介入

## 交接给第 4 阶段

```markdown
## 第 3 阶段 → 第 4 阶段交接包

### 给现实检验者的：
- 完整的应用（所有功能已实现）
- 开发-测试循环中的所有 QA 证据
- API 测试员回归结果
- 性能基准师基线数据
- 品牌守护者一致性审计
- 已知问题列表（如果有接受的限制）

### 给法务合规员的：
- 数据处理实现细节
- 隐私政策实现
- 知情同意管理实现
- 已实施的安全措施

### 给性能基准师的：
- 压力测试用的应用地址
- 预期流量模式
- 架构定义的性能预算

### 给基础设施运维师的：
- 生产环境要求
- 伸缩配置需求
- 监控告警阈值
```

---

*当所有 Sprint 任务通过 QA、所有 API 端点已验证、性能基线达标、没有严重 bug 时，第 3 阶段结束。*