终端里加两个问号就能排障？我用完 Xterminal 小易，先把自动执行关了

排查磁盘告警时，终端里同时开着测试机和生产机。我输入“找出最近 7 天超过 100MB 的日志??”，小易很快给出一条 find 命令。让我停下来的点不在命令语法，而在光标当时所在的标签页：如果直接按回车，AI 的建议就会从“候选答案”变成生产环境里的真实动作。

这件事让我重新看 Xterminal 的 AI 功能。小易是一个能放进 SSH 排障流程的 AI 命令助手，可以分析错误、生成命令、读取允许的上下文，也可以在 AI Agent 模式下分步骤调用工具；终端里的 ?? 适合快速解释或生成命令。最值得建立的习惯，是把“让 AI 给建议”和“让命令进入远程环境”拆成两个动作，先填充，后核对，再执行。

普通补全和 AI 建议，解决的不是同一件事

普通补全依赖 Shell Integration、历史、内置建议和快速命令，通常在本地即时出现，适合补齐路径、参数或已经熟悉的命令。AI 命令辅助由当前 AI 提供商和模型生成，响应需要网络，能解释命令、改写目标和给出排障方案。

输入 cd /var/lo 时，普通补全更适合帮你找到目录；输入“检查当前目录下最近 7 天修改过的大于 100MB 的日志文件??”时，AI 才有机会把自然语言转成候选命令，并解释时间范围、大小和匹配条件。一个解决输入速度，一个解决表达和理解，不能互相替代。

如果 Shell Integration 没有就绪，普通补全的目录和退出状态可能不完整，但这不一定说明 AI 配置坏了。排障时我会先确认自己是在等待本地补全，还是在等待远程模型响应，避免把两个问题混在一起。

?? 的确方便，但问题要小到能回读

在终端输入命令或问题，并在当前输入行加入两个连续的 ?，按 Enter 就会打开 AI 助手。例如：

docker run??

它适合快速问“这条命令做什么”“有没有更安全的写法”，也适合在当前目录和终端上下文里生成候选命令。启用入口在 设置 > 通用终端 > 命令提示 的“AI 助手快捷触发（??）”。如果 ?? 与通配符或脚本语法冲突，可以关闭这个快捷触发。

我不会把完整事故经过、整段生产日志和多个目标混在一条 ?? 请求里。问题越大，模型越容易把真正的约束藏在回答后面。更稳的做法是先描述一个动作，例如“只读检查当前目录中的日志，不使用 root”，拿到候选命令后再切到小易对话继续追问。

Chat、Agent、手动确认，风险边界完全不同

小易的三种模式不是不同皮肤。聊天（Chat）先分析并使用允许的只读工具，不直接执行写入操作，适合学习、解释和初步排障。自动协助（Agent）可以围绕一个目标分步骤分析，并在允许范围内使用工具，适合需要多次检查的任务。手动确认则要求每一步工具操作先停下来，适合生产环境和高风险变更。

自动协助不会因为名字里有 Agent 就绕过终端或服务器确认。涉及命令时，仍会展示目标、命令、执行原因和风险提示。关闭工具使用后，小易只提供对话、解释和建议，不会直接操作终端。这个开关很适合拿来做第一轮排障：先让模型读错误和配置，再决定是否给它更窄的工具权限。

我会把 Chat 当默认入口，把 Agent 当成范围确认后的工作模式，把手动确认留给所有会改变状态的动作。这样做会多一次点击，但每次升级风险时都有明确的停顿位置。

生成命令后，先填充再执行

AI 命令建议里通常有“填充”和“回车执行”两条路径。填充只把命令放进当前终端输入区，不发送回车；回车执行则把它真正提交到当前终端。涉及删除、覆盖、重启、权限修改或生产环境时，我只选择填充，然后逐项检查目标主机、工作目录、通配符、重定向和权限。

例如小易给出：

find /var/log -name "*.log" -mtime -7 -size +100M

这条命令的风险不在 find 本身，而在路径和筛选条件是否符合当前机器。若它被填充到测试机的终端里，先运行只读的 pwd、hostname，再决定是否执行；如果命令中出现 rm -rf、dd 或 chmod 777，我会把它当作需要重新设计的方案，而不是只检查拼写。

小易也能解释 Permission denied (publickey)，但回答只是候选排查路径。公钥是否部署、私钥是否匹配、.ssh 权限是否正确，仍要结合服务器真实状态验证。命令能运行和结论正确，是两件事。

选中的错误文本，是比整段日志更好的上下文

在终端选中 Permission denied (publickey) 等错误文本，可以通过右键菜单的“选中文本 > 咨询 AI 助手”发送给小易。这个动作比复制整段屏幕更容易控制敏感信息，也能把问题限制在一个明确的错误上。

