理解 Claude Code PM：软件开发中的实用工作流程

你有没有想过，如何让软件开发项目保持井井有条，而不丢失创意或进度？在编码和团队协作的世界中，像 Claude Code PM 这样的工具就能发挥作用。它将 AI 辅助与 GitHub 等熟悉平台结合，从规划到执行，一切都变得流畅。让我们一步步了解它是什么、如何运作，以及为什么它可能适合你的下一个项目。我会逐步分解，并回答常见问题，帮助你判断是否合适。

Claude Code PM 是什么？

Claude Code PM 是一种工作流程，旨在帮助开发者和团队更有效地构建软件。它采用规范驱动开发、GitHub 问题、Git 工作树，以及多个并行运行的 AI 代理。将产品需求转化为工作代码，同时保持清晰的可追溯性。不同于基于模糊想法直接编码，它强调结构化规划和协作。

想象一个典型项目：从一个大想法开始，分解成部分，然后编码。但往往细节丢失，或团队成员互相干扰。Claude Code PM 通过创建每个步骤都文档化且可见的系统来解决这些问题。它围绕 Claude AI 构建，但与 GitHub 深度集成，支持真实团队协作。

这张图片展示了实际界面——干净、专注，适合并行工作。

为什么使用这样的工作流程？

许多开发者会问：“我当前的设置有什么问题？”常见的痛点包括工作会话间上下文丢失、并行编码冲突、需求变更无记录，以及进度隐藏。Claude Code PM 直接应对这些。

例如，如果你正在开发一个内存系统功能，这个流程会从头脑风暴引导到部署，而不走捷径。它确保代码追溯到规范，减少 bug 和遗憾。团队反馈显示，任务切换时间减少，交付更快，但重点是构建更好，而非仅仅更快。

工作流程是什么样的？

流程遵循逻辑顺序，这里用图表可视化：

graph LR
    A[PRD 创建] --> B[史诗规划]
    B --> C[任务分解]
    C --> D[GitHub 同步]
    D --> E[并行执行]

这个图表概述了主要阶段。让我们深入每个阶段。

第一阶段：产品规划

从创建产品需求文档（PRD）开始。这是彻底头脑风暴的地方。

如何创建 PRD？使用命令 /pm:prd-new memory-system。这会启动引导会话，捕捉愿景、用户故事、成功标准和约束。输出文件如 .claude/prds/memory-system.md。

为什么这个步骤重要？它防止“氛围编码”——基于松散记忆编写代码。相反，一切都清晰记录。

第二阶段：实施规划

接下来，将 PRD 转化为技术史诗。命令：/pm:prd-parse memory-system。这创建实施计划，包括架构决策、技术方法和依赖映射。输出：.claude/epics/memory-system/epic.md。

这个阶段桥接想法与代码，确保技术可行性。

第三阶段：任务分解

将史诗分解成任务。使用 /pm:epic-decompose memory-system。每个任务有自己的文件，包括验收标准、努力估计和并行标志。创建文件如 .claude/epics/memory-system/001.md。

这使工作可操作，并帮助识别可并行部分。

第四阶段：与 GitHub 同步

将一切推送到 GitHub：/pm:epic-sync memory-system 或更快的 /pm:epic-oneshot memory-system。这创建问题、适当标签，并设置关系。

GitHub 成为中心枢纽，便于协作。

第五阶段：执行

开始处理问题：/pm:issue-start 1235。专用代理处理任务，本地更新。使用 /pm:issue-sync 1235 同步进度。

对于优先级，使用 /pm:next 获取下一个任务及其上下文。

Claude Code PM 有何独特之处？

与传统方法比较：

方面	传统开发	Claude Code PM 系统
上下文管理	会话间常丢失	所有工作持久上下文
任务执行	通常串行	独立任务上的并行代理
编码方法	基于记忆或氛围	规范驱动，可追溯
进度可见性	隐藏在个人分支	GitHub 问题透明
协调	手动	通过命令智能优先级

这个表格突出差异。在传统设置中，你可能忘记细节或阻塞他人。这里，AI 代理和 GitHub 保持流动。

为什么与 GitHub 问题集成？

常见问题：“为什么不只用本地工具？” GitHub 问题将 solo AI 工作转化为团队协作。多个 Claude 实例或人类可同时贡献。进度显示在评论中，支持无缝交接。

它是单一真相来源：问题反映项目状态，评论记录审计，标签组织。无需额外数据库——随团队扩展。

系统背后的核心原则

核心是“无氛围编码”。每行代码链接到规范，通过五个阶段：

「头脑风暴」：深入思考功能。
「文档」：编写详细规范。
「规划」：明确技术选择。
「执行」：精确构建指定内容。
「跟踪」：每步透明进度。

这个纪律避免假设，构建可靠性。

系统架构解释

文件夹结构如下：

