本篇文章更新時間：2026/03/02
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知或向一介資男的 LINE 社群反應。
如果本站內容對你有幫助，歡迎贊助支持 。
MCP 已死，CLI 萬歲：為什麼我們反而不需要另一個協議？
編輯前言：這篇文章來自 MCP is dead. Long live the CLI，作者用實務經驗揭露一件大家心照不宣的事：MCP（Model Context Protocol）也許從一開始就不是那麼必要，而我們真正需要的可能只是更好的 CLI 工具。
核心觀點 (Key Takeaways)
- MCP 沒帶來實質增益，反而增加複雜度。
- LLM 天生擅長使用 CLI，遠勝於需要額外訓練的協議格式。
- CLI 的可組合性、可除錯性與既有驗證流程，遠比 MCP 來得成熟與可靠。
深入解析
文章的主軸非常清楚：MCP 想解決的問題，其實早就被 CLI 解決了，而且做得更好。 作者從數個角度逐一拆解 MCP 的幻象。
作者一句話點破核心：「LLMs don’t need a special protocol. Give them a CLI and some docs and they’re off to the races.」
-
LLM 不需要額外協議：LLM 已經熟悉 man pages、Stack Overflow 和 GitHub scripts，只要有 CLI 指令，它就能自然推理與操作。作者甚至舉例 Claude 直接執行
gh pr view 123毫無障礙。 -
CLI 讓人類與 AI 共享語境：當 LLM 對 Jira 做出奇怪操作，人類能馬上跑同樣指令排錯；反觀 MCP，只能翻 JSON logs，一切變得不透明更難查。
-
CLI 天生可組合、可管線化：這是作者最強的論點。像在分析 Terraform plan 時，只需一行管線指令：
terraform show -json plan.out | jq '[.resource_changes[] | select(.change.actions[0] == "no-op" | not)] | length'
MCP 要嘛把整份 plan 塞進上下文（昂貴、不實際），要嘛自己實作濾器。無論如何都比不上現成 CLI 工具的彈性。 -
身份驗證本來就有成熟方案：AWS、gh、kubectl 都有完整的 auth 流程，而 MCP 卻自己重新造輪子，導致更多狀態管理與錯誤空間。
-
CLI 沒有多餘的 moving parts：MCP server 是背景進程，會掛、要重啟、會失效；CLI 則是單純的可執行檔，需要時才運作，不會增加系統複雜度。
筆者心得與啟發
讀完這篇文章，我最強烈的感受是：很多 AI 工具的創新，其實是在解決一個不存在的問題，反而忽略了那些已被驗證數十年的基礎工具。 MCP 企圖打造一層更抽象的介面，但現實是 LLM 已經能熟練使用 CLI 這種人類與機器共享的介面，且成本更低、可除錯性更高。
這讓我重新思考：在 AI 時代，我們不是要重新打造所有工具，而是要更善用既有的基礎建設。特別是 CLI——它具備人類可讀、AI 可推理、易除錯、可組合的所有優點。與其投注資源打造複雜協議，不如先建好 API，再建好 CLI，自然就能同時服務人與 AI。
如果你正準備打造 MCP server 但手上沒有 CLI，作者的提醒非常務實：
先停下來，想想你的使用者真正需要什麼。
多半時候答案不是新協議，而是更好的工具。