# 四级工作流系统

CCW 四级工作流系统提供了一种从规格说明到部署的结构化软件开发方法。

## 概述

```
Level 1: 规格说明 → Level 2: 规划 → Level 3: 实现 → Level 4: 验证
```

## Level 1: 规格说明

**目标**: 定义构建什么以及为什么构建。

### 活动

| 活动 | 描述 | 产出 |
|------|------|------|
| 研究 | 分析需求和上下文 | 发现上下文 |
| 产品简报 | 定义产品愿景 | 产品简报 |
| 需求 | 创建带有验收标准的 PRD | 需求文档 |
| 架构 | 设计系统架构 | 架构文档 |
| 史诗与故事 | 分解为可跟踪的项目 | 史诗和用户故事 |

### 智能体

- **analyst**: 执行研究和分析
- **writer**: 创建规格说明文档
- **discuss-subagent**: 多视角评审

### 质量门禁

**QUALITY-001** 验证:
- 所有需求已文档化
- 架构已批准
- 风险已评估
- 验收标准已定义

### 示例任务

```
RESEARCH-001 → DRAFT-001 → DRAFT-002 → DRAFT-003 → DRAFT-004 → QUALITY-001
```

## Level 2: 规划

**目标**: 定义如何构建。

### 活动

| 活动 | 描述 | 产出 |
|------|------|------|
| 探索 | 多角度代码库分析 | 探索缓存 |
| 任务分解 | 创建实现任务 | 任务定义 |
| 依赖映射 | 识别任务依赖关系 | 依赖图 |
| 资源估算 | 估算工作量和复杂度 | 计划元数据 |

### 智能体

- **planner**: 创建实现计划
- **architect**: 提供技术咨询（按需）
- **explore-subagent**: 代码库探索

### 输出

```json
{
  "epic_count": 5,
  "total_tasks": 27,
  "execution_order": [...],
  "tech_stack": {...}
}
```

## Level 3: 实现

**目标**: 构建解决方案。

### 活动

| 活动 | 描述 | 产出 |
|------|------|------|
| 代码生成 | 编写源代码 | 源文件 |
| 单元测试 | 创建单元测试 | 测试文件 |
| 文档编写 | 记录代码和 API | 文档 |
| 自我验证 | 验证实现质量 | 验证报告 |

### 智能体

- **executor**: 协调实现
- **code-developer**: 简单、直接的编辑
- **ccw cli**: 复杂、多文件变更

### 执行策略

任务根据依赖关系按拓扑顺序执行:

```
TASK-001 (无依赖) → TASK-002 (依赖 001) → TASK-003 (依赖 002)
```

### 后端

| 后端 | 使用场景 |
|------|----------|
| agent | 简单、直接的编辑 |
| codex | 复杂、架构相关 |
| gemini | 分析密集型 |

## Level 4: 验证

**目标**: 确保质量。

### 活动

| 活动 | 描述 | 产出 |
|------|------|------|
| 集成测试 | 验证组件集成 | 测试结果 |
| QA 测试 | 用户验收测试 | QA 报告 |
| 性能测试 | 测量性能 | 性能指标 |
| 安全审查 | 安全漏洞扫描 | 安全发现 |
| 代码审查 | 最终质量检查 | 审查反馈 |

### 智能体

- **tester**: 执行测试-修复循环
- **reviewer**: 四维代码审查

### 审查维度

| 维度 | 关注点 |
|------|--------|
| 产品 | 需求对齐 |
| 技术 | 代码质量、模式 |
| 质量 | 测试、边界情况 |
| 覆盖 | 完整性 |
| 风险 | 安全、性能 |

## 工作流编排

### Beat 模型

事件驱动执行，由协调器编排:

```
Event           Coordinator              Workers
────────────────────────────────────────────────
callback/resume → handleCallback ─────────────────┐
                 → mark completed                 │
                 → check pipeline                │
                 → handleSpawnNext ──────────────┼───→ [Worker A]
                 → find ready tasks              │
                 → spawn workers ─────────────────┼───→ [Worker B]
                 → STOP (idle) ──────────────────┘      │
                                                        │
callback <──────────────────────────────────────────────┘
```

### 检查点

**规格检查点** (QUALITY-001 之后):
- 暂停等待用户确认
- 验证规格说明完整性
- 需要手动恢复才能继续

**最终门禁** (REVIEW-001 之后):
- 最终质量验证
- 所有测试必须通过
- 关键问题已解决

### 快速推进

对于简单的线性继任，工作器可以直接生成后继者:

```
[Worker A] complete
    → Check: 1 ready task? simple successor?
    → YES: Spawn Worker B directly
    → NO: SendMessage to coordinator
```

## 并行执行

某些史诗可以并行执行:

```
EPIC-003: Content Modules ──┐
                           ├──→ EPIC-005: Interaction Features
EPIC-004: Search & Nav ────┘
```

## 错误处理

| 场景 | 解决方案 |
|------|----------|
| 语法错误 | 带错误上下文重试（最多 3 次） |
| 缺少依赖 | 向协调器请求 |
| 后端不可用 | 回退到替代方案 |
| 循环依赖 | 中止，报告依赖图 |

::: info 另见
- [最佳实践](./best-practices.md) - 工作流优化
- [智能体](../agents/) - 智能体专业化
:::