catlog22/Claude-Code-Workflow
1
0
Fork 0
mirror of https://github.com/catlog22/Claude-Code-Workflow.git synced 2026-03-01 15:03:57 +08:00
Code Issues Packages Projects Releases Wiki Activity

docs: add VitePress documentation site

Browse Source 
- Add docs directory with VitePress configuration
- Add GitHub Actions workflow for docs build and deploy
- Support bilingual (English/Chinese) documentation
- Include search, custom theme, and responsive design
This commit is contained in:
catlog22
2026-02-28 16:14:09 +08:00
parent ab65caec45
commit c3ddf7e322
136 changed files with 34486 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

204
docs/zh/workflows/4-level.md Normal file
View File

@@ -0,0 +1,204 @@
# 四级工作流系统
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/) - 智能体专业化
:::

167
docs/zh/workflows/best-practices.md Normal file
View File

@@ -0,0 +1,167 @@
# 工作流最佳实践
优化您的 CCW 工作流以获得最高效率和质量。
## 规格说明阶段
### 应该做的
- **从明确的目标开始**: 提前定义成功标准
- **让利益相关者参与**: 从所有利益相关者收集需求
- **记录假设**: 将隐性知识显式化
- **及早识别风险**: 评估技术和项目风险
### 不应该做的
- 跳过研究阶段
- 未经验证就假设需求
- 忽略技术约束
- 过度设计解决方案
## 规划阶段
### 应该做的
- **分解任务**: 细粒度的任务更容易估算
- **映射依赖**: 及早识别任务关系
- **现实估算**: 使用历史数据进行估算
- **规划迭代**: 为未知因素预留缓冲
### 不应该做的
- 创建单体任务
- 忽略任务依赖
- 低估复杂度
- 提前规划所有内容
## 实现阶段
### 应该做的
- **遵循计划**: 相信规划过程
- **边写边测**: 与代码同步编写测试
- **记录变更**: 保持文档同步
- **频繁验证**: 每次变更后运行测试
### 不应该做的
- 未经讨论偏离计划
- 为了速度跳过测试
- 推迟文档编写
- 忽略反馈
## 验证阶段
### 应该做的
- **全面测试**: 覆盖正常路径和边界情况
- **审查代码**: 使用代码审查指南
- **衡量质量**: 使用自动化指标
- **记录发现**: 创建测试报告
### 不应该做的
- 跳过边界情况测试
- 忽略审查反馈
- 仅依赖手动测试
- 隐藏测试失败
## 团队协调
### 沟通
- **使用 SendMessage**: 始终通过协调器沟通
- **具体明确**: 清晰的消息减少来回沟通
- **报告进度**: 定期更新状态
- **上报阻塞**: 不要等待阻塞问题
### 协作
- **尊重边界**: 每个角色有特定职责
- **信任流程**: 工作流确保质量
- **分享知识**: 贡献智慧文件
- **从失败中学习**: 事后分析改进未来工作流
## 常见陷阱
### 规格说明
| 陷阱 | 影响 | 预防措施 |
|------|------|----------|
| 模糊的需求 | 返工 | 使用验收标准 |
| 缺少约束 | 实现失败 | 明确列出非功能性需求 |
| 范围不清 | 范围蔓延 | 定义范围内/范围外 |
### 规划
| 陷阱 | 影响 | 预防措施 |
|------|------|----------|
| 乐观估算 | 延误 | 使用不确定性锥 |
| 未知依赖 | 任务阻塞 | 先探索代码库 |
| 单线程规划 | 瓶颈 | 识别并行机会 |
### 实现
| 陷阱 | 影响 | 预防措施 |
|------|------|----------|
| 跳过测试 | 生产环境 Bug | 测试优先方法 |
| 忽略反馈 | PR 被拒绝 | 处理审查意见 |
| 镀金 | 交付延迟 | 遵循需求 |
## 工作流优化
### 减少周期时间
1. **批量处理相似任务**: 减少上下文切换
2. **自动化验证**: 持续集成
3. **并行执行**: 识别独立任务
4. **快速推进**: 对简单继任跳过协调器
### 提高质量
1. **早期验证**: 测试优先开发
2. **同行审查**: 多审查者视角
3. **自动化测试**: 全面的测试覆盖
4. **指标跟踪**: 衡量质量指标
### 有效扩展
1. **史诗分解**: 大项目 → 史诗 → 任务
2. **团队专业化**: 基于角色的智能体分配
3. **知识共享**: 智慧积累
4. **流程改进**: 持续改进
## 示例
### 良好的工作流
```
[Specification]
↓ Clear requirements with acceptance criteria
[Planning]
↓ Realistic estimates with identified dependencies
[Implementation]
↓ Tests pass, documentation updated
[Validation]
↓ All acceptance criteria met
[Complete]
```
### 有问题的工作流
```
[Specification]
↓ Vague requirements, no acceptance criteria
[Planning]
↓ Optimistic estimates, missed dependencies
[Implementation]
↓ No tests, incomplete documentation
[Validation]
↓ Failed tests, missing requirements
[Rework]
```
::: info 另见
- [四级系统](./4-level.md) - 详细工作流说明
- [智能体](../agents/) - 智能体能力
:::

