讓SKILL可以指定最適合的模型，進行協同工作
整理版優先睇
驗證Claude Skills可嵌套調用，為多模型協作鋪路
呢篇文章係由lemonhall分享嘅一次技術實驗，佢睇到而家愈來愈多AI模型各有擅長——Claude擅長寫code同深度推理，Gemini喺多模態同即時資訊表現出色——所以就諗：可唔可以喺一個統一工作流入面，按任務特點靈活揀最適合嘅模型嚟執行？佢發現Claude官方Skill標準已經預留咗指定模型嘅接口，於是設計咗一個框架去驗證。
實驗好簡單：創建一個主流程Skill同一個繪圖子Skill，主流程委派俾子Skill，結果成功咁執行到，證明Skill之間可以互相調用。呢個實驗嘅結論係：我哋唔需要再追求一個「全能模型」，而係可以建立一個「AI包工頭」系統，每個模型做自己最叻嘅嘢，令整體更經濟、更快、更準、更靈活。
- 結論：Skill間調用成功，多模型協作架構技術可行
- 方法：用三層架構（主流程編排層、子技能層）驗證嵌套調用
- 差異：從「揀一個最強模型」轉變為「按場景編排不同模型」
- 啟發：未來AI系統會似微服務咁，靈活組合各模型優勢
- 可行動點：任何人都可以Clone專案重複實驗，甚至貢獻新Skill或模型適配
GitHub 專案：two-sklls
包含main-process、drawing、skill-creator三個已完成嘅Skill，可複現Skill間嵌套調用實驗。
點解要做呢個實驗？
以前用AI多數係全程用同一個模型，或者成日喺唔同API之間切換代碼，搞到好多問題：資源浪費、成本唔划算、體驗唔一致，仲唔能夠發揮每個模型嘅潛能。
Claude擅長代碼同深度推理，Gemini喺多模態同即時資訊方面表現出色
作者睇到Claude官方Skill定義入面有個特性——可以指定用邊個模型——於是靈機一觸：點解唔設計一個框架，等一個總工作流入面嘅每個子Skill可以交畀唔同模型執行？
- 定義一個總工作流（Main Orchestration Skill）
- 呢個工作流由多個子技能組成
- 每個子技能可以指定由唔同模型執行
- 框架自動調度同協調
框架設計：一個AI包工頭系統
作者設計咗一個三層驗證框架：最頂層係主流程編排層，負責協調工作流同委派任務；下層係具體嘅子技能，例如Drawing Skill（由Claude執行），日後可以加其他模型嘅Skill。
佢要驗證三個關鍵問題：Skill之間可唔可以互相調用？可唔可以喺Skill入面指定執行模型？框架實現係咪完整？
Skill之間可唔可以互相調用？
可唔可以喺Skill入面指定執行模型？
實驗過程同結果
作者創建咗三個核心Skill：skill-creator（技能創建指南）、main-process（主流程）、drawing（繪圖子技能）。main-process嘅workflow係：第一步打印「主流程正在執行中...」，第二步委派畀drawing技能繪製Hello World。
- 1 執行 main-process 技能
- 2 輸出結果顯示主流程執行完，並且成功畫咗ASCII藝術嘅Hello World
- 3 ✅ 結論：Skill間調用成功！
Main Process能夠成功委派給Drawing Skill
two-sklls/
├── .claude/
│ └── skills/
│ ├── main-process/ # ✅ 已完成
│ │ └── SKILL.md
│ ├── drawing/ # ✅ 已完成
│ │ └── SKILL.md
│ │ └── references/
│ └── skill-creator/ # ✅ 已完成
│ └── SKILL.md
└── README.md # ✅ 已完成呢個實驗證實咗Skill級別嘅工作流編排係可行嘅，而且Claude嘅Skill標準已經為指定模型預留咗接口，技術基礎存在，剩低嘅係點樣令框架正式實現呢個標準。
下一步：多模型編排嘅願景
作者提出短期目標係令Skill可以正式指定模型參數，測試從Claude切換到Gemini；中期目標包括自動適配API、建立模型選擇策略（成本、速度、精度）同失敗自動降級；長期目標係支援多個AI平台，甚至建立「AI工作流市場」。
用Claude處理複雜推理嘅業務邏輯
用Gemini處理多模態同實時信息
用專用小模型處理高頻低複雜度任務
作者邀請有興趣嘅人一齊參與：Reviewer審視設計、Contributor貢獻新Skill或用戶、User嘗試呢個框架、Thinker討論多模型編排嘅最佳實踐。
令SKILL可以指定最適合嘅模型，一齊做嘢
前言
最近喺度諗一個問題：喺AI技術高速發展嘅今日，我哋有越來越多優秀嘅大模型可以用——Claude擅長寫code同深度推理，Gemini喺多模態同即時資訊方面表現出色，仲有其他各具特色嘅模型。
咁問題嚟啦：可唔可以喺一個統一嘅工作流入面，根據任務嘅特點，靈活揀最適合嘅模型去執行？ 呢個就係我今次實驗嘅出發點。
背景：點解要做呢個？
傳統做法嘅問題
通常我哋用AI嗰陣，一係就全程用一個模型，一係就不停喺唔同API之間切換code。咁樣有幾個問題：
1. 浪費資源 - 一個模型處理曬所有任務，就算佢唔係最優嘅選擇 2. 成本唔理想 - 可能為咗唔適合嘅模型畀錢，例如用Claude處理Gemini擅長嘅任務 3. 體驗唔一致 - 成日切換模型搞到工程複雜度高、維護困難 4. 能力被侷限 - 發揮唔到每個模型嘅最大潛能
啓發
我研究Claude官方嘅Skill實現標準嗰陣，發現咗一個有趣嘅特性：喺Skill定義入面可以指定用邊個模型。
https://code.claude.com/docs/zh-CN/skills#%E5%8F%AF%E7%94%A8%E7%9A%84%E5%85%83%E6%95%B0%E6%8D%AE%E5%AD%97%E6%AE%B5
呢個畀咗我靈感——點解唔設計一個框架，令佢可以：
• 定義一個總工作流（Main Orchestration Skill） • 呢個工作流由多個子技能組成 • 每個子技能可以指定由唔同嘅模型執行 • 框架自動調度同協調
咁就好似建立咗一個「AI包工頭」系統，每個工人（模型）根據自己嘅專長嚟接嘢做。
項目設計
核心架構
我設計咗一個簡單但有意義嘅驗證框架，包含三層：
┌─────────────────────────────────────┐
│ Main Process Skill (主流程編排層) │
│ - 負責工作流協調 │
│ - 委派任務給子技能 │
└──────────────┬──────────────────────┘
│
┌──────┴──────┐
▼ ▼
┌───────────────┐ ┌─────────────────┐
│ Drawing Skill │ │ Others (待開發) │
│ (由Claude執行) │ │ (由Gemini執行) │
└───────────────┘ └─────────────────┘三個關鍵問題
設計嗰陣，我想驗證嘅核心問題係：
1. Skill之間可唔可以互相調用？ • Main Process可唔可以委派畀Drawing Skill？ 2. 可唔可以喺Skill入面指定執行模型？ • 跟Claude嘅標準，理論上係得嘅 3. 框架實現係咪完整？ • 如果唔完整，我哋可唔可以透過修改底層code嚟支援？
實驗過程
第一步：設計Skill標準結構
我創建咗三個核心Skill：
1. skill-creator - 技能創建指南
• 定義咗Skill應該點樣寫 • 規範咗格式同標準
2. main-process - 主流程技能
Workflow:
1. Step 1: 打印"主流程正在執行中..."
2. Step 2: 委派給drawing技能繪製Hello World3. drawing - 繪圖技能（作為演示子技能）
• 支援多種繪圖格式（Mermaid、SVG、ASCII等） • 可以獨立執行或者俾其他Skill調用
第二步：驗證Skill調用鏈
執行指令：執行技能main-process
輸出結果：
主流程正在執行中...
_ _ _ _ __ __ _ _
| | | | ___| | | ___ \ \ / /__ _ __| | __| |
| |_| |/ _ \ | |/ _ \ \ \ /\ / / _ \| '__| |/ _` |
| _ | __/ | | (_) | \ V V / (_) | | | | (_| |
|_| |_|\___|_|_|\___/ \_/\_/ \___/|_| |_|\__,_|
✅ 主流程執行完成！結論：✅ Skill之間調用成功！
第三步：觀察
喺呢個過程中，我觀察到：
1. Main Process成功委派畀Drawing Skill 2. 框架正確咁追蹤咗執行流程 3. 呢個證實咗Claude Skills確實支援嵌套調用
關鍵發現
發現1：Skill級別嘅工作流編排可行
我哋可以設計更大粒嘅組織層級：
• 唔係函數調用，而係Skill調用 • 每個Skill可以包含自己嘅邏輯同資源 • Skill之間可以松耦合咁互動
發現2：模型指定框架已經有基礎
Claude嘅Skill標準已經為指定模型預留咗接口。即係話：
• 技術基礎存在 • 淨低係要令框架實現呢個標準
發現3：開放性畀咗我哋改進空間
如果Claude官方嘅框架實現唔完整，我哋有能力：
• 研究底層實現 • 貢獻改進方案 • 甚至自己擴展框架
實驗輸出
呢個項目而家包含：
two-sklls/
├── .claude/
│ └── skills/
│ ├── main-process/ # ✅ 已完成
│ │ └── SKILL.md
│ ├── drawing/ # ✅ 已完成
│ │ └── SKILL.md
│ │ └── references/
│ └── skill-creator/ # ✅ 已完成
│ └── SKILL.md
└── README.md # ✅ 已完成可重複執行嘅實驗
任何人都可以：
1. Clone呢個項目 2. 執行 執行技能main-process3. 觀察Skill之間嘅調用過程 4. 基於呢個框架加自己嘅技能
下一步：多模型編排
短期目標（現階段）
• ✅ 驗證Skill之間可以互相調用 • 🔄 喺Skill入面正式指定模型參數 • 🔄 測試由Claude切換去Gemini
中期目標
• 實現模型切換嗰陣嘅API自動適配 • 建立模型選擇策略（基於成本、速度、精度） • 加失敗自動降級（模型唔可用嗰陣自動切換）
長期目標
• 支援多個AI平台（OpenAI、Anthropic、Google等） • 建立「AI工作流市場」，預先配置好各行各業嘅最優工作流 • 喺真實業務中驗證ROI提升
思考：呢個代表啲乜？
呢個小實驗其實觸及咗一個更深層嘅問題：
喺AI時代，系統設計嘅重點將會由「揀一個最強嘅模型」轉變為「根據場景靈活編排唔同模型」。
就好似20年前互聯網初期，我哋由「用一個全能嘅框架」發展到「微服務+多語言+最佳工具選擇」一樣，AI系統都會演變。
未來嘅超級應用，可能唔係基於單一模型，而係：
• 用Claude處理複雜推理嘅業務邏輯 • 用Gemini處理多模態同即時資訊 • 用專用小模型處理高頻低複雜度任務 • 用自訓模型處理專有業務
咁樣嘅系統將會係：
• 📊 更經濟 - 每個模型只處理佢擅長嘅嘢 • ⚡ 更快速 - 用最輕量級嘅適配 • 🎯 更準確 - 專業模型嘅專業能力 • 🔧 更靈活 - 可以快速適應模型更新
邀請
呢個項目係開放嘅實驗。我邀請有興趣嘅人：
1. Reviewer - 審視設計係咪合理 2. Contributor - 貢獻新嘅Skill或者模型適配 3. User - 喺實際項目中試嚇呢個框架 4. Thinker - 討論多模型編排嘅最佳實踐
總結
呢個唔單止係一次技術實驗，而係對AI應用未來架構嘅一次思考。
我哋唔係喺度揾最強嘅模型，而係設計一個可以令每個模型發揮所長嘅系統。
項目地址：https://github.com/lemonhall/two-sklls
有任何諗法或者建議，歡迎討論！
寫於 2026年1月19日
「喺AI嘅世界入面，多樣性嘅力量正在顯現。」
讓SKILL可以指定最適合的模型，進行協同工作
前言
最近在思考一個問題：在AI技術高速發展的今天，我們有越來越多優秀的大模型可用——Claude擅長代碼和深度推理，Gemini在多模態和實時信息方面表現出色，還有其他各具特色的模型。
那麼問題來了：能否在一個統一的工作流中，根據任務的特點，靈活選擇最適合的模型來執行？ 這就是我這次實驗的出發點。
背景：為什麼要做這個？
傳統做法的問題
通常我們使用AI時，要麼全程用一個模型，要麼頻繁地在不同API之間切換代碼。這存在幾個問題：
1. 資源浪費 - 一個模型處理所有任務，即使它不是最優選擇 2. 成本不優 - 可能為不適合的模型付費，比如用Claude處理Gemini擅長的任務 3. 體驗不一致 - 頻繁切換模型導致工程複雜度高、維護困難 4. 能力被限制 - 無法發揮每個模型的最大潛能
啓發
我在研究Claude官方的Skill實現標準時，發現了一個有趣的特性：在Skill定義中可以指定使用的模型。
https://code.claude.com/docs/zh-CN/skills#%E5%8F%AF%E7%94%A8%E7%9A%84%E5%85%83%E6%95%B0%E6%8D%AE%E5%AD%97%E6%AE%B5
這給了我靈感 - 為什麼不設計一個框架，讓它能夠：
• 定義一個總工作流（Main Orchestration Skill） • 該工作流由多個子技能組成 • 每個子技能可以指定由不同的模型執行 • 框架自動調度和協調
這就像是建立了一個"AI包工頭"系統，每個工人（模型）根據自己的特長來接活。
項目設計
核心架構
我設計了一個簡單但有意義的驗證框架，包含三層：
┌─────────────────────────────────────┐
│ Main Process Skill (主流程編排層) │
│ - 負責工作流協調 │
│ - 委派任務給子技能 │
└──────────────┬──────────────────────┘
│
┌──────┴──────┐
▼ ▼
┌───────────────┐ ┌─────────────────┐
│ Drawing Skill │ │ Others (待開發) │
│ (由Claude執行) │ │ (由Gemini執行) │
└───────────────┘ └─────────────────┘三個關鍵問題
在設計時，我想驗證的核心問題是：
1. Skill間能否互相調用？ • Main Process能否委派給Drawing Skill？ 2. 能否在Skill中指定執行模型？ • 按照Claude的標準，理論上是可以的 3. 框架實現是否完整？ • 如果不完整，我們能否通過修改底層代碼來支持？
實驗過程
第一步：設計Skill標準結構
我創建了三個核心Skill：
1. skill-creator - 技能創建指南
• 定義了Skill應該如何編寫 • 規範了格式和標準
2. main-process - 主流程技能
Workflow:
1. Step 1: 打印"主流程正在執行中..."
2. Step 2: 委派給drawing技能繪製Hello World3. drawing - 繪圖技能（作為演示子技能）
• 支持多種繪圖格式（Mermaid、SVG、ASCII等） • 可獨立執行或被其他Skill調用
第二步：驗證Skill調用鏈
執行命令：執行技能main-process
輸出結果：
主流程正在執行中...
_ _ _ _ __ __ _ _
| | | | ___| | | ___ \ \ / /__ _ __| | __| |
| |_| |/ _ \ | |/ _ \ \ \ /\ / / _ \| '__| |/ _` |
| _ | __/ | | (_) | \ V V / (_) | | | | (_| |
|_| |_|\___|_|_|\___/ \_/\_/ \___/|_| |_|\__,_|
✅ 主流程執行完成！結論：✅ Skill間調用成功！
第三步：觀察
在這個過程中，我觀察到：
1. Main Process能夠成功委派給Drawing Skill 2. 框架正確地追蹤了執行流程 3. 這證實了Claude Skills確實支持嵌套調用
關鍵發現
發現1：Skill級別的工作流編排可行
我們可以設計更大粒度的組織層級：
• 不是函數調用，而是Skill調用 • 每個Skill可以包含自己的邏輯和資源 • Skill之間可以松耦合地交互
發現2：模型指定框架已有基礎
Claude的Skill標準已經為指定模型預留了接口。這意味着：
• 技術基礎存在 • 剩下的是讓框架實現這個標準
發現3：開放性給了我們改進空間
如果Claude官方的框架實現不完整，我們有能力：
• 研究底層實現 • 貢獻改進方案 • 甚至自己擴展框架
實驗輸出
這個項目現在包含：
two-sklls/
├── .claude/
│ └── skills/
│ ├── main-process/ # ✅ 已完成
│ │ └── SKILL.md
│ ├── drawing/ # ✅ 已完成
│ │ └── SKILL.md
│ │ └── references/
│ └── skill-creator/ # ✅ 已完成
│ └── SKILL.md
└── README.md # ✅ 已完成可復現的實驗
任何人都可以：
1. Clone這個項目 2. 執行 執行技能main-process3. 觀察Skill間的調用過程 4. 基於這個框架添加自己的技能
下一步：多模型編排
短期目標（當前階段）
• ✅ 驗證Skill間可以互相調用 • 🔄 在Skill中正式指定模型參數 • 🔄 測試從Claude切換到Gemini
中期目標
• 實現模型切換時的API自動適配 • 建立模型選擇策略（基於成本、速度、精度） • 添加失敗自動降級（模型不可用時自動切換）
長期目標
• 支持多個AI平台（OpenAI、Anthropic、Google等） • 建立"AI工作流市場"，預配置好各行業的最優工作流 • 在真實業務中驗證ROI提升
思考：這意味着什麼？
這個小實驗其實觸及了一個更深層的問題：
在AI時代，系統設計的重點將從"選擇一個最強的模型"轉變為"根據場景靈活編排不同模型"。
就像20年前互聯網初期，我們從"使用一個全能的框架"發展到"微服務+多語言+最佳工具選擇"一樣，AI系統也會演變。
未來的超級應用，可能不是基於單一模型的，而是：
• 用Claude處理複雜推理的業務邏輯 • 用Gemini處理多模態和實時信息 • 用專用小模型處理高頻低複雜度任務 • 用自訓模型處理專有業務
這樣的系統將是：
• 📊 更經濟 - 每個模型只處理它擅長的事 • ⚡ 更快速 - 可用最輕量級適配 • 🎯 更準確 - 專業模型的專業能力 • 🔧 更靈活 - 可快速適應模型更新
邀請
這個項目是開放的實驗。我邀請感興趣的人：
1. Reviewer - 審視設計是否合理 2. Contributor - 貢獻新的Skill或模型適配 3. User - 在實際項目中嘗試這個框架 4. Thinker - 討論多模型編排的最佳實踐
總結
這不僅僅是一次技術實驗，而是對AI應用未來架構的一次思考。
我們不是在尋找最強的模型，而是在設計能讓每個模型發揮所長的系統。
項目地址：https://github.com/lemonhall/two-sklls
有任何想法或建議，歡迎討論！
寫於 2026年1月19日
"在AI的世界裏，多樣性的力量正在顯現。"