恒美微站
首页
关于我们
建站服务
主题模板
案例展示
资讯中心
联系我们
AI时代最趁手的5个命令行工具:fzf、tmux、rg、jq、LLM实战
首页
资讯中心
/
AI时代最趁手的5个命令行工具:fzf、tmux、rg、jq、LLM实战
AI时代最趁手的5个命令行工具:fzf、tmux、rg、jq、LLM实战
发布时间:2026/9/26 5:51:55
AI 这两年火成什么样大家有目共睹各种图形化 AI 工具一茬接一茬地冒出来。但如果你留意一下那些真正在用 AI 干活的人会发现一个有意思的现象他们手里的终端窗口不仅没消失反而越开越多。这个反差其实说明了一件事——在 AI 时代命令行工具不仅没过时反而成了跟大模型打交道时最趁手的家伙。这篇不是来推荐某个 AI 产品也不是什么大模型部署教程而是我从日常开发、调试、跑模型的过程中筛出来的 5 个命令行工具。它们跟 AI 没有直接绑定关系但恰恰是它们让我在跟大模型配合的时候快人一步。无论你是本地部署过开源模型、写过调用 AI 接口的脚本还是单纯想用 AI 辅助写代码这套工具基本都能派上用场。我会把每个工具的适用场景、核心参数和踩过的坑一并讲清楚。1. 为什么 AI 时代命令行工具反而更吃香1.1 图形界面管不住 AI 工作流现在大家用 AI 的方式早就变了。以前可能只是打开网页聊两句现在 AI 已经嵌进了真实的工作流里尤其是做 AI 应用开发、本地部署大模型的场景。什么叫“真实的工作流”我举一个特别常见的例子你先写一段 prompt调用大模型接口拿到返回结果然后把返回的 JSON 解析出来提取想要的关键字段可能还要根据字段内容做下一步判断。这套流程如果你全程用鼠标点图形界面会非常割裂在网页里复制 prompt到另一个工具里看响应再手动去 JSON 里扒字段……一顿操作下来人已经累了。但如果你在终端里这件事可以用管道一行串起来。命令行工具天然就是干这个的一个工具负责生成输入一个工具负责调接口一个工具负责解析结果再用一个工具把最终摘要渲染出来。数据在工具之间流动全程不需要人工搬运。这种“组合拳”的思路恰好和现在 AI 应用开发里 Agent 的思维方式一致——没有哪个工具是万能的但把合适的工具串起来就能做出很复杂的自动化流程。1.2 命令行工具是模型的“另一双眼睛”还有一个更现实的原因大模型能帮你写命令但验证命令、排查问题还是得靠自己。你给模型一个清晰的上下文它大概率能给你生成一条像模像样的命令但生成之后就万事大吉了吗绝对不是。我自己就遇到过很多次让模型帮我写一条 jq 命令去解析某个 JSON 文件结果模型给出的字段路径是错的。为什么因为模型没有实时看到我本地的数据结构它只能根据常识猜。如果我自己懂 jq 的语法看一眼报错就能手动修正。但如果你完全不懂 jq只依赖模型给的答案可能来回试上十几遍还卡在原地。所以在 AI 时代懂命令行反而成了稀缺能力。模型的生成能力把你从“记语法”里解放出来了但你自己必须能判断命令对不对、输出符合不符合预期。会命令行的人才是真正能把 AI 用起来的人不会的人拿到 AI 也只是多了一个“百度”。1.3 我选工具的四条标准这里顺便说一下我是怎么从几百个命令行工具里挑出这 5 个的。一句话高频、可组合、可脚本化、学习曲线合理。高频不是偶尔用一次的冷门工具而是每周至少打开几十次的那种。可组合能用管道传入传出能和别的工具无缝衔接。像 tmux 这种虽然不是管道型工具但它为“长任务驻留”提供了底层保障也属于组合场景里不可缺少的一环。可脚本化输出的内容能被脚本、被 AI 工具当作输入再处理而不只是给人类眼睛看。学习曲线合理花 30 分钟学会基础用法就能带来长期收益。而不是像 Vim 那样虽然强大但需要几个月才能上手。基于这四条我从终端里反反复复用到的工具里筛出了下面这五个fzf、tmux、ripgrep、jq、还有终端里直接调用大模型的 CLI 工具。接下来逐个拆解。2. 五件套选型我为什么选这几个2.1 它们的组合定位这五个工具在我眼里不是一个“工具集合”而是一条完整的链路找东西、驻留任务、检索代码、解析数据、调用模型。fzf 解决的是“交互式选择”的问题。在终端里任何模糊搜索、文件选择、历史命令挑选全靠它。tmux 解决的是“长任务和会话管理”的问题。训练模型、跑批处理脚本、远程 SSH 调试时保证任务不因为网络中断而丢失。ripgrep 解决的是“大规模代码和文本检索”的问题。代码库变大之后搜索速度决定你的效率。jq 解决的是“ JSON 数据处理”的问题。AI 接口返回的基本都是 JSONjq 就是终端里最顺手的解析器。大模型 CLI 解决的是“把 AI 能力变成命令行原语”的问题。可以直接用管道把文件内容喂给模型或者把模型输出接给下一个命令。你发现没有这套组合覆盖了从“输入 → 计算 → 输出”的三个环节。fzf 和 rg 负责把原始材料找出来tmux 负责让重活在后台稳定跑jq 负责把人读不懂的数据变成人读得懂的结果最后的模型 CLI 负责把一切变成可交互的 AI 能力。2.2 各工具的位置和替代品我在实际推荐的时候经常被问“这个工具有没有替代品”。我列个表格方便大家按自己的习惯选型。工具核心定位常用替代品我为什么选它fzf终端模糊搜索/选择器fzy、peco、selecta交互体验最好能和命令历史、文件预览深度集成tmux终端复用与会话保持screen、Zellij生态成熟插件多SSH 场景下最稳的选择ripgrep快速全文检索grep、ag、ack速度第一梯队默认规则合理输出格式清晰jqJSON 解析与转换yqYAML、dasel语法简练过滤器功能强大脚本可复用llm / ollama终端调用大模型openai 官方 CLI、各种 IDE 插件和 Unix 管道哲学一致自由度高2.3 为什么不用“看起来更现代”的工具也有朋友问我现在 AI 的图形界面工具那么多有 ChatGPT 桌面版有各种全套 IDE 插件为什么还要折腾终端我的理由很简单图形界面工具的缺点在于它的输出是给人看的不是给下一个程序看的。你在图形界面里看到一段代码想把它再喂给另一个 AI 做二次分析怎么复制粘贴都行但很难自动化。而终端工具的输出是纯文本、纯结构化数据你可以直接管道传递、写入文件、作为下一轮 prompt 的上下文。这个差异决定了终端工具在“批量处理”和“自动化流程”上永远有图形界面不可替代的价值。3. 逐个上手核心用法与关键参数3.1 fzf万物皆可模糊搜索fzf 是 fuzzy finder 的缩写作用就是在终端里提供一个模糊搜索框。它最强的地方不是“搜索”本身而是它接收任意文本输入然后在匹配结果里让你选择并把选中的那一行打印到标准输出。有了这个特性它几乎能和任何命令组合。安装方式最简单的一种# macOS brew install fzf # Debian/Ubuntu sudo apt install fzf装完之后先做一件事把它绑定到 shell 的历史搜索和文件搜索上。以 zsh 为例# 在 ~/.zshrc 里加入 eval $(fzf --zsh)这样你按CtrlR就能模糊搜索命令历史按CtrlT就可以把选中的文件路径直接插入到当前命令里。我实际用得最多的两个场景一个是预览文件内容。fzf 支持--preview参数在搜索结果里高亮选中某个文件时右侧窗口会显示这个文件的内容预览。对于在项目代码里找配置文件、读日志非常高效。fzf --preview bat --stylenumbers --coloralways {} 2/dev/null || cat {}另一个是和 ripgrep 组合搜索所有文件的内容然后跳到匹配位置rg --line-number --no-heading | fzf --delimiter : --preview sed -n {1} 文件路径这里解释一下--delimiter :是说 fzf 以冒号作为分隔符这样它知道第一个字段是文件路径第二个字段是行号。预览命令里的{1}会被替换成第一个字段也就是文件名。这样在搜索结果里每选中一行右侧就会显示这个文件被定位到的那一行的上下文做代码排查非常舒服。3.2 tmux让长任务不再“断送”在掉线里tmux 解决的是终端会话的持久化问题。简单说你可以在服务器上开一个 tmux 会话在里面跑训练脚本或者启动一个服务然后断开 SSH。下次重新连上之后tmux 会话还在任务还在跑输出也还在。这个能力对 AI 场景太重要了。本地部署大模型、批量跑推理测试、长时间挂着一个 Agent 流程都是分钟级甚至小时级的长任务。如果直接在裸终端里跑网络一抖或者笔记本合盖任务就没了。基础用法极其简单tmux new -s train # 创建一个名为 train 的会话 tmux ls # 列出所有会话 tmux attach -t train # 重新连接到 train 会话 tmux kill-session -t train # 结束会话在会话内部所有的快捷键都有前缀默认是CtrlB。我常用的几个CtrlB然后c新建一个窗口CtrlB然后,给当前窗口重命名CtrlB然后%左右分屏CtrlB然后上下分屏CtrlB然后d脱离会话但任务继续跑还有一个经验跑长任务的时候不要直接在前台跑。用 tmux 分屏一个窗格跑训练另一个窗格留出来执行其他命令互不干扰。用CtrlB方向键切换窗格非常顺畅。另外要说一个插件tmux-resurrect。它能把 tmux 的会话状态持久化到磁盘上重启机器之后还能恢复。对于经常要反复跑实验的人来说等于给终端会话上了个“存档点”。# 在 ~/.tmux.conf 里启用 tj 的 resurrect 插件后 prefix Ctrls # 保存会话状态 prefix Ctrlr # 恢复会话状态3.3 ripgrep代码库里的“光速检索”rg 是 grep 的现代升级版用 Rust 写的。它的核心优势是快在大型代码库里做递归搜索时体验和 grep 完全是两个世界。项目几百上千个文件、包含 node_modules 和各种构建产物的情况下rg 默认会智能跳过隐藏文件、二进制文件、以及.gitignore里列出的路径所以你不需要手动排除一堆目录。安装方式# macOS brew install ripgrep # Debian/Ubuntu sudo apt install ripgrep基本用法我列几个高频的rg fetchAgent src/ # 在 src 目录下搜索关键词 rg -n fetchAgent src/ # 显示行号 rg -A 3 -B 2 fetchAgent src/ # 显示前后文 rg -l fetchAgent src/ # 只列出文件名 rg --type py def main . # 只在 Python 文件里搜 rg -g !test_*.py fetchAgent # 排除 test 开头的 Python 文件-g参数非常有用它让你可以用通配符来包含或者排除文件。比如你在一个超大前端项目里搜代码Node 的依赖目录通常会被自动忽略但如果某个依赖库的源码里也确实有你要搜的内容你可以临时加一条-g !node_modules之外的规则来调整。我实际用得最多的场景是“找一个函数在哪里被调用”。这个操作在 IDE 里也能做但 rg 在终端里可以直接接管道把结果喂给 fzf 或者喂给大模型做分析这是 IDE 做不到的。3.4 jqAI 接口返回数据的“翻译官”现在几乎所有 AI 服务的接口返回都是 JSON。调试 API 时如果你直接curl xxx | cat看输出很可能被堆成一坨的 JSON 搞得头晕。jq 就是解决这个问题的它把 JSON 变成可以查询、过滤、转换的结构化数据。安装方式# macOS brew install jq # Debian/Ubuntu sudo apt install jq核心语法并不复杂。我用一个模拟的 AI 接口返回数据来演示{ id: chatcmpl-123, choices: [ { index: 0, message: { role: assistant, content: 你好我是AI助手 } } ], usage: { prompt_tokens: 20, completion_tokens: 10, total_tokens: 30 } }先把这个 JSON 存到response.json然后# 提取 choices 下第一个元素的 message.content jq -r .choices[0].message.content response.json # 输出你好我是AI助手-r参数表示裸输出不加引号方便直接作为下一个命令的输入。再来一个复杂点的如果我要统计多个请求的总 token 消耗可以用jq .usage.total_tokens提取每个请求的 token 数然后用awk求和cat responses.jsonl | jq -r .usage.total_tokens | awk {s$1} END {print s}这里有个小细节JSONL 每行是一个独立的 JSON 对象jq 天然支持逐行处理所以你可以把一整个请求日志文件喂给 jq逐行提取字段然后用 awk 做聚合。这种组合在分析 API 账单的时候非常实用。jq 真正强大的地方是过滤器可以链式拼接。比如按某个字段分组统计cat logs.jsonl | jq -r [.model, .usage.total_tokens] | tsv | awk {a[$1]$2} END {for (k in a) print k, a[k]}这里tsv把数组转成了以 Tab 分隔的行再交给 awk 做按模型维度汇总。如果你不熟 awk 也没关系这个思路本身就是“命令行组合拳”的精髓。3.5 大模型 CLI把 AI 变成终端里的“一条命令”前面几个工具解决的是“处理已有数据”的问题最后一个工具解决的是“让 AI 干活”的问题。现在有现成的 CLI 工具可以直接在终端里调用大模型。我用得比较多的是llm这个命令行工具它是一个纯 Python 写的工具可以接入多家模型提供商也支持通过插件连接本地部署的模型服务。安装很简单pip install llm配置模型密钥后最基础的用法是llm 帮我解释一下什么是函数柯里化它会直接把模型返回的文本打印到终端。真正让我离不开它的是它可以接收管道输入。例如我把一段代码喂给它让它做代码审查cat src/agent.py | llm 请帮我检查这个 Python 文件找出潜在的 bug 和性能问题看到没有这是一条完整的命令行管道cat负责读文件llm负责“理解”并生成反馈。你可以把它无缝嵌入任何已有的命令行工作流里。如果本地已经部署了开源大模型也可以用llm连接本地的模型服务比如通过 Ollama 插件llm install llm-ollama llm 你好 -m ollama/qwen3:8b本地部署的好处是数据不出本机适合处理敏感资料。而且你完全可以在 Shell 脚本里调用它实现“自动给一批文档写摘要”“批量给代码文件加注释”这种重复劳动。4. 组合实战一套 AI 提效工作流的完整演示4.1 场景一批量分析 API 请求日志我有一个常见的需求本地在跑一些 AI Agent 测试产生了大量日志文件我想统计出每天请求了哪些模型、总共消耗了多少 token、哪些请求报错了。传统做法是打开日志文件用眼睛一条条看或者写一段复杂的 Python 脚本。但在命令行工具的组合下这个过程可以拆成三步先搜索日志中所有的请求记录并提取 JSONrg request logs/ request_lines.txt然后用 jq 从每行 JSON 中提取关键字段cat request_lines.txt | jq -r [.timestamp, .model, .usage.prompt_tokens, .usage.completion_tokens] | tsv token_stats.tsv最后用 awk 汇总awk {a[$2]$3; b[$2]$4} END {for (k in a) print k, prompt:, a[k], completion:, b[k]} token_stats.tsv整个过程不需要打开任何一个图形编辑器也不需要写 Python 代码。更妙的是如果我想让 AI 帮忙分析这些日志里的异常模式只需要加上最后一步cat token_stats.tsv | llm 请帮我分析这个 token 使用统计指出可能存在的问题五个工具在这里串成了一条流水线rg 负责捞数据jq 负责清洗awk 负责聚合llm 负责解读tmux 保证处理长日志时任务不会中断。4.2 场景二用 AI 给一批文档自动生成摘要假设你手头有 20 个 markdown 文件需要逐个生成摘要。用命令行工具组合可以一个命令搞定for f in docs/*.md; do echo $f head -100 $f | llm 用一句话概括这篇文档的核心内容 done summaries.txt这个循环会遍历docs/下的所有 md 文件取每个文件的前 100 行作为上下文让模型生成一句话摘要然后全部写进summaries.txt。注意这里我用head -100截断了输入因为模型上下文窗口有限一次性喂整个长文档可能会超出 token 限制而且成本也更高。如果你觉得这样太慢完全可以加上并发控制。xargs 天然支持并行find docs/ -name *.md -print0 | xargs -0 -P 4 -I {} sh -c echo {} ; head -100 {} | llm 用一句话概括这篇文档的核心内容-P 4表示同时跑 4 个进程。实测下来20 个文件能在几十秒内全部处理完。这就是命令行工具的优势——不用写 Python不用开 Jupyter几行命令组合就能实现一个简单的 AI 批处理应用。4.3 场景三给开源项目做快速代码走查拿到一个新项目想快速了解它的结构和潜在风险点。我的流程是这样的先用 rg 找出项目里所有 Python 文件rg --type py -l . | head -20再用 fzf 交互式选一个文件直接预览rg --type py -l . | fzf --preview bat {} 2/dev/null || cat {}选中之后把整个文件内容丢给 AI 做审查cat path/to/file.py | llm 你是资深 Python 开发者请审查这个文件指出风险和可优化点并用编号列出这里我甚至可以再加一步同时让模型生成一个“修改后的版本”。但需要提醒的是模型给的建议不一定完全适用你必须结合上下文判断。这就是为什么我强调“懂命令行的人才有判断力”——模型给你的命令和代码最终还是要你自己验证。5. 常见问题与避坑实录5.1 fzf 初始化慢、预览卡顿怎么办fzf 在 Windows 的 Git Bash 或者 WSL 里有时候会感觉比较慢。最常见的两个原因一是你的文件系统太慢二是预览命令每次都启动了一个重量级子进程。解决方法如果在 WSL 里把项目放在 Linux 文件系统下不要放在/mnt/c/这种挂载盘上性能差距非常明显。另一个技巧是在预览命令里设置超时fzf --preview timeout 0.5 bat --coloralways {} 2/dev/null || cat {}这样如果文件太大或者 bat 命令执行超过 0.5 秒就直接回退到cat不会卡住主流程。5.2 tmux 里的鼠标滚轮和复制粘贴刚用 tmux 的人都会遇到一个困惑为什么在 tmux 里用鼠标滚轮窗口不滚动而是滚动 tmux 的历史如果你想让鼠标滚轮直接滚入 tmux 的备份缓冲区可以这样配置# 在 ~/.tmux.conf 里写入 set -g mouse on开启鼠标模式之后滚轮会滚动 tmux 缓冲区也可以直接用鼠标选中文本进行复制。但这个设置有个副作用当你用鼠标滚轮查看长输出时回到命令提示符后显示位置可能会错位。我的习惯是平时不开鼠标模式只在查看长日志时用前缀键 [进入复制模式然后用方向键翻阅。还有一个坑tmux 里 CtrlB 和很多 shell 快捷键冲突。我在 zsh 里用CtrlB做别的绑定结果 tmux 里按前缀键没反应。解决方法是用prefix键重新绑定为别的快捷键比如set -g prefix C-a unbind C-bC-a 离左手更近实际操作也更顺手。5.3 jq 解析失败、字段缺失怎么处理jq 最常遇到的坑是 JSON 格式非法。尤其是你从接口返回里复制的 JSON 可能带了额外字符或者 JSONL 文件某一行本来就是空行。这时 jq 会直接报parse error而不会跳过错误行。解决办法是用-c配合--seq或者用正则过滤空行grep -v ^\s*$ file.jsonl | jq -r .field另一个常见问题是某个字段可能不存在jq 会返回null。如果你想把缺失字段统一替换为默认值可以用//操作符jq -r .data.name // unknown这在处理 AI 接口输出时尤其好用。比如模型有时候不按约定返回content字段你直接.choices[0].message.content // 就能避免整个管道因为 null 而中断。5.4 rg 搜不到文件、搜到过多干扰项怎么办rg 默认会尊重.gitignore这个特性大部分时候很贴心但有时候也会让你困惑为什么明明有这个文件rg 就是搜不到解决方案有两个一是用--no-ignore忽略所有忽略规则二是用-uu同时包含隐藏文件。rg -uu search_term .这个命令会搜索包括隐藏文件在内的所有文件。但要提醒的是这会拖慢搜索速度因为隐藏目录比如.git里面内容很多。更推荐的做法是精确指定搜索范围rg search_term src/ docs/ --type md这样既避免了对大型隐藏目录的扫描又保证了搜索结果的精度。另一个经验rg 搜索中文内容时如果终端编码不是 UTF-8可能会乱码。这个不是 rg 的问题而是终端环境变量的问题。在 WSL 或 SSH 到 Linux 服务器时记得设置LANGen_US.UTF-8或LANGzh_CN.UTF-8。5.5 用 llm 工具时遇到的超时、截断和限流用 CLI 调用大模型接口最常见的坑是请求超时。默认的 HTTP 客户端通常有 60 秒超时但有些模型生成长文本时可能会超过这个时间。我的建议是给 llm 加上超时参数或者在模型服务端把超时时间调高。另一个是长度截断。生成的回答可能在你没看完全部内容时就被截断了解决方案是设置-o max_tokens 4096之类的参数显式控制生成长度llm 写一篇详细的技术分析 -o max_tokens 4096还有限流。如果你用并发模式批量调用模型接口很容易触达 API 的速率限制。我的经验是如果你的 API 账号本身的 limits 不高别直接开-P 10先试试-P 2。同时留意一下返回 429 状态码时的重试策略llm 工具有内置的重试逻辑但配合--attempts 3这种参数更稳妥find docs -name *.md -print0 | xargs -0 -P 2 -I {} sh -c head -200 {} | llm 摘要 --attempts 35.6 本地部署模型时的终端优化最后一个偏方也是我最近半年用得最多的地方。如果你本地部署了一个开源模型想在终端里快速试 prompt我建议把ollama run和 fzf 组合起来用。比如你有一个正在运行的模型服务想在终端里快速和它对话又不想每次敲一长串命令可以给 shell 配一个函数function ai() { ollama run qwen3:8b $* }配合 fzf 的历史记录你甚至可以模糊搜索之前试过的 promptfc -ln | fzf --preview echo {} | xargs -I {} llm {}这个组合解决的是“prompt 工程”的痛点你试过哪些 prompt、效果如何全部在终端历史里留痕方便复盘迭代。这比在图形界面里点来点去要高效得多。写在最后根据我自己的实际体感这些命令行工具在大模型时代不是过时了而是换了一种存在方式。以前它们是“效率工具”现在它们更像是“跟 AI 协作的接口”。你在终端里处理文本、数据、代码的速度越快你和 AI 配合起来就越流畅——因为 AI 其实就是一个文本进、文本出的系统而终端恰好是把文本玩得最溜的地方。最后再分享一个小技巧把这些工具和 AI Agent 结合时别把“让模型直接写完整命令”当默认做法更优的策略是让模型做决策、你自己做执行。比如你问模型“我想统计这个目录下所有 Python 文件的行数”模型给你的命令可能不准确但如果你心里清楚 rg、wc、awk 该怎么组合你就能把模型的建议快速改造成一条靠谱的管道。这种“人机协作”的体验是纯靠图形界面完全得不到的。