ccpm 官方入口：GitHub Issues 与多 Agent 并行开发指南
2026-07-27 3428078
2026-07-27 0
产品会上就撂下一句话：「做一套通知系统，支持站内、邮件和推送。」转头第二天就丢给AI编程，最常见的情况是它先挑个自己顺手的方向就开干：要么建表、写接口，要么直接搭页面。这三条路都能写出代码，但没人说得清优先级怎么排、验收标准是啥、哪些活儿能并行做。
ccpm上手的第一步不是拆Issue，而是先把需求整成PRD。它会追着问清楚：要解决的问题是什么、影响哪些用户、成功的指标是啥、明确哪些东西不做，还有技术和时间上的约束，最后把结果存在 .claude/prds/ 里。这时候的PRD还不算落地方案；等解析生成Epic之后，才会加上架构决策、技术路径、依赖关系和任务预览。
这一步的作用是减少歧义，可不是替团队拍板产品方向。搞砸的情况也很明显：要是「成功标准」还写着「体验更好」这种虚话，AI顶多就是把这句空话搬到更规整的文档里而已。只有把可量化的延迟、送达率、失败重试规则，还有明确不做的范围列清楚，后续拆解才有据可依。
等Epic进入Structure阶段，每个任务都会生成单独的文件。除了任务描述和验收条件，真正决定能不能并行开发的，是三个关键前置信息：
| 字段 | 对应要搞懂的问题 | 填错了会咋样 |
|---|---|---|
depends_on | 得等哪个任务先做完 | 下游任务拿不到需要的接口或数据结构 |
parallel | 能不能和别的任务同时做 | 把本来要按顺序做的活儿误当成并行 |
conflicts_with | 会不会改到同一批文件 | 提交的时候没问题，一合并就炸冲突 |
就拿通知系统来说，数据模型、消息服务、API、前端设置页、测试、文档这些都可以当成候选任务，但这只是个开头。要是API和服务层都得先改同一份公共类型文件，那就得指定其中一个任务先把类型定义交付了，剩下的任务再拉取使用，不能光凭着「模块名字不一样」就标成可并行。
官方的默认规则是一个Epic最好控制在10个任务以内。这个规定能避免「每个小改动都开个票」的碎片化问题，但也不是说10个就一定是最优解。要是一个任务里同时塞了数据库、API、界面和测试，文件体量就太大了；反过来要是连每个按钮都拆成一个Issue，协调成本又会比开发本身还高。
本地任务最开始用的是 001.md、002.md 这种临时编号。同步之后，ccpm会创建Epic Issue和子任务Issue，再把本地文件名改成对应的真实Issue编号，同时更新依赖和冲突的引用关系。GitHub管远程协作和评论，本地Markdown则用来快速查看上下文；这可不是重复记账，而是同一个任务的两种打开方式。
同步的时候还能创建 epic/ 分支和同名的worktree。这个操作能把一组功能改动和主工作区分隔开，但没法保证多个Agent完全不冲突。启动Issue之前还是得先分析涉及的文件范围，共享配置类的内容只能交给一个工作流来主改。
我检查拆解质量的时候，更看重「能不能安全停下来」，而不是任务数量：比如某个Agent中断了，另一个能不能顺着PRD、Epic、Issue文件还有进度记录快速接上上下文；依赖的任务没做完时，后面的任务会不会明确标成阻塞；验收条件够不够清楚，别人能不能直接判断有没有做完，不用非得等原作者回来解释。
要是这三点都能做到，那从PRD到Issues的这条链路就有价值了。它不是让AI更会猜心思，而是让团队不用再靠猜干活。