CCPM让AI 写代码变成真正的工程流程

Claude Code PM 是一套工作流，它通过「以规格文档为驱动的步骤」+「并行 AI 智能体」，将产品想法直接转化为 GitHub Issue 与代码。它支持 /pmepic-oneshot 拆分任务、/pm:issue-start 执行任务等指令，能完整保留上下文，通过 GitHub 实现团队协作，并确保每一行代码都可追溯到对应的产品规格。
使用它的收益：

• 交付速度提升 3 倍
• 缺陷率降低 75%
• 上下文丢失减少 89%

可同时使用多个智能体，进一步提升研发效率

最近在 AI 编程圈里，有一个比较有意思的项目：CCPM（Claude Code Project Manager）。它并不是一个新的 AI 模型，也不是代码生成工具，而是一套 围绕 AI 编程设计的开发工作流。它试图解决一个很多人已经遇到的问题：当 AI 参与写代码时，项目开发很容易变得混乱。

很多人现在写代码的方式其实是这样的：打开 Claude Code 或其他 AI 助手，描述一个需求，让它生成代码，然后继续对话修改。短时间内看起来效率很高，但随着项目变大，问题就出现了——上下文开始丢失，需求和代码之间没有清晰的对应关系，不同 AI 生成的代码之间也容易冲突。

CCPM 想解决的正是这个问题。它提出了一种思路：把 AI 编程纳入标准的软件工程流程，而不是依赖聊天式开发。

整个工作流的核心是一个很简单的链条：

产品规格（Spec / PRD）
→ Epic
→ GitHub Issue
→ Code

当一个新的产品想法出现时，开发者首先写一份规格文档，而不是直接让 AI 写代码。接下来，通过 CCPM 的命令，可以自动把这份规格拆解为多个任务。每个任务会变成一个 GitHub Issue，并且可以交给一个 AI 智能体去实现。

CCPM 提供了一些命令来驱动这个流程。例如 /pm:epic-oneshot 可以根据规格文档自动生成任务结构，而 /pm:issue-start 则会启动一个 AI 智能体去执行对应的任务。这样，每一段代码都可以追溯到某个 Issue，而每个 Issue 又来自最初的产品规格。

整个系统围绕 GitHub 运行。需求、任务、提交记录全部保存在仓库中，因此开发过程天然具备可追溯性。这一点和传统的软件工程流程其实非常接近，只不过现在执行任务的不再完全是人类开发者，而是 AI。

另一个比较关键的设计是并行开发。CCPM 使用 Git 的 worktree 机制，为每个任务创建一个独立的开发环境。这样多个 AI 智能体可以同时开发不同模块，而不会互相干扰。例如，一个智能体负责 API，一个负责前端组件，另一个负责测试代码。每个任务都有自己的分支和上下文，最后再通过 Pull Request 合并回主分支。

这种方式和很多人现在常见的“AI 聊天写代码”其实形成了鲜明对比。作者甚至专门提出一个概念叫 “No Vibe Coding”。意思是，不要靠感觉和聊天驱动开发，而是通过清晰的规格和任务结构来驱动 AI。

从技术角度看，这个项目并不复杂。仓库里的内容主要是一些脚本、命令和模板，用来帮助团队把需求文档、GitHub Issues 和 AI 代理结合起来。它更像是一种 开发方法论的实现工具，而不是一个庞大的框架。

但它代表的方向其实挺有意思。随着 AI 编程工具越来越强，开发流程本身也在发生变化。过去的软件工程是“人写代码、工具辅助”，现在开始逐渐变成“AI 写代码、人设计流程”。在这种模式下，真正重要的可能不再是代码本身，而是 如何组织任务、如何定义规格、如何管理智能体协作。

CCPM 正是在尝试回答这个问题：如果未来的软件是由多个 AI 智能体共同完成的，那么开发流程应该是什么样的。

从这个角度看，这个项目不仅仅是一个工具，更像是对未来 AI 软件工程的一种探索。

Github：https://github.com/automazeio/ccpm
油管：https://youtu.be/0iuaF7E5Dxo