挖掘技能的全新可能性

TL;DR 摘要

AI Agent 的技能不只要能執行任務，更要能被可靠觸發、組合、驗證與持續改善。數據決策股份有限公司技術長尹相志以 skillOps Studio 示範，如何把技能開發提升為生命週期管理：透過單一入口路由與動態工作流協調能力，以六項指令要件建立控制力，再藉由人類選擇的融合與負案例驅動的進化，持續補足技能。這套機制呈現完整的管理思路，但示範仍帶有個人使用情境，部分套用與平台相容性問題也尚待處理。

技能管理全貌：從建立到退場的 skillOps

Skill 的核心不只是記錄經驗，而是把專業方法與操作控制力交給 agent。尹相志認為，專業表現的差異在於每個動作能被控制到什麼程度；因此，憑個人經驗撰寫技能，或透過 Skill Creator 建立符合格式的技能，都還不足以保證文字指令與規則具有足夠的控制力。

格式合規是基本要求，但不能等同於規則有效。技能投入使用後，還可能遇到能力不足、需要修改，或輸出不如預期等問題。這些問題需要持續維護，不能只靠初次建立技能時一次解決。

skillOps 是將技能視為一個需要維護的生態，管理其從建立、改善到退場的生命週期。尹相志實作的 skillOps Studio，本身就是一個管理技能生命週期的技能，以統一入口串接十個功能模組，而不只是技能生成工具。

「是我寫好的一個管理技能的生命週期的技能」
— 尹相志

• 建立與調整：涵蓋新增、修改、刪除與分割，讓技能能隨需求變化調整。
• 融合：當既有能力不足時，選擇同一領域其他技能的長處來截長補短，而非盲目合併兩份內容。
• 持續改善：透過 Evolution 或 Optimization 改善技能，兩者所需的輸入與改善方式不同。
• 評估驗證與安全性 audit：除了檢查技能，也檢查引用內容與輸出中的惡意程式碼風險。
• release life cycle：涵蓋打包發布、遷移與退場，並納入技能包壓縮等部署相關處理。
• agent instruction governance：補強部署後的觸發要求，讓特定行為不只依賴 agent 自行判斷是否使用技能。

Evolution 以負案例作為改善起點，也就是執行失敗或未達預期的案例。人類需要標註案例不足之處，讓不理想的輸出成為後續修改的依據。這條路徑著重於把實際使用中發現的問題，轉化為可持續改善技能的材料。

Optimization 則採用講者所述的 Skill up 概念，使用一整包資料集，搭配明確的連續數值或 flag，透過類似深度學習 Optimization 的方式進行優化。相較於以標註負案例推動的 Evolution，這種方式需要較大量的資料，因此講者較少使用。

安全性與觸發治理處理的是不同風險。安全性 audit 著重於融合或引用其他技能時，檢查輸入與輸出是否包含惡意程式碼；agent instruction governance 則處理「技能已部署，卻不一定會被使用」的問題。對於必須觸發技能的特定行為，講者會將相關要求寫入 agents.md，以補強 agent 的行為控制，而非只放入技能後便交由它自行判斷。

這套 skillOps Studio 呈現的是講者依自身需求建立的技能管理框架：技能寫完後，仍要持續處理能力調整、使用回饋、安全檢查與部署維護。它提供具體的管理思路與工具實作，但不應因此視為已驗證、適用所有環境的通用標準。

路由與動態工作流：用 Studio 統整領域能力

技能拆得越細，不一定越容易命中正確任務。當使用者提出「做一份投影片」這類通用需求，多個細碎技能可能同時競爭觸發窗口，增加錯誤喚醒的機會。講者提出的 Studio 設計，改由同一 Domain 的單一入口承接需求，再透過內部路由分派子模組，將領域入口與具體能力分開管理。

