AI 编程如何拆 PRD 和 Issues？ccpm 使用方法解析

产品会上就撂下一句话：「做一套通知系统，支持站内、邮件和推送。」转头第二天就丢给AI编程，最常见的情况是它先挑个自己顺手的方向就开干：要么建表、写接口，要么直接搭页面。这三条路都能写出代码，但没人说得清优先级怎么排、验收标准是啥、哪些活儿能并行做。

先把想法捋到「没法随便瞎解释」的程度

ccpm上手的第一步不是拆Issue，而是先把需求整成PRD。它会追着问清楚：要解决的问题是什么、影响哪些用户、成功的指标是啥、明确哪些东西不做，还有技术和时间上的约束，最后把结果存在 .claude/prds/.md 里。这时候的PRD还不算落地方案；等解析生成Epic之后，才会加上架构决策、技术路径、依赖关系和任务预览。

这一步的作用是减少歧义，可不是替团队拍板产品方向。搞砸的情况也很明显：要是「成功标准」还写着「体验更好」这种虚话，AI顶多就是把这句空话搬到更规整的文档里而已。只有把可量化的延迟、送达率、失败重试规则，还有明确不做的范围列清楚，后续拆解才有据可依。

拆任务不是按页面切，得按交付依赖关系来

等Epic进入Structure阶段，每个任务都会生成单独的文件。除了任务描述和验收条件，真正决定能不能并行开发的，是三个关键前置信息：

就拿通知系统来说，数据模型、消息服务、API、前端设置页、测试、文档这些都可以当成候选任务，但这只是个开头。要是API和服务层都得先改同一份公共类型文件，那就得指定其中一个任务先把类型定义交付了，剩下的任务再拉取使用，不能光凭着「模块名字不一样」就标成可并行。

官方的默认规则是一个Epic最好控制在10个任务以内。这个规定能避免「每个小改动都开个票」的碎片化问题，但也不是说10个就一定是最优解。要是一个任务里同时塞了数据库、API、界面和测试，文件体量就太大了；反过来要是连每个按钮都拆成一个Issue，协调成本又会比开发本身还高。

同步到Issues的时候，编号就成了任务的「身份证」

本地任务最开始用的是 001.md、002.md 这种临时编号。同步之后，ccpm会创建Epic Issue和子任务Issue，再把本地文件名改成对应的真实Issue编号，同时更新依赖和冲突的引用关系。GitHub管远程协作和评论，本地Markdown则用来快速查看上下文；这可不是重复记账，而是同一个任务的两种打开方式。

同步的时候还能创建 epic/ 分支和同名的worktree。这个操作能把一组功能改动和主工作区分隔开，但没法保证多个Agent完全不冲突。启动Issue之前还是得先分析涉及的文件范围，共享配置类的内容只能交给一个工作流来主改。

合格的拆解，得让人敢随时停下来

我检查拆解质量的时候，更看重「能不能安全停下来」，而不是任务数量：比如某个Agent中断了，另一个能不能顺着PRD、Epic、Issue文件还有进度记录快速接上上下文；依赖的任务没做完时，后面的任务会不会明确标成阻塞；验收条件够不够清楚，别人能不能直接判断有没有做完，不用非得等原作者回来解释。

要是这三点都能做到，那从PRD到Issues的这条链路就有价值了。它不是让AI更会猜心思，而是让团队不用再靠猜干活。