為什么一夜之間大家都在做 CLI？

飛書、Google、Stripe、ElevenLabs、網易云音樂。

最近幾個月，一群看起來毫不相關的公司不約而同做了同一件事：發布 CLI 工具。

Karpathy 最近寫了一篇文章記錄自己用 AI 做 app 的全過程。

他大部分時間不是在寫代碼，主要是在瀏覽器標簽之間跳來跳去，配 API Key、改 DNS、填環境變量。

他的原話是：

"你的服務應該有一個 CLI 工具。不要讓開發者去訪問、查看或點擊。直接指示和賦能他們的 AI。"

2026 年了，為什么大家突然回去做"命令行"這種看起來很復古的東西？

CLI 到底是什么

如果你不是程序員，CLI 聽起來很技術。其實概念很簡單。

GUI（圖形界面）是打開 app，看到按鈕菜單，鼠標點來點去。

CLI（命令行）是打開一個黑色窗口，敲一行文字，按回車，事情做完了。

打個比方：GUI 是去餐廳看菜單、指給服務員"我要這個"。

CLI 是直接對廚房喊"宮保雞丁，少油，多辣"。結果一樣，但 CLI 更精確，更容易被自動化。

那為什么 CLI 和 AI 特別適配？因為 AI 就是"文字進、文字出"的。GUI 是給眼睛看的，AI 沒有眼睛。

CLI 是純文字的，AI 天生就在這個世界里運作。

AI 想幫你壓縮視頻，不需要打開 Premiere 找導出按鈕。它跑一行ffmpeg -i input.mp4 -crf 28 output.mp4就完事了。

人類沒有重新愛上命令行。是 AI 原本就生活在命令行里。

AI 的能力邊界在哪？

很多人把 AI 想象成全知全能的大腦。

更準確的比喻是：一個非常聰明的新員工，什么都能學，學得快，但需要兩樣東西，工具和說明書。

裝了 ffmpeg，AI 能處理視頻。裝了飛書 CLI，AI 能幫你查日程、發消息。

裝了 Google Workspace CLI，AI 能管你的郵箱和云盤。

沒裝？"不好意思，這個我做不了。"

ffmpeg：一款開源音視頻處理工具，幾乎是視頻處理的行業標準。brew install ffmpeg就能裝上，AI 從此能幫你壓縮視頻、轉格式、截片段。

AI 的實際能力 = 它能調用的工具 + 它拿到的上下文。

工具好理解。"上下文"是什么？簡單說就是說明書。

對于 ffmpeg 這種經典工具，AI 在訓練時已經見過海量用法，不需要額外說明書。

但飛書 CLI 是 2026 年剛發布的，AI 的訓練數據里完全沒有，你不給說明書，AI 根本不知道它存在。

所以新一代 CLI 工具都自帶一種叫 Skills 的文件，本質就是 Markdown 寫的說明書，告訴 AI 這個工具能做什么、怎么用。

這里有個推論值得注意：工具越新，AI 越依賴這種顯式說明書。

訓練數據永遠追不上工具發布速度，說明書只會越來越重要。

CLI 正在被重新發明

過去的 CLI 和現在的 CLI，雖然都叫 CLI，已經是兩種東西了。

傳統 CLI，比如 ffmpeg、jq、curl，是給程序員用的。

輸出是給人眼看的彩色文字。遇到需要選擇的時候會彈交互式菜單，對人來說很自然，但 AI 遇到這種彈窗直接卡住。

新一代 CLI 從設計之初就假設調用者可能是 AI：

所有操作通過參數一次性傳入，不彈菜單；

輸出 JSON 格式，AI 直接解析；自帶 Skills 說明書；

支持--dry-run預覽，讓 AI 執行前先看看會發生什么；

AI 還能問工具"你有哪些命令？需要什么參數？"不用讀完整文檔。

拿飛書 CLI 舉例：裝完以后 200 多條命令，覆蓋日歷、消息、文檔、任務、郵箱等 11 個領域。

你說"幫我看看明天有什么安排"，AI 調用lark-cli calendar +agenda；

說"給張三發條消息說會議改到三點"，AI 調用對應的消息命令。整個過程不用打開飛書 app。

Google Workspace CLI 更極端，一條命令啟動一個 MCP 服務，讓 AI 直接通過標準協議操作 Gmail、Google Drive、Google Calendar。

