CCPM (Claude Code Project Management) 中文使用说明

是由Automaze开发的专为Claude Code设计的项目管理系统。它通过GitHub Issues、Git worktrees和多AI代理并行执行，实现规格驱动的快速高质量软件交付。# PRD模板## 产品概述### 产品愿景### 目标用户### 核心价值主张## 功能需求### 用户故事### 功能清单### 优先级矩阵## 技术需求### 性能要求### 安全要求### 可扩展性要求#

thinktodo1998

785人浏览 · 2025-09-18 16:38:47

thinktodo1998 · 2025-09-18 16:38:47 发布

📖 工具简介

CCPM（Claude Code Project Management） 是由Automaze开发的专为Claude Code设计的项目管理系统。它通过GitHub Issues、Git worktrees和多AI代理并行执行，实现规格驱动的快速高质量软件交付。

🎯 核心特性

🚀 并行AI开发

多代理同时工作：最多12个AI代理并行处理同一个Epic
真正的并行执行：单个Issue分解为5-8个并行工作流
无冲突协调：通过Git和显式协调机制避免冲突

📋 规格驱动开发

完整追踪链路：PRD → Epic → Task → Issue → Code → Commit
无模糊编程：每行代码都能追溯到规格说明
五阶段工作流：Think → Document → Plan → Execute → Track

🔄 上下文优化

代理作为防火墙：实现细节不污染主对话
80-90%上下文减少：通过子代理处理复杂任务
跨会话持久化：完美的上下文保持机制

🐙 GitHub原生集成

Issues作为唯一数据源：与现有GitHub工作流无缝集成
透明审计跟踪：团队实时可见AI开发进度
协作协议：人类和AI代理的规模化协作框架

🏗️ 系统架构

📂 目录结构

项目根目录/
├── .claude/                    # CCPM核心系统目录
│   ├── CLAUDE.md              # 始终生效的Claude指令
│   ├── agents/                # 任务导向的专用代理
│   │   ├── code-analyzer.md       # 代码分析和bug检测
│   │   ├── file-analyzer.md       # 文件分析和摘要
│   │   ├── test-runner.md          # 测试执行和分析
│   │   └── parallel-worker.md      # 并行任务协调
│   ├── commands/              # 命令定义目录
│   │   ├── context/               # 上下文管理命令
│   │   ├── pm/                    # 项目管理命令
│   │   └── testing/               # 测试相关命令
│   ├── context/               # 项目级上下文存储
│   ├── epics/                 # Epic工作空间（需加入.gitignore）
│   │   └── [epic-name]/           # 具体Epic目录
│   │       ├── epic.md            # 实现计划
│   │       ├── [issue-id].md      # 单个任务文件
│   │       └── updates/           # 进行中的更新
│   ├── prds/                  # 产品需求文档存储
│   ├── rules/                 # 规则和约定文件
│   └── scripts/               # 自动化脚本
├── ../epic-[name]/            # Epic专用Git worktree
└── CLAUDE.md                  # 项目级配置文件

🤖 代理系统架构

四个核心代理

code-analyzer - 跨多文件搜寻bug而不污染主上下文
file-analyzer - 读取和总结详细文件（日志、输出、配置）
test-runner - 执行测试而不将输出转储到主线程
parallel-worker - 为单个Issue协调多个并行工作流

代理设计原则

单一用途：每个代理有明确的工作职责
上下文减少：返回处理内容的10-20%
无角色扮演：代理是任务执行器，不是"专家"
清晰模式：定义明确的输入→处理→输出模式

🚀 安装和初始化

🔧 系统要求

Git（支持worktree）
GitHub CLI (gh)
gh-sub-issue扩展（推荐，用于Issue关系）
Claude Code CLI

⚡ 快速安装（2分钟）

Unix/Linux/macOS

cd path/to/your/project/
curl -sSL https://raw.githubusercontent.com/automazeio/ccpm/main/ccpm.sh | bash

Windows (PowerShell)

cd path/to/your/project/
iwr -useb https://raw.githubusercontent.com/automazeio/ccpm/main/ccpm.bat | iex

🔨 初始化配置

系统初始化

/pm:init

自动完成：

安装GitHub CLI
GitHub账户认证
安装gh-sub-issue扩展
创建目录结构

创建项目配置

/init include rules from .claude/CLAUDE.md

建立基线上下文

/context:create

📋 完整命令系统

🎯 PRD管理命令

