6 款轻量级 CLI 工具，取代了我臃肿的开发软件

以前写代码，我常年同时开着四十多个 Chrome 标签页。

Jira 用来追任务，Confluence 用来翻文档，Postman 用来测接口，Slack 里挂着三个团队的消息，Figma 放设计稿，DataDog 看监控，GitHub 做代码审查。工具一个不少，窗口一层套一层，电脑却越来越像在替我受刑。

最夸张的时候，笔记本风扇吼得像飞机起飞，内存占用长期贴着 95% 徘徊。每开一个新标签页，就得先狠心关掉一个旧的。那种感觉，不是在工作，更像是在和机器抢最后一点呼吸权。

后来，我的电脑真撑不住了，直接罢工。

等新电脑寄来的那几天，我只能 SSH 连到一台远程服务器上干活，手头能用的东西极其寒酸：vim、curl，再加一个终端。没有 Electron 应用，没有网页后台，没有那些花里胡哨的图形界面。就几件最基础的工具。

结果偏偏就是那三天，我交付出去的东西，比前两周加起来还多。

也是从那一刻起，我突然意识到一个不太舒服的事实：很多开发工具，并没有真正让我们变得更高效；它们只是更擅长消耗资源而已。于是，我给自己定了个目标------把那些又重又慢、存在感极强的开发软件，换成真正"干活不碍事"的轻量工具。

下面这 6 个工具，基本替换掉了我原来那套笨重的工作流。我的电脑谢谢它们，我的专注力更谢谢它们。

1. jq 替代了 Postman，顺手还干掉了我一半自写脚本

Postman 本质上是在做什么？发 HTTP 请求、看响应、格式化 JSON。

可问题是，为了做这几件事，它经常要吃掉几百 MB 内存。就为了发个请求、看个返回值，代价未免太高。

而 curl 加 jq 呢？两者加一起，差不多也就几 MB。功能不花哨，但真够用。

以前我在 Postman 里通常是这么干的：

发送请求等界面慢吞吞加载点来点去找响应内容复制 JSON 再贴到别的工具里筛字段然后继续重复

现在呢？我直接这样写：

go 复制代码

# 获取用户数据，只提取邮箱和订阅状态
curl -s https://api.example.com/users/123 \
  -H "Authorization: Bearer $TOKEN" \
  | jq '{email: .email, subscribed: .subscription.active}'

# 输出：
{
  "email": "user@example.com",
  "subscribed": true
}

如果要同时测试多个接口，也完全不必点界面。丢进一个 bash 脚本就行：

go 复制代码

#!/bin/bash
# test_api.sh

BASE_URL="https://api.example.com"
TOKEN="your-token-here"
endpoints=(
  "/users/123"
  "/users/123/orders"
  "/users/123/preferences"
)

for endpoint in "${endpoints[@]}"; do
  echo "Testing $endpoint"
  response=$(curl -s -w "\n%{http_code}" "$BASE_URL$endpoint" \
    -H "Authorization: Bearer $TOKEN")
  
  http_code=$(echo "$response" | tail -n1)
  body=$(echo "$response" | sed '$d')
  
  if [ "$http_code" -eq 200 ]; then
    echo "✓ Success"
    echo "$body" | jq '.'
  else
    echo "✗ Failed with status $http_code"
  fi
  echo "---"
done

这个脚本我直接放在项目仓库里，跟代码一起版本管理。它可以在 CI 里跑，也不会像某些桌面应用一样，在你切到别的事情时还默默占着几百 MB 内存不撒手。

但真正让我离不开 jq 的，不只是"替代 Postman"，而是它对 JSON 的处理能力实在太顺手了：

go 复制代码

# 从数组中取出所有用户邮箱
curl -s https://api.example.com/users | jq '.[].email'

# 按订阅状态筛选用户
curl -s https://api.example.com/users \
  | jq '[.[] | select(.subscription.active == true)]'

# 重塑数据结构
curl -s https://api.example.com/orders \
  | jq 'map({id: .order_id, total: .amount, date: .created_at})'

当然，我并没有把 Postman 卸得干干净净。遇到复杂认证流程，或者要把请求分享给不懂技术的同事时，它还是方便的。然而，至少 90% 的接口测试场景里，curl + jq 都更快、更轻，也更容易脚本化。

2. fzf 替代了文件搜索工具

以前在代码库里找文件，我习惯依赖 Sublime Text 的 "Go to Anything"，或者 VS Code 的模糊搜索。它们确实做得不错，问题只是：这些功能都寄生在一个动辄两三百 MB 的编辑器里。

后来我发现了 fzf。

它是个命令行模糊查找器，体积小得惊人，差不多只有几 MB，却异常能打。

