為什么在 AI 時代，最古老的交互形式反而卷土重來？

2025 年到 2026 年間，頂級 AI 公司相繼發布了一類產品：CLI 形態的 Agent 工具。

Anthropic 發布了 Claude Code，一個在終端里運行的 AI 編程助手。OpenAI 發布了 Codex CLI，Google 發布了 Gemini CLI。這一波浪潮中，幾乎每家值得關注的 AI 公司都押注了命令行。

這很反直覺。命令行是 1970 年代的產物，GUI 的出現讓計算機走入大眾，現在移動互聯網讓觸屏操作成為默認。按照通常的邏輯，技術的方向應該是越來越 「可視化」、越來越 「易用」。為什么在 AI 時代，最古老的交互形式反而卷土重來？

答案不是情懷，是工程邏輯。

GUI 對 AI 并不友好

GUI 是為人類視覺導航設計的。按鈕、彈窗、拖拽、懸停效果 —— 這些交互范式建立在人類的視覺直覺上。人類看一眼界面，掃描按鈕位置，憑直覺判斷下一步操作。這套機制對人類來說極其自然，幾乎不需要學習成本。

但 LLM 的工作方式根本不是這樣。LLM 的輸入是 token，輸出也是 token。它的 「思考」 在語言空間里發生，而不是在像素空間里。

讓 AI 操控 GUI，意味著要跨越一道巨大的鴻溝：

理解成本極高。AI 需要借助計算機視覺或 Accessibility Tree 來 「看懂」 界面 —— 哪個按鈕可點、哪個輸入框在哪里、當前彈窗是什么意思。這不是 AI 的強項，反而是額外負擔。

狀態隱式且不可預測。同一個按鈕，今天可點，明天可能因為某個條件變灰。這種隱式狀態對人類來說是 「上下文」，對 AI 來說是不確定性 —— 它無法可靠地推理 「這個操作在什么條件下可用」。

操作不可組合。沒有辦法把兩個 GUI 操作用管道連起來。「搜索結果 → 過濾 → 導出」在 GUI 里是三次點擊，沒有辦法作為一個整體傳遞、復用或自動化。

難以測試和驗證。AI 執行了一個 GUI 操作，怎么確認它成功了？要截圖、要解析界面狀態，整個反饋循環又慢又脆。

相比之下，CLI 的每個特性都像是專門為 AI 設計的。

▍CLI 對 AI Agent 的三大優勢 可組合性

Unix 哲學的核心是：「每個程序只做一件事，并把它做好；讓程序能夠協同工作」。

這個幾十年前的設計原則，在 AI 時代煥發出新的意義。

CLI 工具通過標準輸入輸出串聯。linkly search "React 性能優化" | head -5可以把搜索結果傳給下一個命令。linkly search "架構設計" --json | jq '.results[].doc_id'可以提取所有文檔 ID 用于后續處理。

對 AI Agent 來說，可組合性意味著可以把多個命令鏈接成復雜的多步驟工作流，每一步的輸出都是結構化的文本，可以被下一步消費。沒有 GUI 的 「點擊 → 等待 → 截圖 → 解析」循環，只有干凈的輸入輸出。

可預測性

每個命令的行為完全由參數決定。linkly search "數據庫" --limit 10今天執行是這個結果，明天執行（假設數據庫沒變）還是這個結果。沒有隱式狀態，沒有 「這個功能上次為什么好使現在又不好使」 的困惑。

這對 AI 極其重要。AI 在推理一個工具時，需要建立一個心智模型：這個工具的輸入是什么，輸出是什么，有什么副作用。GUI 的隱式狀態讓這個心智模型充滿不確定性。CLI 的顯式參數讓這個心智模型可靠而精確。

linkly read 42 --offset 80 --limit 100—— 這個命令的含義完全由參數決定。AI 可以精確推理它的行為，不需要猜測任何隱式上下文。

可審計性

所有 CLI 操作都是可記錄的文本序列。AI 執行了什么命令、得到了什么輸出，都是人類可讀的文本。

這種透明性有兩個好處。

對 AI 自身：可以做自我檢查。「上一步linkly search "合同模板"返回了 0 個結果，說明關鍵詞不對，換成合同 范本再試。」 這種基于文本的自我糾錯是 AI Agent 能夠可靠工作的基礎。

