Workflow 跟 Skill 終於分家
Anthropic 最近把 multi-step pipeline（多步驟流程——一個任務拆成好幾關接力做完）這件事做了一個正式版本：Workflow——一份 JavaScript 腳本，runtime（背景的執行器）在背景直接執行，不需要 Claude 邊讀邊跑。
這種需求其實一直都在。我自己的 /content-pipeline（我每天發文用的那條流程，從文章寫好到自動上 Facebook/Threads/LinkedIn）就是用 skill（Claude Code 用的招式檔——一份 markdown，AI 讀完照著做）把 TA audit、proofread、跨平台改寫一路串起來——markdown 寫好流程、Claude 照著跑。反正背後是 LLM 在理解，怎麼串其實都跑得起來。
但官方把 workflow 做出來是因為兩種設計目標。這篇分享：Workflow 跟 Skill 到底差在哪、什麼時候該用哪個、為什麼我的 /content-pipeline 還是繼續用 skill 跑。
如果你在用 Claude Code 跑多步驟自動化（用 skill 串、用腳本拼，都算），這篇給你一條判斷線：中途要不要讓人類看一眼？要 → skill，不要 → workflow。剩下的內容是這條線怎麼來的。
兩件事差在「計畫由誰拿著」
最核心的差別是：誰決定下一步要做什麼。
Skill 是一份 markdown 指令——Claude 讀完之後，每一步都自己決定下一步要做什麼。中間每個結果、每個檔案讀取、每個 sub-skill 的回傳，全部都進主對話的 context（AI 到目前為止記得的所有事）。
Workflow 是一份 JavaScript 腳本——runtime 在背景跑這份腳本，loop、branching、fan-out 全部寫死在程式碼裡。中間結果存在 script 變數，完全不會進 Claude 的 context。
換句話說：兩者都有譜，差別是 workflow 譜上每一步寫死，skill 譜寫的是大方向、Claude 看情況自己判斷。
全表對照
| 項目 | Skill | Workflow |
|---|---|---|
| 是什麼 | Claude 讀的 markdown | runtime 跑的 JS script |
| 誰決定下一步 | Claude 一輪一輪決定 | 腳本寫死 |
| 中間結果存哪 | 主對話的 context | script 變數 |
| 在哪裡跑 | 前景，在聊天裡 | 背景，跟主對話隔開的環境 |
| 並行規模 | 一次幾個 subagent（分身——主 AI 派出去做特定任務的另一隻 AI） | 同時 16、最多 1000 |
| 可以中途等人輸入嗎 | 可以 | 不行（只有權限提示能打斷） |
| 可以續跑嗎 | 不行，要重新來 | 可以，同 session 內 |
| 輸出方式 | 邊跑邊串流到聊天 | 跑完一次給你最終報告 |
靠近 n8n 那一塊
workflow 的彈性位置其實跟 n8n（開源的工作流自動化平台）差不多——多步驟、可平行、可續跑、節點之間傳資料。差別是寫 JS 腳本而不是拉節點，整個 runtime 直接跑在 Claude Code 裡。
n8n 發展好幾年，整合多、UI 完整、社群也成熟；workflow 還在 research preview，現在更像是程式版本的雛形。但兩者解的問題類別非常接近。
為什麼 /content-pipeline 還是繼續用 skill
它跑起來其實長得很像 workflow——一連串 sub-skill 接力（TA audit → platform-adapter → crosscheck → image-slides → publishers），總共 8、9 個階段。
「那 Anthropic 既然推 workflow 了，我是不是該改寫一下？」，答案是不用。
關鍵在那幾個 整條流程靠它撐住的人工確認點：
- proofreading 改完之後我要看 diff，看 AI 有沒有把語氣改壞
- image-slides 跑完我要看圖，看有沒有抓到重點
- publisher 上線之後我要確認那是不是真的對的那篇貼文，才能接著去留首則留言
這些都是「中途要讓人類看一眼」的點。Workflow 設計上做不到——它只能在權限提示時暫停，沒辦法因為「我想看一眼」而停。
換成 workflow 之後，全流程跑完比較快沒錯，但「能在中途攔下壞改寫」這件事就沒了。我寧願慢一點。
再加上 context 管理這層——我 /content-pipeline 每個子任務都是 spawn 一隻 agent 出去跑，TA audit、proofread、image-slides 的中間結果都不會塞回主對話。workflow 把中間結果存在腳本變數、不塞回 context 這個副產品，對我這條 pipeline 來說早就已經省下來了。
那 workflow 適合做什麼
Anthropic 內建了一個 /deep-research 作示範——丟一個問題進去，它自己 fan-out 一堆 web search，找來源、跨來源 cross-check、過濾沒通過驗證的 claim、最後給你一份引用完整的報告。整個過程就一次背景任務，session 還是可以做別的事。
對照我自己的專案，比較適合 workflow 的場景：
- 跨檔案的 codebase audit——「找出每一個自己 reimplement CDP / manifest / scrape 的 script，列出可以抽出去 lib/ 的候選」
- 大規模 migration——「把這 100 多個 source.md 統一改成新的 title format」
- 深度研究——「把 Threads 演算法相關的近半年研究整合起來」
共通點：讀很多、決策很多、平行做得起來、過程中不用人類干預。
也理解為什麼 workflow 這波沒被捧上天
跟之前幾波熱門更新比，workflow 這波感覺沒那麼熱。我猜原因是它解的痛——多步驟編排寫成可重跑的腳本、平行 fan-out、context 隔離——對 power user 來說都不是新東西。要平行大家有自己腳本；context 隔離大家早就用 subagent 解了；要編排可重跑，markdown skill 也已經能撐住八成的場景。
加上我平常用 skill 跳步驟、中間漏掉這種事其實也很少發生——markdown 流程寫清楚 Claude 就會照著走。沒有「失控」的痛，自然也沒有「workflow 救命」的衝動。
但這不代表 workflow 不重要——它把這些原本要自己造輪子的事做成官方、可分享、可重跑的腳本，門檻會降很多。對沒在造輪子的人來說，是個有感的便利。
還有幾個想到的點
1. 「不能中途問使用者」可能有灰色地帶。 官方文件明說 workflow runtime 沒有 mid-run user input checkpoint，只有 subagent 的 permission prompt（用到未授權的 shell command / web fetch / MCP 工具時跳出來的授權詢問）可以打斷一次 run。但我跑官方 workflow 時還是會在中間被問問題——可能是這類 permission prompt、也可能是主對話的 Claude 在背景 workflow 跑的同時順手問我（workflow 在背景跑、主 session 仍然可用）。文件講的「沒有 mid-run user input」是 workflow runtime 層的事，agent 跟主 session 還是有空間。
2. JS 寫的所以邏輯可以很複雜。 Workflow 不只是把多個步驟串起來——可以根據前一步的結果決定下一步、條件跳過某些 stage、while loop 跑到滿足條件才停、動態調整 fan-out 數量。markdown 描述的 skill 不太好做這些。
3. 大膽想：頭尾相接的 workflow 是不是一種 ralph-loop？ ralph-loop 是「讓 AI 在背景一直跑、自己決定下一步直到任務完成」的那種模式。Workflow 一次上限 1000 agent 沒錯，但只要把單一 cycle（一輪：派分身去做事 → 收結果 → 決定下一輪要不要再來）控制在幾隻 agent，理論上可以在一次 workflow 裡跑幾百個 cycle——workflow runtime 內建類似 token budget（AI 一次能用的字數額度，跑超過就停）的鉤子可以控制跑到什麼程度才停。ralph 的形狀就已經在那裡，只是換個 runtime 跑。
順帶一提：Ultracode
跟 workflow 一起推出的還有 /effort（Claude Code 裡選 AI 認真程度的選單）多一個新層級——Ultracode。打開之後 Claude 會在每個任務自動判斷要不要起 workflow，不用你主動講「跑 workflow」。留到明天細聊。
一個簡單的判斷題
下次要寫一個多步驟自動化的時候，先問自己一個問題：
中途要不要讓人類看一眼？
要 → skill。可以一步步停下來、可以根據前一步結果調整下一步、可以即時改主意。
不要 → workflow。一次背景跑完、省 context、可平行、可續跑、最後給結論。
很多人（包含我自己一開始）會把「多步驟」直接等於「workflow」。其實多步驟只是表象——真正的差別是計畫由誰主控。
一句話總結：workflow 把每一步寫死所以更穩定、skill 把判斷留給 Claude 所以更彈性。
Sources:
- Claude Code Workflows 官方文件：https://code.claude.com/docs/zh-TW/workflows