作為一個(gè)常年和服務(wù)器打交道的運(yùn)維我在過去幾年里早就習(xí)慣了三種窗口同時(shí)掛在屏幕上SSH 客戶端的終端、記事本里攢下的命令片段、還有聊天框里隨時(shí)準(zhǔn)備翻資料的技術(shù)問答。這個(gè)“三開”狀態(tài)聽起來很勤奮但真正長期用下來你會(huì)意識(shí)到問題根本不是屏幕不夠大而是信息上下文被切得稀碎。最近我把自己一直想要的東西從零做出來了一個(gè)名為 Mini Assistant 的 AI 運(yùn)維工作臺(tái)。它把 SSH 會(huì)話、命令知識(shí)庫和 AI 對(duì)話收斂到同一個(gè)界面里讓我能在一處完成“看回顯、查歷史命令、讓 AI 結(jié)合當(dāng)前環(huán)境給建議”的全流程。這篇文章我會(huì)完整復(fù)盤這個(gè)項(xiàng)目的需求收斂、架構(gòu)設(shè)計(jì)、核心實(shí)現(xiàn)和開發(fā)過程中踩過的坑也會(huì)把方案拆到可以直接照做的程度。1. 三開狀態(tài)的問題不是窗口多而是上下文被切碎了1.1 一次典型故障里的手動(dòng)搬運(yùn)先看一個(gè)再普通不過的排查場(chǎng)景應(yīng)用告警提示某個(gè)端口綁定失敗顯示 address already in use。放在三開狀態(tài)下我一般這么做先打開 SSH 客戶端連上服務(wù)器靠記憶敲ss -lntp看端口占用然后切到記事本翻找之前用過的命令片段翻到之后發(fā)現(xiàn)片段里只有命令沒有環(huán)境說明還得停下來回憶當(dāng)時(shí)是不是加了 sudo接著切到聊天框把報(bào)錯(cuò)描述手動(dòng)打一遍問 AI 這句話是什么意思。得到回答后再回到終端把殺進(jìn)程的命令重新輸入一遍。整個(gè)過程看起來每一件事都不算難但真正的代價(jià)藏在切換之間。你在 SSH 里看到的輸出是幾百行滾動(dòng)日志切到聊天框時(shí)沒法把那幾百行“帶過去”只能靠自然語言轉(zhuǎn)述轉(zhuǎn)到記事本找命令時(shí)又發(fā)現(xiàn)命令和當(dāng)前主機(jī)、端口、目錄沒有任何綁定關(guān)系。每切換一次就丟失一部分上下文然后還得花額外時(shí)間去恢復(fù)。這種“搬運(yùn)成本”才是三開低效的核心而不是工具本身不好用。1.2 單純把 AI 塞進(jìn)聊天框解決不了問題很多人以為給運(yùn)維配上 AI 就是多開一個(gè)智能聊天框有事問一句就行。但我試過之后發(fā)現(xiàn)如果 AI 拿不到終端回顯、不知道當(dāng)前主機(jī)裝了什么應(yīng)用、不了解你剛才執(zhí)行過哪些命令它的回答基本只能停留在“通用運(yùn)維知識(shí)”層面。比如你問它“這個(gè)報(bào)錯(cuò)怎么回事”它能列出一堆可能原因但你仍然需要自己對(duì)著屏幕逐條核驗(yàn)。真正有價(jià)值的 AI 應(yīng)該能看到你眼前的輸出、知道你剛跑過什么命令然后基于這些具體的上下文給出判斷。三開狀態(tài)下這條鏈路根本連不上因?yàn)槊總€(gè)工具都是獨(dú)立的孤島信息靠人肉搬運(yùn)。所以我做 Mini Assistant 時(shí)的第一原則很明確先把上下文鏈路打通再談 AI 能力。終端、命令庫、AI 助手都長在同一個(gè)進(jìn)程和同一份數(shù)據(jù)模型里彼此可以互相引用而不是三個(gè)平行窗口。2. 從痛點(diǎn)收斂到三件事會(huì)話、命令庫、AI 協(xié)助2.1 先劃清邊界別一上來就做平臺(tái)動(dòng)手之前我列過一個(gè)很長的心愿單CMDB、監(jiān)控大盤、告警接入、自動(dòng)化編排、工單系統(tǒng)……每一項(xiàng)聽起來都很有道理但如果全做這個(gè)項(xiàng)目半年都上不了路。后面我強(qiáng)制自己把范圍收窄到三件事每件事直接對(duì)應(yīng)三開里的一個(gè)痛點(diǎn)一是會(huì)話管理解決“SSH 客戶端”的問題。保存主機(jī)信息、連接方式、本地密鑰路徑一鍵建立連接會(huì)話列表一目了然。二是命令片段庫解決“記事本”的問題。把常用命令存成帶變量和標(biāo)簽的片段隨時(shí)檢索一鍵推到終端執(zhí)行結(jié)果還可以回寫為新的知識(shí)。三是 AI 協(xié)助解決“聊天框”的問題。AI 不再只是純聊天而是能讀取當(dāng)前會(huì)話的主機(jī)信息、最近命令歷史、終端回顯尾部在同一個(gè)側(cè)欄里給出有上下文支撐的回答。這三個(gè)能力一旦串起來三開就自然變成“一開”。2.2 桌面形態(tài)與技術(shù)選型為什么是 Tauri在形態(tài)選擇上我一開始在純 Web 頁面和桌面應(yīng)用之間糾結(jié)過。純 Web 的好處是瀏覽器打開就能用但做運(yùn)維工作臺(tái)需要長時(shí)間持有 SSH 和 PTY 連接而且我經(jīng)常在多個(gè)工作區(qū)之間切換瀏覽器標(biāo)簽頁一多就容易誤關(guān)連接狀態(tài)和界面狀態(tài)都不穩(wěn)定。桌面應(yīng)用更貼合“工作臺(tái)”這個(gè)定位常駐任務(wù)欄隨時(shí)點(diǎn)開連接狀態(tài)持久。技術(shù)棧我最后選了 Tauri 2而不是 Electron。原因很樸素內(nèi)存占用差太多。運(yùn)維工作臺(tái)會(huì)長時(shí)間掛著多個(gè) SSH 終端Electron 方案動(dòng)輒幾百兆內(nèi)存而 Tauri 的前端復(fù)用系統(tǒng) WebView后端是 Rust整體常駐內(nèi)存大約十兆到幾十兆對(duì)老舊的辦公筆記本非常友好。Rust 后端處理 SSH 子進(jìn)程、PTY 終端轉(zhuǎn)發(fā)、大模型 API 代理這些 IO 密集任務(wù)也順手得多。前端部分我用 React 18 加 TypeScript終端渲染直接用 xterm.js本地?cái)?shù)據(jù)用 SQLite 存。AI 模塊沒有綁定某個(gè)固定的模型供應(yīng)商而是統(tǒng)一走兼容大模型 HTTP 接口的協(xié)議允許自定義地址、模型名和密鑰這樣后續(xù)換模型或接內(nèi)部網(wǎng)關(guān)都不需要改架構(gòu)。2.3 信息架構(gòu)與數(shù)據(jù)模型界面布局我反復(fù)調(diào)整過幾次最后固定為四塊左側(cè)是會(huì)話樹中間是終端主區(qū)右側(cè)是可以切換“命令庫”和“AI 助手”兩個(gè)面板的側(cè)欄底部是一條狀態(tài)欄實(shí)時(shí)顯示當(dāng)前主機(jī)、最近回顯摘要和連接狀態(tài)。對(duì)應(yīng)的數(shù)據(jù)模型也圍繞這三個(gè)能力展開。會(huì)話表保存主機(jī)、端口、用戶名、認(rèn)證方式、本地密鑰路徑命令片段表保存標(biāo)題、命令模板、變量定義、標(biāo)簽、適用場(chǎng)景回顯快照表保存某次會(huì)話在某時(shí)間點(diǎn)的尾部輸出AI 消息表保存對(duì)話內(nèi)容以及它引用的上下文摘要。核心原則是每個(gè)動(dòng)作都能被追溯一條 AI 建議對(duì)應(yīng)哪段回顯、一條命令片段在哪臺(tái)機(jī)器上執(zhí)行過這些關(guān)系都要記錄否則工具本身又會(huì)成為新的信息孤島。3. 終端、命令庫、AI 三條通道如何在運(yùn)行時(shí)握手3.1 從字節(jié)流到界面PTY 數(shù)據(jù)通路終端功能的實(shí)現(xiàn)鏈路是這樣的Rust 后端通過異步 SSH 庫連接到遠(yuǎn)程主機(jī)分配一個(gè) PTY 會(huì)話遠(yuǎn)程輸出的字節(jié)流經(jīng)過后端處理通過 Tauri 事件通道推送到前端前端 xterm.js 負(fù)責(zé)把字節(jié)流渲染成可交互的終端畫面。反過來前端捕獲鍵盤輸入通過事件通道發(fā)給后端后端再寫入 PTY?？雌饋砗?jiǎn)單但有個(gè)細(xì)節(jié)容易被忽略xterm.js 的terminal.write不是同步渲染的如果后端高頻推送數(shù)據(jù)前端需要自己維護(hù)一個(gè)寫入隊(duì)列避免一次性寫入過多導(dǎo)致界面卡頓。我最初的版本沒做任何緩沖日志一多xterm 直接罷工。后面改成前端用 requestAnimationFrame 分幀消費(fèi)寫入隊(duì)列這才平穩(wěn)下來。3.2 窗口大小同步resize 鏈路終端窗口調(diào)整大小是一個(gè)經(jīng)典的隱藏坑。遠(yuǎn)程終端必須知道當(dāng)前界面有多少行多少列否則輸出會(huì)折行混亂。前端用 xterm/addon-fit 根據(jù)容器尺寸計(jì)算出 cols 和 rows再通過 Tauri 事件通知后端后端調(diào)用 PTY 的窗口大小設(shè)置接口把新的尺寸同步給遠(yuǎn)程 shell。這個(gè)鏈路本身不復(fù)雜但 fit 的觸發(fā)時(shí)機(jī)很關(guān)鍵。如果放在組件掛載后立刻執(zhí)行此時(shí)字體還沒加載完成計(jì)算出的尺寸往往是錯(cuò)的。我加了兩個(gè)保險(xiǎn)一是在 window.load 事件之后強(qiáng)制重新 fit 一次二是用 ResizeObserver 監(jiān)聽容器變化只要尺寸變化就重新同步。實(shí)測(cè)中后者的觸發(fā)頻率太高又加了 100ms 的防抖才避免頻繁 resize 導(dǎo)致遠(yuǎn)程終端刷屏。3.3 命令知識(shí)庫的“確認(rèn)執(zhí)行”機(jī)制命令片段庫真正好用靠的不是簡(jiǎn)單存一段文本而是三個(gè)能力的組合變量替換、一鍵推送、執(zhí)行回寫。命令片段允許定義變量例如{host}、{port}、{log_path}。選中片段后如果包含變量會(huì)彈一個(gè)表單自動(dòng)用當(dāng)前會(huì)話的信息預(yù)填確認(rèn)后生成真實(shí)的命令文本。然后這條命令不會(huì)直接執(zhí)行而是先放到終端輸入?yún)^(qū)模擬人工鍵入并停留在等待回車狀態(tài)。用戶看一眼命令沒問題再按回車執(zhí)行。這個(gè)設(shè)計(jì)我有意為之。運(yùn)維場(chǎng)景里誤操作代價(jià)很高AI 生成的命令或者歷史遺留命令都可能有隱患多一個(gè)“人工確認(rèn)”動(dòng)作只花幾秒鐘卻能把因?yàn)楣ぞ咛樖衷斐傻氖鹿事式迪聛怼?duì)于我特別信任的高頻命令也提供“自動(dòng)確認(rèn)”開關(guān)但這開關(guān)默認(rèn)關(guān)閉。3.4 AI 如何真正觸達(dá)運(yùn)維現(xiàn)場(chǎng)三種上下文模式AI 不是簡(jiǎn)單做一個(gè)聊天框塞進(jìn)側(cè)欄而是設(shè)計(jì)了三種工作模式每一種都顯式裝配不同的上下文。第一種是自由問答。用戶可以直接提問系統(tǒng)默認(rèn)附加當(dāng)前主機(jī)的基礎(chǔ)信息摘要、最近執(zhí)行的 10 條命令以及最近 200 行終端回顯的尾部片段。這些信息是否附加可以由用戶開關(guān)控制避免每次提問都泄露過多輸出。第二種是分析當(dāng)前回顯。用戶從終端選中一段輸出或直接把最近 500 行回顯發(fā)給 AI系統(tǒng)要求模型按“可疑原因、下一步建議、需要進(jìn)一步查看的命令”三段結(jié)構(gòu)返回。輸出會(huì)被解析成結(jié)構(gòu)化面板而不是一大段聊天文字。第三種是推薦命令。AI 拿到同樣的上下文后如果用戶明確要求推薦命令系統(tǒng)會(huì)讓模型把命令放在代碼塊里前端解析后進(jìn)入“命令確認(rèn)區(qū)”經(jīng)過危險(xiǎn)命令檢查和人工確認(rèn)后才會(huì)進(jìn)入終端。這三條通道合在一起AI 才真正從“云聊天”變成了“站在你旁邊看同一塊屏幕的同事”。4. 開發(fā)實(shí)錄PTY 進(jìn)程、回顯風(fēng)暴和 AI 幻覺的攻防4.1 PTY 生命周期管理別讓 ssh 進(jìn)程變成幽靈開發(fā)中最先撞上的硬骨頭是 PTY 進(jìn)程的生命周期管理。剛開始實(shí)現(xiàn)時(shí)前端關(guān)閉會(huì)話窗口只把界面關(guān)掉了后端那個(gè) SSH 連接子進(jìn)程還活著。表現(xiàn)就是連接看似斷開但服務(wù)器上依然掛著你的 shell 進(jìn)程下次重連還會(huì)因?yàn)椤癟oo many open sessions”失敗。解決辦法是為每個(gè)會(huì)話分配全局唯一的會(huì)話 ID后端用一張 HashMap 維護(hù)所有活躍會(huì)話。前端執(zhí)行關(guān)閉操作時(shí)必須調(diào)用顯式的 close 接口傳入會(huì)話 ID后端收到后先斷開 PTY再清理緩沖區(qū)最后把會(huì)話標(biāo)記從映射移除。應(yīng)用退出時(shí)也要遍歷所有活躍會(huì)話做一次兜底清理。斷線重連也不是重新創(chuàng)建會(huì)話而是拿著原有會(huì)話 ID 重新請(qǐng)求后端恢復(fù)盡量保留命令歷史上下文。4.2 回顯風(fēng)暴日志刷屏如何把前端打崩第一次壓測(cè)碰到tail -f大日志時(shí)前端直接卡到?jīng)]有任何響應(yīng)。原因很簡(jiǎn)單后端把每行日志都實(shí)時(shí)轉(zhuǎn)發(fā)到前端xterm.js 寫入成本很高短時(shí)間內(nèi)幾千行數(shù)據(jù)涌進(jìn)來界面線程直接阻塞。后續(xù)的優(yōu)化分了三層。第一層在后端做采樣與合并每秒最多推送 20 批數(shù)據(jù)每批最多合并 200 行超出部分統(tǒng)一在環(huán)形緩沖區(qū)里留作快照不進(jìn)界面。第二層在前端做入隊(duì)和分幀把后端推送的數(shù)據(jù)先放進(jìn)隊(duì)列每幀最多寫入一批保證界面能繼續(xù)響應(yīng)鼠標(biāo)操作。第三層是滾動(dòng)緩沖上限xterm.js 內(nèi)部最多保留 5000 行防止內(nèi)存被無限增長拖垮。對(duì)于確實(shí)需要完整日志的場(chǎng)景我提供一個(gè)“會(huì)話快照落盤”功能直接把全量回顯寫到本地文件不經(jīng)過界面渲染。4.3 編碼與字符集一臺(tái)舊設(shè)備讓我排查了兩小時(shí)有次連一臺(tái)內(nèi)網(wǎng)舊設(shè)備終端輸出全是亂碼命令執(zhí)行沒問題但中文日志和部分特殊符號(hào)完全不可讀。排查到最后發(fā)現(xiàn)是設(shè)備的默認(rèn)字符集還是 GBK而我的管道按 UTF-8 解析了。解決方式是在會(huì)話配置里增加“字符集”字段默認(rèn) UTF-8遇到非主流設(shè)備可以手工指定 GBK 或 GB18030。后端收到字節(jié)流先做 iconv 轉(zhuǎn)換再統(tǒng)一以 UTF-8 寫到前端。這個(gè)坑雖然冷門但在生產(chǎn)網(wǎng)絡(luò)里一旦遇到就是硬傷值得提前做進(jìn)配置。4.4 給 AI 套上護(hù)欄危險(xiǎn)命令檢查與輸出解析容錯(cuò)AI 推薦命令最怕的就是幻覺和危險(xiǎn)操作。我遇到過一次模型在排查端口問題時(shí)給出了包含rm -rf的“清理方案”雖然大概率是示例路徑但絕對(duì)不能直接執(zhí)行。所以我在“AI 推薦命令”這條鏈路上加了嚴(yán)格的結(jié)構(gòu)性防護(hù)。第一道防護(hù)是強(qiáng)制輸出結(jié)構(gòu)。要求模型必須按“命令解釋、實(shí)際命令、風(fēng)險(xiǎn)提示”三段返回命令必須放在獨(dú)立代碼塊里。前端解析時(shí)如果發(fā)現(xiàn)格式不符直接展示原文絕不嘗試猜測(cè)式提取。第二道防護(hù)是危險(xiǎn)命令檢查。命令進(jìn)入確認(rèn)區(qū)之前會(huì)先跑一組正則rm -rf /、mkfs、直接寫塊設(shè)備的dd、清空系統(tǒng)表等都會(huì)命中告警規(guī)則命中后在確認(rèn)區(qū)顯示紅色警告橫幅并且必須二次確認(rèn)才能發(fā)送。第三道防護(hù)也是最重要的一道AI 生成的命令永遠(yuǎn)只進(jìn)入確認(rèn)區(qū)不可能直接寫入 PTY 執(zhí)行。把 AI 從“操作者”降級(jí)為“建議者”整個(gè)系統(tǒng)的風(fēng)險(xiǎn)等級(jí)就完全不一樣了。4.5 還有幾個(gè)不致命但很煩人的細(xì)節(jié)xterm.js 的快捷鍵沖突也折騰了一陣CtrlC 復(fù)制和發(fā)送中斷信號(hào)之間的行為需要按照終端原生交互去設(shè)計(jì)我在 keydown 事件里做了事件分類避免終端面板和側(cè)欄輸入框互相搶焦點(diǎn)。另一個(gè)煩人的點(diǎn)是終端失焦后的滾動(dòng)異常點(diǎn)擊側(cè)欄輸入框再回到終端滾動(dòng)位置經(jīng)常跳到奇怪的地方最后通過給終端容器設(shè)置焦點(diǎn)狀態(tài)機(jī)解決切出時(shí)記住滾動(dòng)偏移切回時(shí)恢復(fù)。5. 七分鐘與十八分鐘的差距一次故障排查的實(shí)測(cè)5.1 同樣的問題兩條路徑為了驗(yàn)證這個(gè)工具到底有沒有用我做了一組對(duì)比。場(chǎng)景是內(nèi)網(wǎng)某臺(tái)機(jī)器上應(yīng)用起不來報(bào)錯(cuò)為端口綁定失敗。準(zhǔn)備兩臺(tái)環(huán)境一致的主機(jī)分別用傳統(tǒng)三開方式和 Mini Assistant 完成排查并修復(fù)記錄每一步耗時(shí)。傳統(tǒng)方式的時(shí)間分布是這樣的先找地址和憑據(jù)從聊天記錄里翻出 SSH 連接信息花掉 1 分鐘登錄后用系統(tǒng)默認(rèn)命令看端口占用1 分鐘切到記事本翻歷史命令里面各種版本混雜花了 3 分鐘才找到一條疑似可用的片段復(fù)制下來手動(dòng)替換成當(dāng)前端口2 分鐘切到聊天框把報(bào)錯(cuò)內(nèi)容打進(jìn)去等回答5 分鐘再回到終端執(zhí)行殺進(jìn)程2 分鐘最后重啟應(yīng)用驗(yàn)證2 分鐘順手再把舊命令記錄更新了一下又是 2 分鐘?？傆?jì) 18 分鐘。Mini Assistant 的路徑完全不同會(huì)話列表里點(diǎn)一下就進(jìn)終端10 秒在命令庫檢索“端口排查”補(bǔ)上端口變量1 分鐘執(zhí)行后看到占用的 PID選中回顯讓 AI 分析2 分鐘AI 給出推薦命令進(jìn)入確認(rèn)區(qū)人工確認(rèn)后執(zhí)行1 分鐘重啟應(yīng)用并驗(yàn)證1 分鐘最后點(diǎn)一次“保存快照”把本次回顯和最終命令記錄到知識(shí)庫1 分鐘?？傆?jì) 7 分鐘。5.2 省下來的時(shí)間花在了哪里對(duì)比這個(gè)表格能明顯看出傳統(tǒng) 18 分鐘里真正花在“執(zhí)行”上的時(shí)間很少大部分都消耗在上下文搬運(yùn)上翻找命令 3 分鐘、轉(zhuǎn)述問題等答案 5 分鐘、復(fù)制替換修改 2 分鐘。Mini Assistant 并沒有讓命令執(zhí)行得更快它只是把這些搬運(yùn)成本基本上消滅了上下文在會(huì)話、命令庫、AI 之間直接傳遞不再經(jīng)過人肉轉(zhuǎn)述。一周使用下來我個(gè)人體感是每天切換窗口的次數(shù)從 60 多次降到了 20 次以內(nèi)命令復(fù)用率明顯上升因?yàn)槊恳粭l執(zhí)行過的命令都可以一鍵存進(jìn)知識(shí)庫而且下次檢索時(shí)能直接關(guān)聯(lián)到主機(jī)和業(yè)務(wù)場(chǎng)景。當(dāng)然也要說句公道話AI 并不是每次都能給對(duì)答案真正提速的核心不是“AI 更聰明”而是“你不用再把上下文重新打一遍”。AI 在上下文完整的時(shí)候它的正確率才有意義。6. 完整復(fù)刻的路線圖MVP 裁剪、關(guān)鍵技術(shù)選型與后續(xù)擴(kuò)展6.1 四步走的 MVP 裁剪如果看完文章你也想照著做一個(gè)我不建議一步到位更推薦按順序分四個(gè)階段推進(jìn)。第一階段做終端加會(huì)話管理不接 AI。這階段解決“窗口多”的基礎(chǔ)痛點(diǎn)同時(shí)把 Tauri 項(xiàng)目、xterm.js 集成、Rust 后端 SSH 通道跑順大概一周。第二階段加命令片段庫做變量替換和一鍵推送。這階段讓“翻記事本”成為歷史大概三天。第三階段做回顯捕獲和 AI 自由問答讓 AI 能看到當(dāng)前環(huán)境上下文大概三天。第四階段再把 AI 推薦命令和危險(xiǎn)命令檢查加上做好安全護(hù)欄大概三天。每個(gè)階段都能獨(dú)立使用不會(huì)出現(xiàn)“做了一半沒法干活”的尷尬。我是按這個(gè)順序走的事實(shí)證明后面每加一塊前面的功能都會(huì)變得更順手而不是相互打架。6.2 關(guān)鍵技術(shù)依賴清單給你一份可以直接參考的依賴表用途選型說明桌面框架Tauri 2內(nèi)存占用低Rust 后端適合 PTY 場(chǎng)景前端界面React 18 TypeScript生態(tài)完善類型友好終端渲染xterm.js最成熟的 Web 終端組件會(huì)話后端Rust 異步 SSH 庫負(fù)責(zé)連接、PTY、字節(jié)流轉(zhuǎn)發(fā)本地存儲(chǔ)SQLite會(huì)話配置、命令片段、回顯快照大模型接入兼容大模型 HTTP 協(xié)議的客戶端自定義地址與模型名不鎖定供應(yīng)商6.3 我后續(xù)想繼續(xù)擴(kuò)展的方向這個(gè)工作臺(tái)目前的形態(tài)只是第一步我后續(xù)有幾個(gè)明確的方向。一個(gè)是命令庫多人協(xié)作把本地 SQLite 里的命令片段同步到 Git 私有倉庫團(tuán)隊(duì)之間共享一套經(jīng)過驗(yàn)證的命令庫。第二個(gè)是把回顯快照做成可檢索的操作審計(jì)每次操作自動(dòng)記錄命令、回顯和結(jié)果這樣出問題時(shí)可追溯寫復(fù)盤報(bào)告也不用到處找聊天記錄。第三個(gè)是定時(shí)巡檢每天固定時(shí)間自動(dòng)執(zhí)行一組合規(guī)命令把摘要生成成報(bào)告推送過來。這些方向都會(huì)繼續(xù)圍繞同一件事轉(zhuǎn)讓運(yùn)維上下文可以被復(fù)用而不是每次重新找一遍。6.4 最后分享一點(diǎn)我的實(shí)操心得項(xiàng)目做到現(xiàn)在我最深的體會(huì)是別讓工具變成新的負(fù)擔(dān)。Mini Assistant 不是高大上的自動(dòng)化平臺(tái)它只是把我每天重復(fù)最多的“上下文搬運(yùn)”這個(gè)動(dòng)作優(yōu)化掉了。想復(fù)刻的人只要記住一個(gè)原則就夠了先把終端回顯、歷史命令、當(dāng)前環(huán)境這些上下文穩(wěn)穩(wěn)地抓在同一個(gè)地方再讓 AI、知識(shí)庫、審計(jì)全部來消費(fèi)這份上下文。把這件事做好比接再多花哨的 AI 能力都更實(shí)用。