昨日回顧

Day 2 拆解了 SKILL.md：frontmatter 決定觸發，本文承載流程，references 按需載入。今天解決一個更前面的問題：手上有一件想讓 agent 做的事，到底該用哪一種機制？

四個選項的本質

Prompt：一次性指令

就是直接在對話裡說「幫我做什麼、怎麼做」。優點是零成本、隨寫隨用；缺點是說完就消散，下次要重講。

Skill：可重複使用的事項知識

把流程、判斷標準、參考資料打包成檔案，agent 判斷時機到了自己載入。本質是「教會 agent 一件事」，之後不用再教。

Subagent：獨立 context 的分工

把一件子任務連同它自己的 context window 一起交出去。本質是「隔離」：子任務的雜訊不污染主對話，結果回來就好。適合需要大量中間過程但只需要結論的工作。

MCP：對外的連接

Model Context Protocol 讓 agent 接上外部系統：資料庫、API、檔案、服務。本質是「打通工具與資料」，不是教知識。

一張選型表

三個判斷問題

不確定的時候，按順序問自己：

1. 這件事需要碰外部系統嗎？（讀資料庫、呼叫 API、操作檔案）→ 需要就是 MCP 的範圍，先解決連接。
2. 這套做法我會用第二次嗎？→ 會，就值得寫成 skill；純一次性，prompt 就好。
3. 這件事的中間過程會淹掉主對話嗎？→ 會，包成 subagent 丟出去。

三題可以疊加：一個任務可以 MCP 接資料、skill 教方法、subagent 跑執行。

套回我們的示範案例

「演唱會購票安全檢查」為什麼是 skill 而不是其他三個？

• 不是 prompt：粉絲每天都會問新連結，判斷標準必須一致，不能每次重講。
• 不是 MCP：第一版不需要即時連售票系統的 API，官方清單用資料檔就夠；真的到了要查即時票況那天，再考慮 MCP。
• 不是 subagent：判斷過程很短（取域名、比對、回報），沒有需要隔離的龐大中間產物。
• 是 skill：固定的判斷流程 + 會更新的官方清單 + 明確的觸發時機，正好是 skill 的三個特徵都命中。

反過來說，如果哪天這個專案長出「每天早上自動掃描 30 個售票頁有沒有開賣」的需求，那就是 subagent 或 MCP 該上場的時候了——而原來的 skill 依然是判斷核心。

一個常見的誤區

「越強的機制越好」是錯的。能 prompt 解決的別寫 skill，能 skill 教會的別接 MCP。機制越重，維護成本越高——MCP 要管權限與連線，subagent 要管任務切分，skill 要管文件與版本。用最輕的機制解決問題，是這個系列接下來 27 天會不斷回來的主題。

明天預告

Day 4 進入實戰前的最後一塊拼圖：怎麼幫一支 skill 寫「規格」——範圍切多大、護欄設在哪，直接決定它好不好用、安不安全。