命令	功能	说明
`/pm:prd-new`	创建新PRD	启动全面头脑风暴，创建产品需求文档
`/pm:prd-parse`	解析PRD	将PRD转换为技术实现计划
`/pm:prd-list`	列出所有PRD	显示项目中所有产品需求文档
`/pm:prd-edit`	编辑PRD	修改现有产品需求文档
`/pm:prd-status`	PRD状态	显示PRD的实现状态和进度

🏗️ Epic管理命令

命令	功能	说明
`/pm:epic-decompose`	分解Epic	将Epic分解为具体可执行任务
`/pm:epic-sync`	同步到GitHub	将Epic和任务推送到GitHub Issues
`/pm:epic-oneshot`	一键创建	完成分解和同步的一体化操作
`/pm:epic-list`	列出Epic	显示所有Epic及其状态
`/pm:epic-show`	显示Epic详情	展示Epic及其所有任务
`/pm:epic-close`	关闭Epic	标记Epic为完成状态
`/pm:epic-edit`	编辑Epic	修改Epic的详细信息
`/pm:epic-refresh`	刷新进度	从任务更新Epic的完成进度

🎯 Issue管理命令

命令	功能	说明
`/pm:issue-show`	显示Issue	展示Issue和子Issue的详细信息
`/pm:issue-status`	检查状态	查看Issue的当前状态
`/pm:issue-start`	开始任务	用专门代理开始Issue开发
`/pm:issue-sync`	同步更新	推送更新到GitHub
`/pm:issue-close`	关闭Issue	标记Issue为完成
`/pm:issue-reopen`	重新打开	重新激活已关闭的Issue
`/pm:issue-edit`	编辑Issue	修改Issue的详细信息

🔄 工作流命令

命令	功能	说明
`/pm:next`	下一个任务	显示下一个优先Issue及Epic上下文
`/pm:status`	项目仪表板	整体项目状态概览
`/pm:standup`	站会报告	生成每日站会报告
`/pm:blocked`	阻塞任务	显示被阻塞的任务列表
`/pm:in-progress`	进行中工作	列出当前正在进行的工作

📄 上下文管理命令

命令	功能	说明
`/context:create`	创建上下文	创建初始项目上下文文档
`/context:update`	更新上下文	用最近变更更新现有上下文
`/context:prime`	加载上下文	将上下文加载到当前对话

🧪 测试管理命令

命令	功能	说明
`/testing:prime`	配置测试	设置测试环境和配置
`/testing:run`	运行测试	智能分析并执行测试

🔄 五阶段工作流程

阶段1：思考（Think）- 产品规划

1.1 创建产品需求文档

/pm:prd-new memory-system

功能说明：

启动全面的头脑风暴会话
捕获产品愿景和目标
定义用户故事和使用场景
建立成功评判标准
识别技术和业务约束条件

输出文件：.claude/prds/memory-system.md

阶段2：文档化（Document）- 技术方案

2.1 解析PRD生成实现计划

/pm:prd-parse memory-system

功能说明：

将业务需求转换为技术实现方案
进行架构设计和技术选型
创建模块依赖关系图
设计数据流和接口规范

输出文件：.claude/epics/memory-system/epic.md

阶段3：规划（Plan）- 任务分解

3.1 分解Epic为具体任务

/pm:epic-decompose memory-system

功能说明：

将Epic分解为可执行的具体任务
为每个任务定义验收标准
进行工作量估算
标记可并行执行的任务

3.2 同步到GitHub（推荐一键操作）

/pm:epic-oneshot memory-system

功能说明：

自动完成分解和GitHub同步
创建GitHub Issues及父子关系
建立适当的标签和里程碑
创建Git worktree准备开发

阶段4：执行（Execute）- 并行开发

4.1 开始任务开发

/pm:issue-start 1235

执行流程：

创建独立的Git worktree：../epic-memory-system/
加载任务专用上下文
启动专门的代理进行实现
自动记录开发过程和决策

4.2 并行执行示例

# 代理1：数据库设计和迁移
/pm:issue-start 1235

# 代理2：服务层和业务逻辑（同时进行）
/pm:issue-start 1236

# 代理3：API端点和中间件（同时进行）
/pm:issue-start 1237

# 代理4：UI组件和表单（同时进行）
/pm:issue-start 1238

# 代理5：测试套件和文档（同时进行）
/pm:issue-start 1239

4.3 同步开发进度

/pm:issue-sync 1235

功能说明：

提交当前代码更改
更新GitHub Issue状态
记录完成进度和里程碑
触发相关的CI/CD流程

阶段5：跟踪（Track）- 进度监控

5.1 获取下一个优先任务

/pm:next

显示信息：