路由型 Skill 的中央只有一個 SKILL.md，主要負責判斷何時應分派到哪個子模組。子模組原本可以是獨立的 Skill，但在這個架構中，會將其 SKILL.md 改為 reference.md，避免由外部直接觸發，只能透過統一入口派送。這讓各項能力不必各自爭取喚醒機會，而由中央入口統整調度。

路由並不是預先列出所有固定路線，而是根據任務意圖、目前狀態與可用能力，選出所需的子模組，動態組成工作流。以 Slide Studio 為例，與投影片有關的需求都由同一入口接收，但不同起點會需要不同流程：

• 既有投影片要套上母片：以現有投影片為起點，尋找完成套用所需的能力。
• 從無到有製作投影片：依尚未建立內容與投影片的狀態，組合所需步驟。
• 已有內容要轉成投影片：以既有內容為輸入，安排轉成投影片所需的能力與流程。

「它並不是寫死的，就只有哪些路線可以走，它可以動態的去組裝出來。」
— 尹相志

動態組裝完成後，執行方式仍是共享工作狀態的線性工作流：各步驟依序推進，並將必要的前置檢查、後置檢查與評估納入流程。動態指的是依需求選擇與安排能力，不代表省略執行順序或交付檢查。

• 交付物通過檢查：完成交付。
• 交付物未通過：回到路由，判斷需要哪些修正能力，重新組成修改工作流，再執行與檢查。
• 需求與現有子模組的能力無關：直接退回，不勉強安排不適用的流程。

Studio 也可作為技能管理的設計參考：擴充時先檢視輸出或流程缺少什麼，再增加對應子模組，補足領域能力範圍。這種做法不是持續增加互相競爭的獨立入口，而是保留統一入口，讓內部能力隨實際需求擴充，並由路由決定如何組合使用。

技能的組成：讓不確定推理搭配可重用執行

技能的組成不只是提示文字，而是把方法論、執行步驟與可驗證的操作安排在一起。instruction 負責向 agent 傳達方法論、步驟與 SOP；需要外部脈絡時，還必須交代在什麼情況下，透過 reference.md 參考哪一份外部檔案，讓資料讀取有明確時機與用途。

執行方式則需要區分 LLM 推理與程式操作。講者指出，LLM 的操作帶有隨機性，不能期待每次都得到固定答案；但某些專業操作需要穩定結果，就應盡量交由已測試有效的程式執行，而不是每次重新請 AI 生成程式。

• instruction：說明方法論、步驟與 SOP，讓 agent 知道如何執行任務。
• reference.md：承接外部脈絡，並在指令中交代何時需要讀取、應參考哪個檔案。
• script folder：保存已確認可用、測試有效的程式，供後續重複使用，降低反覆生成程式帶來的風險。
• 可重用素材與驗證規格：與指令、參考資料及程式搭配，讓技能不必每次從頭建立執行與檢查所需的內容。

驗證也不能只依賴 agent 自評。講者在開發時，曾列出大量 checklist，要求模型逐項檢查自己的行為，卻反覆取得百分之百通過的結果，未能藉此辨識錯誤。這是他在該次開發中的觀察，不能據此推論所有模型或所有自評方式都必然無效；但這段經驗促使他調整驗證設計，不再把自評通過視為充分證據。

「然後我們盡量讓評估這件事情，變成是一個程式碼，確定性的，過或不過。」
— 尹相志

調整後的做法，是把適合明確判定的細部結構交給程式檢查，產生可重複確認的通過或不通過結果。這也有清楚的能力邊界：結構檢查不等於語意品質驗證，不能因為程式判定通過，就認定內容的意義與品質也已獲得保證。確定性檢查的價值，在於讓能被明確定義的規則有可靠的判定依據，而不是取代所有判斷。

指令控制六要件：把規則與例外條件寫完整

高控制力的指令，不是把 MUST 寫成大寫，或用更強烈的語氣要求執行，而是把規則可能被跳過的缺口補齊。除了要求做什麼，還必須交代觸發條件、禁止情境、失敗處理、衝突時的優先順序，以及完成證據，讓執行與例外都有明確界線。

