我自己的日常有一大半时间都泡在终端里。不管是管理服务器、跑数据处理还是写个小工具自用最终都会落到一条条命令上。做这行久了你会发现真正费时间的不是敲命令本身而是三件事想不起来之前那条命令是怎么写的、交互式命令每次都要手工应答、复杂参数的命令记不住也查不到。这次想分享的就是我用三个开源工具从这三个痛点上把命令行改造成个人自动化流水线的过程。它们分别是 atuin、expect 和 ShellGPT搭配起来能让每天的重复操作省掉一大半手工步骤。我会把每个工具的定位、安装配置、实际用法、踩过的坑都写清楚适合那些依赖终端工作、又不想一上来就上 Ansible 这类重框架的运维、开发和测试同学参考。1. 选型逻辑三个工具拼出命令行自动化的完整闭环先说清楚为什么是这三个工具。命令行自动化很多人第一反应是脚本第二反应是 Ansible、Chef 这样的配置管理平台但我的使用场景往往没有那么规整。有的是临时查个历史命令有的是登录设备后要按固定流程应答一堆交互有的只是想知道某个参数怎么写更效率。所以我需要的不是一个大而全的框架而是能嵌入现有工作流的轻量组合。atuin 解决的第一个问题是“找回命令”。它本质上是把 shell 的历史记录变成一个高效可搜索的数据库配合反向模糊搜索和上下文视图让我几秒钟就能翻出几个月前在某目录执行过的命令。expect 解决的第二个问题是“应答命令”。终端里大量工具没有提供非交互参数比如 ssh 的密码输入、某些安装程序的确认提示expect 可以预先定义“看到什么再输入什么”把这类机械应答变成自动化。ShellGPT 解决的第三个问题是“生成命令”。当我不确定某个命令的写法时与其翻手册不如直接用自然语言描述意图让 AI 生成可执行的命令行或脚本片段。它们的层次区分得很清楚一个管记忆、一个管交互、一个管生成。组合起来就是一个最小的命令行自动化闭环——从“知道要做什么”到“找到历史做法”再到“自动完成输入”最后“把命令留存回历史库”。相比之下fzf 和 zoxide 虽然也能提升检索效率但它们更偏导航工具不解决交互应答和命令生成的问题Ansible 功能强大但引入的成本高你需要在 inventory、playbook、模块语法上花很多时间对一个三五台服务器的环境来说显得笨重。所以我的建议也类似先别想着把环境一次性升级成某个自动化平台先用这几个小工具把日常高频操作变顺等真的有需要了再做脚本化、平台化。这套组合的另一个好处是它们都开源、跨平台macOS 和 Linux 都能用Windows 的 WSL 里也能跑后续切换环境成本极低。2. atuin让历史命令变成可搜索的个人数据库2.1 安装与初始化atuin 的安装方式取决于你的系统。macOS 可以用 Homebrewbrew install atuinLinux 可以用官方脚本安装curl --proto https --tlsv1.2 -LsSf https://setup.atuin.sh | sh装完之后需要在 shell 配置里加载它。以 Zsh 为例在 .zshrc 末尾加入一行eval $(atuin init zsh)如果是 Bash对应的是eval $(atuin init bash)这里有第一个坑如果你系统里装了 oh-my-zsh 或 zsh-autosuggestionsatuin init 这行尽量放在它们之后否则插件的历史补全可能会覆盖掉 atuin 键位绑定。重新加载配置后CtrlR 的经典历史搜索就会别替换成 atuin 的交互界面。2.2 核心操作搜索和上下文找回atuin 最常用的入口是快捷键 CtrlR。它的界面类似 fzf直接输入关键词就能模糊匹配但比 shell 自带的 CtrlR 好用太多原生版本必须在命令开头匹配而 atuin 支持命令内容任意位置的模糊匹配。比如我只记得之前跑过一条统计日志中 ERROR 数量的命令但记不清具体写法直接输入 log ERROR 就能搜到那条历史。如果你需要更精细的检索可以用命令行的 atuin searchatuin search -c --cmd docker --cwd /opt/app -l 20这个命令的意思是搜索在 /opt/app 目录下执行过并且包含 docker 的历史命令最多取 20 条。加 -i 可以进入交互式模糊搜索界面加 -a 可以搜索所有主机的历史。比单条历史搜索更实用的是上下文视图。当你按 CtrlR 搜到某条命令后再按 Tab 就可以展开看它附近执行过的上下命令。这个功能在做故障复盘时特别有价值你能顺着历史看到当时是先改了配置还是先重启了服务整个操作链路一目了然。我自己排查线上问题的时候靠这个上下文还原现场的次数非常多。2.3 多端同步与数据加密atuin 的同步功能也是我选它的重要原因。它可以把历史命令加密同步到官方服务器或者用自己的私有服务器。初始化同步需要先注册atuin login -u username -p password -k key这里面的 -k 参数是用于加密历史的密钥它会本地生成或者通过 atuin register 命令自动配置。同步的好处是换了电脑或终端后历史命令还在工作习惯不用重新培养。如果不放心官方服务器atuin 支持自建同步服务毕竟它用的是一套开源的同步协议数据在客户端加密后才上传服务端只能看到密文。我自己的做法是公司内网部署一个私有同步端个人电脑用官方服务两边数据隔离安全性上更有保障一点。2.4 实际效率提升和更容易忽略的细节装上 atuin 之后最直观的感受是几乎不再重复输入长命令。以前一天可能要敲几十次相同的 docker exec 或 git log 命令现在 CtrlR 一下就到手。实测下来大概能省我每天 30 到 40 分钟的找命令时间特别是当你在多个项目目录间切换的时候不同目录的同类命令还往往长得不一样这时候 atuin 的分目录筛选就体现出优势了。使用中有个细节我建议你注意历史记录里可能会包含敏感信息比如你在命令行里直接传过密码或 token。atuin 给了两个防护机制一是 shell 中设置 HISTCONTROLignorespace凡是前面加空格的命令不会进入历史二是 atuin 的过滤规则。你可以按需配置忽略核心关键词避免敏感命令进入数据库。3. expect把交互式应答从手工变成自动3.1 理解 expect 的工作方式expect 是一个基于 Tcl 的传统自动化工具它的核心思想特别简单启动一个程序等待看到某个输出然后发送预设的输入。你可以把它理解成一个“看着屏幕打字的人”屏幕上出现什么我们就回答什么。正因为它模拟的是真实终端交互所以几乎任何带交互提示的命令行工具都可以被它驱动不需要目标程序提供 API 或者非交互参数。最基础的使用方式是用 expect 命令直接执行一段脚本expect -c set timeout 10 spawn ssh root192.168.1.10 expect password: send mypassword\r interact 这里每条命令都有自己的角色spawn 负责启动一个子进程expect 等待指定的字符串出现send 向子进程发送输入interact 则把控制权交回给你这样自动化执行完之后你还能留在会话里继续操作。核心要点就是“期待什么、看到再发什么”顺序不能乱。timeout 是超时秒数如果屏幕上一直没有出现期待的内容脚本会在超时后继续执行所以像 SSH 首次连接时出现的 yes/no 提示也要单独处理。3.2 实战案例登录设备并自动执行一段巡检命令下面是我自己常用的一个场景。公司有一些网络设备和服务器不允许用公钥登录只能密码认证每天要做的巡检其实都一样登录、切换目录、跑一串命令、退出。用 expect 脚本可以把这个过程固化#!/usr/bin/expect set timeout 15 set host 192.168.1.20 set password your-password spawn ssh root$host expect { yes/no { send yes\r exp_continue } password: { send $password\r } } expect # send sh /opt/check.sh\r expect # send exit\r expect eof注意到这里用了 expect 的复合写法当出现 yes/no 时先确认然后继续等待 password最后用 exp_continue 回到等待状态。这种写法在实际中非常常用因为一台设备的首次连接提示和日常连接提示往往不一样一条路到底很容易卡住。脚本执行完后会退出整个 ssh 会话全程不需要人工干预。3.3 用 autoexpect 快速生成脚本骨架手写 expect 脚本文法不是特别复杂但对不熟悉 Tcl 的人来说起步还是有点门槛。这里给你一个偷懒技巧先运行 autoexpect它会录制你手工操作一次终端的全过程然后自动生成一个 expect 脚本。比如你先跑一遍登录服务器的操作把密码也输了exit 退出autoexpect 会把 spawn、expect、send 都自动写进一个 script.exp 文件里。autoexpect ssh root192.168.1.20生成的脚本通常有冗余内容比如把每个可见输出都当作 expect 模式你需要手动删减保留关键的模式切换点即可。我一般用 autoexpect 做草稿再用编辑器把密码和可变参数抽成变量最后换成复合 expect 写法收尾。这个方法能帮你跳过最初语法学习的过程直接把脚本用起来再逐步改进。3.4 expect 的边界与更优选expect 也不是万能的。有些程序输出的定位字符比较模糊比如都是冒号结尾expect 很容易匹配到错误位置这时建议在 prompt 中加入设备的用户名或目录信息来增加特征。另外随时变化的交互内容并不适合用 expect 硬匹配你最好还是为这类目标程序写 API 封装或者用 pexpect、paramiko 这类 Python 库来管理。如果你本身就在写 Python 脚本且希望同一套逻辑里既能管理远程连接又能处理复杂数据处理paramiko 会比 expect 顺手得多。expect 的优势在于它就是一个独立的可执行脚本只要能解释 Tcl 的环境就能跑不需要额外给目标机器装 Python 环境。我的原则是简单的交互式应答用 expect复杂的业务逻辑用 Python两者互补而不是互相替代。4. ShellGPT自然语言到命令的最后一公里4.1 安装与模型配置ShellGPT 是一个命令行 AI 助手包名叫 shell-gpt安装非常简单pip install shell-gpt安装后终端里会多出一个 sgpt 命令。它默认会尝试连接 OpenAI 的 API需要在环境变量里配置 OPENAI_API_KEY。不过考虑到很多人的环境并不方便使用云 API或者有数据隐私顾虑ShellGPT 也支持接入本地模型。只要你有一个本地推理服务比如 Ollama启动后配置一下 base URL 即可export OPENAI_BASE_URLhttp://localhost:11434/v1 export OPENAI_API_KEYollama这条配置的意义在于ShellGPT 走的其实是 OpenAI 兼容协议base URL 指到哪里它就从哪里调模型。用本地模型的好处是命令内容不出本机对处理敏感设备信息场景特别重要。我自己测试下来本地 7B 级别的模型做简单的命令生成和脚本改写已经够用复杂逻辑还是需要云端大模型但作为日常终端助手本地模型的响应速度已经足够。4.2 三个核心用法shell、code、chatShellGPT 的用法可以分成三种模式分别对应不同的需求。第一种是直接生成 shell 命令。如果我想找出当前目录下最近三天修改过且大于 100MB 的文件直接敲sgpt find current directory, files modified in last 3 days, larger than 100MB, output size and mtime它返回的可能是 find、fd 或 ls 的组合命令。注意 ShellGPT 默认只生成命令文本不会自动执行这点很重要——它可以帮你生成但执行与否的决定权始终在你手上。如果确认无误可以加 --exec 参数直接执行会有确认提示但我还是建议先看一遍。第二种是生成代码片段。用sgpt --code python script to parse nginx access log and count top 10 IPs它可以输出完整的 Python 脚本。这个模式对写临时脚本特别有用生成后直接保存到文件就能运行省去了很多查文档的时间。第三种是对话模式。用sgpt --chat进入连续对话上下文你可以接着上一篇继续讨论同一个问题。比如先让它分析一段启动报错日志再问它“根据这个错误下一步该检查什么”它能够记住前面的上下文。这个模式在排查问题时非常接近和一个同事实时讨论的状态。4.3 实战让 AI 帮你解释陌生命令我用的最多的其实不是生成而是解释。遇到一条看不太懂的复杂命令直接粘给 sgptsgpt explain this command: curl -s https://example.com/api | jq .data[] | select(.status\active\) | column -t它的解释会分点列出这条命令每一步做了什么、用了什么管道、最终输出什么样。这个功能对处理自己好久没碰的旧脚本特别有用比一条条拆管道分析快得多。把解释结果存成文档后续交接给队友也比甩一条冷冰冰的命令强。4.4 执行安全要放在心上ShellGPT 最让我警惕的地方是它生成的命令表面上都很有逻辑但你没法保证它 100% 符合当前环境。比如它可能会在没确认路径的情况下生成 rm -rf 相关操作或者执行方式与你的预期有偏差。我给自己定了一条铁律sgpt 生成的内容一律先看后跑尤其是 --exec 之前必须仔细检查一遍涉及到删除、覆盖、重启服务这类高危操作我会手动把命令拆开再确认一次。另外涉及生产环境的命令不要直接让 AI 生成更不要带 token 或密码发给模型。这条底线守住了工具带来的效率提升才真正安全。5. 把三者串成一条自动化的工单的实战案例5.1 场景每日日志统计讲完单独的工具我用一个日常场景把它们串起来假设我需要每天早上统计三台服务器上的应用日志找出 ERROR 数量以及最近 5 条错误详情然后写入一个汇总文件。传统做法是开三个终端、一条一条登录、翻日志整个过程大概 20 分钟。用三个工具配合可以缩短到 3 分钟。第一步用 atuin 找到昨天用过的登录命令和日志路径。因为每天统计的内容很相像历史里大概率已经存在相似命令atuin search --cmd ssh app-server --cwd /ops/check拿到服务器地址后第二步我需要写一个 expect 脚本来完成自动登录和命令执行。如果密码认证是唯一方式脚本大致长这样#!/usr/bin/expect set timeout 20 set host [lindex $argv 0] set pwd [lindex $argv 1] spawn ssh root$host expect password: send $pwd\r expect # send grep -c ERROR /var/log/app/app.log\r expect # send grep ERROR /var/log/app/app.log | tail -5\r expect # send exit\r expect eof执行时传入主机和密码两个参数就可以批量复用。如果不想在命令行暴露密码可以改成从环境变量读取配合 expect 脚本里的$env(PASSWORD)来取值。第三步让 sgpt 辅助加工。虽然 grep 命令已经能拿到数据和错误行但有时候我还想顺手把统计结果整理成日报格式这时可以让 ShellGPT 写一个小脚本把三台服务器汇总的结果合并去重并输出成表格sgpt --code python script to combine multiple server log result files, deduplicate, output markdown table生成脚本后检查一遍再运行最终报告直接落到本地。5.2 调度用 cron 定时触发如果想进一步全自动可以把这套 expect 脚本外包给 cron。比如每天 8 点 30 分执行一次30 8 * * * cd /ops/daily bash /ops/daily/run_all.sh /ops/daily/daily.log 21run_all.sh 内部循环调用 expect 脚本并把结果输出到带日期的文件。这里有几个容易踩的坑cron 的环境变量非常精简PATH 里通常没有 ssh、grep 这些命令的完整路径所以脚本里最好使用绝对路径或先 source 环境文件另外 expect 脚本里的 timeout 要设得充裕一些避免某台机器响应慢了导致整个任务失败。我建议先用人工模式跑通一轮确认每条 expect 命令都能匹配到预期输出后再上线 cron。5.3 工具的配合逻辑这个例子里三个工具的协作方式很清晰atuin 提供了对历史经验的快速复用expect 解决了登录和交互应答sgpt 负责生成那些原本需要查文档的辅助脚本。每种工具都在做自己最擅长的事没有一个是多余的。你可以根据自己的场景替换内部命令但整体的“找命令、自动答、生成脚本”三层结构是可以复用的思路。6. 使用这三个工具时必须注意的坑与安全底线6.1 敏感信息泄漏的常见治理思路expect 脚本里直接写密码是最常见的安全隐患。稍微不留神脚本就被带入版本库、传给同事或者被 atuin 记录到历史数据库中。我的建议是操作者自己本地维护一个独立的配置文件权限设为 600脚本从文件读取密码和环境变量不要硬编码在代码里。对于历史记录配合 atuin 的忽略规则把包含密码参数的命令都过滤掉避免二次扩散。6.2 工具本身的配置与边界atuin 的同步服务器要选可信的平台如果你对数据敏感优先自建同步服务expect 的匹配模式要包含足够特征避免过早匹配导致输入错位ShellGPT 生成命令一定要审查后再执行尤其要防止高危操作在未确认的情况下运行。这些都是我在实际使用中踩过或观察到的教训简单但很关键。6.3 日常使用底线小结历史命令如果不希望入库命令前加空格再敲。expect 中不硬编码口令优先使用密钥认证密钥认证解决不了时从本地配置文件读取变量。sgpt 模式下加 --code 生成的代码先看再跑加 --exec 执行的命令更要逐字检查必要时拆解成两步执行。涉及删除、覆盖、批量修改的命令第一次执行前增加 echo 或 --dry-run 验证逻辑。定期检查 atuin 历史库和 expect 脚本目录的权限设置避免共享账号下无谓的泄漏。注意定制品的安全原则先小范围测试再全部铺开能用只读命令测试就绝不用写操作测试。我这套组合用了大半年最大的感受是命令行自动化并不意味着要推翻原来的使用习惯。auitn 增强记忆、expect 接管机械应答、sgpt 辅助生成都是在不改变“人依然掌控操作”的前提下把重复劳动消掉。每天省下来的时间不需要很多但长期积累的效率提升是很可观的。如果你手里也有一批必须反复登录、反复输入的终端操作又不想引入重型的自动化框架这三个开源工具应该能帮你打开一个新的思路。
命令行自动化三件套：atuin、expect与ShellGPT实战指南
我自己的日常有一大半时间都泡在终端里。不管是管理服务器、跑数据处理还是写个小工具自用最终都会落到一条条命令上。做这行久了你会发现真正费时间的不是敲命令本身而是三件事想不起来之前那条命令是怎么写的、交互式命令每次都要手工应答、复杂参数的命令记不住也查不到。这次想分享的就是我用三个开源工具从这三个痛点上把命令行改造成个人自动化流水线的过程。它们分别是 atuin、expect 和 ShellGPT搭配起来能让每天的重复操作省掉一大半手工步骤。我会把每个工具的定位、安装配置、实际用法、踩过的坑都写清楚适合那些依赖终端工作、又不想一上来就上 Ansible 这类重框架的运维、开发和测试同学参考。1. 选型逻辑三个工具拼出命令行自动化的完整闭环先说清楚为什么是这三个工具。命令行自动化很多人第一反应是脚本第二反应是 Ansible、Chef 这样的配置管理平台但我的使用场景往往没有那么规整。有的是临时查个历史命令有的是登录设备后要按固定流程应答一堆交互有的只是想知道某个参数怎么写更效率。所以我需要的不是一个大而全的框架而是能嵌入现有工作流的轻量组合。atuin 解决的第一个问题是“找回命令”。它本质上是把 shell 的历史记录变成一个高效可搜索的数据库配合反向模糊搜索和上下文视图让我几秒钟就能翻出几个月前在某目录执行过的命令。expect 解决的第二个问题是“应答命令”。终端里大量工具没有提供非交互参数比如 ssh 的密码输入、某些安装程序的确认提示expect 可以预先定义“看到什么再输入什么”把这类机械应答变成自动化。ShellGPT 解决的第三个问题是“生成命令”。当我不确定某个命令的写法时与其翻手册不如直接用自然语言描述意图让 AI 生成可执行的命令行或脚本片段。它们的层次区分得很清楚一个管记忆、一个管交互、一个管生成。组合起来就是一个最小的命令行自动化闭环——从“知道要做什么”到“找到历史做法”再到“自动完成输入”最后“把命令留存回历史库”。相比之下fzf 和 zoxide 虽然也能提升检索效率但它们更偏导航工具不解决交互应答和命令生成的问题Ansible 功能强大但引入的成本高你需要在 inventory、playbook、模块语法上花很多时间对一个三五台服务器的环境来说显得笨重。所以我的建议也类似先别想着把环境一次性升级成某个自动化平台先用这几个小工具把日常高频操作变顺等真的有需要了再做脚本化、平台化。这套组合的另一个好处是它们都开源、跨平台macOS 和 Linux 都能用Windows 的 WSL 里也能跑后续切换环境成本极低。2. atuin让历史命令变成可搜索的个人数据库2.1 安装与初始化atuin 的安装方式取决于你的系统。macOS 可以用 Homebrewbrew install atuinLinux 可以用官方脚本安装curl --proto https --tlsv1.2 -LsSf https://setup.atuin.sh | sh装完之后需要在 shell 配置里加载它。以 Zsh 为例在 .zshrc 末尾加入一行eval $(atuin init zsh)如果是 Bash对应的是eval $(atuin init bash)这里有第一个坑如果你系统里装了 oh-my-zsh 或 zsh-autosuggestionsatuin init 这行尽量放在它们之后否则插件的历史补全可能会覆盖掉 atuin 键位绑定。重新加载配置后CtrlR 的经典历史搜索就会别替换成 atuin 的交互界面。2.2 核心操作搜索和上下文找回atuin 最常用的入口是快捷键 CtrlR。它的界面类似 fzf直接输入关键词就能模糊匹配但比 shell 自带的 CtrlR 好用太多原生版本必须在命令开头匹配而 atuin 支持命令内容任意位置的模糊匹配。比如我只记得之前跑过一条统计日志中 ERROR 数量的命令但记不清具体写法直接输入 log ERROR 就能搜到那条历史。如果你需要更精细的检索可以用命令行的 atuin searchatuin search -c --cmd docker --cwd /opt/app -l 20这个命令的意思是搜索在 /opt/app 目录下执行过并且包含 docker 的历史命令最多取 20 条。加 -i 可以进入交互式模糊搜索界面加 -a 可以搜索所有主机的历史。比单条历史搜索更实用的是上下文视图。当你按 CtrlR 搜到某条命令后再按 Tab 就可以展开看它附近执行过的上下命令。这个功能在做故障复盘时特别有价值你能顺着历史看到当时是先改了配置还是先重启了服务整个操作链路一目了然。我自己排查线上问题的时候靠这个上下文还原现场的次数非常多。2.3 多端同步与数据加密atuin 的同步功能也是我选它的重要原因。它可以把历史命令加密同步到官方服务器或者用自己的私有服务器。初始化同步需要先注册atuin login -u username -p password -k key这里面的 -k 参数是用于加密历史的密钥它会本地生成或者通过 atuin register 命令自动配置。同步的好处是换了电脑或终端后历史命令还在工作习惯不用重新培养。如果不放心官方服务器atuin 支持自建同步服务毕竟它用的是一套开源的同步协议数据在客户端加密后才上传服务端只能看到密文。我自己的做法是公司内网部署一个私有同步端个人电脑用官方服务两边数据隔离安全性上更有保障一点。2.4 实际效率提升和更容易忽略的细节装上 atuin 之后最直观的感受是几乎不再重复输入长命令。以前一天可能要敲几十次相同的 docker exec 或 git log 命令现在 CtrlR 一下就到手。实测下来大概能省我每天 30 到 40 分钟的找命令时间特别是当你在多个项目目录间切换的时候不同目录的同类命令还往往长得不一样这时候 atuin 的分目录筛选就体现出优势了。使用中有个细节我建议你注意历史记录里可能会包含敏感信息比如你在命令行里直接传过密码或 token。atuin 给了两个防护机制一是 shell 中设置 HISTCONTROLignorespace凡是前面加空格的命令不会进入历史二是 atuin 的过滤规则。你可以按需配置忽略核心关键词避免敏感命令进入数据库。3. expect把交互式应答从手工变成自动3.1 理解 expect 的工作方式expect 是一个基于 Tcl 的传统自动化工具它的核心思想特别简单启动一个程序等待看到某个输出然后发送预设的输入。你可以把它理解成一个“看着屏幕打字的人”屏幕上出现什么我们就回答什么。正因为它模拟的是真实终端交互所以几乎任何带交互提示的命令行工具都可以被它驱动不需要目标程序提供 API 或者非交互参数。最基础的使用方式是用 expect 命令直接执行一段脚本expect -c set timeout 10 spawn ssh root192.168.1.10 expect password: send mypassword\r interact 这里每条命令都有自己的角色spawn 负责启动一个子进程expect 等待指定的字符串出现send 向子进程发送输入interact 则把控制权交回给你这样自动化执行完之后你还能留在会话里继续操作。核心要点就是“期待什么、看到再发什么”顺序不能乱。timeout 是超时秒数如果屏幕上一直没有出现期待的内容脚本会在超时后继续执行所以像 SSH 首次连接时出现的 yes/no 提示也要单独处理。3.2 实战案例登录设备并自动执行一段巡检命令下面是我自己常用的一个场景。公司有一些网络设备和服务器不允许用公钥登录只能密码认证每天要做的巡检其实都一样登录、切换目录、跑一串命令、退出。用 expect 脚本可以把这个过程固化#!/usr/bin/expect set timeout 15 set host 192.168.1.20 set password your-password spawn ssh root$host expect { yes/no { send yes\r exp_continue } password: { send $password\r } } expect # send sh /opt/check.sh\r expect # send exit\r expect eof注意到这里用了 expect 的复合写法当出现 yes/no 时先确认然后继续等待 password最后用 exp_continue 回到等待状态。这种写法在实际中非常常用因为一台设备的首次连接提示和日常连接提示往往不一样一条路到底很容易卡住。脚本执行完后会退出整个 ssh 会话全程不需要人工干预。3.3 用 autoexpect 快速生成脚本骨架手写 expect 脚本文法不是特别复杂但对不熟悉 Tcl 的人来说起步还是有点门槛。这里给你一个偷懒技巧先运行 autoexpect它会录制你手工操作一次终端的全过程然后自动生成一个 expect 脚本。比如你先跑一遍登录服务器的操作把密码也输了exit 退出autoexpect 会把 spawn、expect、send 都自动写进一个 script.exp 文件里。autoexpect ssh root192.168.1.20生成的脚本通常有冗余内容比如把每个可见输出都当作 expect 模式你需要手动删减保留关键的模式切换点即可。我一般用 autoexpect 做草稿再用编辑器把密码和可变参数抽成变量最后换成复合 expect 写法收尾。这个方法能帮你跳过最初语法学习的过程直接把脚本用起来再逐步改进。3.4 expect 的边界与更优选expect 也不是万能的。有些程序输出的定位字符比较模糊比如都是冒号结尾expect 很容易匹配到错误位置这时建议在 prompt 中加入设备的用户名或目录信息来增加特征。另外随时变化的交互内容并不适合用 expect 硬匹配你最好还是为这类目标程序写 API 封装或者用 pexpect、paramiko 这类 Python 库来管理。如果你本身就在写 Python 脚本且希望同一套逻辑里既能管理远程连接又能处理复杂数据处理paramiko 会比 expect 顺手得多。expect 的优势在于它就是一个独立的可执行脚本只要能解释 Tcl 的环境就能跑不需要额外给目标机器装 Python 环境。我的原则是简单的交互式应答用 expect复杂的业务逻辑用 Python两者互补而不是互相替代。4. ShellGPT自然语言到命令的最后一公里4.1 安装与模型配置ShellGPT 是一个命令行 AI 助手包名叫 shell-gpt安装非常简单pip install shell-gpt安装后终端里会多出一个 sgpt 命令。它默认会尝试连接 OpenAI 的 API需要在环境变量里配置 OPENAI_API_KEY。不过考虑到很多人的环境并不方便使用云 API或者有数据隐私顾虑ShellGPT 也支持接入本地模型。只要你有一个本地推理服务比如 Ollama启动后配置一下 base URL 即可export OPENAI_BASE_URLhttp://localhost:11434/v1 export OPENAI_API_KEYollama这条配置的意义在于ShellGPT 走的其实是 OpenAI 兼容协议base URL 指到哪里它就从哪里调模型。用本地模型的好处是命令内容不出本机对处理敏感设备信息场景特别重要。我自己测试下来本地 7B 级别的模型做简单的命令生成和脚本改写已经够用复杂逻辑还是需要云端大模型但作为日常终端助手本地模型的响应速度已经足够。4.2 三个核心用法shell、code、chatShellGPT 的用法可以分成三种模式分别对应不同的需求。第一种是直接生成 shell 命令。如果我想找出当前目录下最近三天修改过且大于 100MB 的文件直接敲sgpt find current directory, files modified in last 3 days, larger than 100MB, output size and mtime它返回的可能是 find、fd 或 ls 的组合命令。注意 ShellGPT 默认只生成命令文本不会自动执行这点很重要——它可以帮你生成但执行与否的决定权始终在你手上。如果确认无误可以加 --exec 参数直接执行会有确认提示但我还是建议先看一遍。第二种是生成代码片段。用sgpt --code python script to parse nginx access log and count top 10 IPs它可以输出完整的 Python 脚本。这个模式对写临时脚本特别有用生成后直接保存到文件就能运行省去了很多查文档的时间。第三种是对话模式。用sgpt --chat进入连续对话上下文你可以接着上一篇继续讨论同一个问题。比如先让它分析一段启动报错日志再问它“根据这个错误下一步该检查什么”它能够记住前面的上下文。这个模式在排查问题时非常接近和一个同事实时讨论的状态。4.3 实战让 AI 帮你解释陌生命令我用的最多的其实不是生成而是解释。遇到一条看不太懂的复杂命令直接粘给 sgptsgpt explain this command: curl -s https://example.com/api | jq .data[] | select(.status\active\) | column -t它的解释会分点列出这条命令每一步做了什么、用了什么管道、最终输出什么样。这个功能对处理自己好久没碰的旧脚本特别有用比一条条拆管道分析快得多。把解释结果存成文档后续交接给队友也比甩一条冷冰冰的命令强。4.4 执行安全要放在心上ShellGPT 最让我警惕的地方是它生成的命令表面上都很有逻辑但你没法保证它 100% 符合当前环境。比如它可能会在没确认路径的情况下生成 rm -rf 相关操作或者执行方式与你的预期有偏差。我给自己定了一条铁律sgpt 生成的内容一律先看后跑尤其是 --exec 之前必须仔细检查一遍涉及到删除、覆盖、重启服务这类高危操作我会手动把命令拆开再确认一次。另外涉及生产环境的命令不要直接让 AI 生成更不要带 token 或密码发给模型。这条底线守住了工具带来的效率提升才真正安全。5. 把三者串成一条自动化的工单的实战案例5.1 场景每日日志统计讲完单独的工具我用一个日常场景把它们串起来假设我需要每天早上统计三台服务器上的应用日志找出 ERROR 数量以及最近 5 条错误详情然后写入一个汇总文件。传统做法是开三个终端、一条一条登录、翻日志整个过程大概 20 分钟。用三个工具配合可以缩短到 3 分钟。第一步用 atuin 找到昨天用过的登录命令和日志路径。因为每天统计的内容很相像历史里大概率已经存在相似命令atuin search --cmd ssh app-server --cwd /ops/check拿到服务器地址后第二步我需要写一个 expect 脚本来完成自动登录和命令执行。如果密码认证是唯一方式脚本大致长这样#!/usr/bin/expect set timeout 20 set host [lindex $argv 0] set pwd [lindex $argv 1] spawn ssh root$host expect password: send $pwd\r expect # send grep -c ERROR /var/log/app/app.log\r expect # send grep ERROR /var/log/app/app.log | tail -5\r expect # send exit\r expect eof执行时传入主机和密码两个参数就可以批量复用。如果不想在命令行暴露密码可以改成从环境变量读取配合 expect 脚本里的$env(PASSWORD)来取值。第三步让 sgpt 辅助加工。虽然 grep 命令已经能拿到数据和错误行但有时候我还想顺手把统计结果整理成日报格式这时可以让 ShellGPT 写一个小脚本把三台服务器汇总的结果合并去重并输出成表格sgpt --code python script to combine multiple server log result files, deduplicate, output markdown table生成脚本后检查一遍再运行最终报告直接落到本地。5.2 调度用 cron 定时触发如果想进一步全自动可以把这套 expect 脚本外包给 cron。比如每天 8 点 30 分执行一次30 8 * * * cd /ops/daily bash /ops/daily/run_all.sh /ops/daily/daily.log 21run_all.sh 内部循环调用 expect 脚本并把结果输出到带日期的文件。这里有几个容易踩的坑cron 的环境变量非常精简PATH 里通常没有 ssh、grep 这些命令的完整路径所以脚本里最好使用绝对路径或先 source 环境文件另外 expect 脚本里的 timeout 要设得充裕一些避免某台机器响应慢了导致整个任务失败。我建议先用人工模式跑通一轮确认每条 expect 命令都能匹配到预期输出后再上线 cron。5.3 工具的配合逻辑这个例子里三个工具的协作方式很清晰atuin 提供了对历史经验的快速复用expect 解决了登录和交互应答sgpt 负责生成那些原本需要查文档的辅助脚本。每种工具都在做自己最擅长的事没有一个是多余的。你可以根据自己的场景替换内部命令但整体的“找命令、自动答、生成脚本”三层结构是可以复用的思路。6. 使用这三个工具时必须注意的坑与安全底线6.1 敏感信息泄漏的常见治理思路expect 脚本里直接写密码是最常见的安全隐患。稍微不留神脚本就被带入版本库、传给同事或者被 atuin 记录到历史数据库中。我的建议是操作者自己本地维护一个独立的配置文件权限设为 600脚本从文件读取密码和环境变量不要硬编码在代码里。对于历史记录配合 atuin 的忽略规则把包含密码参数的命令都过滤掉避免二次扩散。6.2 工具本身的配置与边界atuin 的同步服务器要选可信的平台如果你对数据敏感优先自建同步服务expect 的匹配模式要包含足够特征避免过早匹配导致输入错位ShellGPT 生成命令一定要审查后再执行尤其要防止高危操作在未确认的情况下运行。这些都是我在实际使用中踩过或观察到的教训简单但很关键。6.3 日常使用底线小结历史命令如果不希望入库命令前加空格再敲。expect 中不硬编码口令优先使用密钥认证密钥认证解决不了时从本地配置文件读取变量。sgpt 模式下加 --code 生成的代码先看再跑加 --exec 执行的命令更要逐字检查必要时拆解成两步执行。涉及删除、覆盖、批量修改的命令第一次执行前增加 echo 或 --dry-run 验证逻辑。定期检查 atuin 历史库和 expect 脚本目录的权限设置避免共享账号下无谓的泄漏。注意定制品的安全原则先小范围测试再全部铺开能用只读命令测试就绝不用写操作测试。我这套组合用了大半年最大的感受是命令行自动化并不意味着要推翻原来的使用习惯。auitn 增强记忆、expect 接管机械应答、sgpt 辅助生成都是在不改变“人依然掌控操作”的前提下把重复劳动消掉。每天省下来的时间不需要很多但长期积累的效率提升是很可观的。如果你手里也有一批必须反复登录、反复输入的终端操作又不想引入重型的自动化框架这三个开源工具应该能帮你打开一个新的思路。
