AI 工具生態：從 Skills 到 MCP 到自建 Bot 的實戰指南

cover

為什麼「用 ChatGPT」不等於「有 AI 工具鏈」

大多數人對 AI 的使用方式是：打開 ChatGPT，問一個問題，得到答案，關掉視窗。這是「單次對話」模式——你是操作者，AI 是工具，每次都要你親手啟動。

但真正的 AI 工具鏈是另一回事。它是一個持續運作的系統：AI 可以自己讀 Notion、自己回 Discord、自己跑排程任務。你不需要每次都坐在螢幕前面。

這兩者的差距，就像「用計算機算數」和「建一套自動記帳系統」的差距。

flowchart TD
    L1["Layer 1: Chat UI<br/>ChatGPT / Claude / Gemini<br/>人工操作，單次對話"]
    L2["Layer 2: Skill / Plugin<br/>Skills / MCP Server<br/>半自動，擴展 AI 能力"]
    L3["Layer 3: Agent / Bot<br/>ClawdBot / AutoGPT / n8n<br/>全自動，持續運行"]

    L1 --> L2
    L2 --> L3

    style L1 fill:#e8f4f8,stroke:#2196F3
    style L2 fill:#fff3e0,stroke:#FF9800
    style L3 fill:#e8f5e9,stroke:#4CAF50

Layer 1 是大多數人停留的地方——打開網頁，手動對話。Layer 2 是讓 AI 有了「技能」和「接口」，可以做更多事。Layer 3 是讓 AI 變成一個獨立運作的助理，你睡覺它也能工作。

這篇文章會帶你從 Layer 2 走到 Layer 3，告訴你每一層需要什麼知識、適合什麼情境、怎麼配置。

Skills：AI 的「技能包」

什麼是 Skill？

Skill 是一個模組化的「技能包」，用來告訴 AI agent 怎麼做某件特定的事。

你可以把它想成是一份「新人入職指南」——當你請一個聰明但什麼都不知道的新人（AI）來做事，你會給他一份文件，裡面寫著：

這個任務是什麼
步驟是什麼
要用什麼工具
有什麼眉角要注意

一個 Skill 本質上就是這些東西的打包：系統 prompt + 工具定義 + 使用情境 + 可選的腳本和素材。

SKILL.md 格式

每個 Skill 的核心是一個 SKILL.md 檔案，結構長這樣：

my-skill/
├── SKILL.md          # 必要：技能定義 + 使用說明
├── scripts/          # 選配：可執行腳本
├── references/       # 選配：參考文件
└── assets/           # 選配：模板、圖片等素材

SKILL.md 本身分成兩部分：

---
# YAML Frontmatter — AI 用這段來判斷「什麼時候該啟動這個技能」
name: code-review
description: "Review code changes for quality, security, and best practices.
  Use when asked to review a PR, diff, or code snippet."
---
 
# Code Review Skill
 
## 流程
 
1. 讀取 diff 或指定檔案
2. 檢查：安全性問題、效能問題、可讀性
3. 給出具體建議，附上修改範例
 
## 評分標準
 
- Critical：安全漏洞、資料外洩風險
- Warning：效能問題、不好的慣例
- Suggestion：風格建議、更好的寫法

這裡有一個重要的設計原則叫 Progressive Disclosure（漸進式揭露）：

Metadata（name + description）——永遠在 context 裡，讓 AI 知道有這個技能（約 100 words）
SKILL.md body——只有技能被觸發時才載入（建議 < 5k words）
Bundled resources——AI 需要時才去讀（大小不限）

這樣設計是因為 context window 是有限的公共資源，不能每個技能都把所有內容塞進去。

適合情境

重複性任務：每次做 code review 都要檢查同一套清單
固定流程：commit message 格式、PR 模板、文件產出
領域知識：公司的 coding standard、特定 API 的使用方式

需要的知識

基礎 prompt engineering（怎麼寫出清楚的指令）
Markdown / YAML 格式
對任務本身的領域知識（你要教 AI 做什麼，你自己得先會）

範例：寫一個 Code Review Skill

假設你要讓 AI 自動做 code review，以下是完整範例：

---
name: code-review
description: "Review code changes for quality, security, and best practices.
  Use when asked to review a PR, diff, or code changes. Trigger on keywords:
  review, code review, check my code, PR review."
---

# Code Review
 
## 步驟
 