• 何時觸發：明確界定啟動規則的條件。
• 該做什麼：說明觸發後必須執行的動作與範圍。
• 何時禁止：列明即使有執行需求，也不能採取該動作的情境。
• 失敗如何處理：交代執行失敗時的處理與退回路徑。
• 規則衝突聽誰的：明確指定規則互相衝突時的優先順序。
• 如何證明完成：要求能夠證明規則已被履行的完成依據。

這六個面向需要同時閉合，不能只寫一條強制要求，再把其餘判斷留給 agent。講者特別提醒，模糊的條件句或「視狀況決定」容易留下繞過規則的空間。重點不是不能使用條件，而是條件必須具體，不能以未定義的裁量取代明確界線。

「永遠要把你開放的這個洞，寫清楚開放的條件。」
— 尹相志

infographic 的文字方塊限制，是規則放寬的具體例子。為避免畫面變成貼滿文字的便利貼牆，原本規定最多只能放五個文字方塊。但內容確實可能需要更多文字，因此設計重點不是完全禁止放寬，而是寫清楚何時可以放寬、放寬到哪裡。

• 預設限制：最多五個文字方塊。
• 放寬條件：圖中物件的語意數量超過五個，才允許文字方塊多於五個。
• 放寬上限：即使符合條件，文字方塊仍不得超過十個。

「以五個為準，視情況增加」並不足以構成可控的例外，因為是否增加仍交由 agent 自行判斷。以物件語意數量超過五個作為觸發條件，再加上十個的上限，才把開放條件與開放範圍具體化。

不過，觸發門檻與數量上限仍不是完整規則。放寬時還要列明哪些情況禁止使用例外、失敗後如何退回、與其他規則衝突時聽誰的，以及如何證明完成。這些要求同樣適用於例外規則，不能因為是放寬限制，就省略其餘控制要件。

instruction control audit 用來逐條檢查規則是否具備足夠控制力，確認上述六個面向是否閉合。檢查重點不只是措辭是否強硬，而是每條規則的條件、行動、禁止事項、失敗處理、優先順序與完成證據，是否共同構成清楚的執行邊界。

「永遠要把你開放的這個洞，寫清楚開放的條件。」
— 尹相志

選擇性融合：用差異與證據決定如何截長補短

技能修改不只是版本控管，更要能說明改了什麼、為何要改，以及如何證明修改有效。講者提出的管理方式，是先比較修改需求與既有技能的差異，限定最小修改範圍，再保存修改前後的內容與相關輸出證據，避免為了補足一項能力而造成不必要的大幅影響。

融合是這套修改管理中的一種操作：先辨識兩個技能各自的能力與差異，再由人決定哪些值得納入。重點不是把兩份文字直接合併，而是以既有技能為基礎，有選擇地截長補短。

示範應用程式的核心仍是 skillOps Studio，前方只加上一層薄 UI，方便使用者整理必要輸入。介面提供技能來源選擇，可從 Codex、Claude Code、Hermes 或 local 尋找技能；此次示範採用 local。介面提及的 LLM 來源則包括 OpenAI、Anthropic、Codex 的訂閱、Ollama 與 OpenRouter，這些來源選項與待融合的技能來源是不同設定。

示範以較舊的 PPT Maker 作為基礎，與較完整的 Slide Studio 比較。前者主要負責製作投影片，後者涵蓋較完整的投影片內容與製作流程。兩者先進行能力主張分析，把內容差距整理成差異表，而不是選好資料夾後就直接合併。此次使用同一台電腦上的兩個技能是為了示範；講者原本設想的用途，是引入外部技能的長處。

