Skill 是方法論工作流是流程市場上對 Skill 有幾種不同的認知。前幾天騰訊開發(fā)者論壇發(fā)了一篇文章說 Skill 是帶文檔的腳本。但根據(jù)我的經(jīng)驗這個定義太窄了。今年年初 Gemini CLI 的 GitHub 上有一個 issue #15895對 Skill 給出了一個非常好的定義Skill 是方法論不是腳本加文檔。這句話非常好地總結(jié)了我之前的經(jīng)驗。我在 Dify 和扣子上都開發(fā)過工作流也深度使用過各種 Skill。從實際使用的角度來說它們之間有許多使用上不能忽視的區(qū)別維度工作流WorkflowSkill本質(zhì)流程方法論AI 視角黑盒只看到單節(jié)點白盒全貌可見靈活性固化不可逃逸可裁剪、可干預維護節(jié)點多時困難按需加載輕量AI 角色語義工具局部調(diào)用全局編排者工作流有向無環(huán)的黑盒工作流是一個帶有明確流程限制的有向無環(huán)圖DAG它意味著不能從一個節(jié)點在沒有路徑或連接線的情況下直接跳到另一個節(jié)點必須沿著預設的流程走。禁止回邊開始條件判斷 A條件判斷 B執(zhí)行節(jié)點 A1執(zhí)行節(jié)點 B1合并結(jié)果對絕大多數(shù)用戶來說工作流是一個黑盒。你感覺不到它到底是 10 個節(jié)點、20 個節(jié)點還是上百個節(jié)點——只有開發(fā)者才需要關(guān)心這些。用戶只管用但很難了解內(nèi)部到底有哪些流程、哪些異常分支、哪些地方需要人工介入。優(yōu)點是流程固化。用戶不會從流程中逃逸出去可以得到確定性的結(jié)論不會出現(xiàn)完全異常、無法控制的結(jié)果。缺點也很明顯。當工作流超過幾十個甚至上百個節(jié)點時維護起來會非常困難。工作流天然需要腳本作為粘合劑把節(jié)點的輸入輸出對接起來——上一個節(jié)點的輸出就是下一個節(jié)點的輸入中間有大量的膠水代碼。AI 在工作流中的作用只是其中某幾個需要智能判斷的關(guān)鍵節(jié)點沒有承擔整個流程的規(guī)劃也沒有總攬全局僅僅作為一個語義工具被調(diào)用。Skill白盒的方法論Skill 會被加載到 AI 的提示詞中。AI 先閱讀 Skill然后按照 Skill 來執(zhí)行相應的步驟。它知道整個 Skill 從開始到結(jié)束會經(jīng)過哪些流程、有哪些步驟知道哪些地方需要用戶確認、哪些地方允許用戶選擇甚至知道怎么讓用戶退出以及如何把步驟交接給下一個 Skill。對 AI 來說工作流是黑盒的它只能看到一個節(jié)點但 Skill 是完全的白盒。加載Skill 方法論 · 全部可見步驟1讀取需求步驟2分析數(shù)據(jù)步驟3生成方案步驟4交付結(jié)果步驟5沉淀復盤AI · 加載、編排、調(diào)度因為 AI 看到的是完整的方法論而不是單個節(jié)點所以它可以靈活地選擇執(zhí)行方式完整執(zhí)行按步驟 1→2→3→4 走完部分提取只取其中一兩個步驟跳過不需要的環(huán)節(jié)用戶裁剪按用戶指令修改某一步驟調(diào)整后再繼續(xù)AI 閱讀 Skill 方法論完整執(zhí)行部分提取用戶裁剪1 → 2 → 3 → 4全部執(zhí)行跳過 1、4只取步驟 2 和 3步驟 3 被修改為 3按用戶指令調(diào)整這種靈活性就是方法論的本質(zhì)它是一套經(jīng)驗性的指導原則讓你學習并可選擇性地使用它。什么時候選哪個當你作為一個開發(fā)者或者專業(yè)用戶需要寫 Skill 或流程的時候你要先判斷這是一個方法論還是一個流程這個問題的核心區(qū)分是控制權(quán)歸誰需要確定性、自上而下管控的場景公司審批鏈路、數(shù)據(jù)處理管道、固定業(yè)務流程——工作流更合適。流程固化的價值在于不需要使用者做選擇也不會有人從流程中逃逸。面向個人或團隊效率提升的場景——Skill 更合適。因為很多時候我們不能強迫別人方法論的意義在于讓專業(yè)用戶理解后自愿遵循而不是被流程綁住。對專業(yè)使用者先用后改Skill 的使用者通常是或者說“需要是”專業(yè)用戶。這和工作流的使用者有本質(zhì)區(qū)別——工作流不需要你理解你只要照著走就行但 Skill 的使用者需要理解方法論才能用好它、改好它。如果你拿到了別人寫的 Skill首先當然可以用它來完成工作。但更重要的是你可以選擇忽略或修改 Skill 中的某些步驟干預它讓它按照你的想法執(zhí)行。你可以裁剪 Skill把它改成你想要的版本。市場上大部分 Skill 都代表了作者個人的見解和經(jīng)驗。如果你想讓它完美符合你個性化的工作流你需要對原來的 Skill 進行修改發(fā)明自己的 Skill。這是方法論的終局——不是照搬而是內(nèi)化后重造。還有一個隱含的因素你需要讓 Skill 反過來教會你這套方法論。Skill 的使用者需要了解這個 Skill 是怎么用的才能真正駕馭它。一個值得注意的趨勢讓 AI 參與全流程之前我聊到過 Compound Engineering 這個插件它做了一件非常激進的事把子智能體sub-agent的調(diào)用完全改成了純粹的 Skill markdown。其中有一個重要的理由調(diào)用子智能體時某些上下文、工具調(diào)用結(jié)果或 harness 的結(jié)果無法傳遞到子智能體而且各家平臺對智能體的實現(xiàn)方式也不統(tǒng)一。子智能體本質(zhì)上是把 AI 關(guān)進了一個個黑盒彼此看不到對方的上下文。與其費力解決跨智能體的信息傳遞不如讓所有智能體都變成 Skill 的模式——這樣可以直接復用完整的上下文和 harness 結(jié)果模型在整個流程中的表現(xiàn)會更加優(yōu)異。這背后其實就是白盒的紅利打開可見度AI 看到的信息越完整表現(xiàn)就越好。子智能體的調(diào)用模式相當于把流程重新切成黑盒節(jié)點而 Skill 模式把整個方法論和全部上下文都暴露給 AI讓它在完整可見的基礎上做判斷和調(diào)度。這個過程中Skill 是一本經(jīng)驗性的手冊初期可以發(fā)揮作用在更加長程的任務中讓它自己判斷比經(jīng)驗更重要。