go 复制代码

# 查找并打开文件
vim $(fzf)

# 搜索文件内容并跳到对应行
rg "TODO" --line-number | fzf | awk -F: '{print "+"$2" "$1}' | xargs vim

# 查找目录并进入
cd $(find . -type d | fzf)

真正强的地方在于，它可以和 shell 快捷键绑在一起，直接融进你的日常操作：

go 复制代码

# 写进 .bashrc 或 .zshrc

# Ctrl-T：模糊查找文件并插入到命令行
export FZF_CTRL_T_OPTS="--preview 'bat --color=always --line-range :50 {}'"

# Ctrl-R：增强历史命令搜索
export FZF_CTRL_R_OPTS="--preview 'echo {}' --preview-window down:3:hidden:wrap"

# Alt-C：模糊查找目录并 cd 进去
export FZF_ALT_C_OPTS="--preview 'tree -C {} | head -50'"

这样一来，Ctrl-R 不再只是翻 bash 历史，而是可以带预览地模糊查找；Ctrl-T 也能让我一秒在项目里捞出任意文件。整个过程快、直接，而且几乎没额外负担。

我通常还会把它和 ripgrep 搭配起来做代码定位：

go 复制代码

# 搜索函数定义并打开
rg "^function.*exportReport" --line-number \
  | fzf \
  | cut -d: -f1-2 \
  | xargs -I {} sh -c 'vim +$(echo {} | cut -d: -f2) $(echo {} | cut -d: -f1)'

看上去有点复杂，但我早就给它配好别名了。核心不是命令长不长，而是：我现在用不到原来那种沉重的 GUI 编辑器，也能比 VS Code 更快地搜完整个代码库，内存占用却低得多。

3. tmux 替代了我所有"花式终端分屏"习惯

以前我习惯用 iTerm2，开很多 tab，再切很多 split。只要一直在本机工作，这套方式没有太大问题。可一旦切到远程开发场景，尤其是 SSH 到服务器上，我那套操作习惯就立刻失灵。

后来我学会了 tmux。

它最打动我的地方不是"炫"，而是它在哪都能用。本地行，远程也行；换机器可以，换 Unix 系统也照样不耽误。你不需要重新适应环境，肌肉记忆直接继承。

go 复制代码

# 给每个项目开一个会话
tmux new -s api-service
tmux new -s frontend
tmux new -s infrastructure

# 分屏
# Ctrl-b % 纵向分屏
# Ctrl-b " 横向分屏

# 切换会话
# Ctrl-b s

# 分离与重新连接
tmux detach
tmux attach -t api-service

它最狠的一点，是会话会一直活着。

我可以 SSH 到远程开发机，在一个 pane 里跑 dev server，在另一个 pane 里跑测试，在第三个 pane 里盯日志。晚上合上电脑回家，第二天早上再连回去，执行一次 tmux attach，一切都还停留在昨天离开的地方。

开发服务没停，日志还在滚，vim 还开着。

这种"上下文不丢"的体验，真的会让人上瘾。

我自己的配置文件承担了不少工作：

go 复制代码

# ~/.tmux.conf

# 把前缀键改成 Ctrl-a
unbind C-b
set-option -g prefix C-a

# 用 | 和 - 分屏
bind | split-window -h
bind - split-window -v

# 类 Vim 的 pane 切换
bind h select-pane -L
bind j select-pane -D
bind k select-pane -U
bind l select-pane -R

# 开启鼠标支持
set -g mouse on

# 不自动重命名窗口
set-option -g allow-rename off

# 扩大滚动缓冲区
set-option -g history-limit 10000

iTerm2 当然依旧是个不错的本地终端工具。不过，tmux 更轻，也更通用。更重要的是，不管你身处本地还是远程，操作逻辑都完全一致，不需要来回切脑子。

4. entr 替代了文件监视工具

Nodemon、Webpack dev server、Parcel，还有各种热更新工具，很多人一装就是一整套。它们的确方便，可代价也很明显：为了监控文件变化然后执行一个命令，往往要挂着不小的资源开销。

entr 这个工具就简单粗暴得多。

体积小，能力清晰，工作方式也毫不拐弯：监控文件，文件一变，就跑命令。完了。

go 复制代码

# 监听 Python 文件并跑测试
find . -name "*.py" | entr pytest

