API、MCP、CLI、Skills 是什麼？AI 時代非工程師也該懂的 6 個技術名詞

如果你最近開始接觸 AI 工具，不管是研究自動化、試用各種 AI Agent，還是在看一些工具的介紹頁面，你一定常常看到這些字眼：「支援 API」「提供 CLI」「整合 MCP」「內建 Skills」……

看到的當下你可能會想：嗯，聽起來很厲害。然後就滑過去了。

但這些名詞其實沒有你想的那麼難。今天這篇文章，我打算用一件你一定做過的事：在蝦皮買東西，把這六個概念一次講清楚。

讀完之後，你會知道 API、GUI、Browser Use、CLI、MCP、Skills 各自是什麼、彼此有什麼差異，以及它們跟 AI 到底有什麼關係。

不需要任何技術背景，我保證。

內容目錄

一、GUI — 你每天都在用，只是不知道它叫這個名字

你打開蝦皮 App，看到首頁推薦、搜尋欄、商品圖片、購物車圖示、結帳按鈕——這整個你看到、摸到、可以點來點去的畫面，就叫做 GUI。

GUI 的全名是 Graphical User Interface，中文叫「圖形化介面」。白話一點說，就是設計給一般人操作的畫面。

你不需要知道蝦皮背後有幾台伺服器、資料庫怎麼運作、訂單怎麼傳遞——你只要在畫面上點幾下，商品就會寄到你家。這就是 GUI 厲害的地方：把所有複雜的技術藏在好看的畫面後面，讓任何人都能使用。

你每天用的 LINE、Instagram、Google Maps、網路銀行，全部都是 GUI。

但你有沒有想過：當你在蝦皮按下「結帳」之後，背後到底發生了什麼事？

二、API — 讓程式跟程式「對話」的通道

程式跟程式之間的「通道」

你在蝦皮按下結帳，畫面可能轉了一圈就顯示「訂單成立」。但在這短短幾秒鐘裡，其實發生了一連串的事：

蝦皮的 App 把你的訂單資訊，包含你買了什麼、幾件、寄到哪裡、用什麼方式付款…等，打包成一個「請求」，送到蝦皮的伺服器去處理。伺服器收到以後，要去確認庫存夠不夠、跟金流系統確認扣款是否成功、再通知物流系統準備出貨。

這整個「送請求 → 收回應」的通道，就是 API。

API 的全名是 Application Programming Interface，翻成白話就是：讓程式跟程式溝通的接口。

一句話總結：GUI 是給你操作的前台畫面，API 是背後真正在傳遞資料的通道。

你可能聽過「服務生」的比喻，但那只講了一半

如果你之前有查過「什麼是 API」，大概會看到一個很經典的比喻：「API 就像餐廳的服務生，你（客人）跟廚房（伺服器）之間的溝通都透過服務生來傳遞。」

這個比喻沒錯。但它有一個盲點：它讓人以為 API 只存在於「你跟別人的系統之間」。

事實上，API 分成兩種：

內部 API：每個 App 和網站自己的前台跟後台之間就有 API。蝦皮的 App 畫面跟蝦皮的伺服器之間、伺服器跟金流系統之間、金流系統跟銀行之間——這些全部都是透過內部 API 在溝通的。沒有這一層，畫面上的結帳按鈕按下去，什麼事都不會發生。

公開 API（Open API）：服務商「選擇」開放給外部開發者使用的接口，通常會附上文件說明怎麼串接。比如 OpenAI 開放 API 讓你可以在自動化工具裡呼叫 ChatGPT，或是綠界開放金流 API 讓電商網站串接刷卡功能。

用公司簽呈來理解「對內 vs 對外」

如果你在公司待過，應該更好懂。

想像公司的線上簽核系統：你填一張請購單送出去，這張單子要經過主管簽核、財務審批、採購確認、倉庫備貨——每個部門之間傳遞單據的「格式和規則」，就是內部 API。你身為員工看不到這些部門之間怎麼傳遞資料，但如果這套機制不存在，你的請購單根本跑不完流程。

