ccpm 是什么？AI Agent 项目管理 Skill 介绍

第一次点开 ccpm 仓库，多数人最先冒出来的问题不是「怎么用」，而是「这玩意儿到底是啥」：是命令行工具？项目模板？还是又一个能替人写代码的 Agent？其实答案更偏向第四种——它是一套装在 AI 编程助手里的项目管理 Skill，作用是把一句模糊的需求，变成一连串可核查的交付记录。

它不是另一个聊天机器人，而是一套交付秩序

ccpm 的名字来自 Claude Code Project Manager，但目前仓库已经按照 Agent Skills 规范组织，不只面向 Claude Code。只要宿主支持 Skill，Codex、OpenCode、Factory、Amp、Cursor 这类环境也都能读取它。它既不训练新模型，也不托管项目数据；真正嵌入工作流的，是一套写作规则、文件约定和配套脚本。

它要解决的问题特别具体：需求散落在聊天记录里，下次开新会话得从头再讲一遍；好几个 Agent 同时改代码，根本不知道谁碰了同一份配置；进度全靠人脑记；代码写完了，反倒找不到它对应哪条需求。

我自己会这么试：先挑个两三天就能做完的小功能，比如通知设置页，别一上来就搞整套产品重构。等 ccpm 写完 PRD 先停一停，看看要解决的问题、成功标准还有「不做什么」是不是真的讲清楚了。要是这一步都还含糊，后面的自动化只会把含糊放大得更快。

五个阶段各自留下什么

ccpm 把整个交付流程拆成 Plan、Structure、Sync、Execute、Track 五个阶段。Plan 阶段通过提问输出 PRD，再把 PRD 拆解成技术层面的 Epic；Structure 阶段把 Epic 拆成具体任务，同时记录依赖关系、能不能并行、哪些文件可能会有冲突；Sync 阶段把本地任务同步成 GitHub Issues，还会给 Epic 建专用的 worktree；Execute 阶段会进一步分析单个 Issue 内部有哪些独立的工作流；Track 阶段则靠脚本读取本地状态，能直接答出站会内容、下一项任务和当前阻塞点。

这五个阶段不是为了把流程装点得好看，而是让每一步决策都落得到实处。PRD 存在 .claude/prds/ 目录里，Epic 和任务存在 .claude/epics/ 目录下，任务同步后会用真实的 Issue 编号重命名。哪怕聊天会话结束了，这些文件也不会跟着「失忆」。

我自己会这么试：等完成一次拆解后，故意开个新会话，只给 Agent 项目目录，不额外补任何口头背景。要是它能从 PRD、Epic 和任务文件里还原出「为什么做、做到哪了、下一步该干嘛」，那才说明上下文保存是真的管用。

GitHub Issues 为什么成了那根主轴

ccpm 没有重新搞一套项目数据库。GitHub Issue 是远程协作的入口，本地 Markdown 文件负责快速编辑和保存上下文；Issue 评论用来记录阶段性进展，分支和提交还是沿用团队原来的习惯。人可以接手 Agent 做到一半的任务，Agent 也能顺着人留下的 Issue 和提交继续往下做。

并行也不是简单的「多开几个 Agent」就行。任务文件里会记录 depends_on、parallel 和 conflicts_with 这些信息，执行前还会生成 Issue 分析文件，把数据库、服务、API、界面、测试这类工作流按涉及的文件范围划分开。要是两个工作流都要改 package.json，那就不能假装它们互不影响。

我自己会这么试：挑一个同时涉及后端接口和前端页面的 Issue，先看分析文件里有没有明确列出共享文件。要是连共享文件的判断都没有，只列个「Agent A、Agent B」，那根本不是可靠的并行，只是同时开工而已。

它适合谁，也明确不适合谁

ccpm 更适合这类场景：已经有 Git 仓库、习惯用 GitHub Issues、功能开发要跨多个文件且得持续好几天的任务。小团队要是想把 AI 编程从「想到哪写到哪」改成可复盘的交付模式，也能直接受益。

它替代不了产品判断，也没法保证写进 PRD 的需求就一定是对的；要是只是改个小拼写、解释一段代码、单独跑个测试或者纯做 PR Review，也没必要硬走完整的五阶段流程。官方 Skill 的触发边界也写得很明白：没有软件交付上下文的纯 GitHub 操作，不是 ccpm 擅长的领域。

我自己会这么试：先问自己一个特别朴素的问题：这个任务要是搞砸了，团队需不需要知道需求是从哪走偏的、哪个依赖被漏掉了、谁改了什么？答案是「需要」，那 ccpm 就值得用；要是只是十分钟就能搞定的小改动，就别让流程比问题本身还麻烦。