管理 AI 軟體專案
將模糊的 AI 輔助交付工作轉變為一個由單一人類操作員控制的執行系統。透過引導出框架、取得對故事拆分的明確批准、透過持久檔案中的小型路由任務佇列執行、以證據驗證，並僅在每項成功標準通過其端到端檢查後才結案。
保持持久的專案狀態為廠商中立。在 Codex、Claude Code 或其他相容代理之間切換，不得需要轉換 pm/ 檔案。
快速開始
- 檢查工作區。如果
pm/存在，請閱讀pm/STATE.md，然後是pm/TASKS.md；修補缺口，而非重新產生系統。 - 如果沒有專案系統存在，執行 CP1：詢問引導性問題並在
pm/PLAN.md中草擬框架。 - 從 references/file-templates.md 建立四個規範檔案。
- 透過 CP2 拆分、CP3 佇列、執行迴圈以及 CP4 最終驗收來驅動工作。
操作員檢查點協議
與操作員共同建立拆分。在 pm/PLAN.md 或 pm/TASKS.md 中記錄每次的批准並附上日期。
- CP1 — 框架。 引導出並取得對目標、成功標準、最終檢查、範圍、限制和結構性假設的批准。
- CP2 — 拆分。 以操作員的語言呈現故事。為每個故事提供驗收標準，並將其追溯至其所服務的成功標準。與操作員一起解決開放的結構性決策。
- CP3 — 佇列。 在執行開始前，呈現帶有路由層級的排序任務佇列。
- CP4 — 最終驗收。 重新執行每一項 CP1 最終檢查（端到端），連結證據，呈現驗收報告，並取得簽核。僅完成任務並不代表專案完成。
使用這些常設規則：
- 在已批准的框架內填補小缺口，並在
pm/DECISIONS.md中記錄推論的假設。 - 將結構性變更（範圍、故事、成功標準或驗收標準）回饋至相關檢查點，並記錄權衡取捨。
- 在 CP1 時詢問：必須存在什麼成果，以及為誰存在？操作員將如何親自驗證它？什麼是範圍外的？哪些限制是固定的？已經存在什麼？什麼最有風險或最不清楚？操作員希望進行多少審查？
- 在救援模式中，從工作區重建隱含的框架和拆分，呈現給操作員確認，然後重建佇列。
規範專案檔案
在 pm/ 下維護四個檔案：
pm/PLAN.md— 目標、成功標準、範圍、故事、可追溯性、批准pm/TASKS.md— 排序的任務佇列、穩定 ID、路由、驗證、證據pm/STATE.md— 當前狀態、交接備註、會話日誌pm/DECISIONS.md— 決策、假設、風險、問題、變更日誌
預設情況下，不要建立更多的控制檔案。僅在相關分支活躍時才新增 pm/CONSTRAINTS.md、pm/RELEASE.md 或 pm/RESEARCH.md。
保持產品特定的入口檔案（例如 AGENTS.md 或 CLAUDE.md）簡短且具導航性：指向 pm/STATE.md，然後是 pm/TASKS.md，並將 pm/PLAN.md 作為已批准的範圍。將會話本地規劃工具中的持久資訊鏡像到 pm/TASKS.md 和 pm/STATE.md 中。
按能力路由工作
當每個任務進入佇列時，分配一個廠商中立的 Route: 層級：
| 層級 | 用途 |
|---|---|
heavy | 規劃、分解、架構、模糊除錯、跨領域重構、高風險審查、最終驗收 |
standard | 有明確邊界的實作、測試、中等複雜度的變更 |
light | 儲存庫搜尋、摘要、機械性編輯、文件、格式化、日誌分類 |
將每個任務路由到能夠可靠完成它的最便宜層級：
- 保持主要執行緒足以進行指導：框架簡報、路由工作、判斷證據、以及簽核。
- 在同一個任務失敗兩次或得到低信心結果後，升級一個層級；記錄升級。
- 要求審查者層級至少與撰寫者層級相同。對高風險或跨領域的變更，以全新的
heavy上下文進行審查。絕不允許light工作者自行批准。 - 將模型名稱保留在
pm/之外；產品別名和價格會變化，而能力層級則保持有用。 - 在為 Codex、Claude Code 或其他代理配置工作者之前，請閱讀 references/agent-routing.md。
先建立上下文
- 提取真正的目標、使用者、驗收標準、依賴關係和發佈期望。
- 僅在明確指定的情況下，將日期、預算、批准、供應商時程或上線窗口視為第一級輸入。
- 在發明新的產物之前，先尋找現有的
pm/檔案、任務簡報、待辦事項、設計、ADR、測試策略、操作手冊、風險日誌和代理指令檔案。 - 在救援工作中，評估目標清晰度、範圍、依賴關係、驗收品質、風險衛生、上下文可讀性、權限和發佈準備度。
選擇最小的控制模式
- 預設為
solo-operator：一個操作員引導 AI 代理。 - 對於真正的固定日期、合規關卡、批准、供應商依賴、配額或上線窗口，新增
external-constraint。 - 當探索、使用者學習或 UX 迭代佔主導地位時，新增
feedback-heavy。 - 當交付需要切換、回滾、監控或操作備註時，新增
release-safety。
調整執行單元大小
- 使用故事來承載使用者可見的價值和驗收。僅使用里程碑來分組工作。透過任務來執行。
- 使每個任務適合一次聚焦的代理執行和一次快速的操作員審查：一個子系統、介面、文件或測試面，以及一個可審查的 diff。
- 為每個任務提供一個穩定的 ID、故事參考、路由層級、範圍、依賴關係、完成條件、精確驗證、證據欄位和明確的停止點。
- 當任務跨越多個無關領域或包含幾個獨立的驗證時，在執行前拆分。保留歷史記錄：子任務獲得新 ID；被取代的任務標記為
superseded。 - 完成任務後，在同一輪執行中，填寫其證據並更新
pm/STATE.md。
維持可追溯性
- 將每個成功標準映射到至少一個故事，並將每個故事映射到至少一個任務。
- 僅在該故事的所有任務和驗收標準都已透過證據驗證後，才將故事標記為完成。
- 僅在 CP4 重新驗證每項成功標準（端到端）後，才將專案標記為完成。
執行品質優先的循環
- 在實作前定義最小的可信證據：失敗的重現步驟、自動化測試、預期輸出、螢幕截圖比較、合約檢查或精確的手動程序。
- 使用
探索 -> 規劃 -> 實作 -> 驗證 -> 審查 -> 文件化。 - 記錄命令、結果、螢幕截圖、指標和審查備註，而不僅僅是結論。
- 為高風險任務說明變更預算：允許的檔案、穩定的介面、資料安全性、回滾和升級觸發條件。
- 在擴展之前，先在一個狹窄的代表性樣本上試行重複性或自動化的變更。
- 在同樣的失敗發生兩次後，停止並改進環境、文件、規則或驗證器；以全新的上下文重新啟動。
- 將重複的代理失敗視為系統反饋。改進流程，而不僅僅是當前的答案。
安全地委派
- 僅委派準備好自主運作、有明確邊界的工作。將目標、分解、綜合和簽核保留在主執行緒中。
- 為每個工作者提供一份書面簡報：任務 ID、目標、範圍、限制、驗證命令、預期證據、停止點、升級觸發條件和路由層級。
- 當委派開銷超過其效益時，將微小、緊密耦合或高度互動的工作保留在主執行緒中。
- 對於零例外規則（例如必需的測試、路徑限制、格式化或密碼掃描），優先使用確定性驗證器。
- 強制執行最小權限、信任邊界、秘密處理規則，以及對風險行動的明確操作員批准。
參考資料
- 在建立或修復
pm/時，閱讀 references/file-templates.md。 - 閱讀 references/worked-example.md 以取得一個簡潔的端到端範例。
- 在稽核或救援專案時，閱讀 references/project-rulebook.md。
- 僅針對真正的外部限制或生產發佈風險，閱讀 references/external-constraints.md。
- 閱讀 references/ai-agent-practices.md 以獲取關於持久記憶、上下文、委派、評估和護欄的更深入指導。
- 在將層級映射到產品當前能力時，閱讀 references/agent-routing.md。
- 當來源或易變的供應商指導很重要時，閱讀 references/source-anchors.md。
- 僅載入最小且相關的參考資料。
輸出標準
- 以命令式形式撰寫具體、準備好決策的產物。
- 首先報告檢查點狀態，然後在散文狀態前報告任務 ID。
- 將任務格式化為：
任務 ID、任務、故事、路由、範圍、依賴、完成條件、驗證方式、證據、停止點、狀態。 - 偏好每個任務一個可審查的 diff。
- 將模型名稱保留在持久專案檔案之外。
- 除非專案確實需要，否則不要添加日期計劃、預算、批准工作流程、定期儀式或階段關卡。
- 在使用前，務必根據主要來源驗證當前模型、基準、價格或供應商工作流程的主張。