那什麼是公開 API？就是公司進一步決定：開放讓外部供應商可以直接登入系統查詢訂單進度和出貨狀態。這就是把原本只給內部用的通道，開一條路給外面的人用。

為什麼有些服務故意不公開 API？

因為他們不想讓人用程式自動操作。

最常見的例子就是搶票系統。搶演唱會門票、搶高鐵票——如果這些系統公開 API，就會有人寫程式在開賣的那一秒同時送出幾百個請求，一般人根本搶不贏。所以他們故意不公開 API，逼你只能乖乖打開網站（GUI）手動操作。

但這就引出了一個有趣的問題：如果一個服務不公開 API，AI 還有辦法幫你操作嗎？

三、Browser Use — 沒有公開 API？AI 就自己去操作畫面

答案是：可以。AI 可以像人一樣，自己打開瀏覽器來操作。

假設你想讓 AI 幫你在蝦皮下單買東西，但蝦皮並沒有開放公開 API 給外部程式使用。這時候 AI 可以怎麼做？

它可以自己打開 Chrome 瀏覽器、連到蝦皮網站、登入你的帳號、在搜尋欄輸入「藍牙耳機」、點進商品頁、選規格、加入購物車、按結帳、選超商取貨、確認付款……

就像一個坐在你電腦前面幫你操作的小助理。

這個能力叫做 Browser Use。在十年前，工程師叫它「爬蟲」或「自動化測試」；在 AI 時代，它成了 Manus AI、OpenClaw 這類 AI Agent 的核心能力之一。

聽起來很厲害對吧？但代價是：非常慢。

用公司簽呈來比喻的話，Browser Use 就像你請一個工讀生幫你登入簽核系統：他要自己看畫面、找到填表的地方、一欄一欄填寫、按送出，速度跟你自己操作差不多慢，遠不如部門之間直接用系統對接來得有效率。

把速度攤開來看：

你自己在蝦皮下單：大約 3 分鐘
AI 用 Browser Use 模擬你的操作：大約 1-2 分鐘
直接呼叫 API（如果有的話）：幾秒鐘

差距是好幾十倍。

所以 Browser Use 可以這樣記：AI 的萬能備案——什麼都能做，但什麼都比較慢。

四、CLI — 用一行指令完成你在畫面上按了十幾下的事

CLI 其實比 GUI 更早出現

在講 CLI 是什麼之前，先說一個很多人不知道的冷知識：CLI 比 GUI 更早被發明出來。

1950-60 年代的電腦長什麼樣？沒有螢幕畫面、沒有滑鼠、沒有圖示——只有一台像打字機一樣的機器，你輸入一行文字指令，電腦就執行一個動作，然後把結果印在紙上。

這就是 CLI 的起源：Command Line Interface，命令列介面。

GUI 反而是後來技術進步了、電腦可以顯示圖形了，才慢慢發展出來的。所以嚴格來說，CLI 不是從 GUI 和 API「中間」誕生的產物——它是最老的那一個。

但在今天的脈絡下，CLI 剛好站在 GUI 和 API 中間

雖然歷史順序是 CLI → GUI，但如果用「使用體驗」來排列的話：

GUI：有畫面，一般人都能用，但操作起來一步步點，比較慢
API：沒畫面，讓程式直接溝通，最快，但你需要寫程式才能用
CLI：沒畫面，但你只要打一行指令就能完成事情，比 GUI 快、比寫程式簡單

假設蝦皮有一個 CLI 工具，你可能只要打這麼一行：

shopee order --item "藍牙耳機" --qty 1 --ship 7-11

一按 Enter，訂單就成立了。不用打開 App、不用滑頁面、不用選規格、不用按五個按鈕。

用公司簽呈來比喻：CLI 就像你直接打一行字「請購 A4 紙 10 箱送到三樓」送出申請，不用打開系統、找表單、一欄一欄填。

