周一的需求只有一句：“加一套通知功能。”

到周三，数据库表已经有了，接口写了一半，前端也搭出设置页。三处代码都在动，但邮件重试算不算本期范围，没人能从提交里看出来。

更麻烦的是，主对话已经塞满实现细节。换一个 Agent 接手，它先花半小时翻记录，再凭语气猜上一位为什么这么设计。

所谓不规范，往往不是没有文档，而是每一次决定都没有落在下一位能继续使用的位置。

ccpm 切中的正是这条断裂。它没有让 Claude Code 突然更聪明，而是逼着“想做什么、准备怎么做、谁先做、做到哪了”分别留下可复查的产物。

它先把一句需求逼成不能随便改口的东西

需求进入 ccpm 后不会立刻变成代码。Agent 要先问问题、用户、成功标准、约束和范围外事项，再把答案写进 .claude/prds/。接着生成技术 Epic，补上架构决定、实现路径和任务预览。

听起来慢了一步，但这一步专门拦住“邮件也顺便做了吧”“推送失败先不管”之类口头漂移。想改范围当然可以，只是改动要回到 PRD 和 Epic，而不是只存在最新一轮聊天里。

任务文件真正管的，是交接而不是排版

Epic 拆开后，每个任务不只写“做什么”，还记录验收条件、工作量、依赖、并行标志和冲突对象。这里最有价值的不是 Markdown，而是任务开始回答工程里的难问题：它要等谁？会碰哪些共享文件？完成后别人拿什么继续？

通知系统里的数据模型和设置页可以并行，公共类型定义却不能被两边同时抢着改。ccpm 会把这类关系写进任务元数据；同步到 GitHub 后，临时的 001.md 会改成真实 Issue 编号。文件名、Issue 和提交因此指向同一件事。

它没有让 Agent 自由发挥到底

真正启动 Issue 前，还有一次并行分析。数据库、服务、API、界面、测试被划成独立工作流，每个 Agent 只拿到自己的文件范围。依赖没完成的流先排队，共享配置交给一个指定流处理。冲突出现时暂停，而不是自动解决后继续冒险。

这件事对规范化开发很重要。多 Agent 的速度来自同时推进独立工作，不是让更多执行者同时猜同一份代码该怎么改。

状态终于不靠谁记得昨晚聊了什么

ccpm 把状态查询交给脚本。standup、in-progress、next、blocked、validate 都从 .claude/ 下的真实文件读取，不需要模型重新概括整段聊天。解释仍由 Agent 来做，但“现在有几项开放任务”这种确定性工作不再消耗推理。

主对话于是更像指挥席：它决定下一项工作、解释异常、处理需要判断的地方。状态文件和脚本承担重复读取，Issue 评论承担远程交接，Git 提交承担代码轨迹。

规范化不是每个改动都走一遍五阶段

修一个错别字没必要写 PRD，单文件小修也不需要多 Agent。ccpm 更适合会跨模块、持续多个会话、需要人机交接的功能。它要求的克制不只体现在“先写规格”，还体现在知道什么时候不用整套规格。

等一个 Epic 合并回主分支，worktree 被清理，任务归档，GitHub Issue 关闭，整条链路才算结束。留下来的不是一份漂亮流程说明，而是下一次出现争议时，团队能顺着 PRD、Epic、Issue、提交和进度记录找到答案。