Skill 路由引擎：讓 AI 自動選擇正確工作流

每次都要重新教 AI「現在該做什麼」

手動貼 SOP 平均吃掉 35% 工作時間。

就像每天進辦公室都要重新設定桌面捷徑一樣。你有沒有算過自己花多少時間在「教 AI 怎麼做」？根據我自己半年的紀錄，每天光是幫 AI 貼 SOP、貼模板、補風格指南，平均燒掉 35% 的工作時間。想想看。要 AI 幫忙寫科普文章。得先貼流程。再貼模板。再補風格指南。搞完這些前置作業，寫文章的力氣已經用掉一半。下次寫另一篇？同樣的指令再來一遍。煩不煩？煩。

以下拆解 Skill 路由引擎的設計邏輯。從觸發詞（你可以想成通關密語）比對到流程範本自動載入。一句話講完：讓 AI 聽到關鍵字就知道該走哪條工作流。就像手機上的一鍵啟動捷徑。

過去半年我用 Claude Code 打造了一套 AI Agent 系統。Skill 路由引擎是讓整套系統能「自己跑」的那個關鍵零件。沒有它，其他模組再強也得靠你手動串。

Skill 路由引擎是一種用通關密語驅動的自動分派機制，當使用者輸入特定關鍵字時，AI Agent 會自動比對導航地圖（路由表）、載入對應的流程範本與品質清單，省去每次手動指定工作流的重複操作。簡單講，就是自動販賣機：你投幣（說出通關密語），它就掉貨（吐出完整工作流程）。

為什麼你需要 Skill 路由

效率、品質、一致性三項全輸。

沒有路由引擎的 AI Agent，就是一台每次開機都要重新設定的電腦。你手上明明有食譜。卻每次做菜都要從頭查一遍材料和步驟。

我最早用 Claude Code 時，所有工作流都靠對話裡手動指定。煩。寫科普貼一份流程。寫計畫書貼另一份。做文獻篩選又是另一套。規則堆積到後來根本記不住。一天切換三四種任務，光是「告訴 AI 現在該做什麼」就燒掉 20 分鐘。

但效率只是一面。手動指定有兩個更要命的隱藏風險。第一，某次忘了貼品質清單。產出的文章少了 FAQ 區塊。發佈後才發現。第二，同一類任務每次走的流程略有不同。品質時好時爛。就像同一道菜每次放的鹽量不同。味道自然飄忽不定。

路由引擎一次解決三件事。重複操作。遺漏風險。品質不一致。沒錯。上了路由之後，同類任務的品質波動降了約 80%。

核心架構：觸發詞到 SOP 的三步分派

三步完成自動分派。

運作邏輯很單純。三步：

1. 通關密語比對：使用者說了「科普」「寫文章」「popsci」之類的關鍵字
2. 查導航地圖：系統在 YAML 路由表（導航地圖）中找到對應的路線
3. 自動備料：讀取該路線指定的流程範本、樣板、品質清單

整個機制的核心就是一份 YAML 檔案：fact_sop_dispatch.yml。你可以把它想成一本導航地圖。所有工作流的觸發條件跟載入內容，都畫在這一份地圖裡。沒有資料庫。沒有後端。純文字。

路由表結構

以下是一個簡化的路由表範例：

sop_dispatch:
  base_path: "{{VAULT}}/309_Templates"

  routes:
    popsci_article:
      triggers: ["科普", "寫文章", "popsci", "文獻轉文章"]
      must_read:
        - "PopSci/SOP/科普工作流程.md"
        - "PopSci/Prompt/科普文獻_Prompt.md"
        - "PopSci/Template/科普文章模板.md"
      also_read:
        - "PopSci/Guideline/品質標準.md"

    proposal_writing:
      triggers: ["計畫書", "MOST", "IRB", "grant", "proposal"]
      must_read:
        - "Proposal/SOP_撰寫流程.md"
        - "Proposal/INDEX.md"
      also_read:
        - "Proposal/01_IRB/"
        - "Proposal/02_Commercial/"

每條路線有三組東西：triggers（通關密語）、must_read（必讀材料）跟 also_read（參考材料）。通關密語中英文混用。你平常怎麼說話，路由就怎麼觸發。就像便利商店的自動門。你走過去它就開了。不需要按鈴、不需要報到。

為什麼選 YAML 不寫成程式碼

YAML 格式讓非工程師也能直接編輯路由表。AI 也能原生理解。

為什麼用 YAML 而不是寫成 Python 或 JavaScript？