CLI 在 AI 時代特別重要的三個理由

你可能會想：現在都什麼年代了，誰還在用命令列？

但 CLI 在 AI 時代反而越來越重要，因為：

第一，CLI 比 GUI 穩定。 網站會改版、按鈕位置會變、介面長得不一樣。你今天教 AI「點右上角的購物車圖示」，明天蝦皮改版把購物車移到左邊，AI 就找不到了。但 CLI 的指令只要參數沒改，今天能用、明天通常也能用。

第二，CLI 比 Browser Use 快。 同一件事如果可以直接下一行指令完成，就不需要打開瀏覽器、等畫面載入、通過驗證碼、一步步點選。

第三，CLI 對 LLM 來說特別好用。 你仔細看 CLI 的指令，裡面其實都是簡單的英文單字：order、item、ship。這比要求 AI 寫一段完整的程式碼來呼叫 API 容易多了。而且 CLI 指令通常設計得很短，AI 用 CLI 來執行任務也更省 token（也就是更省錢）。

五、MCP — 讓 AI 有「統一的方式」使用各種外部工具

要解決什麼問題？

到目前為止，你已經知道 AI 可以透過 API、Browser Use、CLI 來幫你做事。但還有一個麻煩：

每個服務的「用法」都不一樣。

假設你希望 AI 幫你做一件稍微複雜的事：先到蝦皮下單買一個藍牙耳機，然後到 momo 查一下同款耳機的價格有沒有更便宜，最後再幫你追蹤物流進度。

這三件事背後可能涉及三個平台、三種不同的 API 格式。AI 要一個一個去研究怎麼使用——先搜尋有沒有文件、再讀懂格式、然後嘗試呼叫——整個過程很慢、很不確定、而且會消耗大量的 AI 使用額度。

MCP 想解決的就是這個問題。

MCP 的全名是 Model Context Protocol，你可以把它想成一種「統一規格」：讓所有想要被 AI 使用的工具，都用同一套方式來說明「我能做什麼、你該怎麼用我」。

用公司簽呈來比喻：這就像公司決定統一所有部門的表單格式。不管你是要請購、請假還是報帳，全部用同一套規則來填寫。新人不用每換一個部門就重新學一次表單怎麼填。

如果你有用過 USB-C 充電線，就更好懂了——以前每支手機的充電孔都不一樣，現在大家統一用 USB-C，一條線就搞定。MCP 想做的事情跟 USB-C 很像，只是它統一的不是充電孔，而是「AI 跟各種工具之間的溝通方式」。

MCP 目前發展到哪裡了？

MCP 是 2024 年 11 月由 Anthropic（就是做 Claude 的那家公司）提出的。當時很多人覺得：又來一個新標準，能撐多久？

結果一年多過去，MCP 的發展出乎意料地快：

OpenAI（ChatGPT 的公司）、Google、Microsoft 全都加入了支持
2025 年底，MCP 被捐贈給 Linux Foundation，正式成為一個由多家公司共同維護的開放標準
早期被批評的安全性問題（例如缺乏登入授權機制）也在 2025 年 6 月的規格更新中加入了 OAuth 2.0 認證

但 MCP 也不是沒有挑戰。最主要的問題是：AI 要使用 MCP 工具，就得把所有工具的說明、參數格式都載入到對話中。工具裝越多，佔用的空間就越大，每次對話的成本也越高，而且更容易撞上對話長度的上限。Anthropic 目前正在用「讓 AI 寫程式碼去呼叫工具，而不是直接把工具定義全部塞進對話」的方式來緩解這個問題。

六、Skills — 讓 AI 從經驗中「學會」新技能

概念：幫 AI 寫一份 SOP

最後一個名詞，也是我覺得概念上最好理解的一個。

回到蝦皮的例子。假設蝦皮沒有推出 MCP，但有公開 API 文件。你請 AI 去研究怎麼透過 API 在蝦皮下單，AI 可能要花 20 分鐘去讀文件、嘗試不同的呼叫方式、踩幾個坑，最後終於搞定了。