# 监听 Markdown 并重建文档
ls docs/*.md | entr make docs

# 监听源码并重新构建
find src -name "*.ts" | entr -c npm run build

-c 参数会在每次运行前清屏，-r 则适合重启长时间运行的服务：

go 复制代码

# 文件变化时自动重启服务
find . -name "*.py" | entr -r python app.py

我通常会在每个项目里都放一个简单脚本：

go 复制代码

#!/bin/bash
# watch.sh

case "$1" in
  "test")
    find . -name "*.py" -not -path "./venv/*" | entr pytest
    ;;
  "lint")
    find . -name "*.py" -not -path "./venv/*" | entr -c pylint src/
    ;;
  "server")
    find . -name "*.py" -not -path "./venv/*" | entr -r python -m uvicorn main:app
    ;;
  *)
    echo "Usage: ./watch.sh [test|lint|server]"
    ;;
esac

没有配置地狱，没有插件生态，也没有一层套一层的抽象。只是老老实实盯着文件，变了就执行命令。说白了，它有点"无聊"，可也正因为无聊，所以特别稳。

5. bat 和 ripgrep 取代了我的文本搜索界面

Sublime Text 的全文搜索确实很强，这一点没什么可否认的。但问题还是那个问题：你得先启动一个不算轻的编辑器，还要让它去索引整个项目，之后才能愉快搜索。

ripgrep 就不一样了。

它快得离谱，资源占用又低，很多时候你甚至感觉不到它存在。

go 复制代码

# 基础搜索
rg "function handleSubmit"

# 带上下文搜索
rg -C 3 "handleSubmit"

# 只搜特定文件类型
rg "TODO" -t python
rg "FIXME" -t js -t ts

# 只列出匹配文件名
rg -l "import React"

# 忽略大小写
rg -i "error"

再配上 bat 这个更好看的 cat，体验会再上一个台阶：

go 复制代码

# 带语法高亮查看文件
bat src/main.py

# 查看指定行范围
bat -r 50:100 src/main.py

# 显示 git diff 信息
bat --diff src/main.py

我自己最常用的一组组合拳是这样的：

go 复制代码

# 找出包含某个模式的文件，并预览
rg -l "handleSubmit" | fzf --preview 'bat --color=always {}'

这条命令会先把所有包含 "handleSubmit" 的文件列出来，然后你可以继续模糊过滤，同时右边直接看到带语法高亮的预览内容。

说真的，这套体验比我以前用过的大多数 GUI 搜索工具还顺。更快，也更省。

6. 纯文本文件，替代了我所有笔记类应用

Notion 我试过，Evernote 我试过，Obsidian 我也认真用过一阵。它们都不算差，甚至各有优点。可共同的问题也很明显：偏重、格式体系各有门道、笔记一多就开始拖沓。

最后，我还是回到了最朴素的办法------纯 Markdown 文件，放进一个 Git 仓库。

我的目录大概长这样：

go 复制代码

~/notes/
├── work/
│   ├── 2024-03-01-api-redesign.md
│   ├── 2024-03-08-performance-investigation.md
│   └── meeting-notes/
├── learning/
│   ├── postgres-performance.md
│   ├── rust-ownership.md
│   └── distributed-systems.md
└── personal/
    ├── ideas.md
    └── reading-list.md

我的工作流也很简单：

go 复制代码

# 新建笔记
note() {
  local date=$(date +%Y-%m-%d)
  local title="$1"
  local file="$HOME/notes/work/${date}-${title}.md"
  
  echo "# ${title}" > "$file"
  echo "" >> "$file"
  echo "Date: $(date +%Y-%m-%d)" >> "$file"
  echo "" >> "$file"
  
  vim "$file"
}

# 搜索笔记
search_notes() {
  rg "$1" ~/notes/ | fzf --preview 'bat --color=always $(echo {} | cut -d: -f1)'
}

# 每日工作日志
log() {
  local date=$(date +%Y-%m-%d)
  local file="$HOME/notes/work/daily-${date}.md"
  
  if [ ! -f "$file" ]; then
    echo "# Work Log - ${date}" > "$file"
    echo "" >> "$file"
  fi
  
  echo "$(date +%H:%M) - $*" >> "$file"
}

平时我就这么用：

go 复制代码

# 新建一篇笔记
note "api-redesign"

# 追加到工作日志
log "Fixed bug in payment processor"
log "Meeting with frontend team about new API"

# 搜索所有笔记
search_notes "postgres performance"

这种方式带来的好处，其实非常实在。

文件是纯文本的，足够长期、足够稳定；所有内容都能被 Git 追踪，改了什么一目了然；离线也能用，不会被同步故障绑架；搜索几乎是秒出结果；不存在厂商锁定，因为它本来就只是 Markdown；更关键的是，只有打开时才占资源，平时基本没负担。

我现在就在不同机器之间用 Git 同步这整个目录。要分享内容的时候，也根本不需要什么"导出"按钮，直接复制 Markdown 就好了。它天生就是可迁移的。