一個 AI 不夠用的時候：認識 Dynamic Workflows

我之前寫過，把重複的事沉澱成 skill，等於給 AI 一份 SOP。一個指令丟下去，它照流程跑完，我不用每次重講一遍。

但用久了會碰到一種事，是一份 SOP、一個助理扛不住的。

比方說，把整個專案的程式碼從頭到尾掃一遍找漏洞；把幾百個檔案逐一改成新格式；查一個需要交叉比對幾十篇資料、還要互相驗證的問題。這些事不是「步驟複雜」，是「量太大」。大到一個 AI 在一場對話裡，根本裝不下。

這就是 Dynamic Workflows 要解決的事。

一個對話的腦容量，是有限的

先講一個容易被忽略的限制，AI 的「記性」在一場對話裡是有上限的。

你可以把它想成一張桌子。對話過程中，所有讀過的檔案、講過的話、做過的判斷，全都攤在這張桌子上。桌子很大，但不是無限大。當你叫它掃一個有五百個檔案的專案，它讀到第三百個的時候，桌子早就堆滿了，前面的東西開始被擠下去。結果就是越做越糊、越做越慢，最後給你一份漏東漏西的答案。

過去的做法是叫「子代理」來幫忙，主 AI 像專案經理，臨時叫一個分身去做一件事，分身做完回報，結論放回主 AI 的桌上。這招對「幾件事」很好用。但如果要做的是「幾百件事」，光是把每個分身的回報都攤在主 AI 的桌上，桌子一樣會爆。

問題不在 AI 不夠聰明，在於協調這麼多分身這件事本身，就把桌子占滿了。

換個做法：請一個工頭，照腳本調班

Dynamic Workflows 的解法很巧妙，它不讓主 AI 親自盯著每個分身，而是先寫一份腳本，把「該叫幾個人、誰做什麼、做完怎麼收」全部寫進去，然後交給一個背景的工頭去執行。

換成工地的畫面會很好懂，

• 子代理，是你臨時叫來幫一件事的工人，做完就走。
• skill，是你貼在牆上的一張 SOP，告訴工人這件事該怎麼做。
• workflow，是一個工頭手上拿著完整的施工腳本，照表調度幾十上百個工人，每個人交回來的半成品它自己收進倉庫，最後只把蓋好的成果交給你。

最關鍵的差別有兩個。

第一，中間的半成品不會堆到你的桌上。五百個檔案的處理結果，工頭自己在倉庫裡管，你的桌面始終乾淨，只會收到最後的總結。

第二，這份施工腳本本身會被存下來。下次要做一樣的事，不用重新交代，把腳本再跑一次就好。而且它在背景跑，跑的時候你照樣可以用同一個 AI 做別的事，不用乾等。

最快的體驗：丟一個問題給 /deep-research

講概念不如直接試。Claude Code 內建了一個現成的 workflow 叫 /deep-research，是不寫程式也能馬上感受的入口。

你丟一個需要查很多資料的問題給它，比方「今年十一月想去日本賞楓，哪幾個點最值得、花期大概什麼時候」。它不會自己憑印象回你，而是當場分成好幾個角度去網路上搜尋，把找到的遊記、官方花期預測、交通資訊抓下來互相比對，每一條說法都投票確認過，最後給你一份標好出處的報告。那種「某篇部落格說現在正紅、其實早就掉光了」沒對上的說法，會被先篩掉。

整個過程在背景跑。你會看到一排分身在那邊忙，而你的對話視窗是自由的，可以繼續做別的。跑完，你拿到的不是一長串「它查了又查」的流水帳，是一份結論。

這就是 workflow 的體感，你出一道題，一整班人馬自己分頭跑完，你只收成果。

它跟 skill、子代理，到底差在哪

這三個都能做多步驟的事，最簡單的分辨方法是問一句，那份計畫表，握在誰手上？

• 子代理：計畫握在主 AI 手上，它一輪一輪決定下一個分身要做什麼。
• skill：計畫寫在那份 SOP 裡，AI 照著它走，但執行還是在主 AI 的桌上一輪一輪來。
• workflow：計畫寫成一段腳本，由背景的工頭執行。迴圈、分支、中間結果，全在腳本裡，不占主 AI 的桌子。

一句話總結規模差異：子代理是「一輪派幾個人」，workflow 是「一次跑幾十到幾百個人」。

什麼時候該升級到 workflow？當你發現「這件事多到一場對話協調不完」，或是「這套調度我想存起來、之後反覆重跑」的時候。

真正值錢的地方：讓 AI 互相挑錯

到這裡你可能覺得，workflow 不就是「一次叫比較多人」嗎？其實它更高一階。

因為計畫被寫成腳本，你可以在腳本裡安排一些一個 AI 自己做不到的品質把關。最實用的兩種：

互相挑錯。第一批分身負責找出問題，第二批分身專門去推翻第一批的發現。一條結論要好幾個分身都駁不倒，才算數。這樣過濾掉的，是那種「聽起來很合理、其實是它腦補」的答案。一個 AI 自己跟自己對話很難做到這件事，因為它會傾向認同自己。

多角度起草。同一個難題，讓幾個分身各自從不同立場各寫一版方案，再請另一批分身評分、挑出最好的，把其他版本的好點子補進來。比起「寫一版、自己改來改去」，這種做法給你的結果可信得多。

這才是 workflow 比「跑更多次」真正多出來的價值，它把「讓多個獨立的腦袋互相驗證」這件事，變成可以照腳本重複執行的紀律。

代價：它很燒，先拿小範圍試水溫

天下沒有白吃的午餐。一個 workflow 動輒叫出幾十上百個分身，同一件事用 workflow 做，會比在對話裡慢慢做燒掉多很多額度。

所以務實的用法是，別一上來就叫它掃整個專案。先挑一個資料夾、或一個範圍很窄的問題試一次，看它跑出來的東西是不是你要的、大概吃掉多少額度，再決定要不要放大。它有內建的上限 ( 一次最多幾百個分身 )，會幫你擋掉腳本失控狂叫人的最壞情況，但額度還是真金白銀，先小後大永遠是對的。

這跟我在 skill 那篇講的「何時不該寫 skill」是同一種克制，工具強，不代表每件事都該動用它。一次性的、範圍小的、一場對話就做得完的事，老老實實對話就好，不用搬出一整班人馬。

從 skill 到 workflow，是同一條路

回頭看，這幾年我寫的其實是同一件事的不同層次。

skill 是把「一個流程」沉澱下來，讓重複的事有固定做法。workflow 是再往上一層，把「調度很多個流程、很多個分身」也沉澱成一份可重跑的腳本。一個管的是「這件事怎麼做」，一個管的是「這麼多事怎麼一起做完」。

說到底都是同一個信念：別讓 AI 每次都從零開始亂跑，而是替它把該固定的東西固定下來。流程沉澱成 skill，脈絡沉澱成記憶，調度沉澱成 workflow。這跟我先前寫的 停止重寫 Prompt，開始設計 Skills 和 我用 Claude 管 Obsidian 的三個月 是接得起來的。模型只是引擎，真正讓它能託付大事的，是你替它蓋的那套環境。

Dynamic Workflows 只是又給了這套環境一塊新的拼圖，當一個 AI 不夠用的時候，你可以叫一整班。

如果你正在把 AI 導入自己的工作流、或想聊聊什麼時候該動用 workflow、什麼時候一場對話就夠，歡迎找我聊聊。