SSH 的 AI 命令生成：10,000 位使用者教會我們什麼

為什麼 SSH 比聊天難

讓 LLM 寫一行 shell 命令聽起來是個小問題。其實不是。在聊天產品裡，錯答案的代價是使用者重看或再問。在 shell 裡，錯答案的代價是一條命令在生產伺服器上跑起來。當輸出會被執行時，「夠用」的門檻要高得多。

我們在 TermAI v0.4 上線了 AI 命令助手，看了一年的遙測。約三分之一使用者每天用；約一半每週用；四分之一基本不碰。每天用的使用者是我們最認真聽的 —— 他們發現了每一個小毛病，且有自己的看法。

脈絡：傳多少、傳什麼

第一版只傳使用者問題，別的什麼都不送。模型經常猜錯 shell 脈絡 —— 你在 Alpine 上它假設 Ubuntu，你用 zsh 它假設 bash，你不是 root 它假設你是。

所以我們加了脈絡。但加多少？

最便宜的做法是傳完整終端機 scrollback。我們沒那麼做，三個理由：

隱私。Scrollback 含一切 —— 檔案內容、輸出、滾走的金鑰。預設傳給模型感覺不對。
Token 成本。長脈絡貴。AI 助手免費檔要用；我們承擔不起每次呼叫 10× 成本。
品質。反直覺地，更多脈絡經常**傷害**答案。模型會咬住 scrollback 裡某個跟新問題無關的老錯誤。

最終上線行為：助手看到當前工作目錄、上一條命令的退出碼、最近 5 行輸出。夠把答案錨定在**當前**會話裡，又不洩露其他。代理在轉發前剝離 IP、主機名、明顯的金鑰。使用者可以完全關閉脈絡要「裸 prompt」。

能用的 prompt 設計

Prompt engineering 值得單獨寫一篇，但一年迭代下來收斂的模式長這樣：

System: You are a shell command generator. Output ONLY a runnable
command, no explanation. If the request is ambiguous, generate the
most common interpretation. Do not include backticks or markdown.
Target shell: {detected_shell}
OS: {detected_os}

User: {question}

Context (last 5 lines of output):
{context_lines}

兩個關鍵。第一，我們告訴模型只輸出命令、只輸出命令 —— 沒有前言。行動使用者要的是結果，不是教學。第二，系統 prompt 說「最常見解讀」而不是請求澄清。在 ChatGPT 裡透過聊天請求澄清沒問題；在終端機裡那是多一個來回打斷節奏。如果使用者想要更具體的東西，他們會編輯結果。

執行前確認

產生的命令永不自動跑。助手產生建議；你點按傳送到終端機。這聽起來理所當然，但這是整個產品最重要的 UX 決定。使用者信任助手恰恰因為它不帶來意外。

每條建議三個動作：執行原樣傳出去，編輯放進輸入行調整，取消關掉建議。我們考慮過且短暫上線「簡單命令自動跑」模式。使用者討厭。即使是 ls 也要這一點，因為助手接下來建議的可能不是 ls。

把錯誤貼進去當脈絡

最常用的流程結果不是命令生成，是錯誤分析。模式：使用者跑命令、失敗、選錯誤輸出、點「問 AI 這個」。助手拿到錯誤、失敗的命令、scrollback 最近幾行當脈絡 —— 解釋哪裡出問題。

這一個功能可能占了助手 40% 用量。錯誤訊息棘手又嚇人；LLM 是真的擅長解析它們。我們加了一個 fast-path：偵測到輸入像錯誤（比對 sshd、nginx、systemd、docker 等已知模式），就路由到更小的模型，用更緊的錯誤解釋 prompt。更快、更便宜，經常更好。