終端機現代化：DevOps 工程師的六個 CLI 升級

前言：差點對錯誤的 cluster 下指令

某天下午，我在兩個 EKS（Amazon Elastic Kubernetes Service）cluster 之間切換除錯，staging 和 production 的 kubeconfig context 都掛在同一台筆電上。當我打完 kubectl delete deployment 按下 Enter 前的那半秒，我其實不確定自己在哪個 context。那次運氣好，是 staging。

事後檢討，問題不是粗心，是預設的終端機提示字元什麼都不告訴你。user@host ~ % 這行字 20 年來沒變過，但我們的工作環境早就變了：一個人同時面對多個 cluster、多組 AWS 帳號、十幾個專案目錄。工具沒跟上環境，靠的就只剩自律——而自律總有失靈的一天。

這篇文章整理我把終端機全面現代化的過程：六個主力工具，加上一批不用安裝任何東西的原生 shell 技巧。每個工具都回答三個問題：為什麼要換、不換的代價是什麼、以及會踩到哪些坑。

六個升級，按痛點排序

1. starship — 操作 EKS 前，先看一眼提示字元

starship 是用 Rust 寫的跨 shell 提示字元引擎。裝完之後，每行指令前會自動顯示：目前路徑、git 分支與狀態、語言版本，以及對 DevOps 最關鍵的兩個欄位——kubernetes context 和 AWS profile：

~/work/api-server on  main via 🐍 v3.11.4
☸ arn:aws:eks:ap-northeast-1:123456789012:cluster/prod-cluster (default)
❯

為什麼這樣做？ 防呆的本質是把「需要主動確認的事」變成「被動就會看到的事」。kubectl config current-context 誰都會打，但沒有人會在每一條指令前打一次；提示字元每次都在，你想忽略都難。

不這樣做會怎樣？ 回到開頭的故事——你對 production 下了一條本來要給 staging 的指令。這種錯誤一年只要發生一次，造成的損失就遠超過所有花在工具上的時間。

會踩的坑： starship 預設模組很多，進到大型 git repo 時掃描狀態可能拖慢提示字元出現的速度。用 ~/.config/starship.toml 把用不到的模組關掉，並善用 command_timeout 設定。另外 took Xs 欄位（指令跑超過 2 秒才出現）是隱藏的好物——CI 腳本哪一步慢了，一眼就看到。

2. fzf — 把「找」這個動作統一成一個介面

fzf 是模糊搜尋過濾器。裝好後三組快捷鍵自動生效：Ctrl+R 搜尋歷史指令、Ctrl+T 搜尋檔案、Alt+C 模糊切換目錄。

但 fzf 真正的威力是當管線元件用。它的輸入是任何清單、輸出是你選中的那一行，於是任何指令都能加上互動式選擇：

# 模糊選分支再 checkout——不用再記分支全名
git checkout $(git branch | fzf)

# 從 process 清單裡挑一個殺掉
kill -9 $(ps aux | fzf | awk '{print $2}')

為什麼這樣做？ 我每天按 Ctrl+R 約 20 次。傳統的上鍵翻歷史是 O(n) 的線性掃描，fzf 把它變成「打關鍵字直接命中」。單次省 5 秒，一天就是 100 秒，而且省掉的不只是時間，是打斷思路的成本。

會踩的坑： Ctrl+R 按 Enter 是直接執行，按 → 才是貼回命令列讓你編輯。對著歷史裡的 terraform destroy 按錯這兩個鍵，後果差很多——建議養成一律先 → 再確認的習慣。

3. zoxide — cd 的 frecency 升級

zoxide 會記住你去過的目錄，之後打 z api 就能跳到路徑含 api 且你最常去的那個資料夾。排序演算法是 frecency = frequency（頻率）+ recency（新近度），跟瀏覽器網址列的補全邏輯同源。

會踩的坑： 剛裝好時資料庫是空的，z 什麼都跳不了，很多人這時就放棄了。它需要「先去過才記得」——撐過第一週，命中率會高到讓你回不去。原本的 cd 沒有被覆蓋，隨時可以混用。

4. eza — exa 停止維護後的社群接棒