• 新增：對方具備、原始技能尚未具備的能力，由人決定是否納入。
• 強化：雙方都有的能力，但對方的做法更完整或更強，由人決定是否採用。
• 衝突：雙方做法不一致的項目，需由人判斷新技能應採取哪一種做法。

「你要想要融合出一個自己覺得最好的，那你必須加入你自己的判斷。」
— 尹相志

此次比較產生七種新增能力、九個強化與八個衝突。使用者逐項選擇要新增、強化或解決的內容後，系統才依原先選定的基礎技能，加上這些選擇，組成新的技能。這些數量只代表當次 PPT Maker 與 Slide Studio 的比較結果，並非融合流程的固定規格。

負案例進化：把未觸發轉成可審核的修補建議

負案例進化的重點，是把「技能應該觸發卻沒有觸發」轉成可追查、可審核的修補依據，而不是直接要求系統重寫技能。Human in the Loop 也不能只靠增加人工關卡：若審查者未實際檢視內容，流程仍可能流於橡皮圖章。講者以現場轉述的行銷審核情境提醒這項風險；該情境並非經查證的事件紀錄，重點在於人工參與不等於實質把關。

示範使用涉及歷史傷口的內容，檢查專門處理這類風險的 Harm Aware Editor 是否會被喚起。講者先發現所選環境未安裝該技能，再把內容放到 Codex 環境重試；依現場判斷，技能仍未觸發。輸出雖提出避免歡慶、應予尊重等提醒，但講者認為處理力度不足，也未真正啟用預期的技能，因此將這次失敗轉為 Evolution 的負案例。

• 保留失敗輸出，將問題明確標註為「應觸發而未觸發」，並指定應被喚起的 Harm Aware Editor，讓修補有具體案例與對象。
• 系統先將案例 Normalize，整理可供分析的內容，再檢查指令控制六要件是否存在缺口，以及 Description 是否清楚界定技能的能力邊界。
• 分析結果先形成修改建議與 PMtch，呈現建議調整的部分，不直接改寫原有技能。
• 由人類檢視建議，確認可接受後才回填、套用到技能內容。人工判斷保留在實際變更之前，而非僅在流程末端形式上批准。

「它不是直接去修改它，直接給你一個修改建議。」
— 尹相志

現場已展示 PMtch 與套用操作，但套用時出現小問題，因此這次示範呈現的是負案例進化的機制與操作路徑，不能視為修補已完整成功驗證。這套偏向個人化使用的技能優化管理機制，提供了從失敗輸出、缺口分析到人工確認的具體方法；實際使用時，仍須依環境確認技能是否正確觸發，以及套用修改後是否真正改善原先的失敗。

交付前驗證：用契約、回歸測試與視覺檢查把關

融合或進化後的技能，仍須經過評估才能交付。評估不只確認格式，也要檢查準確度、效度、reference 孤兒檔案與能力邊界；部分小型格式問題可由工具協助調整，再產生最後的技能內容。修補完成不等於效果能持續成立，因此失敗輸出也必須保留，作為後續驗證的依據。

「因為只要你要把這個東西交付給人類，你都必須要做一次評估。」
— 尹相志

負案例除了能用來推動技能進化，也應在修改後保留，進行二次測試，確認相同錯誤沒有再次出現。這讓負案例不只是一次性的修補材料，也成為防止錯誤回歸的測試依據。

講者將檢測分成三個層級，其中 skillOps Studio 處理前兩項：結構檢查與工作流模擬。這兩項分別確認技能包是否符合規範，以及流程中的輸入、輸出與最終結果是否符合約定。

• 結構檢查：確認格式與結構符合規範，並檢查檔案大小及數量是否合規。
• 工作流模擬：以 schema 明確約定各功能接受哪些輸入、應產生哪些輸出，作為檢查流程是否符合要求的依據。
• 證據保存：將線性工作流各步驟的結果存入 state，完成後可據此檢查最終輸出，而不只依賴口頭描述或完成宣告。