面向	寫成程式碼	寫成 YAML
修改門檻	需要懂程式	純文字編輯即可
AI 可讀性	需要解析邏輯	原生結構化，AI 直接理解
版控友善度	diff 難讀	每行一個設定，diff 清楚
擴充方式	改 code + 測試	加幾行 YAML

AI 讀 YAML 就像人讀菜單一樣自然。不需要額外的翻譯層。不需要寫轉換器。加一條路由？多打 4 行 YAML。就像在食譜本子裡多夾一頁。完事。

實作：從零建立路由表

四步驟，半小時內可完成。

先盤點你的重複工作流

先列出你每週重複執行的 AI 任務。我當初的清單長這樣：

• 科普文章撰寫
• 文獻篩選與消化
• 計畫書撰寫
• 技術文件撰寫
• 社群貼文產出
• 學術簡報製作

為每個工作流建 SOP

每個工作流至少寫一份流程範本（SOP）。描述步驟、品質清單、輸出格式。把它當烹飪食譜來寫：材料列出來、步驟寫清楚、火候標明白。不用長。半頁到一頁就夠。就這樣。但要夠具體。具體到 AI 讀完就知道怎麼做。不需要再問你。

定義觸發詞

原則很簡單：你平常怎麼說，通關密語就怎麼寫。「寫文章」「產文」「科普」都指向同一條路線。中英文都放。因為有時候你會打「popsci」，有時候打「科普」。但不同路線的通關密語別重疊。重疊就有歧義。AI 不知道該走哪條。就像兩個房間共用同一把鑰匙。你永遠不確定會開到哪間。

寫入 YAML 路由表

把上面的食材組合起來。寫進 fact_sop_dispatch.yml 這份導航地圖裡。格式就是前面範例那樣。不用想太多。

在 CLAUDE.md 裡註冊路由行為

但光有導航地圖還不夠。你得告訴 AI「聽到通關密語時該幹嘛」。在 CLAUDE.md 或 AGENTS.md 裡加上這段執行指引：

ai_sop: |
  當偵測到 sop_dispatch 中任一觸發詞：
  1. 先讀取該 route 的 must_read 所有檔案
  2. 確認理解 SOP 流程後，才開始執行任務
  3. 若有 also_read，在執行對應階段時載入
  4. 任務結束後，對照 SOP 的品質標準自檢

AI 讀到這段就知道路由觸發後該怎麼做。不用你每次嘴巴講。

手動指定 vs Skill 路由

手動六步，路由一步搞定。

拿寫科普文章來比較。差距一目了然：

步驟	手動指定	Skill 路由
1. 指定任務類型	「幫我寫科普文章」	「幫我寫科普文章」
2. 提供 SOP	手動貼上 SOP 全文	系統自動讀取
3. 提供模板	手動貼上模板	系統自動讀取
4. 提供風格指南	手動貼上指南	系統自動讀取
5. 提供品質標準	可能忘記	系統自動讀取
6. 開始撰寫	第 6 步才開始	第 2 步就開始

手動要六步。路由引擎一步觸發。剩下全自動。就像自動販賣機：你投幣，它出貨。不需要你跑進機器後面自己拿。而且品質清單每次都載入。不會漏。上次忘了貼品質清單那種事？不會再發生。

進階技巧：讓路由表更聰明

三招讓路由引擎升級。

基礎路由跑順之後，可以往下加幾個設計讓它更聰明：

串接 Skill 管線

有些工作流不只需要一份食譜。還要串多個 AI 快捷鍵依序跑。在路由裡加一個 skills_pipeline 欄位就行：

deai_optimization:
  triggers: ["去AI感", "DeAI", "humanizer"]
  must_read:
    - "DeAI/審核SOP.md"
    - "DeAI/禁用詞表.md"
  skills_pipeline:
    - "/content-humanizer"
    - "/slopbuster"
    - "/copy-editing"

觸發「去 AI 感」時，AI 不只讀流程範本。還會依序跑完 3 個快捷鍵。你說一句「幫這篇去 AI 感」，它自己跑完全部。很簡單。像洗衣機一樣：衣服丟進去。洗脫烘一條龍。你只管收乾淨的衣服。

內嵌 SOP 邏輯

流程短但邏輯明確的任務。不用另外寫一份完整食譜。直接在 YAML 裡嵌入執行步驟就好。像便利貼提醒一樣輕量：

