Claude Code PM是一組工作流程，通過「規範文檔驅動的步驟」+「並行人工智慧代理」將產品創意直接轉化為GitHub問題和代碼。它支持/pmepic-oneshot拆分任務和/PM：issue-start執行任務等指令。它可以完全保留上下文，通過GitHub實現團隊協作，並確保每一行代碼都可以追溯到相應的產品規範。
使用它的好處：
- 交付速度加快3倍
- 不良率降低75%
- 上下文損失減少89%
多種藥劑可同時使用，進一步提高研發效率
最近，人工智慧編程圈出現了一個更有趣的項目：CCPM（Claude Code Project Manager）。它不是一個新的人工智慧模型，也不是代碼生成工具，而是一套 圍繞人工智慧編程和設計的開發工作流程。它試圖解決許多人已經遇到的問題：當人工智慧參與編寫代碼時，項目開發很容易變得混亂。
現在很多人寫代碼的方式實際上是這樣的：打開Claude Code或其他人工智慧助手，描述需求，讓它生成代碼，然後繼續對話進行修改。看起來在短時間內很高效，但隨著項目規模越來越大，問題就出現了--上下文開始丟失，需求和代碼之間沒有明確的對應關係，而且不同人工智慧生成的代碼容易發生衝突。
這正是CCPM想要解決的問題。它提出了一個想法：將人工智慧編程集成到標準軟體工程流程中，而不是依賴基於聊天的開發。
整個工作流程的核心是一個非常簡單的鏈條：
產品規格（規格/CPD）
→史詩般的
→ GitHub問題
→代碼當新的產品創意出現時，開發人員首先編寫規範文檔，而不是讓人工智慧直接編寫代碼。接下來，通過CCPM命令，該規範可以自動分解為多個任務。每個任務都成為GitHub問題，並可以移交給人工智慧代理來實現它。
CCPM提供了一些命令來驅動此過程。例如 /下午：epic-oneshot 任務結構可以根據規範文檔自動生成，並且 /下午：問題開始 將啟動人工智慧代理來執行相應的任務。這樣，每條代碼都可以追溯到一個Issue，並且每個Issue都來自原始的產品規範。
整個系統圍繞GitHub運行。需求、任務和提交記錄都保存在倉庫中，因此開發過程自然是可追溯的。這實際上非常接近傳統的軟體工程流程，但現在執行任務的不再完全是人類開發人員，而是人工智慧。
另一個關鍵設計是並行開發。CCPM使用Git的工作樹機制為每個任務創建單獨的開發環境。這樣，多個人工智慧代理就可以同時開發不同的模塊，而不會相互干擾。例如，一個代理負責API，一個負責前端組件，另一個負責測試代碼。每個任務都有自己的分支和上下文，最終通過拉取請求合併回主分支。
這種方法與現在很多人常用的「人工智慧聊天寫代碼」形成鮮明對比。作者甚至專門提出了一個概念，叫做 「沒有Vibe編碼」。這意味著，與其依賴感覺和聊天來驅動開發，不如通過明確的規範和任務結構來驅動人工智慧。
從技術角度來看，這個項目並不複雜。存儲庫中的內容主要是腳本、命令和模板，以幫助團隊組合需求文檔、GitHub Issue和AI代理。它更像是一個 開發方法的實施工具，而不是一個巨大的框架。
但它所代表的方向實際上很有趣。隨著人工智慧編程工具變得越來越強大，開發過程本身也在發生變化。過去，軟體工程是「人寫代碼，由工具輔助」，現在逐漸變成「人工智慧寫代碼，由人設計流程」。「在這個模型中，真正重要的可能不再是代碼本身，而是 如何組織任務、如何定義規範以及如何管理代理協作。
CCPM試圖回答這個問題：如果未來的軟體由多個人工智慧代理完成，開發過程應該是什麼樣子？
從這個角度來看，這個項目不僅僅是一個工具，更像是對未來人工智慧軟體工程的探索。
Github：https://github.com/automazeio/ccpm
輸油管：