MCP（Model Context Protocol）：AI 與外部服務之間的標準通信協議，下節有完整解釋。

CLI 正在變成 AI 的萬能插件

這里說一個我在做 CodePilot 過程中觀察到的現象，目前還很少被討論到。

先用一句話解釋三個概念：

MCP：AI 和外部服務之間的標準通信協議。你可以理解成 AI 世界的 USB 接口。

Skills：告訴 AI"這個工具怎么用"的說明書。

Plugin：把工具、協議、說明書打包在一起的可安裝擴展。類似手機上的 App。

AI 圈一直在討論這三個東西哪個會成為主流。

但你仔細看新一代 CLI 在做什么，會發現它們把這三樣全打包了。

Google Workspace CLI 就是典型：CLI 命令提供執行能力，內置 MCP 服務提供標準通信協議，自帶 Skills 文件充當使用說明書。

飛書 CLI、Stripe CLI、ElevenLabs CLI、網易云音樂 CLI，全是這個模式。

一個 CLI 工具就是一個事實上的 Plugin。

但它比 Plugin 多了幾個好處。

Claude Code 的 Plugin 只能在 Claude Code 里用。

飛書 CLI 裝了以后，Claude Code、Cursor、Gemini CLI 都能用，不鎖平臺。

這一點在國內尤其重要，因為眾所周知的原因，用戶可能今天接 Claude，明天換 DeepSeek，后天試 Qwen。

CLI 不關心調用它的是哪個模型，它是模型無關的執行層。

Plugin 商城有審核流程，CLI 工具往 npm 上 publish 就上線了，跟發網站一樣自由。

而且人也能用，不裝 AI 也能在終端里直接敲命令，開發者有更大的動力去做和維護。

npm：開發者版本的 App Store，大量命令行工具通過它分發安裝。運行npm install -g 工具名就能裝上。

CLI 還有一個 Plugin 做不到的事：

組合。gws gmail +triage | jq '.messages[]'，兩個工具用管道串起來，前一個的輸出變成后一個的輸入。

Shell 管道這個幾十年前的設計，在 AI 時代突然又變得值錢了。Plugin 之間是隔離的，沒有標準的組合方式。

大家在爭 MCP、Skills、Plugin 哪個會贏，答案可能是 CLI 把它們全打包了，而且跨平臺。

但事情沒那么美好

說了這么多好處，該說問題了。

CLI 最大的結構性缺陷是安全。

Plugin 在平臺沙箱里跑，有聲明式權限控制。

CLI 是直接執行 shell 命令，AI 一旦能跑gws，就能用這個身份做任何事。

沒有"只讀不寫"的細粒度控制。目前靠--dry-run和彈窗確認來補救，但跟平臺級權限框架比，差距很大。

沙箱：一種隔離運行機制，類似手機 App 的權限彈窗——"是否允許訪問相機？"。程序只能做它被允許做的事，出了問題也不影響系統其他部分。

具體到實際使用，我在 CodePilot 里接入各種 CLI 工具的過程中也踩了不少坑。

第一個：說明書太大，AI 腦子撐爆了。

有些工具有非常大的 Skills 文件。AI 的上下文窗口有容量限制，這一個文件就占掉一大塊，加載完推理質量明顯下降。

對比之下，Google Workspace CLI 的 Skills 文件平均 1.6KB，精準給 AI 需要的信息，不多不少。

第二個：交互式提示卡死 AI。

Stripe CLI 早期版本彈? Which environment?選擇菜單，人覺得挺自然，AI 直接卡住不動了。后來加了--no-interactive才解決。

第三個：輸出太長，淹沒有用信息。

一個查詢返回幾萬字符 JSON，全灌進上下文，真正需要的信息反而找不到了。

Google Workspace CLI 用 field masks 控制返回大小，這個設計目前很少有工具跟進。

field masks：調用 API 時指定只返回哪些字段，而不是把所有數據都倒回來。查郵件只要主題和發件人，不要正文，上下文省一大塊。

這幾個問題有一個共同根源：

"為 AI 設計"和"在 AI 中驗證"是兩件事。就像移動端適配，設計稿上看著響應式沒問題，真機上按鈕根本點不到。

我的實驗：讓 AI 管理自己的工具

