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