ls 的現代替代品 exa 不久前宣告停止維護，社群隨即 fork 出 eza 接手。如果你已經在用 exa，參數幾乎可以無痛沿用；Homebrew formula 上架前，可以先用 cargo install eza 安裝。

對工程師最有感的是 --git 欄位——在 repo 裡列目錄時，每個檔案旁直接顯示 git 狀態（M=modified、N=new）：

alias ll='eza -l --git --group-directories-first'
alias lt='eza --tree --level=2'   # 樹狀檢視，取代 tree

為什麼換？ 不是為了好看。ll 一眼看出哪些檔案改過沒 commit，等於把 git status 的一半資訊免費附在每次列目錄上。

5. bat — cat 加上語法高亮，而且管線安全

bat 是 cat 的替代品：語法高亮、行號、git 修改標記。最重要的設計是管線安全——當輸出端不是終端機時（例如 bat x | grep y），它自動退化成純文字，行為與原本的 cat 完全一致。

為什麼這個細節重要？ 替代工具最大的風險是破壞既有腳本。bat 的設計哲學是「互動時加值、管線中隱形」，這讓你可以放心 alias cat='bat' 而不用擔心 cron job 或 CI 腳本壞掉。看 log 時 bat app.log 有行號和高亮，bat app.log | grep ERROR 照常運作。

6. tmux — SSH 斷線，但工作不死

tmux 是 terminal multiplexer（終端機多工器）。對 DevOps 來說它解決一個致命問題：SSH（Secure Shell）連線斷掉時，跑到一半的工作跟著死。

tmux new -s deploy      # 開一個叫 deploy 的 session
# ... 跑長時間的 migration / 部署，網路斷線也沒關係 ...
tmux attach -t deploy   # 重連後接回原現場，畫面跟你離開時一模一樣

不用 tmux 會怎樣？ 在遠端主機跑 2 小時的資料庫 migration，咖啡廳 Wi-Fi 閃斷一秒，process 收到 SIGHUP 死在 47%。nohup 能保住 process，但保不住你的工作現場——tmux 連畫面、捲動歷史、分割視窗全部保留。

會踩的坑： tmux 的快捷鍵前綴 Ctrl+B 與部分編輯器衝突，而且學習曲線是六個工具中最陡的。建議先只學三招：new -s、detach（Ctrl+B 再按 d）、attach -t，其他等需要再說。

不用裝任何東西：原生 shell 技巧速覽

以下技巧零安裝、所有環境通用——SSH 進任何一台裸機都帶著走，這正是它們的價值：

最後一個趣味收尾：thefuck。打錯指令後輸入 fuck，它會猜你本來要打什麼並代為修正。是的，這是它的本名；是的，它意外地好用。

Nerd Font：圖示顯示的前置作業

starship 的部分符號與 eza 的 --icons 需要 Nerd Font 才能正常顯示，否則會看到方框：

brew install --cask font-meslo-lg-nerd-font

裝完到終端機設定把字型改成 MesloLGS Nerd Font 即可。沒裝也能用，只是少數圖示變方框，不影響功能。

一週養成計畫

工具裝完只是開始，肌肉記憶才是終點。我的做法是一次只攻一個習慣：

1. 第 1–2 天：強迫自己用 Ctrl+R，禁用上鍵翻歷史
2. 第 3–4 天：移動目錄一律先試 z 關鍵字，失敗才用 cd
3. 第 5 天起：ll 取代 ls -la，遠端長任務一律先開 tmux
4. 隨時：對任何 cluster 下指令前，先看一眼提示字元的 ☸ 欄位

總速查表

結語

這六個工具沒有一個是必需品——預設的 shell 用 20 年也能活。但 DevOps 的日常是在多個環境、多個 cluster、多條 SSH 連線之間切換，環境複雜度早已超過預設工具的設計假設。把確認 context 變成被動可見、把搜尋歷史變成模糊命中、把斷線從災難變成小事，這些升級買到的不是炫，是少犯一次那種會上 post-mortem 的錯。

從 Ctrl+R 開始吧，那是投資報酬率最高的一個。