.claude/
├── CLAUDE.md          # 始终开启指令（复制到项目 CLAUDE.md）
├── agents/            # 任务导向代理，用于上下文
├── commands/          # 命令定义
│   ├── context/       # 创建和更新上下文
│   ├── pm/            # 项目管理命令
│   └── testing/       # 准备和执行测试
├── context/           # 项目范围上下文文件
├── epics/             # 史诗本地工作区（添加到 .gitignore）
│   └── [epic-name]/   # 史诗细节
│       ├── epic.md    # 实施计划
│       ├── [#].md     # 任务文件
│       └── updates/   # 进度更新
├── prds/              # PRD 文件
├── rules/             # 参考规则文件
└── scripts/           # 实用脚本

这个设置本地组织，同时同步到 GitHub。

详细命令参考

命令是使用系统的关键。按类别分解。

初始设置命令

/pm:init：安装依赖如 GitHub CLI，认证，安装扩展，创建目录，更新 .gitignore。

PRD 命令

/pm:prd-new：启动新 PRD 头脑风暴。
/pm:prd-parse：将 PRD 转为史诗。
/pm:prd-list：列出所有 PRD。
/pm:prd-edit：编辑 PRD。
/pm:prd-status：显示实施状态。

史诗命令

/pm:epic-decompose：分解史诗成任务。
/pm:epic-sync：推送到 GitHub。
/pm:epic-oneshot：一键分解和同步。
/pm:epic-list：列出史诗。
/pm:epic-show：显示史诗和任务。
/pm:epic-close：标记完成。
/pm:epic-edit：编辑细节。
/pm:epic-refresh：从任务更新进度。

问题命令

/pm:issue-show：显示问题和子问题。
/pm:issue-status：检查状态。
/pm:issue-start：用代理开始。
/pm:issue-sync：推送更新。
/pm:issue-close：标记完成。
/pm:issue-reopen：重新打开。
/pm:issue-edit：编辑细节。

工作流程命令

/pm:next：显示下一个优先问题。
/pm:status：整体仪表板。
/pm:standup：每日站会报告。
/pm:blocked：列出阻塞任务。
/pm:in-progress：列出进行中工作。

同步命令

/pm:sync：与 GitHub 全双向同步。
/pm:import：导入现有问题。

维护命令

/pm:validate：检查完整性。
/pm:clean：归档完成工作。
/pm:search：搜索所有内容。

快速总结用 /pm:help。

并行执行如何工作

问题不是单一任务——它们分解成流，如数据库工作、API、UI、测试。多个代理在同一工作树中同时运行。

例如：

分析：/pm:issue-analyze 1234
启动：/pm:epic-start memory-system
合并：/pm:epic-merge memory-system

这优化上下文：主线程保持战略，代理处理细节。

GitHub 看到干净问题；本地是协调复杂性。

关键功能和益处

「上下文保存」：史诗和代理通过文件维护状态。
「并行执行」：并发标志任务加速。
「GitHub 原生」：使用现有工具，无新依赖。
「代理专业化」：针对不同工作类型。
「可追溯性」：从 PRD 到提交。
「生产力」：专注构建，自动优先级。

团队看到更少上下文切换、并行任务、更少 bug、更快交付。

示例流程演示

假设构建内存系统。

/pm:prd-new memory-system – 头脑风暴 PRD。
审查并完善。
/pm:prd-parse memory-system – 创建史诗。
审查史诗。
/pm:epic-oneshot memory-system – 分解和同步，创建问题如 #1234（史诗）、#1235、#1236。
/pm:issue-start 1235 – 代理本地工作。
/pm:issue-sync 1235 – 更新 GitHub。
/pm:epic-show memory-system – 检查状态。

这个流程系统地将想法转为代码。

入门指南：一步步设置

如何设置 Claude Code PM

将仓库克隆到项目中：
```
cd path/to/your/project/
git clone https://github.com/automazeio/ccpm.git .
```
如果已有 .claude 目录，克隆到别处并复制内容。
初始化：
```
/pm:init
```
这处理 GitHub CLI、认证、gh-sub-issue 扩展、目录和 .gitignore。
创建 CLAUDE.md：
```
/init include rules from .claude/CLAUDE.md
```
或 /re-init 更新现有文件。
准备系统：
```
/context:create
```

现在，用 /pm:prd-new your-feature-name 开始。

本地 vs. 远程操作

操作	本地处理	GitHub 处理
PRD 创建	是	否
实施规划	是	否
任务分解	是	是（同步后）
执行	是	否
状态更新	是	是（同步后）
最终交付	否	是

这种分离保持本地工作快速，GitHub 作为最终权威。

实施技术笔记

「GitHub 集成」：使用 gh-sub-issue 处理关系；回退到任务列表。史诗通过标签如 epic:feature 跟踪子任务。
「文件命名」：任务如 001.md，同步后 1234.md。
「设计决策」：有意避免 Projects API 复杂性；本地优先速度；显式同步；工作树隔离。

常见问题解答（FAQ）

如果我已有 GitHub 问题，能导入吗？

是的，用 /pm:import 导入并与本地结构同步。

如何处理阻塞任务？

运行 /pm:blocked 列出，然后解决依赖或用 /pm:issue-edit 更新。

这只适合 solo 开发者吗？

不，它设计用于团队。GitHub 使 AI 和人类协作无缝。

并行工作冲突怎么办？

任务标志并发以最小化冲突，Git 工作树隔离变更直到合并。

如何检查整体项目状态？

用 /pm:status 获取仪表板或 /pm:standup 获取报告。

我能编辑现有史诗或问题吗？

是的，/pm:epic-edit 或 /pm:issue-edit 允许变更。

为什么用工作树？

它们为并行代理提供干净隔离，而不干扰主分支。

可追溯性如何工作？

从 PRD 到史诗、任务、问题、代码和提交——一切链接。

如果需要搜索什么？

/pm:search 扫描所有内容。

如何关闭史诗？

/pm:epic-close 标记完成，/pm:clean 归档。

结语：这个工作流程适合你吗？

如果你厌倦散乱笔记和不明进度，Claude Code PM 提供结构化替代。它关于有意构建、有效协作和交付可靠代码。在小功能上试试设置，看看感觉。记住，它灵活——调整命令适应需求。

Claude Code PM：揭秘AI如何终结软件开发混乱，打造高效工作流程