這套做法的核心是把功能之間的關係寫成可檢查的契約。schema 定義預期輸入與輸出，state 則保存執行結果，讓流程留下可核對的證據。是否完成任務，不能只看流程有沒有跑完，還要比對最後交付的內容是否符合要求。

交付前的必要檢查由 preflight 子模組承接。以投影片為例，僅完成程式撰寫與 render，仍可能留下箭頭偏移、物件遮蓋等版面問題；這些問題需要檢視實際產出的畫面，而不是只檢查生成它的程式。

• 投影片製作完成後，先轉成圖檔，再進行視覺檢視。
• 確認畫面沒有需要退回修正的問題，再交付給人類或進入新版發布。
• 視覺檢查針對實際呈現結果，不等同於只靠 checklist 宣告各項皆已通過；內容仍由講者逐頁確認。

講者表示，加入圖檔轉換與視覺檢查後，投影片的產出效果明顯改善，代價則是製作時間拉長。這是其實際使用經驗：增加交付前的自我檢查，有助於找出直接輸出時容易遺漏的問題，但並未取代人工對內容的逐頁把關。

部署限制與延伸資源：先確認能否打包與落地

技能能否落地，除了功能設計，也受平台的檔案數量、大小與匯入相容性限制。講者在分享當時指出，Google SPM 的技能檔案上限為一百個，Claude 則為兩百個。這些是當時的平台限制，不宜視為永久規格。

為因應較嚴格的部署條件，skillOps Studio 增加了 skill PMckage compression，目的是將技能包壓縮至目標平台允許的檔案數量與大小範圍。不過，符合限制不等於一定能成功匯入：講者表示，Google SPMRC 當時即使在檔案數量合規的情況下，仍可能出現未清楚指出原因的錯誤訊息，因此尚有相容性問題需要處理。

講者表示，其他已測試的平台未見重大問題；這項觀察僅限於已測範圍，不能視為跨平台全面相容的保證。打包合規與實際匯入成功，仍是兩個需要分別確認的條件。

延伸資源集中在講者透過 ChatGPT 發布的補充網站，提供下載與操作說明，讓使用者能依實際情境進一步嘗試。網站內容包括：

• skillOps Studio 技能下載。
• 動態工作流與路由執行方式的深入說明。
• 建立一般 Skill 與路由型 Skill 的操作步驟。
• 不同建立情境所需的 prompt 範例。

下載時需區分技能與示範應用程式的發布狀態。講者表示，skillOps Studio 技能當時已放上網站；示範用的 SkillOps 應用程式則因近期仍在調整，尚未上架。應用程式已打包為 Windows EXE 檔，也有 Mac 版本，預計後續放到同一處提供。

講者也預計在網站留下聯絡方式，蒐集使用問題與回饋，持續改善技能管理與開發流程。

重點回顧

• 技能管理要涵蓋建立、調整、融合、驗證、發布與退場，而非只關注如何寫出一份技能。
• 路由型 Skill 以單一入口整合領域能力，再依任務與狀態組成動態工作流，減少細碎技能競爭觸發的問題。
• 高控制力指令必須同時交代觸發、行動、禁止、失敗處理、衝突優先序與完成證明；例外開放也必須有具體條件與上限。
• 融合以能力差異和人類選擇為核心；進化則以標註負案例產生修補建議，經確認後才套用。
• 可靠交付需要程式化結構驗證、明確輸入輸出契約、回歸測試與必要的視覺檢查，不能只靠自評或人工簽核。
• skillOps Studio 展示了可參考的個人化管理實作；採用時仍須確認平台限制、觸發效果與修補結果，並區分已提供資源和後續發布計畫。

SkillskillOpsskillOps Studio路由型 Skill動態工作流SKILL.mdreference.md指令控制六要件instruction control auditFusionEvolutionOptimizationagent instruction governanceHuman in the LoopHarm Aware Editorschemastatepreflightskill PMckage compression