下一个最高优先级的Issue
包含完整的Epic上下文
任务的依赖关系和前置条件
预期工作量和时间估算

5.2 项目状态仪表板

/pm:status

显示信息：

整体项目进度概览
各Epic的完成状态
团队成员工作分配
阻塞项和风险识别

5.3 每日站会报告

/pm:standup

生成内容：

昨日完成的工作
今日计划的任务
遇到的阻塞和风险
需要的帮助和支持

🌟 并行执行深度解析

🔥 突破传统思维

传统模式 vs CCPM模式

传统思维：一个Issue = 一个开发者 = 一个任务

CCPM现实：一个Issue = 多个并行工作流

实际案例：用户认证功能

传统方式（串行）：
数据库设计 → 服务层开发 → API开发 → UI开发 → 测试编写
总时间：15天

CCPM方式（并行）：
代理1：数据库表和迁移        ┐
代理2：服务层和业务逻辑      ├── 同时进行
代理3：API端点和中间件      ├── 3天完成
代理4：UI组件和表单        ┤
代理5：测试套件和文档       ┘

⚙️ 协调机制

1. 文件级并行

在不同文件上工作的代理永不冲突
自动的作用域隔离
最大化并行效率

2. 显式协调

当代理需要相同文件时：
1. 明确声明需要协调
2. 建立协调时间点
3. 一次性解决冲突
4. 继续并行执行

3. 快速失败原则

立即暴露潜在冲突
不尝试智能解决
由人类做最终决策

📊 实际效果

使用CCPM的团队报告：

89%减少上下文切换损失
5-8个并行任务 vs 传统的1个
75%减少bug率
高达3倍速度的功能交付

🔧 高级功能和配置

📝 自定义模板

PRD模板定制

<!-- .claude/rules/prd-template.md -->
# PRD模板

## 产品概述
### 产品愿景
### 目标用户
### 核心价值主张

## 功能需求
### 用户故事
### 功能清单
### 优先级矩阵

## 技术需求
### 性能要求
### 安全要求
### 可扩展性要求

## 成功指标
### KPI定义
### 验收标准
### 风险评估

Epic模板定制

<!-- .claude/rules/epic-template.md -->
# Epic实现计划模板

## 技术架构
### 系统设计
### 技术选型
### 依赖分析

## 实施策略
### 开发阶段
### 并行度规划
### 风险缓解

## 质量保证
### 测试策略
### 代码审查
### 性能基准

🔌 第三方集成

Slack通知集成

# 配置Slack Webhook
/pm:config set slack.webhook "https://hooks.slack.com/services/..."
/pm:config set slack.channel "#development"

# 自动通知设置
/pm:config set notifications.epic-complete true
/pm:config set notifications.issue-blocked true

Jira同步集成

# 配置Jira连接
/pm:config set jira.url "https://company.atlassian.net"
/pm:config set jira.project "PROJ"
/pm:config set jira.sync-labels true

🎯 最佳实践指南

1. 任务分解策略

✅ 合适的任务粒度

理想任务特征：
- 1-3天可完成
- 有明确验收标准
- 可独立测试
- 有清晰的输入输出

示例 - 用户注册功能：
✅ 设计用户数据模型
✅ 实现注册API端点
✅ 添加邮箱验证逻辑
✅ 创建注册表单界面
✅ 编写注册功能测试

❌ 开发整个用户管理系统（太大）
❌ 修改数据库字段类型（太小）

🔗 依赖关系管理

Phase 1 (无依赖，可并行)：
- 数据库设计和迁移
- API规范文档编写
- 前端框架和样式设计
- 测试框架搭建

Phase 2 (依赖Phase 1)：
- 后端服务实现
- 前端组件开发
- 集成测试编写

Phase 3 (集成阶段)：
- 端到端测试
- 性能优化
- 部署配置

2. 上下文管理策略

📄 上下文文件组织

.claude/context/
├── architecture.md          # 系统架构决策
├── coding-standards.md      # 编码规范和约定
├── api-conventions.md       # API设计约定
├── database-schema.md       # 数据库设计
├── deployment-guide.md      # 部署和运维指南
└── troubleshooting.md       # 问题排查手册

🔄 上下文更新流程

# 会话开始时
/context:prime

# 开发过程中的决策更新
# （自动记录到上下文文件）

# 会话结束时
/context:update

3. 团队协作模式

👥 角色和职责

Product Owner：PRD编写和需求管理
Tech Lead：架构设计和技术决策
Senior Developer：Epic分解和技术指导
Developer：任务实施和代码实现
QA Engineer：测试策略和质量保证

