把一百本 SOP 手冊全塞給新助理
想像你雇用了一位新助理，第一天上班，你把公司所有的 SOP 手冊全塞給他——請假流程、出差報帳、IT 申請、會議室預約、客戶接待規範……一百本。你說：「你要用到的時候，自己翻。」
他翻著翻著，就開始出錯了。問他請假要填什麼表，他給你一半是出差申請的規定；問他 IT 支援流程，他把人事規範混進去說了一遍。不是因為他笨，是因為你一開始就把他的腦袋塞滿了。
現在換成 AI 助手，也是一樣的問題。AI 的「腦容量」有個上限，太多規則塞進去，它就開始混亂、顧此失彼、甚至把 A 情境的處理方式套用在 B 問題上。Google 的 ADK（Agent Development Kit）在 2026 年初推出的 Skills 功能，試圖解決這件事。Skill，簡單說，就是給 AI 的「技能卡片」——要用到哪張，才把哪張拿出來，而不是一開始就把整個抽屜搬到桌上。
接下來的 5 個設計模式，說的不是 ADK 的技術細節，而是「設計哲學」——為什麼要這樣拆、為什麼這樣管比較好、這些模式在辦公室或學校裡長什麼樣子。就算你不寫程式，這些想法也值得你知道，因為它們解釋的，其實是「怎麼讓 AI 助手長期用得下去」這個比技術更根本的問題。
一張技能卡，只做一件事
最直覺的設計陷阱，就是讓 AI「什麼都做」。
你可能見過這種狀況：公司部署了一個 AI 助手，它能幫你寫 email、安排會議、查差旅規定、回答 IT 問題……功能清單看起來很厲害。但實際用下去，你發現它在做出差申請的時候，會不小心把請假規定混進去；你問 IT 問題，得到的答案有一半是人事規範。這不是 AI 不夠聰明，是它同時要記太多不同領域的規則，彼此開始干擾了。
Single-Responsibility Skill（單一職責模式）是解決這件事的第一步：每一張技能卡，只做一件事，而且做到最好。
教育場景裡有個很好的例子。老師的 AI 助教，如果把「出題」和「批改」放在同一個 skill 裡，那每次你要更新評分標準，就要動到出題邏輯；你要新增一道題型，又可能影響批改規則。拆開之後——出題 skill 管出題，批改 skill 管批改——兩邊各自獨立，老師可以在完全不影響出題的情況下調整評分方式，或者反過來。改一個地方，不用擔心另一個地方跟著壞掉。
這個道理，在辦公室也是一樣。公司 AI 助理如果把「請假申請流程」和「出差報帳流程」拆成兩個獨立 skill，各自維護各自的表單模板、步驟說明與注意事項，哪天報帳規定改了，只要更新那一張卡，請假流程完全不受影響。分工越清楚，出錯的概率越低。
要用到時，再去翻手冊
單一職責解決了「每張卡做什麼」的問題，接下來是「什麼時候拿出哪張卡」。
Tiered Loading（分層載入模式）的核心想法很簡單：AI 不需要一開始就把所有手冊都背起來，用到的時候才去翻，才是聰明的省力之道。ADK 的 Skill 有三個層次：最外層只有名字和一句描述，讓 AI 知道「這張卡是做什麼的」；中間層是具體的步驟說明，觸發 skill 後才讀；最裡層是詳細的附錄和參考文件，只有真正需要深入細節時才拉出來。
想像法律部門的 AI 助手。它每天可能要接觸 NDA、採購合約、勞動合約、服務協議各種不同的合約類型，每種都有各自的審查清單。分層設計讓它不需要一開始就把所有清單都記住——它只知道「我有一個合約審閱 skill」。你丟進去一份 NDA，它才去翻 NDA 的審查清單；換成採購合約，它才去拉採購條款的細則。
這樣的設計讓 AI 每次處理的資訊量保持最小，也讓它更不容易因為同時顧著太多東西而犯錯。對企業來說，還有一個很現實的好處：AI 每次對話載入的文字越少，API 費用就越省。對需要大規模部署 AI 助手的機構——比如學校、大型行政單位——這個細節一點也不小。
學校的成績計算系統也適合這個邏輯。基本步驟放在中間層，各學年度、各學期的評分標準文件放在最裡層的資產資料夾，依需要動態載入。平時只讀基本步驟，遇到特殊情況才拉具體細則，乾淨俐落。
知識放這裡，邏輯放那裡
前兩個模式說的是「怎麼切」和「什麼時候讀」，第三個模式說的是一個更根本的問題：AI 的「知識」和「工作方法」，應該分開放。
Reference-Driven Skill（文件驅動模式）的邏輯是：技能卡裡只寫步驟，「第一步，查閱產品 FAQ；第二步，根據問題類型選擇對應的回答方式」。而那份 FAQ，放在旁邊的資料夾裡，是一個獨立的文件，任何有權限的人都可以直接去編輯它。
這個模式最大的好處，是讓維護知識庫的責任，真正回到「最懂那個領域的人」手上——而不是 AI 工程師。
客服場景：客服 AI 的產品問答 skill，技能卡只說「去查閱 FAQ 文件，然後根據問題類型回答」。FAQ 本身，由產品團隊獨立維護。每次產品功能更新、定價調整、政策改變，產品 PM 直接去改那份文件就好，不需要通知 AI 工程師，也不用等待任何部署流程。知識改了，AI 下次對話就用新的知識，就這麼直接。
補習班的 AI 助教用這個模式會更自在。教學的「方法」不常改，但「課綱」幾乎每年都在調整。把課綱對照表放在文件層，教務組的行政人員直接去編輯那份 Markdown 文件，AI 助教自然就會用到最新的課綱——完全不需要工程師介入。老師可以自己維護教材，這才是讓 AI 落地的正確姿勢。
根據你是誰，給你不一樣的卡
前三個模式，都是針對「固定場景」的設計。但有時候，你需要的不是一張標準卡片，而是一張「針對你這個人」動態生成的卡片。
Inline Dynamic Skill（動態 Inline 模式）解決的就是這件事。比起前面幾個模式，這個比較「程式導向」——它是在執行時，由系統根據使用者身份或資料庫查詢結果，動態組裝出一張臨時的技能卡，交給 AI 去用。
HR 系統的薪資查詢功能是個很直觀的例子。一般員工只能查自己的薪資，主管需要查整個部門的薪資分佈，財務長可能需要看全公司的數字。你不需要為此部署三套不同的 AI 助手——你只需要讓系統在每個人登入時，根據他的職級，動態生成一張範圍不同的「薪資查詢技能卡」，然後把這張卡交給 AI 去用。使用者看到的，是同一個 AI 助手；背後跑的，是完全針對他的角色客製化過的指令。
學習平台的個人化複習功能也是這個邏輯。平台根據學生過去的錯題記錄，動態生成一份個人化的「複習 skill」，把學生的弱點資料注入 AI 的參考資訊，讓 AI 可以針對這個學生的具體問題出題，而不是對著全班發同一套練習題。每個學生拿到的卡片，都是為他一個人準備的。
這個模式的代價是比較難讓非技術人員直接維護——因為它不是一份固定的文件，而是每次都在程式裡組裝出來的。知道什麼時候用固定卡片、什麼時候用動態卡片，是設計者最重要的判斷。
一個懂分工的調度員，比什麼都攬著做的員工有用
最後一個模式，把前面幾個都串了起來。
你有很多張技能卡，但你不需要讓 AI 自己決定「我現在該拿哪張」——尤其是當卡片越來越多的時候，這個判斷本身就會變得複雜。SkillToolset + Coordinator（技能工具箱 + 協調者模式）的解法，是另外設計一個「協調者」，它的工作就是聽懂使用者在說什麼，然後把任務分派給正確的 skill。
想像企業的 AI 助理，同時裝載了三張技能卡：「會議安排」、「費用報帳」、「IT 支援」。員工說：「我的筆電連不上公司 Wi-Fi。」協調者聽完，知道這是 IT 問題，把任務交給 IT 支援 skill 去處理；員工說：「我下週要去台北出差，幫我安排住宿，順便告訴我怎麼報帳。」協調者把這件事拆成兩個任務：住宿部分交給差旅安排 skill，報帳部分交給費用報帳 skill，分頭處理。員工不需要知道背後有幾張卡、每張卡叫什麼名字。他只需要說話。
這個模式讓你的 AI 助手可以「慢慢長大」。學校的智慧客服可以先從「選課說明」和「圖書館查詢」兩個 skill 開始，等到系統穩定、師生習慣了，再加上「獎學金申請」、「宿舍事務」……每次加一張新卡，協調者學會多認一個任務類型，整個系統的能力就自然擴展一圈。不需要一開始就規劃得很完整，也不會因為功能越來越多就越來越難維護。
這種「循序漸進」的部署方式，對資源有限的學校或中小型企業來說，是非常友善的起點。
帶走一件事就夠了
五個模式說完，拆解開來看，背後其實只有一個精神：分工清楚，知識好維護。
設計得好的 AI 助手，不會因為用得越久就越難管；不會因為公司政策改了就整個打掉重來；不會因為新來一個不懂程式的行政人員就沒辦法更新規則。它應該讓對的人維護對的東西，讓 AI 只在真正需要的時候讀真正需要的資訊。
你不需要一開始就把所有模式都用上。如果你正在規劃替部門引入 AI 助手，或者已經用了但覺得「越用越不對」，可以先問自己兩個問題：「這個 AI 的每一個功能，如果哪天規則需要更新，是誰負責去改？」以及「改一個地方，會不會意外影響到另一個地方？」
能夠回答這兩個問題的設計，就是好的設計。技能卡片系統幫你想清楚這件事——但想清楚這件事的人，還是你。