做 CodePilot 的 CLI 管理功能時，我經歷了一次思路轉變。

一開始是傳統軟件思路：

寫代碼嗅探用戶系統裝了什么、寫 UI 讓用戶在界面上管理工具、寫邏輯檢測更新。標準做法。

后來想明白了一個問題：我產品里已經有 AI 了，為什么要繞過它？

安裝工具，直接拉起對話讓 AI 來。

AI 讀--help，判斷操作系統，處理權限錯誤，引導認證配置。

安裝報錯了它能讀錯誤信息自己判斷，要不要 sudo？先裝個依賴？

注冊工具也一樣，給 AI 一個提示詞模板，讀完--help自動生成結構化描述，工具能做什么、怎么用、典型場景。

sudo：macOS/Linux 上臨時獲取系統管理員權限的命令。安裝某些工具需要寫入系統目錄，普通權限不夠，加 sudo 才行。

別用軟件幫用戶管理 AI 的工具，讓 AI 管理自己的工具。

每個工具的情況都不一樣，用代碼寫死安裝邏輯是寫不完的。

但 AI 能處理這種開放式問題。把工具安裝變成 AI 任務，比寫一個覆蓋所有邊界情況的安裝器靠譜得多。

我還做了一個 5 維 Agent 兼容度評分，從是否為 AI 設計、是否支持結構化輸出、是否支持自查、是否支持預覽、是否注意上下文大小五個方面去打分。

說實話這個評分更多是一個呼吁：希望工具開發者開始想"我的 CLI 對 AI 友好嗎？"

還缺什么？

CLI 正在成為 AI 能力擴展的基礎設施，但有幾個明顯缺口。

你怎么知道"有個飛書 CLI 能讓 AI 操作飛書"？

目前基本靠口口相傳。npm 和 GitHub 最有條件做 AI 工具的 App Store，但它們沒這個動力。發現機制是空白的。

認證也是問題。

飛書一套登錄，Google 一套，Stripe 一套，裝五個工具登錄五次。對普通用戶來說摩擦太大了。

安裝體驗也不靠譜。

npm、brew 是十幾年前設計的，假設使用者是懂命令行的開發者。

當操作者變成 AI，權限問題、依賴缺失、路徑沖突這些"查 Stack Overflow 就能解決"的問題，變成了真正的障礙。

Homebrew（brew）：macOS 上最流行的包管理器，專門用來安裝命令行工具。brew install ffmpeg裝 ffmpeg，brew install jq裝 jq，就這么簡單。

行業不缺工具，不缺協議，不缺說明書。

缺的是讓這三樣東西被發現、被安裝、被信任的那一層基礎設施。

誰做出來這個，誰就是 AI 時代的 npm。

所以，為什么大家都在做 CLI？

大家意識到 CLI 可能是當下效率最高的 AI 能力分發方式。

一個 CLI 工具同時包含執行能力、通信協議和使用說明，就是一個完整的 AI 插件。

跨平臺，免審核，人和 AI 都能用。

每多裝一個好用的 CLI 工具，你的 AI 就多一項技能。每少一分多余的上下文噪音，你的 AI 就聰明一點。

我們正處在一個混亂的新舊交替時代。

舊的格式、舊的數據壁壘、舊的包管理器，和新的 AI 原生工具鏈交織在一起。

CLI 不是唯一的答案，但它是目前最務實的那一個。

好了，以上就是今天的內容。如果覺得寫得還不錯的話，可以幫我點個贊，或者轉發給你需要的朋友。

這里嘗試 CodePilot：https://github.com/op7418/CodePilot

引用：

[1] 過了個年，AI 圈變天了？但沒人告訴你為什么 — https://mp.weixin.qq.com/s/z7zNi_DayzevcTe0EUTv5g

[2] You Need to Rewrite Your CLI for AI Agents — https://justin.poehnelt.com/posts/rewrite-your-cli-for-ai-agents/

[3] Stripe Projects CLI — https://docs.stripe.com/projects

[4] Building CLIs for agents — https://x.com/ericzakariasson/status/2036762680401223946

[5] MenuGen — https://karpathy.bearblog.dev/vibe-coding-menugen/

[6] Google Workspace CLI — https://github.com/googleworkspace/cli

[7] 飛書 CLI — https://github.com/larksuite/cli