🗓️ 工作节奏

每日节奏：
09:00 - 站会同步（/pm:standup）
09:30 - 获取优先任务（/pm:next）
17:30 - 同步进度（/pm:issue-sync）

每周节奏：
周一 - Epic规划和任务分解
周三 - 中期进度评审
周五 - 代码审查和质量检查

每月节奏：
月初 - 项目规划和目标设定
月中 - 技术架构评审
月末 - 项目回顾和改进

🚨 故障排除指南

🔍 常见问题诊断

1. GitHub CLI认证问题

# 症状：无法创建或更新Issues
gh auth status

# 解决方案
gh auth login --web
gh auth refresh

2. Worktree创建失败

# 症状：并行任务无法启动
git worktree list
git worktree prune

# 手动创建worktree
git worktree add ../epic-feature-name -b epic-feature-name

3. 代理协调冲突

# 症状：多个代理修改同一文件
git status
git diff

# 解决策略
1. 明确文件归属
2. 建立协调时间点
3. 手动解决冲突
4. 更新协调规则

4. Issue关系丢失

# 症状：父子Issue关系错误
gh sub-issue list --parent 1000

# 重新建立关系
gh sub-issue link --parent 1000 --child 1001

🛠️ 高级故障排除

代理性能优化

# 检查代理资源使用
/pm:agent-status

# 调整并行度
/pm:config set max-parallel-agents 8

# 代理重启
/pm:agent-restart parallel-worker

上下文清理

# 清理过期上下文
/context:cleanup --older-than 30days

# 压缩上下文大小
/context:optimize --max-size 50kb

📊 监控和分析

📈 项目仪表板

Epic进度可视化

/pm:epic-show memory-system

输出示例：

📊 Memory System Epic 状态报告

总体进度: ██████████░░ 83% (5/6 完成)

