Mistral Vibe 證明 CLI 代理仍然重要

Mistral Vibe 證明，本地、可審批的 CLI 代理仍然最適合寫程式工作。

Mistral Vibe 不是要取代編輯器、repo 或工程師判斷，而是要嵌進既有工作流，這正是它重要的原因。它提供檔案編修、shell 執行、git 感知、subagent 與明確的 approval 控制，還支援 Windows 並強調 UNIX 環境更成熟。再加上 uv、pip 與一鍵安裝腳本，目標很清楚：它面向的是每天在終端機裡處理真實程式碼的工程師，而不是只想看一個漂亮網頁的觀眾。

第一個論點

CLI 才是寫程式的原生介面。程式碼本來就活在終端機裡，Mistral Vibe 也順著這個事實設計：它能讀寫與 patch 檔案，能在有狀態的 terminal 裡跑 bash，能用 grep 遞迴搜尋，還能在工作過程中維護 todo list。這不是炫技，而是直接貼合工程師排查 bug、重構模組、追 failing test 的實際回圈。

它的功能清單也比口號更有說服力。slash command 與檔案路徑補全、持久化命令歷史、透過 @ 夾帶圖片、以及適合鍵盤操作的快捷鍵，都是在把終端機變成控制台，而不是聊天框。這種設計尊重本地開發的速度，也避免把原本就很自然的 shell 工作流硬搬進瀏覽器。

第二個論點

真正有用的代理，關鍵不是更自主，而是更可控。Mistral Vibe 把 autonomy 做成一組明確模式：default 需要審批才能執行工具，plan 是唯讀，accept-edits 只對檔案修改自動放行，auto-approve 才是全自動。這個分層很重要，因為大家對 coding agent 最大的疑慮從來不是能不能做，而是做錯時會波及多大。

它的 trust folder、session 管理、custom system prompt、tool permissions 與 update prompts，也都在傳達同一件事：代理應該先證明自己，再拿到更多權限。官方同時坦白說它以 UNIX 為主、Windows 仍可用但不是最強場景，這種誠實反而加分。比起假裝所有平台都一樣成熟，清楚標示邊界更像一個能落地的工程產品。

反方可能怎麼說

最強的反對意見是，CLI 代理仍然是 power user 的小眾工具。終端機優先的產品要求使用者熟悉 shell、能接受設定檔與 API key、也能理解 trust prompt 的意義。對某些團隊來說，這確實比一個有圖形化審查層的產品更難上手，尤其是非工程角色加入時，門檻會更明顯。

另一個合理擔心是，只要代理能碰 shell 和檔案，就永遠存在誤操作風險。即使有審批機制，使用者還是得看懂它要做什麼，這代表監督責任不會消失。若團隊需要集中政策、稽核紀錄或高度託管的企業介面，CLI 工具看起來就會太開放。

這些批評成立，但不足以推翻 Mistral Vibe。它從來不是在宣稱自己是所有人的最安全抽象層，而是在主張：對已經在終端機工作的工程師來說，它是最快、最順手的抽象層。approval 模式、trust folder 與唯讀 planning agent，正是讓這個取捨成立的機制。CLI 代理不該假裝沒風險，它應該把風險攤開並提供控制，而這正是它做對的地方。

你能做什麼

如果你是工程師，把 Mistral Vibe 用在最吃緊密回饋的場景：repo 探索、局部重構、測試驅動修改、以及靠 shell 進行的除錯。先用 plan 模式做探索，再切到 default 取得審批流程，只有在你完全理解影響範圍時才用 auto-approve。若你是 PM 或創辦人，應把這件事視為一個訊號：代理產品要真正被採用，不是靠更華麗的介面，而是要貼合開發者既有習慣，尤其是終端機工作流。