AI 協作流大改造：一次從「過度設計」到「返璞歸真」的實驗紀錄
還記得我之前分享過那套讓 Claude 當「專案經理」、指揮 Gemini 當「寫手」的 AI 協作流程嗎？
這兩天，我正式把它投入實戰，用來製作新一期的週報。簡單來說，這是一次從滿懷期待到「差點放棄」的完整體驗。
這篇貼文，就是這次壓力測試的血淚紀錄，主要想分享過程中的試錯、有趣的發現，以及我最終「返璞歸真」的調整計畫。
Day 1：理論完美，現實翻車
第一天，我信心滿滿地啟動了這個「完美」流程。一開始似乎很順利，但就在第一個專題的草稿剛產出時，系統就卡住了——Claude Pro 的用量限額直接觸頂，我被迫停工。
整個下午，我都在進行問題排查。最後定位到一個根本原因：Claude 並沒有如我所願地「授權」給 Gemini，而是把所有重度的工作都自己扛了。
我發現，儘管我在流程文件上標註了「由 Gemini 執行」，但沒有設計一個明確的「轉交檢查點」，也沒有指定它必須使用能將 Token 消耗算在 Gemini 頭上的 clink 工具。結果，這位「專案經理」過於勤奮，自己跳下去當寫手，導致 Token 瞬間燒完。
Day 2：修復後再戰，新的惡夢
經過一下午的文檔修正，我補上了各種檢查點和明確的工具使用指令。第二天，我抱著「這次總該順利了吧」的心情再次測試。
結果，這是一個新的惡夢。
雖然 Claude 終於學會了「轉交」，但新的問題來了：
Gemini 極不穩定：作為「寫手」的 Gemini，API 頻繁出錯，指令發過去，很久才得到一個失敗的回應。這讓整個流程充滿了不確定性。
Claude 限額依然是瓶頸：即使 Gemini 分擔了部分工作，但在大量的溝通、指令傳遞、以及後續的風格修正過程中，Claude 的 Token 消耗依然巨大。我再次因為額度用完，進入了長達三小時的「冷卻懲罰時間」。
最終，我發現自己大量的時間和有限的額度，都花在了「讓系統運作起來」這件事上，而不是真正地「用系統來寫作」。
一個有趣的發現：AI 的「個性」
在這次協作中，我還觀察到一個有趣的現象：單就文字創作風格而言，Gemini 確實比 Claude 更「聽話」。
或許是因為我長期使用，Gemini 似乎更熟悉我的寫作口吻，微調起來很容易。相比之下，Claude 就顯得很有「個性」，即使你明確要求它修正文風，它在答應之後，產出的內容裡，還是會頑固地保留自己的風格。
結論：返璞歸真，重新定義 AI 的「角色」
這次實驗證明，試圖打造一個過於複雜、追求全自動化的 AI 協作系統，至少在現階段是得不償失的。系統的維護成本和溝通成本，遠高於它帶來的好處。
所以，我的下一步計畫是「返璞歸真」，主要有兩個方向：
流程簡化：我不再追求自動串接，而是回歸手動。我會同時開著兩個 CLI 工具，讓 Claude 專心做規劃，產出詳細的執行文檔後，由我親自擔任兩者之間的「橋樑」，將指令手動交給 Gemini 執行。
指令精簡：我會重新為兩個 AI 設計更精要的「角色設定」。捨棄之前那些過於龐大複雜的指示文件，專注於核心、關鍵的規則。目標是讓 AI 能「讀得完、記得住」，在不過度消耗 Token 的前提下，也能最大化地遵循指令，讓整個協作過程更順暢。
這兩天的實驗，讓我對 AI 協作有了新的體悟：在 AI 有限的額度以及可能產生的服務不穩定等狀況下，與其追求完美的「自動化」，不如先建立一套與 AI 之間「溝通順暢」的默契。跟 AI 更好地成為協作的「同事」，而不是直接將自己升級為指揮它做事的「經理」，或許才是更適合目前狀況的做法。
不知道大家在打造自己的 AI 工作流時，有過類似的踩坑經驗嗎？歡迎留言分享！
作者：Roland Zhong