SSH 的 AI 命令生成：10,000 名用户教会我们什么

为什么 SSH 比聊天难

让 LLM 写一行 shell 命令听起来是个小问题。其实不是。在聊天产品里，错答案的代价是用户重看或再问。在 shell 里，错答案的代价是一条命令在生产服务器上跑起来。当输出会被执行时，「够用」的门槛要高得多。

我们在 TermAI v0.4 上线了 AI 命令助手，看了一年的遥测。约三分之一用户每天用；约一半每周用；四分之一基本不碰。每天用的用户是我们最认真听的 —— 他们发现了每一个小毛病，且有自己的看法。

上下文：发多少、发什么

第一版只发用户问题，别的什么都不送。模型经常猜错 shell 上下文 —— 你在 Alpine 上它假设 Ubuntu，你用 zsh 它假设 bash，你不是 root 它假设你是。

所以我们加了上下文。但加多少？

最便宜的做法是发完整终端 scrollback。我们没那么做，三个理由：

隐私。Scrollback 含一切 —— 文件内容、输出、滚走的密钥。默认发给模型感觉不对。
Token 成本。长上下文贵。AI 助手免费档要用；我们承担不起每次调用 10× 成本。
质量。反直觉地，更多上下文经常**伤害**答案。模型会咬住 scrollback 里某个跟新问题无关的老错误。

最终上线行为是一份精选快照、而非整段回滚：操作系统和已装工具、这台机器当前的磁盘/内存/CPU 负载、最近约 30 行输出、以及你最近的命令和它们的结果。够把答案锚定在**当前**会话里，又不必把整段历史都塞进去（也不必为此付费）。代理在转发前剥离 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。更快、更便宜，经常更好。