✅ 已完成任务:
- 缓存接口设计 (#1001) - 2天
- Redis连接池 (#1002) - 1天
- LRU算法实现 (#1003) - 3天
- 单元测试编写 (#1004) - 1天
- 性能基准测试 (#1005) - 2天

🔄 进行中任务:
- 分布式锁机制 (#1006) - 进度65%, 预计明天完成

📈 效率指标:
- 平均任务完成时间: 1.8天
- 并行执行效率: 85%
- 代码审查通过率: 100%
- Bug密度: 0.2/KLOC

团队效率分析

/pm:team-analytics --period 30days

👥 团队效率分析 (过去30天)

🚀 生产力指标:
- 代码提交量: ↑ 127% vs 上月
- 功能交付: 15个Epic完成
- Bug修复: 平均0.5天
- 代码审查周期: 平均2.3小时

🔄 并行执行统计:
- 平均并行度: 6.2个代理
- 最高并行度: 12个代理
- 冲突解决: 平均15分钟
- 上下文切换: 减少89%

📊 质量指标:
- 测试覆盖率: 94.5%
- 代码质量评分: A+
- 客户满意度: 9.2/10

🌟 成功案例分析

案例1：电商平台开发

项目规模：15个Epic，120个任务
团队规模：6名开发者 + 20个AI代理
开发周期：3个月（传统方式需要8个月）

关键收益：
- 开发效率提升3.2倍
- Bug率降低75%
- 代码质量评分A+
- 团队满意度提升85%

案例2：金融风控系统

项目特点：高并发、强一致性、严格监管
技术挑战：实时计算、风险建模、合规审计

CCPM优势：
- 规格驱动确保合规性
- 并行开发缩短上线时间
- 完整审计满足监管要求
- 上下文保持保证一致性

📚 深入学习资源

📖 官方文档

主仓库：https://github.com/automazeio/ccpm
命令参考：https://github.com/automazeio/ccpm/blob/main/COMMANDS.md
架构文档：https://github.com/automazeio/ccpm/tree/main/docs
问题反馈：https://github.com/automazeio/ccpm/issues

🎓 学习路径

初学者路径

阅读核心概念和设计理念
完成快速安装和初始化
创建第一个PRD和Epic
体验基本的并行开发流程
学习常用命令和故障排除

进阶路径

深入理解代理系统架构
掌握复杂的并行协调机制
自定义命令和模板
集成第三方工具和服务
优化团队协作流程

专家路径

贡献代码到CCPM项目
开发自定义代理和插件
设计企业级集成方案
培训和指导其他团队
参与社区建设和讨论

🤝 社区参与

获取帮助

GitHub Issues：报告bug和功能请求
GitHub Discussions：技术讨论和经验分享
Hacker News：https://news.ycombinator.com/item?id=44960594

贡献方式

文档改进：补充使用案例和最佳实践
代码贡献：修复bug和实现新功能
社区建设：回答问题和分享经验
推广传播：在会议和博客中分享经验

🚀 CCPM：让人类和AI代理团队协作开发变得简单高效！ 📋 从想法到产品，全程规格驱动，完全可追溯！ ⚡ 突破传统开发瓶颈，实现真正的并行AI开发！

📄 CCPM文档生成体系（完整版）

🎯 核心文档类型

除了基础的需求、设计、任务文档外，CCPM系统生成10大类超过30种不同类型的文档：

1. 核心项目文档

PRD文档 (.claude/prds/*.md) - 产品需求文档
Epic文档 (.claude/epics/*/epic.md) - 技术实现史诗
Task文档 (.claude/epics/*/[数字].md) - 具体任务文件

2. 项目管理与报告文档

Progress文档 (.claude/epics/*/updates/*/progress.md) - 任务进度跟踪
Daily Standup报告 - 每日站会报告（通过standup.sh生成）
Status报告 - 项目整体状态报告
Epic进度报告 - Epic完成度和时间线分析

3. 质量保证文档

代码审查报告 - 基于Codex Review工作流
架构审查文档 - 四层存储架构评估报告
性能分析报告 - 量化系统性能指标验证
测试覆盖率报告 - 自动化测试结果统计

4. 输出样式与规范文档

quantitative-code.md - 量化策略代码生成规范
architecture-review.md - 架构审查输出格式
codex-review-workflow.md - 代码审查流程文档
performance-analysis.md - 性能分析输出样式
testing-strategy.md - 测试策略文档
storage-layer.md - 存储层设计文档

5. 运维与配置文档

命令帮助文档 (.claude/commands/pm/*.md) - 各PM命令说明
Agent配置文档 (.claude/agents/*.md) - 子代理配置说明
工具集成指南 (.serena/memories/tool_integration.md)
部署清单文档 - 自动化部署验证清单

6. 上下文与记忆文档

项目上下文 (.serena/memories/project_context.md)
架构决策记录 (.serena/memories/architecture_decisions.md)
重构策略文档 (.serena/memories/refactoring_strategy.md)
工作流程文档 (.serena/memories/essential_workflows.md)
质量保证策略 (.serena/memories/quality_assurance_strategy.md)

7. 数据分析文档

需求分析报告 - 通过requirements_discovery系统生成
API需求分析 - 基于GitHub数据提取
依赖关系分析 - 任务依赖图表和分析
工作量评估报告 - 基于历史数据的预测分析

8. 决策支持文档

技术选型分析 - 基于Sequential Thinking工具
风险评估报告 - 量化交易特定风险分析
合规检查清单 - 金融级代码标准验证
变更影响分析 - 代码修改的风险评估

9. 专业化输出文档（适用于量化交易项目）

策略回测报告 - 量化策略性能分析
交易执行分析 - 延迟和性能指标报告
风险控制报告 - 实时风险监控文档
多频率数据质量报告 - tick到日线数据质量评估

10. 集成与部署文档

QMT接口集成文档 - 券商接口配置指南
十大量化库适配文档 - 量化工具兼容性报告
CI/CD流水线文档 - 自动化构建和部署指南
监控和告警配置 - 系统监控体系文档

🔄 文档自动化生成机制

工具链集成

Serena MCP: 代码分析和符号级编辑生成技术文档
Sequential Thinking: 结构化决策分析文档
Playwright: 自动化测试和性能验证报告
File/Code Analyzer: 日志分析和代码质量报告

生成时机

实时生成: 进度报告、状态仪表板
里程碑生成: Epic完成报告、架构审查文档
定期生成: 日站会报告、团队效率分析
按需生成: 风险评估、技术选型分析

文档分层管理

项目级文档 (.claude/prds/, .claude/epics/)
  ├── 业务文档 (PRD, 需求分析)
  ├── 技术文档 (Epic, 架构设计)
  └── 管理文档 (进度, 状态报告)

系统级文档 (.claude/rules/, .claude/output-styles/)
  ├── 规范文档 (编码标准, 输出样式)
  ├── 配置文档 (代理配置, 命令定义)
  └── 模板文档 (PRD模板, Epic模板)

记忆级文档 (.serena/memories/)
  ├── 上下文文档 (项目背景, 决策记录)
  ├── 经验文档 (最佳实践, 教训总结)
  └── 知识文档 (技术栈, 工具使用)