我想讓 Claude Chat 與 Claude Code 接力，最後卻回到複製貼上

2026 年 5 月，我已經讓 Claude Code 按照 PCM 的流程接手專案。前一篇提到的文件整理，也把部署、架構與程式位置移到適合的入口：需要哪一類知識，就去讀相應的文件。

但知道去哪裡找資料，不代表它能和我把事情談清楚。

當時最讓我不滿意的，是 Claude Code 的溝通方式。我覺得它相當呆板，很難明確說明長期規劃，也不容易和我深入討論。專案還沒決定要往哪裡走，我需要的是來回交流、把想法逐漸說清楚；直接進入實作流程，並不能代替這段工作。

所以，我一直在想：能不能讓 Claude Chat 和我討論，再由 Claude Code 實作？

這個想法並不是拆完文件後才突然出現的。文件如何組織、代理如何和我合作，是當時並存的兩個困難。前一篇處理了知識放在哪裡，這一篇則是我嘗試替對話與實作尋找不同承擔者的過程。

Google Drive 讓分工有了可以嘗試的交棒方式

讓 Claude Chat 負責討論，還有一道很實際的障礙：討論完的內容，要怎麼交給 Claude Code？

在我當時使用的環境裡，Claude Chat 起初沒有這些 MCP 工具，也就是讓 AI 連接外部服務的介面。後來有了 Google Drive MCP，我才想到可以透過雲端硬碟，讓兩個 AI 讀寫同一份檔案。

這樣一來，Chat 討論出的規劃就有地方存放，Code 也有地方讀取；執行後的結果再寫回，下一次討論便能接續專案進度。我想建立的，是能反覆接力的工作方式。

5 月 24 日凌晨，Claude Code 還一度判定 Google Drive 工具不能使用，後來經由 ToolSearch 搜尋並載入工具，才確認 Google Drive MCP 可用。這個發現讓原本的分工構想有了可執行的管道。

當天，PCM 4.0 正式把角色分開：Claude Chat 負責規劃，Claude Code 負責執行，Google Drive 負責傳遞文件。

兩個 AI 要接力，先得建立一套交接規則

可是，能讀取雲端文件，距離能接手工作還有一段路。

Claude Chat 應該交出哪些文件？Claude Code 從哪個資料夾讀？執行完又要把什麼寫回？如果只規定兩個角色，沒有規定交接內容，下一個代理仍然得重新猜測工作狀態。

5 月 24 日清晨，專案新增了兩百二十三行的 chat-pcm.md，作為 Claude Chat 的專用指南。它安排需求訪問、計畫書產出與 Google Drive 上傳；Claude Code 接手後，再執行工作，回寫審查、覆盤與封存資料。五類交棒文件、雲端目錄和雙向同步，也一起被寫進流程。

原本只是希望換一個比較適合對話的 AI，實際上卻先建出了一套文件交接系統。

同一天傍晚，這份 Chat 指南又被併入 PCM 流程中段，獨立檔案刪除，Google Drive 的路徑也簡化一層。這些整理調整了指引與文件的位置，但後來讓我放棄的困難，不只在於入口太多。

我想更新同一份規劃，Chat 卻只能一直新增檔案

回想當時的使用過程，最直接的障礙就是檔案權限。

我花了很多時間確認狀況，最後確認在當時那套 Chat 與 Google Drive 工具配置下，它無法修改既有檔案，也無法刪除檔案，只能不斷新增。規劃有了修正，雲端硬碟裡增加的是另一份文件，舊版卻仍留在原處，逐漸累積成大量舊版本。

這和我原先希望的「兩個 AI 讀寫同一份檔案」差了很遠。要持續合作，計畫就得能隨討論與實作更新；如果每次修正都變成新增副本，接手之前又多了一個問題：到底哪一份才是現在要執行的規劃？

另一個限制是內容的完整性。我當時觀察到，Chat 輸出的檔案會受到容量大小限制，字數受限後，內容也被大幅壓縮。現在沒有保留下來的精確容量數字，但我記得它帶來的問題：規劃即使在對話裡談過，也很難完整地透過文件交給 Code。

我原本就是因為 Claude Code 不容易和我深入討論，才把規劃交給 Chat。結果，負責傳遞規劃的檔案又裝不下完整內容。前面花時間討論出來的細節，到了交接時仍然保不住。

檔案能建立，不等於計畫能被完整、持續地更新與交付。

補齊同步規則，仍然跨不過工具限制

這段使用經驗沒有留下每一次測試的時間與操作紀錄；同期的專案文件，則保存了另一組可以定位的交棒問題。

5 月 31 日，Roadmap 列出三項高優先缺陷：版本文件沒有完整同步、建立 Google Drive 資料夾時缺少父資料夾位置，以及專案上層文件沒有一併同步。

這些缺陷各有具體後果。版本資料缺漏，兩個代理取得的進度就不一致；資料夾位置不明，接手者可能找不到文件；上層文件沒有帶過去，Chat 規劃時能看到的背景又比 Code 少了一部分。

6 月 1 日上午，PCM 4.9 補強了資料夾設定、版本文件與上層文件的同步規則。這些改動處理的是交接規格：哪些資料要傳、放在哪裡、何時寫回。

但規則補得再細，也不能讓當時的 Chat 突然取得修改、刪除既有檔案的能力，更不能保證完整規劃都能裝進輸出文件。同期計畫書還指出另一項限制：Chat 不能直接讀寫最終的 repo，仍須由 Claude Code 承接實作。

到這裡，我要維護的已經不只是專案本身。為了讓兩個 AI 合作，我還得處理檔案版本、內容完整性、資料夾位置和同步範圍。這套交棒方式沒有讓討論與實作順利接起來。

最後，我只在專案啟動時複製貼上一次

6 月 1 日，PCM 4.9 的計畫書已經確定下一版要移除 Claude Chat。約一小時後，PCM 5.0 刪除 Chat 路線，把正式工作流程交回 Claude Code；當天下午，PCM 5.3 又移除 Google Drive 的啟動檢查與同步步驟。

從 5 月 24 日建立雙代理，到 6 月 1 日撤回，這套正式流程只走了八天。

至於我後來實際怎麼做，方法更直接：只有在專案剛啟動、需要討論規劃時，我才使用 Chat。規劃完成後，把內容複製貼給 Code，後面的工作就全部交給 Code，不再持續使用 Chat。

這和原先的構想不同。原本希望兩個 AI 隨專案進展反覆交棒；後來保留下來的，只是開工之前的一次性交接。Chat 仍能用來討論起始方向，但不再是整段專案生命週期中的另一個常駐角色。

複製貼上讓我不必再為這次交接維護一套雲端同步流程。代價是，討論與實作之間的搬運仍然由我處理，後續也沒有繼續維持原本想要的對話分工。當時沒有前後效率量測，不能替這個選擇補上節省多少時間的數字。

我放棄了這套雙代理規劃，卻沒有因此認為「深入討論」不重要。這次嘗試讓我確認：光是把對話與實作分配給不同 AI 還不夠。交接管道必須能保存完整內容、更新既有規劃，並讓接手者辨認現在應該依據哪一份資料工作。

正式流程回到 Code 後，計畫、執行狀態與跨 session 紀錄仍然需要安放。接下來，我們會回到同一時期另一條文件實驗：如果讓代理直接在文件裡推進工作，文件又能不能同時保留可信的歷史紀錄？它與這次分工嘗試的時間有所重疊，不是等雙代理撤回後才開始。