lumen：把 git diff 變成終端機裡的審查工作台
Beautiful git diff viewer, generate commits with AI, get summary of changes, all from the CLI
秒懂
- 它是什麼？
- lumen 是 Rust 寫成的終端機 diff 檢視器，提供並排瀏覽、註解、GitHub PR 整合與可選的 AI 輔助功能。本文檢視它的實際操作方式、設定檔結構，以及它在哪些場景下不值得取代你現有的工具。
- 適合誰用？
- lumen 適合每天花大量時間在終端機裡看 diff、需要跨 commit 或 PR 做註解、而且願意接受一套按鍵綁定的人。它不適合只想要快速產生 commit message 的使用者，因為 AI 功能需要另外設定 provider、API key 與模型，而且 diff 檢視器本身不依賴 AI，兩者的價值要分開評估。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 61 天前。
- 用什麼語言寫的？
- 主要是 Rust（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是哪一類痛點
git diff 在終端機裡的預設輸出是兩段文字前後排列，要看懂一個改動往往得在腦中重建檔案結構。lumen 把這個過程變成 side-by-side 的並排檢視，加上 tree-sitter 的語法上色，讓新增與刪除的區塊在視覺上直接對應。它的目標使用者是那些不離開終端機的人，不是偶爾看一下 diff 的人。README 裡列出的功能，例如 `lumen diff --pr 123` 直接抓 GitHub PR、`--watch` 自動重新整理、`--stacked` 逐 commit 審查，這些都是為了長時間、多檔案、需要留下審查意見的工作場景設計的。換句話說，它想取代的是瀏覽器裡的 PR 頁面，而不是 git 本身。
從指令到畫面的資料流
lumen 不是 git 的替代品，它讀取的是 git 既有的輸出。`lumen diff` 不帶參數時顯示未提交的變更，帶 `HEAD~1` 或 `main..feature/A` 時則顯示指定範圍。`--pr 123` 與 `--detect-pr` 的存在說明它會去跟 GitHub 的 API 溝通，把 PR 的 diff 內容拉回來。`--stacked` 模式把 `main..feature` 這種範圍拆成逐個 commit 顯示，header 會標出目前位置、SHA 與 commit message，`ctrl+h` 與 `ctrl+l` 切換前後。這個設計的關鍵在於 viewed file 的狀態是逐 commit 記錄的，切換時不會丟失進度。檔案層級的標記會用 `space` 同步回 GitHub，這表示 lumen 不只在本地讀 diff，它也會把審查狀態寫回去。
安裝與第一條指令
安裝路徑有兩條。macOS 與 Linux 可以用 Homebrew，指令是 `brew install jnsahaj/lumen/lumen`。另一條是 `cargo install lumen`，前提是系統裡已經有 Rust 的套件管理工具。README 特別提醒 cargo 會隨 rust 一起安裝。啟動檢視器只要在 repository 裡下 `lumen diff`，想看特定 commit 就加 `HEAD~1`，跨分支比較用 `main..feature/A`。`--file` 可以重複指定來過濾檔案，`--focus` 則是在開啟時直接跳到某個檔案。`--wrap` 讓長行軟換行，這個選項也可以寫進設定檔。fzf 與 mdcat 都是選用的，前者用於 `lumen explain --list`，後者用於輸出美化，核心的 diff 檢視器不需要它們。
設定檔的優先順序與主題系統
設定集中在 `~/.config/lumen/lumen.config.json`。主題的優先順序是 CLI 旗標大於設定檔，再大於 `LUMEN_THEME` 環境變數，最後才是作業系統的自動偵測。可用主題從 Catppuccin 的 mocha 與 latte、Dracula、Nord、One Dark、Gruvbox 到 Solarized 與 Flexoki，各有深淺版本。這個優先順序設計有一個實際後果：如果你在設定檔裡寫了 `theme: dracula`，又習慣用 `LUMEN_THEME` 在不同終端機之間切換，環境變數會失效，因為設定檔的層級更高。README 沒有列出設定檔的完整欄位，只給了 theme 這個範例，實際要擴充設定時得自己摸索或看原始碼。
註解與鍵盤操作是綁在一起的
註解分成三個層級：選取範圍、hunk、整個檔案。用滑鼠拖曳選字元範圍，或點行號選整行，按 `i` 開始註解。`{` 與 `}` 用來跳 hunk，跳到某個 hunk 後按 `i` 就是對整個 hunk 註解。沒有選取也沒有 hunk focus 時按 `i` 則對整個檔案註解。被註解的行會顯示 `▍` 記號，按大寫 `I` 可以檢視、編輯、刪除、複製或匯出所有註解。這個流程的取捨在於它完全依賴鍵盤與滑鼠的混合操作，`j/k` 移動、`w` 切換 watch mode、`tab` 開關側欄、`e` 用編輯器開啟檔案。如果你習慣只用鍵盤，滑鼠選取這一步會卡住；如果你習慣只用滑鼠，`{`/`}` 跳 hunk 的效率又發揮不出來。
AI 功能是附加的，不是核心
AI 功能與 diff 檢視器是分開的。`lumen draft` 根據暫存的變更產生 commit message，可以加 `--context` 提供額外線索。`lumen configure` 提供互動式設定，需要 provider、API key 與 model，這些資料存進同一個 `lumen.config.json`。README 提到支援 10 個以上的 provider，但沒有逐一列出名稱，也沒有說明各家在 API 格式或費用上的差異。這表示 AI 功能的實際可用性取決於你選的 provider 與模型，lumen 本身只負責把 diff 內容送出去並接回結果。換句話說，draft 的輸出品質會直接受到模型能力影響，而這不是 lumen 能控制的變數。
註解與 PR 同步的實際邊界
lumen 對 GitHub PR 的支援有兩個方向。讀取方向是 `lumen diff --pr 123` 或直接貼 PR 網址，也可以 `--detect-pr` 讓它從目前分支推測對應的 PR。寫回方向是 `space` 標記 viewed file，README 說這會與 GitHub 同步。但要注意，檔案層級的 viewed 標記與行內註解是兩種不同的事情，前者同步回 GitHub 有明確說明，後者的匯出功能只提到可以從 `I` 選單中操作，沒有描述匯出的格式或是否能貼回 PR 的評論區。如果你需要的是在 PR 上留下逐行的 review comment，lumen 的文件並沒有保證這個流程是完整的。
維護成本與授權
專案以 MIT 授權釋出，這表示整合進商業工具或內部流程時，授權限制相對寬鬆。最近的版本更新頻率不低，v2.32.0 在 2026 年 7 月 16 日釋出，往前有 v2.31.0 與 v2.30.0，間隔從一天到一個月不等。活躍的釋出節奏代表 bug 修復與功能新增會持續進來，但也代表升級時要留意行為變更。以 Rust 寫成並打包成單一靜態二進位檔，部署成本低，不需要 runtime 或相依套件。升級路徑沒有在 README 中特別說明，但既然能用 cargo 安裝，`cargo install lumen` 重新執行就能更新。真正的維護成本在設定檔與按鍵習慣，如果你自訂了主題或依賴某個按鍵行為，升級前最好先看 release notes。
編輯結論
lumen 適合每天花大量時間在終端機裡看 diff、需要跨 commit 或 PR 做註解、而且願意接受一套按鍵綁定的人。它不適合只想要快速產生 commit message 的使用者，因為 AI 功能需要另外設定 provider、API key 與模型，而且 diff 檢視器本身不依賴 AI，兩者的價值要分開評估。也不適合習慣在編輯器或網頁介面完成 code review 的人，lumen 的註解流程綁在終端機互動裡，匯出與同步的細節在 README 中著墨不多。採用前先確認三件事：你的 git 工作流程是否常用 `--stacked` 這種逐 commit 審查模式、你的團隊是否接受以 `space` 標記 viewed file 並與 GitHub 同步、以及你願意不願意為了 `--watch` 或主題設定去讀 `lumen.config.json` 的完整欄位清單。lumen 的定位是審查工具而不是 git 的替代品，它依賴你原本的 git 指令與 repository 結構，這點在架構上不會改變。
社群筆記