十一步驟還是太難找路：PCM 3.0 如何把入口收成三個階段

PCM 2.0 把 546 行手冊拆成十一個步驟，需求訪問、計畫、執行、審查與封存也各自有 guides、templates 和 references。不同責任終於不必擠在同一份文件裡。

可是，Claude Code 接手專案時，仍要完成一連串換算。

它先看需求、計畫、審查與覆盤文件是否存在，再判斷目前是第幾步；開始規劃時選擇四種模板之一；進入流程分支時判斷純規劃或實作；真正工作時，再從分層技能庫找出適用工具。

PCM 2.0 並非沒有分支。問題是文件狀態、工作類型與工具位置都要在中央流程裡轉換。工作種類繼續增加時，再補一個分支只能處理下一個已知情境，中央入口也會繼續變複雜。

2026 年 5 月 16 日，PCM 3.0 開始處理這個問題。它沒有把十一個步驟擴成更多項，而是先減少頂層入口，再把細部判斷移到工作發生的位置。

16:51：十一個頂層步驟先收成前、中、後

下午 4 點 51 分，第一個 PCM 3.0 提交將十一個頂層步驟改為前段、中段與後段。

前段處理環境、接手、需求與計畫，出口是一份足以指導後續工作的計畫。中段把修改、推送、部署、驗證與記錄組成反覆執行的迴圈，直到 milestone 完成。後段負責審查、方法萃取、上層文件更新與封存，讓功能完成後仍留下下一個 session 可以接手的狀態。

這次修改刪除 167 行、加入 94 行。行數只能證明結構變短，不能證明工作變快。真正的差異是定位問題改了：2.0 要代理回答「目前是第幾步」，3.0 先讓它回答「現在是在準備、反覆實作，還是收尾」。

三個階段提供較粗的工作座標，文件狀態、工作類型與工具選擇可以分別在更接近使用時機的位置處理。這是設計機制；此時還沒有實際資料證明 Claude Code 因此更容易找到路。

17:24：三十二分鐘後，正式入口恢復 2.0

下午 5 點 24 分，主線恢復 PCM 2.0。提交訊息明確寫下，PCM 3.0 改到功能分支繼續開發。

能確認的是：正在使用的正式入口與尚未成熟的重組被隔離。不能確認的是：當時是否做過完整風險評估，或撤回帶有什麼情緒。同期紀錄沒有留下這些內容。

後續變更則顯示，第一次三階段重排仍缺兩樣東西。第一，不同工作不一定需要走完三段；第二，即使知道自己位於某一階段，代理仍不知道應讀哪份操作文件、使用哪個 skill。

18:43：Route A／B 先判斷是否進入實作

下午 6 點 43 分，Route A／B 被加入 PCM 3.0。

需要修改程式、文件或設定的工作走 Route A，經過前、中、後三段；只形成策略或方向的純規劃走 Route B，在前段完成計畫後直接進入較輕的收尾。

這項分流處理一個具體矛盾：如果所有工作都強制經過中段，純規劃也得製造一段不存在的修改、部署與驗證紀錄。

Route A／B 沒有列舉所有工作種類。它只先回答一個足以改變整條路線的問題：這項工作是否需要實作。Route 後來還會改名、合併並漂移，那是 HIST-07 的故事；本篇只處理它第一次出現時的用途。

19:27：短入口與三份 guide 讓階段可以執行

晚上 7 點 27 分，根目錄建立短 PCM.md。二十二秒後，前段 guide 出現，接著中段與後段 guide 也在幾分鐘內加入。

只有前、中、後三個標題，代理仍不知道每段要讀什麼、產出什麼、何時可以離開。短入口負責辨認工作位置，三份 guide 保存各段的操作、產物與完成條件。三階段到這裡才從分類名稱變成一條可執行的路由。

但工具選擇仍沒有解決。當時的 skill 依工程模式、系統藍圖或專案規則分類；工作階段是另一套座標。Claude Code 即使知道自己在中段，仍要回舊索引，把階段重新換算成工具分類。

5 月 18 日：搬移 skill，再讓 frontmatter 保存適用條件

5 月 18 日正式合併的 PCM 3.0 同時做了兩個動作。

第一，依工作時機搬移 skill。環境與部署準備放到前段，工程與驗證工具放到中段，版本里程碑與 skill 管理放到後段。分類問題從「這是哪一種知識」改為「Claude Code 在什麼時候需要它」。

第二，替 skill 加入 frontmatter。trigger、preconditions、inputs、outputs 與 role 和工具本體放在一起。Claude Code 進入階段後，可以依每支 skill 自己的條件選擇，而不是要求中央 PCM.md 保存所有工具對照。

PCM 3.0 到此形成兩層判斷：前、中、後標示宏觀工作位置；Route A／B 決定是否經過實作；frontmatter 再篩選階段內工具。頂層入口變少，微觀條件則變細。

完成後的 PCM PAPER 曾比較 workflow runtime、向量搜尋與 DAG 執行器，最後保留由語言模型判斷 metadata 的做法。這份 PAPER 可以說明完成後如何理解取捨，不能冒充 5 月 16 日第一次重排時的同步決策。

5 月 19 日：審查不再等到最後才補寫

正式合併後，第一個實際校正發生在 5 月 19 日凌晨。

1 點 1 分，審查報告由後段移到中段；一分多鐘後，中段 guide 同步修改。新的做法是在執行開始時建立審查報告，每完成一輪就追加修改與驗證結果，milestone 全部完成後再定稿。後段因此由五項收尾縮成四項。

同期文件沒有保存完整理由。從 diff 可以確認的是，審查由完成後回顧變成執行中的活紀錄。合理推論是：若報告要保存每一輪修改與驗證，最後才建立仍會依賴代理回憶；移到中段才符合證據產生的時間。

這次移動也說明，文件不能只按名稱分類。「審查」聽起來像收尾工作，但它真正需要伴隨的是每一輪實作與驗證。

3.0 改變了路由，還沒有證明代理不再迷路

5 月 16 日到 19 日的動作形成一條連續路線：十一個頂層入口先收成三階段；正式入口撤回 2.0，讓 3.0 隔離開發；Route A／B 處理是否實作；短入口與 guides 補上階段操作；skill 搬移和 frontmatter 把工具判斷放到階段內；審查移位再依資訊產生時機校正文件責任。

Git 能證明這些結構確實落地。它不能證明定位時間、重入成本、錯誤率或維護工時已下降。大型 skill 不會因搬家自動變小，frontmatter 也可能過時；專案專用工具放在哪裡仍可能產生爭議。

PCM 3.0 真正完成的是路由責任重組：宏觀入口收斂，細部判斷靠近工具。它沒有完成「代理從此不再迷路」這個更大的承諾。

下一個問題也因此變得具體。文件與 skill 即使已按工作時機排列，若 Claude Code 每次進場仍固定讀取大量入口規則，檔案拆分究竟有沒有減少它真正承受的內容？下一篇將進入一個十七小時內先拆、再撤回、最後反向合併的文件實驗。