1. 讀取所有變更的檔案（用 `git diff` 或指定路徑）
2. 依序檢查以下面向：
   - **安全性**：是否有 hardcoded secrets、SQL injection、XSS
   - **效能**：是否有 N+1 query、不必要的重新渲染、大量同步操作
   - **可讀性**：命名是否清楚、函式是否過長、邏輯是否過度巢狀
   - **測試**：是否有對應的測試、edge case 是否涵蓋
3. 輸出格式：
 
### [檔案名稱]
 
- **Critical**: [問題描述] -> [建議修改]
- **Warning**: [問題描述] -> [建議修改]
- **Suggestion**: [問題描述] -> [建議修改]
 
## 注意事項
 
- 不要建議風格偏好（除非違反既有的 linter 規則）
- 優先指出安全性和正確性問題
- 如果程式碼品質很好，也要明確說「looks good」

把這個 SKILL.md 放到 skills 目錄下，AI agent 就能在你說「幫我 review 這段 code」的時候自動啟動這個技能。

MCP (Model Context Protocol)：AI 的「萬能接頭」

什麼是 MCP？

MCP 是一個標準化的 tool calling 協定，讓 AI 可以存取外部系統。

打個比方：USB 出現之前，每個裝置都有自己的接頭（印表機是並列埠、滑鼠是 PS/2、手機是各種奇形怪狀的充電頭）。USB 統一了這些接頭。MCP 想做的事情類似——統一 AI 存取外部工具的方式。

在 MCP 出現之前，你想讓 AI 讀 Notion，你得自己寫一個 Notion API wrapper，然後手動定義 function calling 的 schema，然後自己處理認證、錯誤、分頁… 每接一個新服務就重來一次。

有了 MCP：

AI Agent <-> MCP Client <-> MCP Server (Notion) <-> Notion API
                         <-> MCP Server (Gmail)  <-> Gmail API
                         <-> MCP Server (GitHub) <-> GitHub API

每個 MCP Server 都遵循同一個協定（基於 JSON-RPC），AI agent 只需要會「講 MCP」，就能跟所有實作了 MCP 的服務溝通。

MCP Server 怎麼運作

一個 MCP Server 做三件事：

Tool Discovery：告訴 AI「我有哪些工具可以用」
Tool Execution：AI 呼叫工具，Server 執行並回傳結果
Authentication：處理 OAuth、API key 等認證

以 mcporter CLI 為例，這是一個讓你直接管理和呼叫 MCP server 的工具：

# 列出所有可用的 MCP Server
mcporter list
 
# 查看某個 Server 提供哪些工具（附 schema）
mcporter list notion --schema
 
# 呼叫 Notion 的搜尋工具
mcporter call notion.search query="meeting notes"
 
# 呼叫 Gmail 的寄信工具
mcporter call gmail.send_email to="team@example.com" subject="Weekly Report" body="..."

適合情境

讓 AI 讀寫外部系統：Notion、Gmail、GitHub、Slack、Trello
整合企業內部系統：只要你的系統有 API，就能包成 MCP Server
多系統串接：例如「讀 Notion 的任務清單 → 建立 GitHub Issue → 發 Slack 通知」

需要的知識

JSON-RPC 概念：MCP 底層用的通訊協定（不需要自己實作，但要理解 request/response 結構）
API 基礎：REST、HTTP method、status code
OAuth 流程：大多數 MCP Server 都用 OAuth 認證
JSON Schema：工具的輸入輸出定義

範例：用 mcporter 連接 Notion

# 1. 安裝 mcporter
npm install -g mcporter
 
# 2. 設定 Notion MCP Server（觸發 OAuth 認證）
mcporter auth notion
 
# 3. 瀏覽器會跳出 Notion 授權頁面，同意後回到 terminal
 
# 4. 確認連線成功——列出可用工具
mcporter list notion --schema
# 輸出：search, get_page, create_page, update_page, query_database...
 
# 5. 測試：搜尋 Notion 裡的頁面
mcporter call notion.search query="weekly standup" --output json
 
# 6. 進階：查詢特定資料庫
mcporter call notion.query_database database_id="abc123" \
  --args '{"filter":{"property":"Status","select":{"equals":"In Progress"}}}'

設定完成後，任何支援 MCP 的 AI agent（包含 Claude Code、OpenClaw 等）都能透過這些 MCP Server 存取 Notion。

