五步框架：把 Workflow 變成可進化的 Skill
整理版優先睇
用五步框架將 Workflow 轉化為可進化嘅 Skill，實現更靈活嘅 AI 自動化
呢篇文章係作者喺 X 上同 pippingg 討論 Dify workflow 同 Claude Code Skills 嘅優劣之後寫嘅。作者認為大部分 workflow 場景其實可以用 Agent + Skills 取代，而唔係大家想像中咁依賴可視化拖拽。佢提出咗一個五步框架——拆分、編排、存儲、分攤、疊代——用自己嘅寫作工作流做例子，示範點樣將傳統 workflow 嘅每個功能節點對應成獨立嘅 skill，再用自然語言描述協作關係。
整體結論係：Skill 架構比 workflow 更靈活、可進化、易分享，尤其適合輸入多變、需要判斷嘅任務。但作者冇一刀切否定 workflow，佢承認喺嚴格審計要求、超高頻簡單任務同非技術用戶可視化呢啲場景，workflow 仍然有優勢。關鍵係要混合使用——確定性邏輯交俾腳本，需要判斷嘅交俾 Agent。
作者仲引用咗 Rakuten、Box 同 McKinsey 嘅案例，證明成本雖然高啲，但整體效率提升遠超 token 費用。而且 skill 係文本文件，可以用 Git 管理版本，甚至讓 AI 自我疊代，越用越好。
- 結論：Agent + Skills 可以取代大部分 workflow，但要混合腳本處理確定性邏輯。
- 方法：五步框架——拆分、編排、存儲、分攤、疊代，將工作流轉化為可組合嘅技能模塊。
- 差異：Workflow 提供確定性但僵化難改；Skill 靈活可進化，但成本更高、門檻較高。
- 啟發：Skill 係可組合嘅資產，AI 可以幫你創建同維護，形成自我疊代嘅自動化系統。
- 可行動點：將自己常用嘅 workflow 逐步沉澱為 skill，用文件系統同 Git 管理，並藉助 AI 持續優化。
五步框架：將 Workflow 轉化成 Skill
1. 拆分：將工作流拆成單一職責嘅 skill 或 subagent。 2. 編排：用自然語言描述流程，條件分支、並行執行、錯誤處理都交俾 Agent。 3. 存儲：所有中間結果保存成本地文件，可追溯、可斷點續傳、可人工幹預。 4. 分攤：Subagent 之間只傳文件路徑，唔傳內容，減少上下文消耗，可以並行執行。 5. 疊代：透過 AI 自動修改 prompt 或流程，持續進化。
文件結構示例
source.md → analysis.md → outline-a.md → draft-outline-a.md → final.md 配圖路徑按目錄組織，與文章關聯。
Workflow vs Skills：一場核心討論
作者同 pippingg 喺 X 上討論 Dify 可視化拖拽 workflow 同 Claude Code Skills 嘅優劣。有人話「80 多個節點嘅 workflow，穩定性和可調整性，唔係 subagent 能比擬嘅」。作者認為呢句說話「對，也不對」。
對嘅地方係傳統 workflow 每次執行結果可預測，出問題可以一步步排查，普通人睇得明流程圖。
唔對嘅地方係好多人低估咗 AI Agent + Skills 架構嘅潛力。作者觀點好明確：大部分 workflow 編排場景，都可以被 Agent + Skills 取代。
- Workflow 優勢：確定性、易排查、合規友好。
- Workflow 硬傷：唔夠強大（節點功能有限）、唔夠靈活（流程定死難應變）、難以移植（平台鎖定）。
五步框架：將 Workflow 轉化為可進化 Skill
作者用自己嘅寫作工作流做例子，演示點樣將每個功能節點對應成獨立嘅 skill。關鍵係理解 skill 唔係單一技能，而係「可組合嘅模塊」，可以用自然語言編排協作關係。
Skill 應該被看作可組合嘅模塊，而唔係單一技能。
- 1 第一步，拆分：將工作流拆成單一職責嘅 skill，例如 article-analyzer、outliner、writer-agent、polish。
- 2 第二步，編排：喺主 skill 入面用自然語言描述整個流程，唔使寫代碼。例如 outliner 會話：「先調用 article-analyzer 分析素材，分析完成後保存 analysis.md，然後根據分析結果生成 2-3 個提綱方案。」
- 3 第三步，存儲：所有中間結果保存成本地文件，例如 source.md → analysis.md → outline-a.md → draft-outline-a.md → final.md，方便追溯、斷點續傳同人工幹預。
- 4 第四步，分攤：Subagent 之間只傳文件路徑，唔傳內容，減少上下文消耗，仲可以並行啟動多個 subagent。
- 5 第五步，疊代：發現 skill 嘅 prompt 唔夠好？讓 Claude Code 幫你改。配合 ralph-loop 等工具，甚至可以實現自我疊代進化。
所有中間結果都保存成本地文件，係可追溯、可斷點續傳、可人工幹預嘅關鍵。
source.md → analysis.md → outline-a.md → draft-outline-a.md → final.mdSubagent 之間只傳文件路徑，唔傳內容，上下文窗口就乾淨好多，仲可以並行執行。
應對三大質疑，同埋適用邊界
有人質疑穩定性、成本同門檻。作者逐一回應，並提出混合架構嘅思路：確定性邏輯交俾腳本，Agent 負責需要判斷嘅任務。
確定性邏輯唔一定要交俾 Agent，可以寫成腳本。例如格式轉換用 format-markdown.ts，skill 調用就得。
關於成本，作者話要「算總賬」：開發、維護、疊代成本都計在內，整體效率提升遠超 token 費用。佢引用咗 Rakuten 同 Box 嘅案例——Rakuten 用 Claude Skills 處理財務報表，原本一日嘅工作變成一小時完成，效率提升 8 倍。
門檻問題方面，作者認為 AI 本身就可以幫你創建 skill。用 /skill-creator 描述需求，Claude Code 幫你生成配置，再微調就得。長期嚟講，skill 係文本文件，可以用 Git 管理版本，比 workflow 更容易維護。
AI 本身就能幫你創建 skill，門檻其實冇想像中咁高。
作者仲劃清咗邊界：Agent + Skills 更適合輸入多變、跨系統協調、需要頻繁疊代、需要分享複用嘅任務；Workflow 仍有優勢嘅場景包括嚴格審計要求嘅合規流程、超高頻簡單任務、非技術用戶可視化需求。
- Agent + Skills 適合：輸入多變、需要判斷嘅任務；跨系統協調；需頻繁疊代；需分享複用。
- Workflow 仍有優勢：嚴格審計合規；超高頻簡單任務；非技術用戶可視化。
可進化係被低估嘅優勢：Skill 可以自我疊代，越用越好，而 workflow 搭好就開始過時。
80幾個節點嘅workflow，穩定同可調整性，唔係subagent可以比得上嘅
上面呢句說話係我喺X上面同朋友 pippingg一次圍繞Dify呢啲可視化拖拽workflow同Claude Code Skills嘅討論。
呢句說話啱，又唔啱。
啱喺邊度？傳統workflow編排的確有佢嘅核心價值——每次執行結果可預測，出咗問題可以一步步排查，普通人亦都睇得明流程圖。呢啲優勢實實在在。
唔啱喺邊度？好多人低估咗AI Agent + Skills架構嘅潛力。我嘅觀點係：大部分workflow編排場景，都可以被Agent + Skills取代。
Workflow編排嘅「舒適區」
可視化工作流工具可以咁流行，係有道理嘅。
拖拽節點、連連線，一個自動化流程就搞掂咗。唔使寫程式碼，改起上嚟亦都直觀。更重要嘅係，佢畀你確定性——節點A執行完一定係節點B，唔會突然跳到節點C。對於需要審計、需要合規嘅業務場景，呢種確定性好重要。
但workflow編排都有硬傷。
佢唔夠強大可視化節點做到嘅嘢有限，複雜邏輯好難表達。
佢唔夠靈活一旦流程定死，遇到輸入變化就容易出錯。你設計嘅流程係處理A類文檔嘅，嚟咗B類文檔，成個流程可能就卡住咗。
佢難移植你整咗個好犀利嘅工作流，想畀人用？匯出匯入一輪操作，仲要喺對方環境度搞半日。平台鎖定效應好明顯。
Agent + Skills嘅「降維打擊」
我嘅睇法可能比較激進：幾乎所有可以用workflow完成嘅AI任務，都可以用Agent + Skills實現。
關鍵在於點樣理解skill。好多人將skill當成單一技能——例如一個skill負責翻譯，另一個負責總結。咁樣用太浪費喇。
Skill應該被視為可組合嘅模塊你可以將多個skill串埋一齊，用自然語言描述佢哋之間嘅協作關係。換句話講，用自然語言去編排工作流，而唔係用拖拽。
我總結咗一個五步框架用我自己嘅寫作工作流嚟演示。
第一步，拆分
將工作流拆成單一職責嘅skill或subagent。每個模塊只做一件事，做好一件事。
以我嘅寫作工作流為例，拆成咗呢啲模塊：
• article-analyzer分析素材，輸出analysis.md• outliner生成2-3個提綱方案• writer-agent根據提綱寫草稿（可以並行啟動多個）• polish潤色定稿
再睇配圖工作流，都係同樣嘅思路：
• generate-image原子技能，調用圖像生成API• article-illustrator組合技能，分析文章內容，喺需要視覺輔助嘅位置生成插圖• cover-image組合技能，基於文章內容生成2.35:1嘅封面圖
然後寫作同配圖又可以組合成一個更完整嘅寫作工作流。
你原本喺workflow工具入面畫嘅每個功能節點，基本都可以對應一個skill。
第二步，編排
喺主skill入面用自然語言描述成個流程。唔需要寫程式碼，就好似同同事交代任務一樣講清楚就得。
例如我嘅outliner技能入面會寫：「先調用article-analyzer分析素材，分析完成之後保存analysis.md，然後根據分析結果生成2-3個唔同風格嘅提綱方案，為每個方案並行啟動writer-agent寫草稿。」
條件分支、並行執行、錯誤處理，都可以用自然語言描述。Agent能夠理解。
再睇article-illustrator嘅編排邏輯：「讀取文章內容，識別需要配圖嘅位置（概念抽象處、資訊密集處、情感轉折處），為每個位置生成圖像描述，調用generate-image生成圖片，最後將圖片插入文章對應位置。」
一個skill可以調用另一個skill，組合出複雜嘅工作流。
第三步，儲存
呢一步特別重要：所有中間結果都保存成本地文件。
三個好處：
• 可追溯出咗問題可以睇到每一步嘅輸出 • 可斷點續傳中途停咗，下次由上次嘅位置繼續 • 可人工幹預唔滿意某一步嘅結果，手動改完之後讓Agent繼續
我嘅文件結構係咁樣嘅：
source.md → analysis.md → outline-a.md → draft-outline-a.md → final.md每一步嘅產出都有跡可循。配圖流程同理，生成嘅圖片按目錄組織，同文章關聯。
第四步，分攤
Subagent之間只傳文件路徑，唔傳內容。
呢條規則好重要。如果你將一大段內容直接塞畀subagent，上下文窗口好快就會爆滿。但如果只傳路徑，subagent自己去讀文件，上下文就乾淨好多。
我嘅writer-agent啟動時只需要三個參數：source文件路徑、analysis文件路徑、outline文件路徑。佢自己讀取內容，寫完之後保存到指定路徑，返回輸出文件路徑。
咁做仲有個好處：可以並行啟動多個subagent。三個writer-agent同時行，各自處理一個提綱方案，互不幹擾。
第五步，迭代
呢個係Agent + Skills相比傳統workflow 最大嘅優勢可以持續進化。
發現某個skill嘅提示詞唔夠好？讓Claude Code幫你改。某個流程步驟可以優化？隨時調整。你嘅skills會越用越好，而唔係整完就放喺度封塵。
呢一點係pippingg喺討論中特別強調嘅：subagent可以自己迭代system prompt，配合一啲自動化工具，甚至能夠完成自我迭代進化。喺token同系統資源充足嘅情況下，呢套系統會變得越來越勁。
正面應對三大質疑
有人會話：你呢套嘢聽起嚟幾好，但……
質疑一：穩定性點算？
呢個係最有力嘅反駁。80個節點嘅workflow的確經過咗反覆驗證，每個分支都測試過，穩定性有保障。Agent呢？每次執行可能行唔同嘅路徑，結果不可預測。
我嘅回應係：確定性邏輯唔一定要交畀Agent。
你可以將需要確定性嘅部分寫成腳本。嗰80個節點入面，有幾多係需要AI判斷？有幾多隻係固定嘅數據處理？固定嘅部分用腳本實現，skill調用呢個腳本就得。
舉個例子，我嘅寫作流程入面有個格式化步驟：將中文引號換成全形、中英文之間加空格。呢種規則明確嘅操作，我寫咗個 format-markdown.ts 腳本。polish技能執行完潤色之後，自動調用呢個腳本處理格式。
Anthropic喺設計Skills時都強調咗呢一點：「Skills可以包含可執行代碼，用於嗰啲傳統編程比token生成更可靠嘅任務。」呢個係混合架構嘅思路：代碼處理確定性邏輯，Agent處理需要判斷嘅任務。兩者各司其職，取長補短。
質疑二：成本太高
冇錯，Agent執行確實更費token。每次調用模型都喺度燒錢，複雜任務可能要調用幾十次。
但成本要計總數。
• 開發成本workflow嘅節點要一個個配，skill可以用自然語言描述。後者更快。 • 維護成本workflow改起嚟要小心翼翼驚影響其他節點，skill改起嚟更靈活。 • 迭代成本workflow優化需要人工分析，skill可以讓AI幫你改進。
幾個案例好說明問題。
Rakuten（樂天） 用Claude Skills處理財務報表，自動處理多個電子表格、捕捉關鍵異常、按公司流程生成報告。原本一日嘅工作而家一個鐘完成，8倍效率提升。
Box 用Skills讓用戶可以即時將儲存嘅文件轉換為PowerPoint、Excel、Word文檔，並自動遵循企業風格指南。為團隊節省咗幾小時嘅手工作業。
呢啲案例說明：token成本喺整體效率提升面前根本唔算咩。而且Skills採用「按需加載」嘅設計——只加載當前任務需要嘅資訊，而唔係將所有上下文都塞畀模型。呢個本身已經係喺度優化成本。
質疑三：門檻太高
將workflow轉化成skill需要抽象能力。普通用戶整可視化流程可以，叫佢寫skill配置文件？太難喇。
但呢個問題正在被解決。AI本身已經可以幫你創建skill。借用 /skill-creator你將需求描述清楚，Claude Code可以幫你生成skill嘅配置。我自己就係咁樣做——好多skill唔係我手寫嘅，係讓AI幫我生成然後再調整。
長遠嚟睇，skill比workflow更容易維護。因為佢係文字檔案，可以用Git管理版本，可以代碼審查，可以喺唔同機器之間同步。Workflow呢？鎖喺平台入面，換個環境就要重新嚟過。
邊界喺邊度
我唔係話workflow毫無價值。兩種方案各有適用場景。
Agent + Skills更適合：
• 輸入多變、需要判斷嘅任務例如處理唔同格式嘅文檔，分析各種類型嘅數據。Agent可以根據輸入靈活調整處理方式。 • 跨系統協調嘅複雜流程需要調用多個API、訪問多個數據源、協調多個工具。Agent配合MCP（Model Context Protocol）可以即插即用地接入各種服務。 • 需要頻繁迭代嘅工作流今日咁樣做，聽日可能要調整。Skill改起嚟比workflow方便得多。 • 需要分享重用嘅自動化邏輯Skill就係幾個檔案，打包畀人就可以用。比匯出workflow JSON再匯入方便得多。
Workflow仍然有優勢嘅場景：
• 嚴格審計要求嘅合規流程金融、醫療呢類行業，每一步操作都要可追溯、可審計。固定嘅workflow更容易滿足監管要求。 • 超高頻執行嘅簡單任務每秒執行幾百次嘅簡單操作，固定腳本比Agent划算得多。 • 非技術用戶嘅可視化需求讓業務人員自己睇得明、自己調整流程，可視化編排確實更友好。
一個被低估嘅優勢：可進化
Skill架構有個成日被忽略嘅好處：佢係活嘅，可以不斷進化。
傳統workflow一旦整好，基本上就定型咗。改動需要人工介入，要小心測試，改完可能仲會引入新問題。
但skill唔同。佢係基於本地文件系統嘅，你可以讓Claude Code幫你維護更新。用咗一段時間，積累咗一啲問題，直接讓AI分析並改進。
更激進啲嘅玩法係pippingg提到嘅：subagent可以自我迭代system prompt。
Claude Code仲有一個好勁但好少人用嘅地方，係可以自己迭代subagent嘅system prompt，配合ralph-loop，已經可以完成自我迭代進化。喺token同系統資源充足嘅情況下，可以進化成非常恐怖嘅存在。
聽起嚟有啲科幻，但已經有人喺度實踐緊。
McKinsey嘅報告都印證咗呢一點：喺一個法律文檔審核流程入面，agent系統會記錄每次人工修正，然後用呢啲反饋嚟改進自己嘅prompt，逐漸將新嘅專業知識編碼入系統。
呢個意味住咩？你投入時間打造嘅skill，會隨住使用越來越好。而唔係好似workflow咁，整好就開始慢慢過時。
將你常用嘅workflow沉澱為skill啦。呢個唔只係換個工具嘅問題，而係喺度積累可重用、可進化嘅自動化資產。
下次有人話「呢個流程太複雜，只能用workflow」，不妨諗諗：真係咁？抑或只係未揾到正確嘅拆分方式？
“80 多個節點的 workflow，穩定性和可調整性，不是 subagent 能比擬的”
上面這話這是我在 X 上和朋友 pippingg 的一次圍繞 Dify 這樣可視化拖拽 workflow 和 Claude Code Skills 的一次討論。
這話對，也不對。
對在哪裏？傳統 workflow 編排的確有它的核心價值——每次執行結果可預測，出了問題能一步步排查，普通人也能看懂流程圖。這些優勢實實在在。
不對在哪裏？很多人低估了 AI Agent + Skills 架構的潛力。我的觀點是：大部分 workflow 編排場景，都可以被 Agent + Skills 取代。
Workflow 編排的“舒適區”
可視化工作流工具能火起來，是有道理的。
拖拽節點、連連線，一個自動化流程就搭好了。不用寫代碼，改起來也直觀。更重要的是，它給你確定性——節點 A 執行完一定是節點 B，不會突然跳到節點 C。對於需要審計、需要合規的業務場景，這種確定性很重要。
但 workflow 編排也有硬傷。
它不夠強大。可視化節點能做的事情有限，複雜邏輯很難表達。
它不夠靈活。一旦流程定死，遇到輸入變化就容易出錯。你設計的流程是處理 A 類文檔的，來了 B 類文檔，整個流程可能就卡住了。
它難以移植。你搭了個很厲害的工作流，想給別人用？導出導入一通操作，還得在對方環境裏調半天。平台鎖定效應明顯。
Agent + Skills 的"降維打擊"
我的看法可能比較激進：幾乎所有能用 workflow 完成的 AI 任務，都可以用 Agent + Skills 實現。
關鍵在於怎麼理解 skill。很多人把 skill 當成單一技能——比如一個 skill 負責翻譯，另一個負責總結。這樣用太浪費了。
Skill 應該被看作可組合的模塊。你可以把多個 skill 串起來，用自然語言描述它們之間的協作關係。換句話說，用自然語言去編排工作流，而不是用拖拽。
我總結了一個五步框架，用我自己的寫作工作流來演示。
第一步，拆分
把工作流拆成單一職責的 skill 或 subagent。每個模塊只做一件事，做好一件事。
以我的寫作工作流為例，拆成了這些模塊：
• article-analyzer：分析素材，輸出 analysis.md• outliner：生成 2-3 個提綱方案• writer-agent：根據提綱寫草稿（可並行啓動多個）• polish：潤色定稿
再看配圖工作流，也是同樣的思路：
• generate-image：原子技能，調用圖像生成 API• article-illustrator：組合技能，分析文章內容，在需要視覺輔助的位置生成插圖• cover-image：組合技能，基於文章內容生成 2.35:1 的封面圖
然後寫作和配圖又可以組合成一個更完整的寫作工作流。
你原來在 workflow 工具裏畫的每個功能節點，基本都可以對應一個 skill。
第二步，編排
在主 skill 裏用自然語言描述整個流程。不需要寫代碼，就像給同事交代任務一樣說清楚就行。
比如我的 outliner 技能裏會寫：“先調用 article-analyzer 分析素材，分析完成後保存 analysis.md，然後根據分析結果生成 2-3 個不同風格的提綱方案，為每個方案並行啓動 writer-agent 寫草稿。”
條件分支、並行執行、錯誤處理，都可以用自然語言描述。Agent 能理解。
再看 article-illustrator 的編排邏輯：“讀取文章內容，識別需要配圖的位置（概念抽象處、信息密集處、情感轉折處），為每個位置生成圖像描述，調用 generate-image 生成圖片，最後將圖片插入文章對應位置。”
一個 skill 可以調用另一個 skill，組合出複雜的工作流。
第三步，存儲
這一步特別重要：所有中間結果都保存成本地文件。
三個好處：
• 可追溯：出問題了能看到每一步的輸出 • 可斷點續傳：中途停了，下次從上次的位置繼續 • 可人工干預：不滿意某一步的結果，手動改完讓 Agent 繼續
我的文件結構是這樣的：
source.md → analysis.md → outline-a.md → draft-outline-a.md → final.md每一步的產出都有跡可循。配圖流程同理，生成的圖片按目錄組織，和文章關聯。
第四步，分攤
Subagent 之間只傳文件路徑，不傳內容。
這條規則很重要。如果你把一大段內容直接塞給 subagent，上下文窗口很快就撐滿了。但如果只傳路徑，subagent 自己去讀文件，上下文就乾淨很多。
我的 writer-agent 啓動時只需要三個參數：source 文件路徑、analysis 文件路徑、outline 文件路徑。它自己讀取內容，寫完保存到指定路徑，返回輸出文件路徑。
這樣做還有個好處：可以並行啓動多個 subagent。三個 writer-agent 同時跑，各自處理一個提綱方案，互不干擾。
第五步，迭代
這是 Agent + Skills 相比傳統 workflow 最大的優勢：可以持續進化。
發現某個 skill 的提示詞不夠好？讓 Claude Code 幫你改。某個流程步驟可以優化？隨時調整。你的 skills 會越用越好，而不是搭完就放在那兒吃灰。
這一點是 pippingg 在討論中特別強調的：subagent 可以自己迭代 system prompt，配合一些自動化工具，甚至能完成自我迭代進化。在 token 和系統資源充足的情況下，這套系統會變得越來越強。
正面應對三大質疑
有人會說：你這套東西聽起來挺美，但……
質疑一：穩定性怎麼辦？
這是最有力的反駁。80 個節點的 workflow 確實經過了反覆驗證，每個分支都測試過，穩定性有保障。Agent 呢？每次執行可能走不同的路徑，結果不可預測。
我的回應是：確定性邏輯不一定要交給 Agent。
你可以把需要確定性的部分寫成腳本。那 80 個節點裏，有多少是需要 AI 判斷的？有多少隻是固定的數據處理？固定的部分用腳本實現，skill 調用這個腳本就行。
舉個例子，我的寫作流程裏有個格式化步驟：把中文引號換成全角、中英文之間加空格。這種規則明確的操作，我寫了個 format-markdown.ts 腳本。polish 技能執行完潤色後，自動調用這個腳本處理格式。
Anthropic 在設計 Skills 時也強調了這一點：“Skills 可以包含可執行代碼，用於那些傳統編程比 token 生成更可靠的任務。”這是混合架構的思路：代碼處理確定性邏輯，Agent 處理需要判斷的任務。兩者各司其職，取長補短。
質疑二：成本太高
沒錯，Agent 執行確實更費 token。每調用一次模型都在燒錢，複雜任務可能要調用幾十次。
但成本要算總賬。
• 開發成本：workflow 的節點要一個個配，skill 可以用自然語言描述。後者更快。 • 維護成本：workflow 改起來要小心翼翼怕影響其他節點，skill 改起來更靈活。 • 迭代成本：workflow 優化需要人工分析，skill 可以讓 AI 幫你改進。
幾個案例很說明問題。
Rakuten（樂天） 用 Claude Skills 處理財務報表，自動處理多個電子表格、捕捉關鍵異常、按公司流程生成報告。原本一天的工作現在一小時完成，8 倍效率提升。
Box 用 Skills 讓用戶可以即時將存儲的文件轉換為 PowerPoint、Excel、Word 文檔，並自動遵循企業風格指南。為團隊節省了數小時的手工操作。
這些案例說明：token 成本在整體效率提升面前根本不算什麼。而且 Skills 採用“按需加載”的設計——只加載當前任務需要的信息，而不是把所有上下文都塞給模型。這本身就是在優化成本。
質疑三：門檻太高
把 workflow 轉化成 skill 需要抽象能力。普通用戶搭可視化流程可以，讓他寫 skill 配置文件？太難了。
但這個問題正在被解決。AI 本身就能幫你創建 skill。借用 /skill-creator，你把需求描述清楚，Claude Code 可以幫你生成 skill 的配置。我自己就是這麼幹的——很多 skill 不是我手寫的，是讓 AI 幫我生成然後再調整。
長期來看，skill 比 workflow 更易維護。因為它是文本文件，可以用 Git 管理版本，可以代碼審查，可以在不同機器間同步。Workflow 呢？鎖在平台裏，換個環境就得重來。
邊界在哪裏
我不是說 workflow 毫無價值。兩種方案各有適用場景。
Agent + Skills 更適合：
• 輸入多變、需要判斷的任務。比如處理不同格式的文檔，分析各種類型的數據。Agent 可以根據輸入靈活調整處理方式。 • 跨系統協調的複雜流程。需要調用多個 API、訪問多個數據源、協調多個工具。Agent 配合 MCP（Model Context Protocol）可以即插即用地接入各種服務。 • 需要頻繁迭代的工作流。今天這樣做，明天可能要調整。Skill 改起來比 workflow 方便得多。 • 需要分享複用的自動化邏輯。Skill 就是幾個文件，打包發給別人就能用。比導出 workflow JSON 再導入方便多了。
Workflow 仍有優勢的場景：
• 嚴格審計要求的合規流程。金融、醫療這類行業，每一步操作都要可追溯、可審計。固定的 workflow 更容易滿足監管要求。 • 超高頻執行的簡單任務。每秒執行幾百次的簡單操作，固定腳本比 Agent 划算得多。 • 非技術用戶的可視化需求。讓業務人員自己看懂、自己調整流程，可視化編排確實更友好。
一個被低估的優勢：可進化
Skill 架構有個經常被忽略的好處：它是活的，可以不斷進化。
傳統 workflow 一旦搭好，基本就定型了。改動需要人工介入，要小心測試，改完可能還會引入新問題。
但 skill 不一樣。它是基於本地文件系統的，你可以讓 Claude Code 幫你維護更新。用了一段時間，積累了一些問題，直接讓 AI 分析並改進。
更激進一點的玩法是 pippingg 提到的：subagent 可以自我迭代 system prompt。
Claude Code 還有一個很強但很少人用的地方，是可以自己迭代 subagent 的 system prompt，配合 ralph-loop，已經可以完成自我迭代進化了。在 token 和系統資源充足的情況下，能進化成非常恐怖的存在。
聽起來有點科幻，但已經有人在實踐了。
McKinsey 的報告也印證了這一點：在一個法律文檔審核流程中，agent 系統會記錄每次人工修正，然後用這些反饋來改進自己的 prompt，逐漸將新的專業知識編碼進系統。
這意味着什麼？你投入時間打造的 skill，會隨着使用越來越好。而不是像 workflow 那樣，搭好就開始慢慢過時。
把你常用的 workflow 沉澱為 skill 吧。這不只是換個工具的問題，而是在積累可複用、可進化的自動化資產。
下次有人說“這個流程太複雜，只能用 workflow”，不妨想想：真的嗎？還是隻是沒找到正確的拆分方式？