183
docs/zh/workflows/index.md Normal file
View File

@@ -0,0 +1,183 @@
# 工作流系统
CCW 的 4 级工作流系统编排从需求到部署代码的整个开发生命周期。
## 工作流级别
```
Level 1: 规范
↓
Level 2: 规划
↓
Level 3: 实现
↓
Level 4: 验证
```
## Level 1: 规范
定义要构建的内容和原因。
**活动:**
- 需求收集
- 用户故事创建
- 验收标准定义
- 风险评估
**输出:**
- 产品简报
- 需求文档 (PRD)
- 架构设计
- Epics 和 Stories
**代理:** analyst, writer
## Level 2: 规划
定义如何构建。
**活动:**
- 技术规划
- 任务分解
- 依赖映射
- 资源估算
**输出:**
- 实现计划
- 任务定义
- 依赖图
- 风险缓解
**代理:** planner, architect
## Level 3: 实现
构建解决方案。
**活动:**
- 代码实现
- 单元测试
- 文档
- 代码审查
**输出:**
- 源代码
- 测试
- 文档
- 构建产物
**代理:** executor, code-developer
## Level 4: 验证
确保质量。
**活动:**
- 集成测试
- QA 测试
- 性能测试
- 安全审查
**输出:**
- 测试报告
- QA 发现
- 审查反馈
- 部署就绪性
**代理:** tester, reviewer
## 完整工作流示例
```bash
# Level 1: 规范
Skill(skill="team-lifecycle-v4", args="构建用户身份验证系统")
# => 创建 RESEARCH-001, DRAFT-001/002/003/004, QUALITY-001
# Level 2: 规划 (QUALITY-001 后自动触发)
# => 创建 PLAN-001 及任务分解
# Level 3: 实现 (PLAN-001 后自动触发)
# => 执行 IMPL-001 及代码生成
# Level 4: 验证 (IMPL-001 后自动触发)
# => 运行 TEST-001 和 REVIEW-001
```
## 工作流可视化
```
┌─────────────────────────────────────────────────────────────┐
│ 工作流编排 │
├─────────────────────────────────────────────────────────────┤
│ │
│ [RESEARCH-001] 产品发现 │
│ ↓ │
│ [DRAFT-001] 产品简报 │
│ ↓ │
│ [DRAFT-002] 需求 (PRD) │
│ ↓ │
│ [DRAFT-003] 架构设计 │
│ ↓ │
│ [DRAFT-004] Epics 和 Stories │
│ ↓ │
│ [QUALITY-001] 规范质量检查 ◄── 检查点 │
│ ↓ ↓ │
│ [PLAN-001] 实现计划 │
│ ↓ │
│ [IMPL-001] 代码实现 │
│ ↓ │
│ [TEST-001] ───┐ │
│ ├──► [REVIEW-001] ◄── 最终关卡 │
│ [REVIEW-001] ─┘ │
│ │
└─────────────────────────────────────────────────────────────┘
```
## 检查点
### 规范检查点 (QUALITY-001 后)
在实现前暂停以供用户确认。
**验证:**
- 所有需求已记录
- 架构已批准
- 风险已评估
- 验收标准已定义
### 最终关卡 (REVIEW-001 后)
部署前的最终质量关卡。
**验证:**
- 所有测试通过
- 关键问题已解决
- 文档完整
- 性能可接受
## 自定义工作流
为您的团队定义自定义工作流:
```yaml
# .ccw/workflows/my-workflow.yaml
name: "功能开发"
levels:
- name: "discovery"
agent: "analyst"
tasks: ["research", "user-stories"]
- name: "design"
agent: "architect"
tasks: ["api-design", "database-schema"]
- name: "build"
agent: "executor"
tasks: ["implementation", "unit-tests"]
- name: "verify"
agent: "tester"
tasks: ["integration-tests", "e2e-tests"]
```
::: info 另请参阅
- [4 级系统](./4-level.md) - 详细工作流说明
- [最佳实践](./best-practices.md) - 工作流优化技巧
:::