對人類：可以做事后審查。你可以查看 AI 運行了哪些命令、每步的輸入輸出是什么，整個推理鏈路一目了然。GUI 操作的 「點了什么」 很難被追溯，CLI 操作的日志天然就是審計記錄。

▍Linkly AI CLI 的設計實踐

LinklyAI 是我們自己開發的本地搜索引擎和知識庫創建軟件。在設計 Linkly AI 的 CLI 工具時，我們從一開始就把 AI Agent 當作主要用戶之一來考慮。

4 個精心設計的核心命令

Linkly AI CLI 的核心命令只有四個：

linkly grep                           # 全文正則搜索

這四個命令完全符合 Unix 哲學：每個只做一件事，有明確的輸入輸出契約。AI Agent 可以把它們任意組合成復雜的檢索流程。

一個典型的 Agent 工作流如下：

linkly read 42 --offset 80 --limit 100

每一步的輸出都是結構化文本，可以直接被 AI 消費和推理。沒有任何 GUI 操作，沒有任何視覺解析的負擔。

與管道等進行組合

CLI 的另一個優勢是可以和系統中其他命令自由組合，帶來超出單個工具能力邊界的新能力。

過濾和提取：--json輸出可以直接接jq提取字段，結果再傳給下一個工具：

linkly search "數據庫設計" --json | jq -r '.results[].doc_id' | xargs -I{} linkly outline {}

與grep組合做二次過濾：先用語義搜索縮小范圍，再用精確關鍵詞過濾：

linkly search "架構設計" | grep -i "微服務\|分布式"

統計和分析：配合wc、sort、uniq等做文檔統計：

linkly search "" --json | jq '.results[].type' | sort | uniq -c

與腳本結合：在 shell 腳本里批量處理，自動化重復任務：

> all-outlines.txt

GUI 工具無法參與這些組合。CLI 工具的輸出是文本流，天然可以被任何其他工具消費，這讓整個系統的能力遠大于各個工具的簡單相加。

CLI 也是最簡單的 MCP 橋接方式

CLI 和 MCP 并不是對立的。linkly mcp一條命令可以把 CLI 變成一個 stdio MCP 服務器，供任何支持 MCP 的 AI 客戶端使用：

Json：

}

這比直接配置 HTTP MCP Server 簡單得多 —— 用戶不需要知道端口號，不需要手寫 JSON 里的 URL，只需要告訴 AI 客戶端 「運行這個命令」。

CLI 成了 MCP 生態的入場券，對用戶幾乎零配置摩擦。

▍更宏觀的趨勢

Claude Code 選擇優先發布 CLI 形態而不是 IDE 插件，這個決定背后有清晰的工程邏輯：IDE 插件受限于宿主環境，CLI 工具可以在任何有終端的地方運行，可以被任何 Agent 調用，可以和任何其他工具組合。

這揭示了一個更根本的規律：AI Agent 調用工具的本質，就是在執行命令。工具調用（function call /tool use）從語義上就是 CLI—— 給定名稱和參數，返回結果。CLI 工具天然就是 Agent 可以調用的函數，不需要任何轉換層。

「Terminal as the new IDE」這個說法早在 AI 興起之前就有人提過，但在 AI 時代它獲得了全新的含義。不只是 「在終端里寫代碼」，而是 「Agent 通過終端與世界交互」。

過去，CLI 是技術人員的專屬工具。未來，CLI 可能會成為 Agent 的通用語言 —— 人類通過自然語言和 Agent 對話，Agent 通過 CLI 和系統交互。

▍小結

GUI 的地位不會受到太大影響，它仍然是人類直接操作計算機的最佳界面。但當你的 AI 工具需要調用另一個工具時，CLI 是最自然的橋梁，會有更多的軟件為了順應 Agent 習慣推出更多的 CLI 工具。

想試試在終端里搜索你的文檔？看看這兩篇文章：不離開終端，讓 AI 搜索你的文檔 和 一行命令，讓 30+ AI 工具讀取本地文件。

https://sspai.com/post/107173?utm_source=wechat&utm_medium=social

作者：Blueeon

/產品推薦/