20 分鐘？聽起來好像也沒有很快。

但關鍵在下一步：你可以告訴 AI——「把你剛剛學到的東西整理起來，存成一份筆記。」

AI 就會把它的研究過程、最終找到的方法、要注意的眉角，全部寫成一份文件。

下次你再說「幫我在蝦皮買東西」，它就不用再花 20 分鐘重新研究了——直接翻開上次的筆記，幾秒鐘就搞定。

這份「筆記」就是一個 Skill。

本質上，一個 Skill 就是一個 markdown 檔案（就是純文字加一點格式），記錄著 AI 該怎麼完成某件事情。你可以自己寫，也可以讓 AI 從經驗中自己學了之後幫你整理。

用公司簽呈來比喻：你教新進員工「請購流程怎麼跑」，他把你教的內容寫成一份 SOP 手冊，以後每次要請購就照著做，不用每次都重新問你。

Skills 和 MCP 是互補的，不是對立的

你可能會想：既然 Skills 這麼方便，那還需要 MCP 嗎？

需要的，因為它們擅長的場景不一樣：

MCP 適合的情境： 需要即時存取外部系統、資料會一直變動的場景。比如查蝦皮的即時庫存、查某支股票現在的價格——這些資料每分鐘都在變，你不可能寫一個固定的 SOP 來處理。

Skills 適合的情境： 流程相對固定、你希望 AI 快速又穩定地執行。比如「每次下單都用同一種格式、同一個寄送方式」這類不太會變的流程。

實務上，最好的做法往往是兩者搭配使用。

其實你早就在做類似的事了

如果你有在用 AI 工具，你可能已經做過類似的事：把好用的 prompt 存成模板，下次要用的時候直接套用，不用每次都重新想怎麼寫。

Skills 的概念跟這完全一樣——只是它更進一步，不只存 prompt，連「怎麼呼叫 API」「怎麼下 CLI 指令」「要注意什麼眉角」都一起存起來。

讓 AI 不只會說話，還真的會做事。

總結：一張表看懂六個名詞

最後幫你做一張對照表，把今天講的六個名詞放在一起比較：

	GUI	API	Browser Use	CLI	MCP	Skills
白話翻譯	操作畫面	程式間的通道	AI 自己操作畫面	一行指令搞定	統一的工具規格	AI 的 SOP 筆記
速度	🐢 慢	⚡ 最快	🐢 慢	⚡ 快	⚡ 快	⚡ 快
誰在用	一般人	程式	AI Agent	人＋ AI	AI	AI
穩定性	低（會改版）	高	低	高	高	高
需要對方配合	有網站就行	要開放公開 API	有網站就行	要提供 CLI	要開發 MCP Server	不需要
簽呈比喻	填表單的畫面	部門間傳單據的規則	請工讀生操作系統	打一行字送出申請	統一所有表單格式	新人的 SOP 手冊

如果你記不住這麼多，就記一個核心概念：當你想讓 AI 幫你做某件事的時候，背後其實就是在這六種方式裡面選一條路走。

有些路快但需要對方配合（API、MCP），有些路慢但什麼都能做（Browser Use），有些路是 AI 自己開出來的（Skills）。了解這些差異，你在選工具、評估方案的時候就不會頭昏腦脹了。

如果你想進一步學習怎麼實際運用 AI 工具來做自動化，歡迎參考我的 AI 工具文章總整理，裡面有更多實作教學。

本文以非工程師的角度撰寫，目的是幫助一般讀者建立基礎認識。為了降低理解門檻，部分技術細節經過簡化，若有不夠精確之處敬請見諒。

本文的撰寫靈感來自 Zeabur 創辦人林沅霖（@yuaanlin）的 Threads 分享，我在他的基礎上加入了自己的理解與觀點。感謝原作者用淺顯的方式開啟了這個話題。