做运维的应该都有过这种时刻屏幕上开着三个窗口左边是 SSH 客户端连着生产服务器中间是记事本密密麻麻记着 IP、命令片段和同事发的报错右边是聊天框把报错原文整段贴过去问 AI。三个窗口来回切换复制、粘贴、翻记录、再复制一个故障处理下来光上下文迁移就占了大半时间。我花了大概两个月做了个把这三件事收拢到一起的 AI 运维工作台名字就叫 Mini Assistant。它本质上不复杂就是把终端、笔记和 AI 诊断放进同一个会话体系里让每次排查的动作和结论自动落盘让 AI 始终知道我们刚才在干什么。这篇分享就讲讲我为什么做、怎么做的以及真实使用了一个多月之后哪些设计经受住了考验哪些已经被我推翻重来。1. 三开模式的真相切换不是成本丢失上下文才是1.1 一次故障排查里的五次窗口切换我先描述一个最典型的排查场景。某天服务突然告警请求成功率掉到 90% 以下。大多数人第一反应是切到 SSH 客户端连服务器先跑top看一眼负载再翻日志。看到一大段报错之后本能是复制、切到聊天框把报错粘给 AI 问它什么意思。AI 回了一堆可能的排查方向于是切回终端继续查。查到一半发现上个月处理过类似问题、当时的步骤写在记事本里又要切到记事本翻。翻了半天找到的笔记只有一句话“上次重启了下游服务就好了”没有前置判断没有验证过程等于没写。这个流程里上下文搬家至少做了五次终端到聊天框、聊天框回终端、终端到记事本、记事本回终端、再把 AI 建议复制到记事本留档。每一次切换看起来只花几秒钟但当问题复杂度上升之后真正崩溃的不是切换动作本身而是切换之后“我刚才查到哪了”的失忆。人脑的工作记忆槽位是有限的既要记排查进度又要记聊天框里 AI 提到的最小权限用户是什么还要记记事本里那台机器别名对应哪台真实 IP信息一多就开始乱套。1.2 上下文断裂带来的三个隐形开销表面上是切换成本实际上是上下文断裂。第一个代价是重复排查。AI 不知道你已经确认过系统负载没问题于是又把负载检查放在第一条建议里推给你你得花两三分钟告诉它“这个查过了没有异常”。第二个代价是信息被稀释。排查过程里最有价值的中间判断比如“内存占用不高但 IO 持续写入”散落在终端回显、聊天记录和随手笔记三个地方没有一个位置能还原完整链路。第三个代价是经验难以沉淀。处理完一个故障如果不刻意整理下次遇到几乎从零开始。记事本里那段笔记经常是“反正重启好了”没有根因、没有判断过程参考价值极低。这三个代价在三开模式下特别隐蔽平时感知不到一旦故障高发期集中爆发整个人基本就变成了一个低效的信息搬运工。更难受的是这种忙碌感会给人一种“今天处理了很多事情”的错觉实际上大部分精力都消耗在窗口间的来回搬运上。1.3 现有工具为什么只解决了孤岛内的问题市面上并不是没有人尝试解决这些问题。有的终端插件能把输出直接发给 AI省掉复制粘贴这一步有的笔记软件做了双向链接和标签体系号称能帮助知识沉淀。但它们解决的其实是孤岛内部的问题终端插件解决的是终端到 AI 的连接问题对“这次任务的目标是什么”“之前验证过哪些结论”一概不知笔记软件解决的是信息保存问题但没有任何终端和会话感知本质是一个静态仓库。传统工单系统离得更远记录全靠事后补宁可错杀也不放过填出来的东西基本没人看。所以三开模式一直存在并不是大家懒而是没有一个工具把“正在进行的临时状态”当成头等大事来管理。大家都默认排查过程中的中间产物是留不住的需要人脑来维护。我决定自己动手写 Mini Assistant最初动机很简单想让这些中间状态有一个真实的家。2. 产品逻辑会话不是历史记录而是事故现场2.1 一次故障排查对应一个会话动手之前我列了一份需求清单第一行写着终端、笔记、AI 必须共享同一个会话上下文。但这个会话不是聊天记录那种线性文本而是一个结构化的实体要在里面存放这次任务的目标、涉及的服务器信息、已执行的命令、捕获到的日志片段、AI 的判断建议、最终的处理结论。我按“一次故障排查 一个会话”来组织。帮同事处理低频接口超时、例行发布后的日志检查、某个慢 SQL 的定位都各自开一个会话。排查可能持续两小时也可能一个诡异问题断断续续查三天所有相关动作和结论都归属到同一个会话下。这样直接解决了记事本最大的毛病信息跟任务绑定而不是跟时间或文件夹绑定。找历史记录的时候永远从“这次任务”出发不用靠在文件树里翻目录位置。2.2 界面布局一屏之内完成“操作-记录-求助”闭环Mini Assistant 的界面我做成左侧终端、右上笔记、右下 AI 的布局。左侧终端是核心操作区支持多标签页每个标签页绑定一个 SSH 连接右上笔记区平时收得很窄需要记录时展开记的内容自动关联当前终端服务器和当前会话右下 AI 区可以随时提问提问时默认附带当前终端服务器信息、最近执行的若干条命令及其输出摘要。这个布局本身没什么特别关键是两个交互细节。第一终端输出自动截取。我没有把终端所有回显都丢给 AI那样既贵又乱而是按块截取关键片段最近执行的命令以及其后的输出会自动进入会话上下文。第二AI 回答一键沉淀。当 AI 给出的建议里有一条被验证有效我可以直接在回答中划选、点击“存入笔记”它会自动带上会话编号、服务器标签和验证状态。这个动作特别不起眼但用了之后我才发现它直接养成了“顺手记结论”的习惯比任何强制写周报都有效。2.3 没有被放进第一版的功能清单有经验的读者应该能想到这种工具如果不控制边界会死在半路。我的第一个可用版本砍掉了很多东西没有用户系统、没有多人协同、没有操作审计、没有 Web 版连配置管理都只是本机一个 JSON 文件。最小可用版本只做四件事SSH 连接管理、终端输出捕获、AI 问答上下文注入、笔记沉淀。这四件事做透已经能替代三开模式里的一半功能剩下的一半比如配置管理、多人共享是等我自己真正每天使用之后才逐步补上的。我当时给自己定的原则是只解决“一个人排查故障时的上下文连续性”其他需求一律后置。事实证明这个原则有效因为工具是给自己用的自己用过才知道哪些是真实痛点哪些只是想象出来的需求。3. 核心实现拆解三层会话模型、AI上下文组装与安全执行链路3.1 三层会话模型session / action / insight先说数据结构。我把会话设计成三层模型。最外层是会话实体session保存任务元信息包括标题、目标、创建时间、服务器标签列表、状态中间层是动作实体action保存每次终端操作包括命令文本、执行时间、退出码、输出的关键片段摘要最内层是结论实体insight保存从 AI 回答或人工笔记中沉淀下来、经过或未经验证的判断。存储上我直接用了 SQLite因为单机工具够用零部署一个文件搞定。三层各建一张表用会话 ID 关联。动作表里存的是输出摘要而不是完整输出——完整回显太占空间而且大部分是重复内容摘要时重点保留报错关键字、系统状态数值、最后几行关键输出。需要完整回溯的时候我可以从原始命令入手重跑因为很多命令本身是幂等的查询类命令。关键表结构大致是这样CREATE TABLE session ( id INTEGER PRIMARY KEY, title TEXT NOT NULL, status TEXT DEFAULT open, tags TEXT DEFAULT [], created_at INTEGER ); CREATE TABLE action ( id INTEGER PRIMARY KEY, session_id INTEGER NOT NULL, server_id INTEGER NOT NULL, cmd TEXT NOT NULL, rc INTEGER, output_summary TEXT, created_at INTEGER ); CREATE INDEX idx_action_session ON action(session_id, created_at); CREATE TABLE insight ( id INTEGER PRIMARY KEY, session_id INTEGER NOT NULL, kind TEXT, -- ai / manual / verified content TEXT, ref_action_id INTEGER, status TEXT DEFAULT pending, -- pending / verified / invalid created_at INTEGER );实际使用中我在action表上加了server_id字段。这个字段最初没有后来发现它是区分多标签上下文的关键具体原因后面会讲到。3.2 装配运维上下文给 AI 的不是零散聊天而是结构化状态包Mini Assistant 能用的关键在于 AI 必须知道“现在我们在查什么”。我的做法是把会话上下文组装成一个固定格式的状态包每次请求自动附带。状态包包含三部分会话目标描述、最近动作序列最近 10 条命令及关键输出摘要、已沉淀结论列表包括验证状态。配给模型的系统提示大概长这样你是一名运维排查助手。以下是从运维工作台同步的当前会话状态 - 任务目标{session.title} - 服务器{server.alias} ({host}) - 最近的命令执行序列{actions_json} - 已经确认或待验证的结论{insights_json} 请注意 1. 回答前先参考已沉淀的结论不要重复建议已验证无效的方案。 2. 结合最近命令的输出优先给出下一步排查命令。 3. 给出的命令建议格式为可执行命令块我需要时可直接执行。 4. 如果信息不足请明确说出还需要哪些进一步信息。注入上下文之后AI 的表现明显不一样。之前它像刚进群的新同事只看了最后一条消息就回答现在像是带着工单上下文的老手知道我们查到哪一步、试过什么、怀疑过什么。实测中有一条很典型的对比不注入上下文时问“接下来怎么办”它给的是通用的八条排查建议注入上下文后它会直接说“你已经确认内存充足下一步建议用ss -antp查看连接状态重点看 TIME_WAIT 数量”。这个差别就是工作台有没有真正起效的分水岭。需要说明的是组装上下文时我还做了动作序列的重排。最前面放的是最近执行的命令和关键输出而不是最早的记录因为模型需要先看到最新状态历史信息按需往前翻。这跟聊天框里从头开始翻记录是完全不同的体验。3.3 让 AI 碰终端之前的三道安全闸门让 AI 直接参与运维操作很多人第一反应是安全性。我一开始就没打算做一个“AI 说命令终端就执行”的傻瓜式工具。Mini Assistant 的安全控制分三层连接层、命令层、确认层。连接层上SSH 凭据只存在本机且优先使用密钥。为了在断网或者机器休眠时不丢会话我还做了连接保持和自动重连重连之后不会让会话数据丢失。命令层上我维护了一个危险命令识别表rm、mkfs、dd、iptables这一类命令默认直接拒绝自动执行只能通过手动输入到终端里执行并弹一次确认。识别表不打算做成纯黑名单因为很多命令本身没有威胁威胁来自参数组合比如curl管道到sh。所以我的实现其实是一个规则引擎先做命令分片再对管道、shell 控制符做标记命中高危组合就标记成“高危”。确认层是最核心的一环AI 给出的命令建议永远不直接落到终端而是出现在一个“待执行”卡片里由我点确认之后才真正执行。这个设计刚做出来时我认为有点多余但用多了之后发现确认动作本身会逼着我再想一遍。哪怕是 AI 给了很合理的命令点确认之前我都会对它的副作用多一秒复核这一秒常在关键时刻值很多。三层安全控制的思路可以总结成这样安全层作用实现方式连接层控制谁能连、怎么连本机凭据 密钥优先 自动重连命令层识别危险动作命令分片 高危命令规则 管道标记确认层人工兜底AI 建议进“待执行”卡片人工确认后才执行3.4 报错捕获到结论沉淀的半自动诊断链路诊断链路是 Mini Assistant 区别于“AI 聊天 终端双开”方案的关键部分。我做了一个半自动化的流水线分为三步。第一步是报错感知。终端输出捕获过程中如果出现报错的文本行包含Error、Exception、fatal、panic等常见关键词工作台会自动截取报错前后各 20 行作为“报错片段”存入action表。第二步是预诊断。拿到报错片段之后工作台触发一次轻量 AI 分析把报错片段、当前服务器信息、最近动作序列一起发过去生成预诊断结论包含可能原因和验证命令建议。这个结论进入insight表初始状态是pending。第三步是人工验证闭环。我按建议执行命令之后可以给这条预诊断结论标记为verified或invalid。标记结果会进入后续对话的上下文同时沉淀到当前会话的结论里。这样一轮下来故障排查从“我贴报错、AI 猜原因、我验证、忘了结果”变成了“工作台捕获报错、AI 给假设、我验证、结论沉淀”。中间最爽的不是自动分析而是验证闭环。以前最怕 AI 给三条建议试一条不行、再试一条最后忘了哪一条有效现在每条都有状态下次遇到类似报错我可以先按verified的结论处理。4. 实际使用一个月后的数据与三个教训4.1 排查时间缩短三成但更值的是心理稳定感做出来之后我自己把它当日常运维主力工具用了一个多月。说数据不是实验室数据只能代表个体体验但趋势能说明问题。处理同类型问题比如服务响应变慢、磁盘占用告警、数据库慢查询这几类单次排查完成时间大约缩短了 30% 到 40%。省下的时间主要来自两个环节一个是不用在聊天框里反复解释背景二是排查完不需要额外整理笔记因为笔记已经在工作流中顺手沉淀掉了。更明显的体验改善是心理层面的。以前排查复杂故障时那种“查了快一小时却觉得毫无进展”的焦虑很大程度来源于对上下文碎片化的失控感。现在所有动作和结论都挂在会话里随时打开右侧笔记区就能看到一步步的思考和判断链路。这种“一切都在掌握中”的感觉让我在排查时更冷静更少重复跑命令也更少冲动重启服务。4.2 长耗时命令、多标签串扰、API 成本三个真实教训预期之内的方便很多预料之外的坑也不少。第一个坑是输出捕获在长耗时命令下失真。最初我在“命令执行结束”时才触发输出摘要逻辑很简单但遇到tail -f、top这种持续输出的命令时就凉了——命令一直不结束输出永远进不了摘要AI 的上下文停留在命令执行前的状态。后来我改成双阈值触发命令超过 3 秒没结束或者输出超过一定行数就先拍一个当前片段快照进上下文后续增量再继续追加。这样长耗时命令的场景也被覆盖了。第二个坑是多个终端标签页引起的上下文串扰。最初我把整个会话的所有终端输出混在一起送入上下文结果发现同时开两个服务器标签排查问题时AI 会把 A 服务器的命令输出当成 B 服务器的给出的建议全串了。后来我给每个动作都带上server_id上下文组装时只取当前焦点服务器的动作序列并且上下文描述里的“当前服务器”字段随焦点切换自动更新。这个坑值得单独提因为它特别隐蔽表面上是 AI 回答变慢或者变怪了但根因是上下文被不同来源的数据污染了。第三个坑是 API 调用量失控。不加控制时一次复杂排查下来可能触发几十次模型调用每次调用又携带一大坨上下文费用比想象中涨得快。我做了两个收敛第一上下文包里的输出摘要强制截断最长只保留前 200 字第二预诊断不是每次都触发同一类型报错在同一天内只做第一次深度分析之后相同报错只增量记录出现次数。这样收敛完费用大概降到原来的三分之一诊断质量没有肉眼可见的下降。4.3 把“顺手”做成仪式快捷键与会话恢复体验层面有几个优化我认为回报特别高。第一是快捷键体系。终端、笔记、AI 三个区各有焦点模式我把最常用的动作简化成几组快捷键Ctrl1 切终端、CtrlK 聚焦笔记、CtrlJ 聚焦 AICtrlEnter 把当前终端输出片段直接发给 AI。一套下来最频繁的“把输出喂给 AI”动作变成了一键完成。快捷键看着是小事但它往往是把一个工具从“能用的产品”变成“离不开的工具”的分水岭。第二是会话恢复能力。我做了会话自动恢复重启工作台之后所有打开着的会话、终端标签、焦点状态都恢复原样。一开始做这个功能只是顺手结果用久之后发现它彻底消除了“每天早上重新打开服务器连接”的启动成本。打开工作台就是昨天离开时的现场这个体验谁用谁知道。第三是轻量知识库的自动整理。每个会话里verified状态的 insight会被定期汇总到一个本地知识文件里并按服务器标签和问题类型归类。我现在遇到新问题第一步不是问 AI而是先在本地知识库里搜经常发现类似问题之前处理过答案就在里面。这或许是整个工作台最朴素也最被低估的能力——它让个人经验开始有了积累效应。5. 回看这个项目哪些设计值得复用哪些要引以为戒5.1 三个我当时坚持做对的设计回看整个项目我最认可的设计决策有三个。第一个是“会话为中心工具为附属”。终端、笔记、AI 全部挂在同一个会话实体上信息自然以任务为脉络组织特别适合跨天的复杂运维场景。第二个是“结论闭环机制”。让 AI 的建议变成可标记、可验证、可沉淀的状态化条目使 AI 从一次性顾问变成了有积累效应的工作伙伴。第三个是“安全确认的人工兜底”。在 AI 执行链路里保留一个不可跳过的人工确认点既保留 AI 的便捷又守住操作安全的底线。运维场景下这个兜底怎么强调都不过分。5.2 过度设计的两段弯路也有起初自信、后来被推翻的设计。最典型的是“命令输出解析器”。当时我很想写一套规则自动解析终端输出里的错误码、磁盘使用率、进程信息生成一个结构化的状态面板。志向挺大实际做出来发现严重过度设计——规则覆盖面根本不全一碰到没见过的输出格式立刻失效还不如把原始输出片段直接交给 AI 让它自己提取。后来我把整块解析逻辑全删了改成“原始片段 AI 提取”的路线准确率和维护成本都好了很多。这个教训很直接不要跟模型抢规则解析的活它的上下文理解和抽取能力已经足够强我该花精力的是上下文组织而不是写解析规则。另一个弯路是早期版本做了一个很重的会话标签体系。每次开启会话前要选多个标签、填一堆元信息结果发现实际使用中根本没人爱填包括我自己。后来我把标签全部降级为可选并基于服务器别名自动生成默认标签server:xx元信息才开始真正被用起来。做个人效率工具凡是需要额外录入才能开始干活的设计都应该先砍掉。5.3 下一步方向与可复用模块目前 Mini Assistant 还是单机个人工具下阶段有两个明确方向。一个是多人协同团队排查故障时其他人也要能看到会话上下文已验证的结论要能共享。单机 SQLite 没问题多人场景就需要一个轻量后端和服务端权限控制。二是操作闭环目前 AI 建议还需要我手动确认或复制执行我希望支持更精细的“半自动执行”模式只读命令自动执行写入类命令必须确认涉及重启等高风险操作的走双人确认。如果这个方向做出来工作台就能从“排查助手”升级为“操作助手”。我也在考虑把核心能力抽成可复用的独立模块发布出来比如会话存储模型、AI 上下文组装器、危险命令识别引擎。这样其他有同样痛点的人不需要从零复制整个工作台只需要集成自己缺的那一块就能把三开的工作模式改成两开甚至一开。毕竟这个项目的价值不在界面布局而在那些经历了真实运维毒打之后沉淀下来的状态管理思路。