為什麼大廠都在做 CLI？它比 MCP 到底強在哪？
整理版優先睇
大廠重推CLI嘅原因：AI時代下CLI比MCP更省Token、易除錯，但兩者將融合
呢篇文章嘅作者係技術觀察者，佢發現飛書、釘釘、Google、Stripe等大廠突然都開始做CLI。文章解釋呢個現象背後嘅原因：AI時代下，CLI嘅文本交互特性正好適合AI，所以大廠係為咗AI而做CLI。作者整體結論係CLI同MCP各有優勢，未來會融合，唔會互相取代。
文章先比較CLI同GUI，指出CLI過去門檻高，但AI唔需要記命令。然後重點列出CLI三大優勢：第一，漸進式披露令Token消耗大減；第二，CLI出錯可以即刻複製命令喺終端復現，除錯好方便；第三，管道符可以一條命令串聯多個任務。同時文章都提到MCP嘅三大優勢：多租户、標準化安裝、嚴謹權限。作者仲介紹咗CLI-Anisign（將開源軟件變CLI）同Open CLI（將網站變CLI）兩個工具，同埋MCP Powder等融合工具。最後，文章建議讀者根據場景選擇，未來AI Agent可以同時調用CLI同MCP。
- CLI係AI嘅母語，比MCP更適合AI Agent，但MCP喺企業規範上更強。
- 漸進式披露（靠--help按需加載）係CLI減少Token消耗嘅關鍵方法。
- CLI除錯好方便：出錯時複製命令即刻復現；MCP係黑盒，難復現。
- 大廠做CLI係為咗畀AI用，開發者設計工具時應優先考慮CLI接口。
- 可以試用CLI-Anisign同Open CLI將常用軟件變成CLI，再用管道符組合命令提升效率。
CLI-Anisign
將開源軟件轉化為CLI，兩週2.5萬Star
Open CLI
將網站或桌面應用程式轉化為CLI
GitHub CLI (gh)
GitHub官方命令行工具
MCP Powder
將MCP轉換為CLI格式
內容片段
drawio-cli create project # 創建項目drawio-cli add shape --text "Hello" # 添加圖形drawio-cli list elements # 查看元素drawio-cli export --format svg # 導出 SVGCLI：AI時代嘅天然接口
過去CLI係極客嘅專利，門檻高，但AI唔需要GUI，佢最擅長文本輸入輸出。
CLI嘅本色：文本進去，文本出來
大模型訓練時學咗大量程式碼同終端輸出，所以CLI係AI最自然嘅交互方式。大廠突然做CLI，唔係畀人用，而係畀AI用。
CLI嘅價值被重新發現
大廠為AI而做CLI
CLI vs MCP：各有千秋
CLI喺AI Agent場景有三大優勢，同時MCP喺企業場景亦不可取代。
- CLI優勢：上下文佔用低，支援漸進式披露，Token消耗更低。
- CLI優勢：調試方便，出錯可複製命令即時復現。
- CLI優勢：管道符組合，一條命令完成複雜操作。
- MCP優勢：多租户支援，適合雲平台。
- MCP優勢：標準化安裝包，統一鑑權。
- MCP優勢：支援嚴格權限控制。
上下文佔用低係CLI最大殺手鐧
調試方便：複製命令即刻復現
多租户支援係MCP獨有優勢
值得關注嘅開源工具同未來趨勢
CLI-Anisign可以將開源軟件自動轉化為CLI，兩週獲得2.5萬Star。Open CLI則將網站同桌面應用變成CLI，支援幾十種網站。
兩週2.5萬Star
漸進式披露：按需加載--help
未來方向係融合：Claude Code嘅Tool Search引入按需加載工具，MCP Powder將MCP轉換為CLI格式。
Tool Search：按需加載工具
MCP Powder：反向打通兩邊生態
前言
最近你有冇發現一個奇怪嘅現象——飛書、釘釘、Google、Stripe，呢啲大廠突然間都喺度搞 CLI。
CLI？咪即係命令行？呢樣嘢都幾十年啦，點解突然間又興返？
原因好簡單：AI 嚟咗，CLI 嘅價值被重新發現咗。
以前 CLI 係畀極客用嘅，門檻高、唔直觀。但而家，AI 唔需要圖形界面，佢最擅長嘅就係文本輸入、文本輸出——而呢樣啱啱就係 CLI 嘅本色。
更加值得關注嘅係，已經有啲團隊開始由 MCP 轉向 CLI。MCP 唔係啱啱興起咩？點解就有人要轉？
呢篇文章就嚟傾下：CLI 同 MCP 各自嘅優劣勢，以及未來嘅趨勢。
一、CLI 同 GUI，兩種完全唔同嘅交互邏輯
先講個最基礎嘅概念。
GUI（圖形界面） 就係你每日都用緊嘅嘢——開軟件、㩒掣、拖檔案。佢係為人設計嘅，直觀、易上手。
CLI（命令行） 就係嗰個黑框框。輸入一行命令，按 Enter，件事就搞掂咗。
舉個例：你要剪一段影片。
• 用 GUI： 開剪輯軟件 → 揾時間點 → 切分片段 → 揀格式 → 匯出。成個操作落嚟，㩒咗十幾次滑鼠。 • 用 CLI： 一行命令搞掂。
睇落 CLI 更加簡潔，但以前大家唔鍾意用，因為你要記命令、記參數，門檻太高啦。
但而家唔同啦。AI 唔需要記命令——佢本身就係靠文本驅動嘅。
二、點解話 CLI 係 AI 嘅「母語」？
呢個講法唔係誇張。你諗下大模型係點訓練出嚟嘅：
• 學咗海量嘅程式碼 • 學咗海量嘅命令行操作記錄 • 學咗海量嘅終端輸入輸出
CLI 嘅特點係咩？文本入去，文本出嚟，報錯都係文本。 呢三樣嘢，AI 全部都可以直接理解同處理。
但你叫 AI 去操作 GUI 呢？㩒掣、拖滑塊、識別圖標位置？佢真係唔擅長呢啲。
所以本質上，CLI 係 AI 最自然嘅交互方式。呢個亦都係點解大廠們突然間都喺度做 CLI——唔係畀人用嘅，係畀 AI 用嘅。
三、兩個值得關注嘅開源項目
3.1 CLI-Anisign：將任意開源軟件變成 CLI
GitHub 兩星期升咗 2.5 萬 Star，非常犀利。
佢嘅願景好簡單：一行命令，將任意開源軟件以 CLI 嘅形式接入 AI Agent。
點樣做到？佢有一套全自動化流程：
分析源代碼 → 分析 API 邏輯 → 規劃命令分組 → 設計輸入輸出
→ 編碼實現 → 編寫測試 → 更新文檔併發布全程 AI 自動完成，你只需要等。
實戰例子：將 draw.io 變成 CLI
將 draw.io 嘅原始碼下載落嚟，執行一條命令，大概 46 分鐘後，AI 就會幫你生成一整套命令行工具。然後你就可以咁樣用：
drawio-cli create project # 創建項目
drawio-cli add shape --text "Hello" # 添加圖形
drawio-cli list elements # 查看元素
drawio-cli export --format svg # 導出 SVG更加正嘅係，你可以叫 AI 接入呢啲命令，同佢講「畫一個快速排序嘅流程圖」，佢就會自己調用 CLI 命令，一步步將圖畫出嚟，生成 .drawio 檔案，你仲可以喺 draw.io 裏面直接開嚟編輯。
呢度有一個特別重要嘅概念——
🔑 漸進式披露
咩意思？AI 唔需要一開始就學識所有命令。 佢可以隨時調用 --help，需要邊個命令就學邊個，用唔到嘅唔使理。
呢個帶嚟兩個巨大嘅好處：
1. Token 消耗大幅降低 — 唔使一次性將所有工具說明塞入去 2. 調用準確率更高 — 每次只專注當前需要嘅命令
呢個思路喺 Claude Code 嘅 Skill 機制入面都有體現，本質上係同一套理念。
3.2 Open CLI：將網站同桌面應用變成 CLI
CLI-Anisign 係將開源軟件 CLI 化，Open CLI 就更進一步——將任意網站或者 Electron 桌面應用變成命令行工具。
裝好之後，你就可以用命令行操作各種網站：
open-cli hackernews top --limit 5 # Hacker News 前 5 熱門
open-cli grok ask "你的問題" # 用 Grok 問問題
open-cli boss search --city 青島 --keyword 軟件開發 # BOSS 直聘搜職位
open-cli boss search --city 青島 --keyword 軟件開發 --format json # JSON 格式返回佢背後嘅原理係自動操作 Chrome 瀏覽器完成任務，已經支援幾十種網站。而且你可以用 AI 編程工具嚟開發新嘅命令，擴展性好強。
3.3 唔好唔記得官方 CLI
其實好多大型軟件本身就有官方 CLI。例如 GitHub 嘅 gh 命令：
gh issue list # 查看 Issue 列表
gh repo create my-repo # 創建新倉庫
gh pr create # 創建 Pull Request呢啲官方 CLI 質素高、維護好，AI 用起上嚟好順手。
四、CLI vs MCP：到底點揀？
好，鋪墊咗咁多，嚟講最關鍵嘅問題。
CLI 嘅三大優勢
✅ 優勢一：上下文佔用低
呢個係 CLI 最大嘅殺手鐧。
CLI 支援漸進式披露——AI 需要用邊個命令，就調 --help 睇下，按需學習。
但 MCP 唔同。MCP 要將所有工具嘅名、參數格式、調用範例，一次過全部塞入上下文。工具一多，就咁描述呢啲工具就要食好多 Token。
GitLab 做過實測：喺所有任務場景下，CLI 嘅 Token 消耗都比 MCP 低。
✅ 優勢二：除錯方便，對人類友好
CLI 出錯，你直接將嗰條命令複製去終端執行一次，即刻就可以重現問題。然後將錯誤訊息貼畀 AI，叫佢幫你整返。
CLI 出錯 → 複製命令 → 終端運行 → 立即復現 → 修復但 MCP 出錯呢？佢係喺 Agent 內部黑盒運行嘅。你好難知佢到底執行咗啲咩，亦都好難喺本地重現。
MCP 出錯 → 黑盒運行 → 難以復現 → 調試困難差距一目瞭然。
✅ 優勢三：管道符組合，一條命令搞掂複雜需求
CLI 支援管道操作——用 | 將多個命令串埋一齊，上一個命令嘅輸出直接變成下一個命令嘅輸入。
# 獲取 Issue → 篩選 bug → 按時間排序 → 導出 CSV
glab issue list | jq '.[] | select(.title | test("bug"))' | sort_by(.created_at) | export csv一條命令，流水線式處理。
但 MCP 要做同樣嘅事，要一步一步調用工具，每一步都要消耗 Token 同等待時間。效率差距好明顯。
MCP 嘅三大優勢
講完 CLI 嘅好處，公平起見，MCP 都有佢無可取代嘅地方：
✅ 多租户支援 — 喺雲平台場景下，用戶可以上載自定義 MCP 包喺雲端使用，呢樣係 CLI 好難做到嘅。
✅ 標準化安裝包 — MCP 有統一嘅安裝同鑑權規範。CLI 喺呢方面比較散，每個工具嘅安裝方式、認證方式都唔同。
✅ 嚴格嘅權限控制 — 喺企業場景下需要細粒度嘅權限管理，MCP 做得更加完善。
一張表睇清點樣揀
一句講曬：CLI 係 AI 嘅母語，MCP 係企業嘅規範。
五、未來趨勢：唔係邊個取代邊個，係互相融合
話 CLI 要取代 MCP？暫時仲言之尚早。實際上，兩邊都喺度學對方嘅優點。
融合案例一：Claude Code / Codex 嘅 Tool Search
以前 MCP 係將所有工具描述一次過塞入上下文嘅。但而家 Claude Code 同 Codex 都有咗 Tool Search 功能——按需加載工具，唔再全量注入。 呢個其實就係將 CLI 嘅漸進式披露思想引入咗 MCP。
融合案例二：MCP Powder
一個開源工具，可以將任意 MCP 轉換成 CLI 格式畀 Agent 調用。反向打通咗。
所以未來嘅方向好明確：CLI 同 MCP 唔係二揀一，而係各取所長，功能互相融合。
六、關鍵概念速查
七、工具清單
寫喺最後
AI 時代，交互方式正在被重新定義。
CLI 唔再係「極客嘅玩具」，而係 AI Agent 最高效嘅操作接口。但 MCP 都唔會消失，佢喺企業級場景下嘅標準化同權限管理能力，係 CLI 短期內補唔到嘅。
最聰明嘅做法唔係站邊，而係理解兩者嘅邊界，按場景揀。
未來大概率嘅結局係：你寫嘅 AI Agent，既可以調 CLI，都可以調 MCP，兩套能力無縫切換。
都睇到呢度啦，關注下啦！
前言
最近你有沒有發現一個奇怪的現象——飛書、釘釘、Google、Stripe，這些大廠突然都在搞 CLI。
CLI？那不就是命令行嗎？這東西都幾十年了，怎麼突然又火了？
原因很簡單：AI 來了，CLI 的價值被重新發現了。
過去 CLI 是給極客用的，門檻高、不直觀。但現在，AI 不需要圖形界面，它最擅長的就是文本輸入、文本輸出——而這恰好就是 CLI 的本色。
更值得關注的是，已經有一些團隊開始從 MCP 轉向 CLI。MCP 不是剛火起來嗎？怎麼就有人要換了？
這篇文章就來聊聊：CLI 和 MCP 各自的優劣勢，以及未來的趨勢。
一、CLI 和 GUI，兩種完全不同的交互邏輯
先說個最基礎的概念。
GUI（圖形界面） 就是你每天在用的東西——打開軟件、點按鈕、拖文件。它是給人設計的，直觀、好上手。
CLI（命令行） 就是那個黑框框。輸入一行命令，回車，事情就辦了。
舉個例子：你要剪一段視頻。
• 用 GUI： 打開剪輯軟件 → 找到時間點 → 切分片段 → 選格式 → 導出。一套操作下來，點了十幾次鼠標。 • 用 CLI： 一行命令搞定。
看起來 CLI 更簡潔，但過去大家不愛用，因為你得記命令、記參數，門檻太高了。
但現在不一樣了。AI 不需要記命令——它本身就是靠文本驅動的。
二、為什麼說 CLI 是 AI 的"母語"？
這個說法不是誇張。你想想大模型是怎麼訓練出來的：
• 學了海量的代碼 • 學了海量的命令行操作記錄 • 學了海量的終端輸入輸出
CLI 的特點是什麼？文本進去，文本出來，報錯也是文本。 這三樣東西，AI 全都能直接理解和處理。
但你讓 AI 去操作 GUI 呢？點按鈕、拖滑塊、識別圖標位置？它真不擅長這個。
所以本質上，CLI 是 AI 最自然的交互方式。這也是為什麼大廠們突然都在做 CLI——不是給人用的，是給 AI 用的。
三、兩個值得關注的開源項目
3.1 CLI-Anisign：把任意開源軟件變成 CLI
GitHub 兩週漲了 2.5 萬 Star，非常猛。
它的願景很簡單：一行命令，把任意開源軟件以 CLI 的形式接入 AI Agent。
怎麼做到的？它有一套全自動化流程：
分析源代碼 → 分析 API 邏輯 → 規劃命令分組 → 設計輸入輸出
→ 編碼實現 → 編寫測試 → 更新文檔併發布全程 AI 自動完成，你只需要等。
實戰例子：把 draw.io 變成 CLI
把 draw.io 的源代碼下載下來，跑一條命令，大概 46 分鐘後，AI 就會幫你生成一整套命令行工具。然後你就可以這樣用：
drawio-cli create project # 創建項目
drawio-cli add shape --text "Hello" # 添加圖形
drawio-cli list elements # 查看元素
drawio-cli export --format svg # 導出 SVG更酷的是，你可以讓 AI 接入這些命令，跟它說"畫一個快速排序的流程圖"，它就會自己調用 CLI 命令，一步步把圖畫出來，生成 .drawio 文件，你還能在 draw.io 裏直接打開編輯。
這裏有一個特別重要的概念——
🔑 漸進式披露
什麼意思？AI 不需要一上來就學會所有命令。 它可以隨時調用 --help，需要哪個命令就學哪個，用不到的不用管。
這帶來兩個巨大的好處：
1. Token 消耗大幅降低 — 不用一次性把所有工具說明塞進去 2. 調用準確率更高 — 每次只聚焦當前需要的命令
這個思路在 Claude Code 的 Skill 機制裏也有體現，本質上是同一套理念。
3.2 Open CLI：把網站和桌面應用變成 CLI
CLI-Anisign 是把開源軟件 CLI 化，Open CLI 則更進一步——把任意網站或 Electron 桌面應用變成命令行工具。
裝好之後，你就可以用命令行操作各種網站：
open-cli hackernews top --limit 5 # Hacker News 前 5 熱門
open-cli grok ask "你的問題" # 用 Grok 問問題
open-cli boss search --city 青島 --keyword 軟件開發 # BOSS 直聘搜職位
open-cli boss search --city 青島 --keyword 軟件開發 --format json # JSON 格式返回它背後的原理是自動操作 Chrome 瀏覽器完成任務，已經支持幾十種網站。而且你可以用 AI 編程工具來開發新的命令，擴展性很強。
3.3 別忘了官方 CLI
其實很多大型軟件本身就有官方 CLI。比如 GitHub 的 gh 命令：
gh issue list # 查看 Issue 列表
gh repo create my-repo # 創建新倉庫
gh pr create # 創建 Pull Request這些官方 CLI 質量高、維護好，AI 用起來非常順手。
四、CLI vs MCP：到底怎麼選？
好，鋪墊了這麼多，來說最關鍵的問題。
CLI 的三大優勢
✅ 優勢一：上下文佔用低
這是 CLI 最大的殺手鐧。
CLI 支持漸進式披露——AI 需要用哪個命令，就調 --help 看一下，按需學習。
但 MCP 不一樣。MCP 要把所有工具的名字、參數格式、調用示例，一股腦全塞進上下文。工具一多，光是描述這些工具就要吃掉大量 Token。
GitLab 做過實測：在所有任務場景下，CLI 的 Token 消耗都比 MCP 低。
✅ 優勢二：調試方便，對人類友好
CLI 出了錯，你直接把那條命令複製到終端裏跑一下，馬上就能復現問題。然後把錯誤信息貼給 AI，讓它幫你修。
CLI 出錯 → 複製命令 → 終端運行 → 立即復現 → 修復但 MCP 出錯了呢？它是在 Agent 內部黑盒運行的。你很難知道它到底執行了什麼，也很難在本地復現。
MCP 出錯 → 黑盒運行 → 難以復現 → 調試困難差距一目瞭然。
✅ 優勢三：管道符組合，一條命令搞定複雜需求
CLI 支持管道操作——用 | 把多個命令串起來，上一個命令的輸出直接變成下一個命令的輸入。
# 獲取 Issue → 篩選 bug → 按時間排序 → 導出 CSV
glab issue list | jq '.[] | select(.title | test("bug"))' | sort_by(.created_at) | export csv一條命令，流水線式處理。
但 MCP 要實現同樣的事情，得一步一步調用工具，每一步都要消耗 Token 和等待時間。效率差距明顯。
MCP 的三大優勢
說完 CLI 的好處，公平起見，MCP 也有它不可替代的地方：
✅ 多租户支持 — 雲平台場景下，用戶可以上傳自定義 MCP 包在雲端使用，這是 CLI 很難做到的。
✅ 標準化安裝包 — MCP 有統一的安裝和鑑權規範。CLI 在這方面比較散，每個工具的安裝方式、認證方式都不一樣。
✅ 嚴格的權限控制 — 企業場景下需要細粒度的權限管理，MCP 做得更完善。
一張表看清怎麼選
一句話總結：CLI 是 AI 的母語，MCP 是企業的規範。
五、未來趨勢：不是誰取代誰，是互相融合
說 CLI 要取代 MCP？目前還為時尚早。實際上，兩邊都在學對方的優點。
融合案例一：Claude Code / Codex 的 Tool Search
以前 MCP 是把所有工具描述一次性塞進上下文的。但現在 Claude Code 和 Codex 都有了 Tool Search 功能——按需加載工具，不再全量注入。 這其實就是把 CLI 的漸進式披露思想引入了 MCP。
融合案例二：MCP Powder
一個開源工具，可以把任意 MCP 轉換成 CLI 格式供 Agent 調用。反向打通了。
所以未來的方向很明確：CLI 和 MCP 不是二選一，而是各取所長，功能互相融合。
六、關鍵概念速查
七、工具清單
寫在最後
AI 時代，交互方式正在被重新定義。
CLI 不再是"極客的玩具"，而是 AI Agent 最高效的操作接口。但 MCP 也不會消失，它在企業級場景下的標準化和權限管理能力，是 CLI 短期內補不上的。
最聰明的做法不是站隊，而是理解兩者的邊界，按場景選擇。
未來大概率的結局是：你寫的 AI Agent，既能調 CLI，也能調 MCP，兩套能力無縫切換。
都看到這裏了，關注一下吧！