注意：Notion API 回傳的 JSON 非常冗長。在實務中如果讓 AI 直接處理原始回傳，很容易把 context window 撐爆。建議讓 AI 只提取需要的欄位（如 title + id），立刻寫入檔案，不要在記憶體裡累積大量 API 回應。

ClawdBot / AI Bot：你的 AI 助理

Bot 跟 Chat UI 的差別

面向	Chat UI (ChatGPT 網頁)	Bot (ClawdBot)
啟動方式	你打開網頁	持續運行，等待觸發
對話載體	瀏覽器	Discord / Slack / API
工具存取	受限（GPT 的 plugin）	完整（file system, MCP, browser）
Session 管理	平台處理	你自己控制
自訂程度	有限	完全可控
成本	月費制	按 token 計費

Bot 的核心價值是：你不在的時候它也能工作。它可以監聽 Discord 訊息、定時執行任務、主動回報進度。

配置一個 Bot 需要什麼

1. LLM Gateway

Bot 需要一個 LLM（大型語言模型）來「思考」。你有幾種選擇：

直接呼叫 API：OpenAI API、Anthropic API、Google Gemini API
透過 Gateway：OpenClaw Gateway（本地轉發）、OpenRouter（多模型路由）

Gateway 的好處是統一管理 API key、做流量控制、提供 fallback。例如 OpenClaw Gateway 跑在 localhost:18789，bot 只需要對這個 endpoint 發 request，Gateway 負責轉發到實際的 LLM provider。

Bot -> OpenClaw Gateway (:18789) -> OpenAI / Anthropic / Google

2. 系統 Prompt 設計

系統 prompt 決定 bot 的「人設」和「行為規範」。一個好的 bot prompt 至少要包含：

1. 角色定義：你是誰、你的能力範圍
2. 行為規範：什麼該做、什麼不該做
3. 輸出格式：回應的風格和結構
4. 環境資訊：OS、可用工具、檔案路徑
5. Context 管理規則：什麼時候該 summarize、什麼時候該清 session

這比 ChatGPT 的 Custom Instructions 複雜得多，因為 bot 需要處理更多邊界情況。

3. Context Management

這是 bot 開發中最容易踩坑的地方。

Token 限制：每個 LLM 都有 context window 上限（8K / 32K / 128K / 200K）
Session 管理：對話紀錄會越來越長，你需要策略來處理（truncate / summarize / 開新 session）
工具回傳：MCP server 和其他工具的回傳可能很大，容易撐爆 context

實務上的做法：

{
  "contextTokens": 64000,
  "sessions": {
    "maxAge": "24h",
    "summarizeAt": 48000,
    "clearStrategy": "summarize-and-archive"
  }
}

當 context 快到上限時，讓 bot 先 summarize 之前的對話，再繼續。或者乾脆寫 {} 到 sessions.json 強制開新 session。

4. Tool Access

Bot 真正強大的地方是它能存取各種工具：

File System：讀寫本地檔案
Browser Automation：截圖、點擊、填表
MCP Servers：Notion、Gmail、GitHub（上一節講的）
Shell Commands：跑腳本、執行 CLI 工具
Skills：前面講的技能包

{
  "agents": {
    "main": {
      "model": "openai-codex/gpt-5.2-codex",
      "systemPrompt": "You are a helpful assistant...",
      "tools": ["file-system", "browser", "mcp:notion", "mcp:gmail"],
      "skills": ["github", "code-review", "summarize"]
    }
  }
}

適合情境

長期運行：24/7 Discord 助理、客服機器人
排程任務：每天早上整理 email 摘要、每週產出報告
多步驟工作流：讀取任務 → 執行 → 回報結果 → 等待下一個
多人協作：團隊共用一個 AI 助理

需要的知識

LLM API 的使用（Chat Completion API, streaming）
Token 計算和成本控管
Prompt 設計（不只是寫 prompt，還要設計 prompt 的生命週期管理）
基本 DevOps：讓 bot 持續運行（process manager, 重啟機制, log）
平台 API：Discord.js / Slack Bolt 等

最小單位 ChatGPT 架構

如果你想從零建一個最簡單的 ChatGPT-like 系統，你需要什麼？

這不是叫你真的自己做一個 ChatGPT。而是讓你理解：原來 ChatGPT 的核心就這些東西。理解了之後，你就知道每個工具在做什麼，也知道要自己客製化什麼。

架構圖