literature_match:
  triggers: ["這篇", "這份文獻", "paper"]
  must_read:
    - "memory/fact_active_projects.yml"
  sop: |
    1. 解析文獻的標題、摘要、關鍵字
    2. 比對活躍專案的 domain_keywords
    3. 若有命中，列出匹配結果與應用建議
    4. 若無命中，正常處理文獻

搭配記憶系統

路由引擎跟記憶系統是天然搭檔。就像導航地圖跟你腦中的目的地清單。路由引擎決定「做什麼」。記憶系統提供「用什麼背景做」。舉個實際的例子：文獻篩選路由會讀取 fact_active_projects.yml。AI 知道我目前有三個專案在跑。就能自動判斷新文獻跟哪個專案最相關。我不用每次告訴它「我在做 NLRP3 的案子」。它記得。

不過，路由引擎也有侷限。它只處理「已知的重複工作流」。遇到全新的、從沒做過的任務類型？路由表裡沒有對應路線。AI 還是得靠你手動指引。它減少的是重複勞動。不是思考。

我目前的路由表規模

從 2 條長到十幾條，花了約 3 個月。

分享一下目前的規模。我的 fact_sop_dispatch.yml 裡有 十幾條 路由，涵蓋：

• 科普文章撰寫
• 知識消化管線
• 配圖生成
• 去 AI 感最佳化
• 計畫書撰寫（IRB、政府補助、產學合作）
• 論文撰寫
• 文獻篩選
• 技術文件
• 學術簡報
• 專利申請
• SEO 文章
• 社群分發

每條路線背後都有流程範本、樣板、品質清單。切換任務時幾乎零設定時間。就像按手機上不同的 App 快捷鍵。點一下就進入對應的工作模式。

這不是一天建好的。大約三個月。每次碰到重複操作就多加一條路線。一條一條長出來的。第一週只有 2 條。一個月後有六條。三個月後變成現在這個樣子。就像食譜本子。第一天只有兩道菜。每做一道新菜就多記一頁。慢慢就變成一本完整的料理手冊。沒有路由的時候，時間都被吃掉在重複貼指令上。現在涵蓋 12 項 常用工作流。

---

常見問題

以下回應常見疑問，包括這套做法的限制與潛在風險。

Skill 路由引擎跟 ChatGPT 的 Custom Instructions 有什麼不同？

差很多。Custom Instructions 是單一全域設定。所有對話共用一份指引。一把鑰匙開所有門。路由引擎是多路線分派。不同任務載入不同流程範本跟樣板。每扇門有自己的鑰匙。寫科普跟寫計畫書需要的指引完全不同。用一份 Custom Instructions 塞不下。

觸發詞衝突怎麼辦？

設計時盡量避免。真碰到模糊地帶（「文獻」可能是篩選也可能是消化），有兩種解法：用更具體的通關密語區分（「篩選文獻」vs「消化文獻」）。或者讓 AI 在模糊時主動問你「你是要篩選還是消化？」。我用第二種比較多。因為懶得記太細的通關密語。

路由表可以動態更新嗎？

可以。而且即時生效。導航地圖是 YAML 純文字檔。改完存檔。AI 下次觸發就會讀到最新版。不需要重開機。不需要重新安裝。

不會寫 YAML 怎麼辦？

不用擔心。YAML 語法很簡單。就是「名稱: 內容」加上縮排。比填 Excel 表格還容易。你甚至可以直接請 Claude Code 幫你寫：「幫我建一個寫論文的路線，通關密語是 paper、論文、寫稿，流程範本在這個路徑...」。三十秒搞定。

路由引擎有沒有安全風險？

風險不大。但值得注意一點：路由表裡的 must_read 路徑如果指向敏感檔案，任何觸發該路線的人都能讓 AI 讀到那些內容。確保路由表裡不要放密鑰路徑或內部憑證的檔案位置。

這套方法適用於 Claude Code 以外的 AI 工具嗎？

核心概念通用。只要你的 AI 工具能讀外部檔案（多數命令列工具都行），就能用類似的路由機制。Gemini 的 GEMINI.md、Codex 的 AGENTS.md。換個入口檔名而已。導航地圖的畫法一模一樣。跨平台做法可以參考多平台同步。

---

想更深入？

路由引擎的上下游：記憶架構寫在AI Agent 記憶系統設計：三層架構實作，路由執行後的品質把關機制在 Hook 守門系統。

我整理了一份《Claude Code 快速上手速查表》，安裝、CLAUDE.md 配置、記憶系統基礎、常用指令一頁搞定。

免費下載速查表

下一篇：Hook 守門系統：AI 寫的每一行 code 都過品管