小易会使用当前对话消息作为上下文，服务器地址、命令和错误输出也可能进入后续请求。连续追问有助于保持同一个目标，但切换话题时应清空上下文或新建对话，否则上一台服务器的路径可能继续影响下一次回答。

我会先做一次脱敏：删掉密码、令牌、私钥内容、内部域名和不必要的完整日志，只保留错误类型、系统版本、当前目录和目标。使用自定义 Anthropic 或 OpenAI 兼容接口时，对话内容会发给选定服务商，数据处理范围要在启用前确认。API 密钥只保存在当前设备，不应写入笔记、导出文件或截图。

扩展思考不是准确率开关

支持的模型可以在 设置 > AI 助手 > 高级配置 中开启扩展思考，并选择简略、标准或深度。更大的推理预算通常意味着更详尽的回答，也可能带来更长等待和更高消耗；最终是否生效还取决于当前模型和接口。

我会把扩展思考用在需要比较多种排查路径的任务上，例如“跳板机已连通但目标端口超时，如何分别验证网络、认证和转发权限”。对于一条简单的 ls 命令，打开深度思考只会增加等待，不会替你确认路径是否写对。更长的回答也不等于更可靠，事实仍要回到终端输出和服务器文档。

如果回复被截断或响应很慢，可以先让小易总结，再继续追问细节；复杂问题拆成几个小问题，通常比不断提高思考深度更容易回读。

批量服务器和高风险命令要有停止条件

小易支持选择多个目标，并显示目标数量、每个目标的执行状态和输出摘要；这对批量读取版本和状态很有帮助，也更容易把测试命令发送到生产环境。批量执行前，我会先确认范围，再用只读命令回读主机名，最后逐台放行有副作用的动作。

需要交互式密码、动态验证码或持续运行的程序时，也不适合只依赖 AI 工具。回到 Xterminal 的 SSH 终端，保留人工输入和会话状态，往往更清楚。AI 可以生成 tmux、日志查看或检查命令，但不会替你判断当前会话是否经过正确跳板，也不会自动理解发布窗口里的业务约束。

还有一个反例：为了让答案看起来完整，把所有服务器信息和整段日志一次性提供。这样可能得到一份很长的建议，却失去最重要的可控性。我的停止条件很简单：命令无法在一个明确的目标、目录和权限下解释清楚，就先不执行。

我会把“可回读”写进每一次 AI 请求里。命令生成后先看目标主机和当前目录；命令执行后看退出码和关键输出；工具调用后确认它读的是哪一台服务器、写的是哪一个文件。即使只是查看磁盘，也先用 hostname 和 pwd 把标签页身份重新钉住。这样做不会让模型更聪明，却能让错误更早暴露。

同样的原则适用于小易给出的替代写法。它可能把 du、find 和 sort 组合成一条很长的管道，语法看起来完整，但其中一个目录不存在、一个通配符匹配过宽，结果就会偏离原问题。我会要求它先解释每一段，再把复杂命令拆成两三条只读命令逐步验证。命令短一点，人工确认才有实际意义。

如果回答引用了当前服务器的路径或版本信息，我会把这些信息和终端真实输出对照，而不是把模型的复述当成证据。对话可以帮助整理线索，事实仍然来自机器本身。

当问题已经从“解释错误”进入“修改系统”，我会重新打开确认流程，而不是沿用前一轮对话的信任。清空上下文、重新说明目标和权限，有时比继续追问更快，也更不容易把上一台服务器的约束带进生产环境。

我会把 Xterminal AI 放进哪一段工作流

我会把一次排障分成四个小动作：先用普通补全或命令搜索确认语法，再用 ?? 询问一个短问题；需要连续分析时进入 Chat，让小易读取经过脱敏的上下文；需要工具操作时先限定目标和模式，所有写入动作保持手动确认；最后把经过核对的命令和结果整理进笔记或工单。

这个流程没有承诺 AI 会自动修好服务器。它真正省下的是把模糊问题改写成可验证问题的时间：当前在哪台机器、要读哪个目录、命令会改变什么、结果如何回读。Xterminal 的优势在于终端、对话和确认流程挨得很近；限制也同样明确，模型需要网络和可用接口，回答可能不准确，工具权限和上下文都要由人维护。

我会把确认后的命令连同目标、时间和结果一起留在工单里，而不是只保存一句“AI 建议执行”。这样下次遇到相似告警时，团队能复查当时的上下文，也能判断哪些步骤适合再次交给模型，哪些步骤应该固定成脚本。

如果只是记不住一个参数，普通补全和命令搜索更快；如果要理解错误、比较方案或生成一条带约束的候选命令，小易更值得打开。我会看每次使用后能不能留下可复现的命令、明确的目标和经过确认的结果。能回读，才算真正帮上忙。

这也是我最后保留小易的原因：它帮我少走弯路，但没有替我按下最后那个回车。