flowchart LR
    User["使用者"] --> FE["Frontend<br/>Chat UI"]
    FE --> API["Backend API<br/>Express / FastAPI"]
    API --> TPL["Prompt Template<br/>System + User Message"]
    API --> History["Chat History<br/>Token Counter"]
    API --> LLM["LLM Provider<br/>OpenAI / Anthropic"]
    LLM --> Stream["Streaming Response"]
    Stream --> FE

    style User fill:#f5f5f5,stroke:#333
    style FE fill:#e3f2fd,stroke:#1976D2
    style API fill:#fff3e0,stroke:#F57C00
    style LLM fill:#e8f5e9,stroke:#388E3C

組件拆解

Prompt Template

const messages = [
  { role: "system", content: "你是一個有幫助的 AI 助理..." },
  ...chatHistory,  // 之前的對話紀錄
  { role: "user", content: userInput }  // 使用者的新訊息
];

就這樣。ChatGPT 的每次對話，底層就是把 system prompt + 歷史訊息 + 新訊息打包成一個 array 送出去。

Chat History 管理

// 每次對話都要算 token 數
const tokenCount = countTokens(messages);
 
// 超過限制就截斷舊訊息
if (tokenCount > MAX_TOKENS) {
  messages = truncateOldMessages(messages, MAX_TOKENS);
}

Streaming Response

// 不要等整個回應生成完才顯示——邊生成邊送出
const stream = await openai.chat.completions.create({
  model: "gpt-4",
  messages,
  stream: true,
});
 
for await (const chunk of stream) {
  process.stdout.write(chunk.choices[0]?.delta?.content || "");
}

技術選型

方案	前端	後端	適合誰
Next.js + Vercel AI SDK	React	Next.js API Routes	前端工程師
Python + FastAPI + OpenAI SDK	任意	FastAPI	後端工程師
純前端	React / Vue	無（直接呼叫 API）	快速 prototype

用 Vercel AI SDK 的話，核心程式碼大約 50 行就能搞定一個可用的聊天介面。重點不是程式碼量，而是理解每一行在做什麼。

情境 x 工具對照表

不知道該用什麼？看這張表：

你想做什麼	適合的工具	需要的知識	複雜度
自動回覆 Discord 訊息	ClawdBot + Skills	prompt + Discord API	★★★
讓 AI 讀寫 Notion	MCP Server (mcporter)	MCP + OAuth	★★
定時整理 email 摘要	n8n + AI node	n8n workflow + prompt	★★
建一個聊天介面	Vercel AI SDK	React + LLM API	★★★
自動 Code Review	Skill + CI/CD Hook	prompt + CI/CD	★★
RAG 文件搜尋系統	LangChain + Vector DB	embedding + DB 概念	★★★★
多系統自動化串接	n8n / Zapier + MCP	workflow + API 整合	★★★
自然語言查資料庫	Text-to-SQL + LLM	SQL + prompt design	★★★

怎麼讀這張表：

★★ 代表「有基礎程式能力就能做」
★★★ 代表「需要理解 API 和系統設計」
★★★★ 代表「需要額外的專業知識（如向量資料庫、ML pipeline）」

如果你是剛開始的人，建議從 Skills 開始，因為你只需要會寫 Markdown 和基本的 prompt。等你需要串接外部系統了，再學 MCP。等你需要 24/7 運行的助理了，再搞 Bot。

知識地圖：你需要先學什麼

每個工具需要的前置知識不同。以下是依賴關係圖：

flowchart TD
    PE["Prompt Engineering<br/>寫出好的 AI 指令"]
    API["API 基礎<br/>REST / HTTP / JSON"]
    YAML["YAML / Markdown<br/>格式化文件"]
    OAuth["OAuth 認證<br/>授權流程"]
    JSONRPC["JSON-RPC<br/>MCP 底層協定"]
    Token["Token Management<br/>計算與控制成本"]
    Session["Session Design<br/>對話歷史管理"]
    DevOps["基本 DevOps<br/>process manager / 部署"]
    RAG["RAG 架構<br/>embedding + vector DB"]
    Workflow["Workflow Engine<br/>n8n / Temporal"]

    PE --> Skills["Skills<br/>技能包"]
    YAML --> Skills

    PE --> MCP["MCP<br/>萬能接頭"]
    API --> MCP
    OAuth --> MCP
    JSONRPC -.->|nice to have| MCP

    PE --> Bot["Bot<br/>AI 助理"]
    API --> Bot
    Token --> Bot
    Session --> Bot
    DevOps --> Bot

    Bot --> Full["全自動系統<br/>AI Workflow"]
    MCP --> Full
    RAG -.->|進階| Full
    Workflow -.->|進階| Full

    style Skills fill:#e8f5e9,stroke:#4CAF50
    style MCP fill:#fff3e0,stroke:#FF9800
    style Bot fill:#e3f2fd,stroke:#1976D2
    style Full fill:#fce4ec,stroke:#E91E63

