發布於 2026 年 9 月 15 日 · AGENOTE 歷程系列

546 行手冊拆開後，為什麼變成十一個步驟？

第一份 project-lifecycle skill 讓 Claude Code 可以跨 session 接手工作。它也留下了一個明確代價：需求訪問、規劃、審查、部署、覆盤、使用者偏好與專案規則，全都累積在同一份 546 行手冊裡。

直接刪短不是答案。部分規則處理已發生的漏步，另一些防範可預見的風險。若只為減少行數而刪除，先前需要反覆提醒的問題可能回來；若全部保留，每個代理開工時又要讀完整本手冊。

2026 年 5 月 7 日，問題因此從「如何把流程寫完整」變成「如何讓完整流程不必集中在一個入口」。

先保留正式入口，再拆一份實驗架構

重建沒有直接發生在正式入口。當時的 546 行手冊雖然笨重，仍是正在使用的工作規則；在新結構尚未完成前直接替換，進行中的專案可能突然失去原有流程。

因此，5 月 7 日起先建立獨立重建線，盤點現有內容、製作新架構副本並保留回滾可能。這不是證明新方案安全的技術保證，而是把可用的舊入口與尚未成熟的重組工作分開。

盤點也顯示，問題比一份大檔案更廣。代理工作流、可重用工程技巧、完整系統方案與單一專案規則都排在同一層；生命週期手冊裡還混著固定路徑、部署語境與特定技術。Claude Code 不只讀得多，也不容易知道哪一段是跨專案通則，哪一段只在眼前專案成立。

5 月 8 日的早期拆分計畫先採最直覺的方式：把跨 session 接手、文件模板、使用者確認與 skill 萃取拆成不同 skill，主手冊只保留生命週期骨架。

計畫也安排了次序。先處理接手，再做確認協定、文件模板和 skill 萃取，最後才換新版主手冊。這能降低一次改動的範圍，也讓各種責任不再擠在同一份文件。

可是，它仍沿用舊手冊的邊界。原本有一份很大的 project lifecycle，現在只是把它切成數份小文件。這些文件如何共同保存長期工作的狀態、如何讓下一個代理判斷目前位置，仍沒有答案。

同一天，設計問題被改寫成 Project Cycle Management，簡稱 PCM。

PCM 不只服務軟體開發。它要處理的是大型、長期、跨 session，甚至可能由不同代理接手的工作。對話會結束，能留下來的是需求訪問、計畫、審查和覆盤等可重新讀取的文件。

於是另一份方案提出四個「文件產出階段」：檢查、讀取與訪問；規劃與審查設計；執行與驗證；覆盤、技能與同步。每個階段都要寫清楚必讀文件、操作方式、產出、完成條件，以及中斷後如何接續。

文件把這個方向標成「已決策，待落實」。這是一個真實存在、也曾獲決策的候選方案，但它沒有成為正式 PCM 2.0。若只看設計文件，很容易把它與兩天後的最終版本混在一起；Git 顯示正式落地採用的是十一個步驟。

2026 年 8 月重新核對時，我確認：正式採十一個步驟，是我的決策。同期材料沒有完整保存我為什麼放棄四階段，因此不能把後見分析寫成當時原話。

兩套方案的作用差異仍然可以看見。四階段擅長表示工作位於哪一大段；十一個步驟則保留舊手冊裡可逐項確認的節點。對一套剛從 546 行手冊拆出的系統來說，後者比較容易看見原有經驗是否被保留。這是根據結構差異做出的解釋，不是同期動機證據。

5 月 10 日，PCM 2.0 正式落地。十一個步驟依序處理環境檢查、專案接手、需求訪問、規劃、流程分支、執行、驗證與審查、skill 萃取、覆盤、上層文件更新、同步封存。

主 PCM.md 不再保存全部細節，而是負責調度：現在是哪一步、要讀哪個資料夾、何時分支、完成後往哪裡走。訪問指引、規劃模板、審查清單與封存方式則移入 steps/、guides、templates 與 references。

這確實改變了文件責任。要做需求訪問時，設計上不必同時讀部署、覆盤與封存的完整細節。但當時沒有保存前後載入量，不能據此宣稱 token 或接手時間已經下降。

PCM 2.0 同時加入四種規劃模板：版本更新、戰略、模組功能與文件架構。純規劃不必假裝進入程式實作；需要落地的長期方向，則可以再拆成具體版本。

技能庫也由扁平清單改成四個可執行責任層。代理工作流、可重用工程模式、完整系統藍圖與專案專用技能分開保存；00-index 負責索引，90-archive 負責封存。

這次重建確實改善了「所有責任擠在單一入口」的問題。修改需求訪問規則，可以鎖定對應文件；新增工程技巧，也不必再塞回生命週期主文。

然而，主檔變薄不代表整套系統變小。正式重建一次增加了 1,017 行。代理要維護更多檔案、路徑、索引與引用，完整性從單一手冊轉移到整套結構，也把一致性變成新責任。

圖一｜三種拆分方向、正式十一個步驟與新成本

PCM 2.0 很快出現幾項具體修正。skill 索引的更新責任需要重訂；步驟 8 內出現互相矛盾的說明；已不存在的路徑仍被引用。這些問題後來都有修改紀錄，但是否長期不再發生，沒有證據。

跨 session 接手也仍需要推理。Claude Code 要先掃描需求、計畫、審查與覆盤文件，再把文件組合換算成十一個步驟中的位置；開始規劃時選模板，進入執行前判斷純規劃或實作，真正工作時再從技能庫找工具。

PCM 2.0 因此完成的是結構分工，而不是證明整體工作已經更省力。它讓完整性不必再等於「所有內容放進一份文件」，同時產生索引同步、失效引用與步驟定位的新成本。

下一篇的問題就出在這裡：資料已經有位置，Claude Code 仍得自行回答「我現在位於十一個步驟中的哪裡？」PCM 3.0 將不再增加更多頂層分支，而是重新設計工作位置與工具選擇的層次。