你的 AI 助理太多了嗎？用一個「總機」幫你全部管起來
Router 範式：讓一個入口管理多個專業教練
說來也算是巧合——但又不完全是。Router（路由）本來就是虛擬助理工作方法裡最重要的基本功之一，所以當我最近在幫一家企業做虛擬助理基礎課程的內訓時，同時也有兩個輔導中的 AI 輔助研究的學員，在同一個月內各自問了和「代理範式（Agentic Pattern）」相關的問題。
第一個學員提到：「我們已經設計了好幾個助理，每個功能都很好用，但現在數量實在太多了，我根本搞不清楚要用哪一個。」
這個問題我當下坦白說——我知道這個問題的存在。但就像系統設計一樣，當每個片段都還在快速發展的階段，太早整合、太早優化，往往不會是好事，因為你事後的修改成本會非常高。不過話說回來，有時候時機就是到了。這個月企業內訓剛好又談到 Routing 這個範式，我們也在最近完成了研究教練的 Router 範例，所以今天就來和大家分享這個：看起來簡單、但又常用又好用的設計範式。
為什麼你會遇到這個問題？
如果你已經開始認真用 AI 輔助工作，你大概走過這樣的路：
一開始，你只有一個助理，什麼都問它。後來你發現，同一個助理要它「幫你分析數據」跟「幫你潤飾文字」，效果差很多。於是你開始為不同任務設計不同的助理：有一個專門處理文件摘要、一個負責起草回信、一個用來做資料分析……
這是對的方向。專業化助理的品質，遠高於什麼都能做的通用助理。
但問題隨之而來：
「我到底要用哪一個？」
這個問題的成本比你想像的高。每次要切換任務，你都得停下來想：這件事該找誰？然後切換視窗、找提示詞、重新設定情境。更糟的是，有時候你自己也不確定，你說「幫我看這段文字」，但你其實需要的不是文字潤飾，而是邏輯結構的診斷。
Router 範式，就是為了解決這個問題而生的。
Router 是什麼？四個角色，不只是分類器
很多人第一次聽到 Router，會以為它只是一個「分類器」——你輸入一個問題，它判斷該呼叫哪個助理，然後你去找那個助理。
但這樣的設計其實還差了一層。真正好用的 Router，要同時扮演四個角色：
1. 總機（Dispatcher） 判斷該呼叫哪個 agent，並且直接在同一個對話視窗內切換成那個 agent 回應你。你不需要再跑去別的地方找——Router 切換後，就是那個 agent 在跟你說話。
2. 守門人（Gatekeeper） 判斷你現在的狀態「適不適合」使用任何助理。舉個例子：如果你說「幫我設計問卷」，但你的研究題目根本都還沒定下來，一個好的 Router 不會幫你生出問卷，它會溫和地說：「你現在還不到設計問卷的階段，先讓我們把研究方向確認一下。」這不是刁難，是真的在幫你。
3. 校正者（Reframer） 識別「假需求」。你說的需求，跟你真正需要的，常常不是同一件事。「幫我寫問卷題目」的背後，99% 是研究設計還沒做完。「幫我看這段草稿，邏輯怪怪的」的背後，往往不是文字問題，而是論證鏈斷了。Router 要能看穿這一層，在派發之前先說清楚。
4. 流程顧問（Workflow Advisor） 當某個 agent 的任務告一段落，Router 會主動提示你下一步通常該做什麼。你不需要自己記流程，它幫你記。
暖身範例：品質要求來函的路由
在講研究教練之前，我們先用一個企業場景的案例熱熱身——這也是我在課程裡第一個示範的 Router 例子。
場景： 企業收到了一份客戶的品質要求更新來函。這份文件很長，不同受眾需要不同格式的輸出：
- 業務助理需要的是「一分鐘重點摘要」——精簡、好轉達給老闆
- 業務團隊內部需要的是「待辦清單」——具體行動項目、有負責人、有截止日
傳統做法是：先閱讀整份文件，判斷要給誰看，再分別撰寫兩種格式。每次都要重新看一遍、重新思考。
引入 Router 的做法，是設計一個兩步驟的工作流：
Step 1：資料提取（Extraction）
→ 閱讀原始文件，依照提取規則整理出核心資訊
Step 2：任務路由（Routing）
→ 判斷本次任務是「生成摘要」還是「生成待辦清單」
→ 條件 A：套用一分鐘摘要模板
→ 條件 B：套用待辦清單生成器模板
這個設計的好處是：提取邏輯只寫一次，輸出格式依需求自動選擇。 你只需要告訴系統「這次要哪種輸出」，其他都自動處理。
下圖是這個設計的示意：
這個例子看起來簡單，但它已經包含了 Router 最核心的邏輯：同一份輸入，依據條件路由到不同的下游處理。
主角範例：研究教練 Router
現在來看這個月給學員的範例——一個為研究者設計的教練生態系統。
背景： 研究生在不同的研究階段，需要完全不同類型的幫助。讀文獻需要有人幫你釐清概念；找研究缺口需要有人扮演嚴格的審稿人；設計問卷需要有人守住方法論的底線；修改草稿需要有人做論證結構診斷……
這五件事，如果交給同一個助理，它往往會把角色混在一起，給你一個「什麼都略懂」的泛泛回答。專業化助理的設計，是讓每個助理只做好一件事，並且有明確的邊界。
這個研究教練 Router，管理的是五位專業教練：
| 教練 | 任務定位 |
|---|---|
| A. 學術思辨教練 | 引導釐清單篇文獻的概念，最終沉澱成「能寫進論文的一句話」 |
| B. 理論缺口偵測 | 期刊審稿人視角，找出前人研究的空白、矛盾與失靈之處 |
| C. 跨理論整合 | 發現兩個理論共享的底層邏輯，整合成統一解釋框架 |
| D. 問卷設計助理 | 從研究設計到操作化，守住方法論底線 |
| E. 論文指導教練 | 針對草稿做論證結構診斷，給出漸進改進建議 |
你不需要記住這五個助理、也不需要決定「現在該找誰」。你只需要告訴 Router：「我現在最卡的是什麼。」它會幫你判斷。
Router 的派發決策樹
Router 收到你的輸入之後，內部會依序走這七個步驟（這些判斷是在背景執行的，你看到的只有結果）：
Step 1：守門人檢查 你的狀態適合用任何 agent 嗎？如果題目都還沒定、或者你要求的是「幫我做整篇論文」，Router 會先把你退回前置工作，不勉強派發。
Step 2：訊號掃描 對你的輸入裡的關鍵詞打強度分：強訊號（直接派發）、弱訊號（需要澄清）、無訊號（用開放問題引導）。
Step 3：假需求檢查 比對常見的「說要 X，但真正需要 Y」的情境。下面這張表是 Router 內建的假需求對照表，也是整個設計裡我最喜歡的一個部分：
| 你說的 | 表面需求 | 真實任務 | 應派發 |
|---|---|---|---|
| 「幫我寫問卷題目」 | 題項撰寫 | 研究設計多半沒做完 | D（會退回上游） |
| 「幫我看草稿，邏輯怪怪的」 | 改稿 | 論證鏈問題 | E（做結構診斷） |
| 「我要寫文獻回顧」 | 寫稿 | 先找研究缺口才能寫 | B |
| 「這個概念是什麼意思」 | 解釋 | 讀單篇文獻釐清 | A |
| 「我想結合 X 和 Y 理論」 | 整合 | 跨理論縫合 | C |
Step 4–5：澄清判斷 如果訊號不夠清楚，Router 最多問你 2–3 題：「你想要的最後產出是什麼？」「你手上現在有什麼素材？」「你的研究卡在哪個步驟？」
Step 6：派發並切換角色 確認之後，Router 用一行字告訴你要切換到誰，然後完整切換成那個教練的人格與規則。切換後，它就是那個教練了，不再是 Router。
Step 7：接力提示 當某個教練的任務告一段落，Router 會主動提示：「A 教練的任務看起來到一個段落了，下一步通常是找研究缺口——你準備好的時候告訴我，我幫你切到 B。」
下圖是這個派發邏輯的示意：
為什麼這樣設計？背後的判斷依據
有些人可能會問：這樣設計不是很麻煩嗎？直接讓一個超強的通用助理什麼都處理不就好了？
這個問題問得好。這裡有幾個重要的判斷依據：
1. 角色混合導致品質下降 當同一個助理同時扮演「嚴格的審稿人（B）」和「有耐心的思考夥伴（A）」，它的回應往往兩邊都做得半吊子。明確的角色定義，會讓模型知道「這個角色不做那件事」——這個限制，反而提升了品質。
2. 假需求比你想像的更普遍 研究者最常見的狀況是：你以為自己需要的，和你真正需要的，是不同的事。Router 的守門人與校正者設計，是在幫你省去走錯方向的時間。
3. 流程記憶的負擔轉移 學生不應該需要記住「現在應該用哪個教練、下一步是什麼」。這個認知負擔，應該由系統來承擔。Router 的流程顧問角色，就是在做這件事。
4. 一個入口降低使用門檻 如果有五個助理，使用者就要記五個入口。如果有一個 Router，使用者只要記一個地方、說一句「我現在最卡的是什麼」，系統幫你做剩下的事。
雙場景落地實戰
企業職場場景
你有一個業務助理、一個文件整理助理、一個提案撰寫助理，加上一個市場分析助理。每個助理都做得很好，但你每天要切換好幾次，而且常常說「幫我整理這份資料」卻不確定該找哪一個。
設計一個 Router，讓它能：
- 判斷你的任務是「摘要型」、「分析型」還是「起草型」
- 偵測假需求（你說要「整理資料」，但你其實需要的是「從資料裡找出決策依據」）
- 在任務結束後，提示接下來通常會接哪個步驟
這樣你每次只需要說：「我需要處理這份報告」，Router 幫你決定接下來的路。
研究者場景
你在寫論文，手上有一堆文獻、一個模糊的研究方向、幾段草稿。每次想用 AI 幫忙，都要停下來想「這個問題應該去哪裡問」。
研究教練 Router 讓你只需要說：「我卡在理論整合這裡，有兩個理論想結合但不知道邏輯怎麼接。」Router 聽完，判斷這是 C（跨理論整合教練）的任務，切換過去，直接以 C 的角色問你：「這兩個理論各自的核心假設是什麼？」
你的對話流程不中斷，你不需要切換視窗，你只需要繼續說話。
📎 完整可執行的 research-coach-router-v1.1 提示詞，點擊此連接，進入學員專屬資源
這篇文章介紹了 Router 的基本原理、四個角色、以及兩個示範範例。但 Router 真實使用時，還有一些進階問題我在這裡刻意沒有展開：
漸進式任務漂移：你和教練聊了十幾個來回之後，話題不知不覺滑向另一個教練的範圍。AI 不會主動說「我的任務到這裡」，它只會繼續回答。怎麼設計防護機制，讓系統自己偵測並提示切換？
多層 Router 的嵌套：如果你有跨部門的多個業務領域，每個領域都有自己的助理生態系，怎麼設計「Router of Routers」？
Router 與整個工作環境的整合：Router 不只是一個提示詞，它和你的工作環境怎麼整合，才能發揮最大效益？
這些問題，往後的課程會陸續展開。
延伸思考
你的 Router 派發出去之後，學生對話了十幾個來回，話題開始一點一點地漂移——AI 還停留在原本的教練角色，但回答已經開始答非所問。你沒有意識到這件事，還以為教練只是「今天狀態比較差」。
這是 Router 在真實使用時一定會遇到的問題，而且它是漸進式的，不像錯誤派發那樣一眼就能發現。你會怎麼設計，讓系統能自動偵測並提示切換？
完整版課程會展開三層防護機制的實作。
這篇文章是【AI 虛擬助理基礎工作方法】系列的第 3 篇／共 6 篇
📚 完整系列：
- 🔒 文章 1：為什麼 AI 工作方法比 AI 工具還重要？
- 🔒 文章 2：老闆 persona——為對話加上「視角」
- ▶ 文章 3（你正在閱讀）：Router——讓一個入口管理多個專業教練
- 🔒 文章 4：Evaluator-Optimizer——讓 AI 自己改自己
- 🔒 文章 5：SOP 是怎麼長出來的 + ISO/BPM/ACM 組合拳
- 🔒 文章 6：Orchestrator + LLM Wiki——複雜流程變知識庫
其他文章規劃中，即將陸續公佈。訂閱電子報-收到第一手訊息。