各路線所需學習時間（粗估）

路線	前置知識	學習投入	產出
Skills	Prompt Engineering + Markdown	1-2 天	可重複使用的 AI 技能
MCP	+ API 基礎 + OAuth	3-5 天	AI 存取外部系統的能力
Bot	+ Token 管理 + Session 設計 + DevOps	1-2 週	24/7 運行的 AI 助理
全自動	+ RAG + Workflow + Vector DB	1-2 月	完整 AI 自動化系統

建議的學習順序

先學 Prompt Engineering——這是所有路線的共同基礎。你寫的 prompt 品質直接決定 AI 的輸出品質。
再試 Skills——門檻最低，一個 SKILL.md 就能開始。你會在這個過程中理解 AI agent 怎麼消費指令。
搞懂 API 和 OAuth——當你需要 AI 存取外部系統（Notion、Gmail），這是必經之路。
挑戰 Bot——當 Skills + MCP 不夠用（你需要 24/7 運行、需要多步驟工作流），就是時候搭一個 bot 了。

三個工具怎麼組合在一起

最後，用一張圖解釋這三個層次怎麼組合成一個完整的系統：

flowchart TB
    subgraph Bot["ClawdBot (Layer 3)"]
        direction TB
        Agent["AI Agent<br/>LLM + System Prompt"]
        SM["Session Manager<br/>Token 控制 / 對話歷史"]
        Agent <--> SM
    end

    subgraph Skills_Layer["Skills (Layer 2a)"]
        S1["code-review"]
        S2["summarize"]
        S3["github"]
    end

    subgraph MCP_Layer["MCP Servers (Layer 2b)"]
        M1["Notion MCP"]
        M2["Gmail MCP"]
        M3["GitHub MCP"]
    end

    subgraph External["外部服務"]
        Notion["Notion"]
        Gmail["Gmail"]
        GitHub["GitHub"]
    end

    Bot <--> Skills_Layer
    Bot <--> MCP_Layer
    M1 <--> Notion
    M2 <--> Gmail
    M3 <--> GitHub

    Discord["Discord<br/>使用者在這裡互動"] <--> Bot

    style Bot fill:#e3f2fd,stroke:#1976D2
    style Skills_Layer fill:#e8f5e9,stroke:#4CAF50
    style MCP_Layer fill:#fff3e0,stroke:#FF9800
    style External fill:#f5f5f5,stroke:#999

Discord 使用者發訊息給 ClawdBot
ClawdBot 的 AI Agent 判斷要用哪個 Skill（例如 code-review）
如果需要存取外部系統，透過 MCP Server（例如 Notion MCP）
結果回傳給使用者

每一層都是可以獨立使用的。你不一定要三層都搭。只用 Skills？可以。只用 MCP？也可以。全部串起來做一個自動化助理？當然也可以。

Terry Yao's Blog

分類

目錄

AI 工具生態：從 Skills 到 MCP 到自建 Bot 的實戰指南

為什麼「用 ChatGPT」不等於「有 AI 工具鏈」

Skills：AI 的「技能包」

什麼是 Skill？

SKILL.md 格式

適合情境

需要的知識

範例：寫一個 Code Review Skill

MCP (Model Context Protocol)：AI 的「萬能接頭」

什麼是 MCP？

MCP Server 怎麼運作

適合情境

需要的知識

範例：用 mcporter 連接 Notion

ClawdBot / AI Bot：你的 AI 助理

Bot 跟 Chat UI 的差別

配置一個 Bot 需要什麼

1. LLM Gateway

2. 系統 Prompt 設計

3. Context Management

4. Tool Access

適合情境

需要的知識

最小單位 ChatGPT 架構

架構圖

組件拆解

Prompt Template

Chat History 管理

Streaming Response

技術選型

情境 x 工具對照表

知識地圖：你需要先學什麼

各路線所需學習時間（粗估）

建議的學習順序

三個工具怎麼組合在一起

延伸閱讀

關係圖譜

反向連結