Claude Code 開始工作後，我先替它寫了一份完整手冊

2025 年，Claude Code 把語言模型帶進真實的程式專案。它能搜尋與閱讀程式碼、修改檔案、執行測試，也能操作命令列工具。人交給 AI 的不再只是一個等待回答的問題，而可能是一項要在專案裡連續判斷、修改與驗證的工作。

能力進入工作現場後，我很快遇到另一種麻煩。

一段對話可以在同一個 session 裡結束，專案卻會持續數天、數週。下一個 session 開始時，Claude Code 不會自然擁有可靠的專案記憶。它看得懂程式，也有能力繼續做，但我得重新告訴它：上次的檔案存在哪裡、哪些事情已經討論完成、現在做到哪一步、哪些規則不能違反。

專案愈大，需要補回的現場愈多。我不只要重述資料，有時還得在工作走偏後停下來問：「我定的規則為什麼沒有遵守？你是不是又飄移了？」

問題不是 Claude Code 不會做，而是它每次進場時，如何知道自己接手的是哪一個現場，以及這個現場已經累積了哪些決定。

5 月 4 日 20:21：先把工作次序寫成一份 skill

2026 年 5 月 4 日晚上 8 點 21 分，第一份 project-lifecycle skill 被提交。它有 296 行，把一個版本分成前置、執行、收尾三段，再展開成十個步驟。

開工前，代理要確認環境、閱讀上一版覆盤、訪問需求、整理規劃，並等待我確認。執行時，它依規劃修改、提交與審查。收尾時，它寫覆盤、判斷是否有方法值得整理成 skill，最後同步並封版。

這份 skill 也承認一件重要的事：三段工作可以跨越多個 session，不必假裝一次對話就能完成。全新版本、臨時修正、中途接手、功能完成等待收尾，各自有不同入口。

當時的判斷很直接。既然模型不會自動保存完整工作現場，就把共同工作秩序留在專案可以反覆讀取的文件裡。下一個 Claude Code 不必猜測上一輪發生了什麼，而是先讀規則，再從專案留下的痕跡接手。

Git 能證明 296 行 skill 在這個時間點出現，也能證明後續加入了哪些規則。至於我為什麼需要它，則是 2026 年 8 月回看當時工作後的說明：檔案位置、既有討論、規則失守與方向飄移同時增加，沒有一個單獨事故可以代表全部原因。

十三分鐘後，第一版就露出缺口

晚上 8 點 34 分，第一批規則被補進去。

原本的「確認工作分支」仍讓代理自行猜測。新規則改成先問我：沿用現有分支、從主線建立新分支，還是直接在主線工作。分支選擇從代理的預設判斷，變成使用者必須確認的決策。

需求訪問也從對話改成文件。訪問記錄保存我的回答、追加問題、被排除的選項與最後需求摘要，後續規劃、執行和覆盤都要引用它。這處理的是 session 結束後只剩結論、看不到決策過程的問題。

審查則被拆成兩種責任。Claude Code 可以做技術自查，檢查程式與測試；功能是否符合實際使用情境，仍要由我驗收。報告因此需要列出技術結果、待確認項目、遇到的困難與移到下一版的工作，再把我的回應寫回去。

第一個晚上尚未結束，原本的十步清單已開始長成一組可以保存對話決策的文件。

21:17：把合作邊界也寫進流程

晚上 9 點 17 分，需求訪問再次被改寫。

如果 Claude Code 只是逐題問我想做什麼，整理問題的責任仍全部落在我身上。新規則要求它先讀上一輪覆盤，提出自己看到的方向與選項，再由我修正。訪問不再是固定問卷，而是一次只處理一個主題的頭腦風暴；方向與邊界先確認，技術細節稍後再談。

執行中的偏差也被分級。函式名稱或工具選擇等小偏差，可以由代理處理並留下紀錄；實作路線改變但目標不變的中偏差，需要簡短回報；只有增減功能、改動資料結構或影響全局的大偏差，才必須停下等待我決策。

這次修改處理的是兩種相反壓力。所有異常都停下，工作會被切碎；所有事情都讓代理自行決定，專案方向又可能在不知不覺中改變。流程必須明確說出，什麼可以由 Claude Code 判斷，什麼一定要交還給人。

同一輪還加入文件命名、集中存放與使用者偏好。我的訪問習慣、規劃書格式與可接受的停頓時機，第一次被當成工作系統的一部分，而不只存在某段對話裡。

21:28：把 session 中斷改造成重入協定

十一分鐘後，跨 session 接手被寫成三個動作。

第一步，Claude Code 掃描版本資料夾，確認需求訪問、規劃書、審查報告與覆盤是否存在。只有需求訪問，規劃可能尚未開始；已有規劃但沒有審查，工作可能停在執行；已有審查而沒有覆盤，功能也許完成，但收尾尚未結束。

第二步，它讀最後一份文件的狀態。文件存在不代表已完成，也可能正在等待我的確認。

第三步，它把推斷結果說給我聽，例如：「我判斷目前停在審查，這一輪從這裡繼續，對嗎？」取得確認後才開始修改。

這套協定不要求模型記得上一輪，而是要求它檢查工作留下了什麼。2026 年 8 月回看實際使用時，我確認它降低了重新說明現場與糾正接手方向的成本。但它沒有讓 session 永遠延續，也沒有消除方向飄移。改善的是重新拼回工作的成本，不是代理記憶本身。

五天內，缺口與風險持續變成新規則

接下來幾天，規劃、封版、部署與驗收繼續被補進同一份 skill。

規劃書成為沒有例外的必要文件，避免需求訪問完成後直接進入實作，卻沒有整理範圍、驗證方法與完成條件。封版前加入完整檢查清單，避免需求、規劃、審查、覆盤尚未齊全就合併與建立版本標記。若合併後才發現漏件，也不能直接在主線補交，而要回開發分支完成後重新合併。

部署節奏也由最後才同步上線，改為每個功能完成後部署與驗證；最後一步只核對本機、遠端、線上版本與文件是否一致。這項變更是我的決策，Git 能證明改法，卻沒有保存完整同期理由。從機制上可以推測，它讓審查更早取得可驗收環境；沒有前後數據可以證明部署效率因此提高。

這些補寫並非都能追到一個具名事故。有些 commit 明確留下根因，有些只留下差異，另一些處理的是可預見風險。能確定的是，處理方法仍持續回到同一入口。

到 5 月 7 日，296 行首版已增至 546 行。5 月 9 日，我決定把舊檔改成只留下遷移說明的 19 行 stub，工作入口移向新的結構。Git 證明這項動作確實落地，完整取捨理由則沒有被同期保存。

它改善了接手，也製造了下一個問題

第一份 skill 確實做成一件事：它把需要我反覆口述的工作秩序，轉成 Claude Code 可以重新檢查的文件。需求、規劃、審查與覆盤也開始承擔跨 session 的專案記憶。依我的事後使用經驗，重新說明與糾正成本下降了。

但所有修法都擠進同一個入口。生命週期、部署方式、文件模板、使用者偏好、技術注意事項與封版命令逐漸放在一起。代理只需要找到一份文件，代價是每次都要讀到整套內容。

因此，五天後的問題已經改變。我要處理的不是如何再補一條規則，而是如何保留這 546 行累積的經驗，又不讓每個 Claude Code 在每次開工時全部讀完。

下一篇，PCM 2.0 將從三種方案中選擇一種正式結構：拆成小 skill、改成四個文件產出階段，或保留可以逐項核對的十一個步驟。