jnsahaj/lumen 是什么？

lumen 是一个用 Rust 写的终端 diff 查看器和代码审查 TUI，支持侧边对比、GitHub PR 审查、注解，以及可选的 AI 提交信息生成。它面向那些不想离开终端、又希望 diff 体验更直观的开发者。

jnsahaj/lumen 可以商用吗？

可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。

jnsahaj/lumen 还在维护吗？

在维护。仓库最近一次提交在 61 天前。

jnsahaj/lumen 是用什么编程语言写的？

主要是 Rust（依据 GitHub 的语言统计）。

lumen 终端 diff 查看器评测：Rust 实现，支持 AI 提交信息

秒懂

它是什么？: lumen 是一个用 Rust 写的终端 diff 查看器和代码审查 TUI，支持侧边对比、GitHub PR 审查、注解，以及可选的 AI 提交信息生成。它面向那些不想离开终端、又希望 diff 体验更直观的开发者。
适合谁用？: lumen 适合那些日常在终端里处理 git diff、需要快速审查多个提交或 PR、并且愿意尝试 AI 辅助生成提交信息的开发者。如果你已经习惯用 IDE 的图形 diff 工具，或者对 AI 生成的提交信息持怀疑态度，那么 lumen 的核心价值在于它的纯本地 diff 查看器，这部分不需要任何 AI 配置，你可以只用 `lumen diff` 来体验。
能商用吗？: 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
还在维护吗？: 在维护。仓库最近一次提交在 61 天前。
用什么语言写的？: 主要是 Rust（依据 GitHub 的语言统计）。

以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。

开源项目深度解析

Hysen Labs 编辑部 · 2026年9月10日 · jnsahaj/lumen

它解决什么问题：终端里的 diff 体验长期落后

大多数终端 diff 工具只输出两列文本，没有语法高亮，没有行内差异，更没有交互式注解。lumen 的目标是填补这个空白：它提供一个侧边对比的 TUI，用 tree-sitter 做语法高亮，支持查看未提交改动、单个提交、分支差异以及 GitHub PR。它的目标用户是那些整天泡在终端里、不想为了看 diff 而切换到浏览器或 IDE 的开发者。README 特别强调它能在多千行的 diff 上保持流畅，这暗示了性能是它的一个卖点。但要注意，这里说的“流畅”是项目自己的描述，我没有实际运行过，所以不能替它背书。从工具定位看，它更像是把 GitHub 的 PR 审查界面搬到了本地终端，而不是简单的 `git diff` 包装。

工作机制：从 git diff 到交互式 TUI 的完整链路

lumen 的底层是 Rust，编译成单个静态二进制，这决定了它的启动速度和资源占用。它读取 git 的 diff 数据，然后用 tree-sitter 对代码进行语法分析，从而在侧边视图中高亮不同的语法元素。交互层面，它支持鼠标点击和拖拽选择，你可以对选中的行、某个 hunk 或整个文件添加注解，注解会以 `▍` 标记显示在行号旁边。对于 GitHub PR，`lumen diff --pr 123` 或直接传 PR 链接都能拉取远程数据，并且按空格键可以把文件标记为已查看，这个状态会同步回 GitHub。它还有一个 watch 模式，用 `--watch` 开启后会自动刷新 diff，适合边改代码边看变化的场景。stacked 模式则把一段提交范围（比如 `main..feature`）拆成单个提交逐个审查，用 `ctrl+h` 和 `ctrl+l` 切换，每个提交的查看进度会被单独记录。这个设计对大型 PR 或提交链很实用，因为它避免了在多个提交之间来回跳时丢失上下文。

安装与上手：三条路，配置集中在 JSON 文件

安装方式有三种：macOS 和 Linux 可以用 Homebrew，命令是 `brew install jnsahaj/lumen/lumen`；有 Rust 环境的话用 `cargo install lumen`；GitHub Releases 页面也提供预编译的二进制。注意 README 没有提供 Windows 的安装方式，所以 Windows 用户可能需要自己编译。启动查看器很简单，`lumen diff` 显示未暂存改动，`lumen diff HEAD~1` 看某个提交，`lumen diff main..feature/A` 比较分支。常用参数包括 `--file` 过滤特定文件、`--focus` 打开时跳到指定文件、`--wrap` 软换行。主题配置有三层优先级：CLI 的 `--theme` 参数高于配置文件，配置文件高于环境变量 `LUMEN_THEME`，最后才是系统自动检测。配置文件位于 `~/.config/lumen/lumen.config.json`，比如设置 `{"theme": "dracula"}`。AI 功能需要先运行 `lumen configure` 做交互式设置，包括 provider、API key 和模型。整个配置模型很直接，没有复杂的嵌套结构，对熟悉 JSON 的开发者来说几乎零学习成本。

AI 辅助：draft 提交信息与自然语言 git 命令

lumen 的 AI 功能是可选的，核心 diff 查看器不依赖任何 AI。`lumen draft` 会根据暂存区的改动生成提交信息，例如输出 `feat(button.tsx): Update button color to blue`。它支持 `--context` 参数，比如 `lumen draft --context "match brand guidelines"`，这样生成的提交信息会考虑你给的额外背景。README 还提到它能生成 git 命令，但具体用法在截断的部分没有展示。AI 功能支持 10 个以上的 provider，这比只支持 OpenAI 的工具更灵活，意味着你可以接入自托管的模型或其它兼容 API。但这里有一个明显的权衡：提交信息生成需要把代码改动发送到外部服务，即使你用的是私有部署的 provider，也增加了数据暴露面。对于处理闭源代码的开发者，这是一个需要认真考虑的点。另外，README 提到 `lumen explain --list` 依赖 fzf，而漂亮的输出格式需要 mdcat，这两个都是可选依赖，没有它们功能会降级，但不会崩溃。

与 Jujutsu 的兼容：一个被轻描淡写的特性

README 在功能列表里简单提了一句“Works with Git and Jujutsu (jj)”，但没有给出任何具体命令或配置示例。这让我怀疑这个兼容性的成熟度。Jujutsu 是一个新兴的版本控制系统，它的 diff 模型和 git 不同，如果 lumen 只是通过某种适配层读取 jj 的输出，那可能只支持基本的 diff 查看，而不支持 stacked 模式或 PR 审查。另一方面，如果它原生集成了 jj 的 commit 概念，那对 jj 用户会是一个巨大的卖点，因为终端里针对 jj 的好用 diff 工具非常少。但 README 没有展开，我只能说这个特性存在，但具体边界不明确。如果你是一个 jj 用户，在采用前应该去项目的 issue 或讨论区确认它支持哪些 jj 子命令，而不是假设它和 git 支持完全对等。

局限性与失败模式：并非所有 diff 场景都适合

首先，lumen 是一个 TUI，意味着它依赖终端能力。如果终端不支持真彩色或鼠标事件，侧边对比的颜色和点击注解功能会大打折扣。其次，README 没有提到对二进制文件、图片或超大文件（比如几 MB 的 JSON）的处理策略，这类 diff 在很多工具里都会卡顿或显示无意义的内容。第三，AI 功能需要网络连接和外部 API，如果你在离线环境或内网工作，`lumen draft` 和解释功能完全不可用，但核心 diff 查看器不受影响。第四，`lumen diff --pr` 需要能访问 GitHub，对于私有仓库，你需要配置认证，但 README 没有说明如何设置 token，这是一个文档缺口。最后，watch 模式虽然方便，但如果你同时用 IDE 自动格式化代码，频繁的刷新可能会干扰你的专注。这些限制不是致命伤，但每个用户都应该根据自己的工作流评估。

替代方案：git diff 增强工具与 IDE 内置对比

最直接的替代方案是 `diff-so-fancy` 或 `delta`，它们都是命令行工具，但定位不同。delta 也是 Rust 写的，它把 `git diff` 的输出美化并加上语法高亮，但它不是交互式 TUI，没有侧边对比、没有注解功能，也没有 PR 集成。delta 的优势是它直接管道在 `git diff` 后面，配置简单，适合那些只需要更好看的输出而不需要完整审查工作流的人。另一个替代是 IDE 自带的 diff 视图，比如 VS Code 或 JetBrains 系列，它们提供图形化的侧边对比、行内编辑和直接暂存，但你需要离开终端。lumen 的独特之处在于它把 PR 审查（包括与 GitHub 同步的查看状态）和注解带到了终端，这是 delta 或 IDE 都没有的。如果你更看重轻量级的美化输出，delta 可能更合适；如果你需要完整的审查交互，lumen 的设计更接近 GitHub 的网页体验。

维护与升级成本：版本节奏快，但风险可控

从仓库信息看，lumen 的发布频率很高，v2.32.0 在 2026-07-16 发布，v2.31.0 在 7 月 15 日，v2.30.0 在 6 月 4 日，虽然不能确定具体间隔，但看起来接近每周或每两周一个版本。这种节奏意味着 bug 修复和新功能会快速落地，但也要求用户频繁升级，否则可能错过关键修复。升级方式取决于安装路径，Homebrew 用户可以用 `brew upgrade lumen`，cargo 用户用 `cargo install lumen --force`（具体命令 README 没有写，但这是 cargo 的常见做法）。配置格式是 JSON，目前看比较稳定，但版本更新可能会引入新的配置键，旧配置通常向后兼容，但你需要留意 changelog。许可证是 MIT，这意味着你可以自由使用、修改和分发，没有 copyleft 义务，但如果你分发修改版本，需要保留版权声明。对于内部工具来说，MIT 是一个低风险的选择，但如果你打算把 lumen 集成到自己的商业产品中，最好还是咨询法律意见。

编辑结论

lumen 适合那些日常在终端里处理 git diff、需要快速审查多个提交或 PR、并且愿意尝试 AI 辅助生成提交信息的开发者。如果你已经习惯用 IDE 的图形 diff 工具，或者对 AI 生成的提交信息持怀疑态度，那么 lumen 的核心价值在于它的纯本地 diff 查看器，这部分不需要任何 AI 配置，你可以只用 `lumen diff` 来体验。不适合的场景包括：你完全依赖鼠标操作且不熟悉 TUI 键位，或者你需要处理非 git 版本控制系统（虽然它支持 Jujutsu，但 README 没有给出具体命令）。在采用之前，建议先确认你的终端是否支持真彩色和鼠标事件，因为侧边对比和点击注解依赖这些能力。另外，AI 功能需要你自己配置 provider 和 API key，数据会发送到第三方服务，如果你对代码隐私敏感，应该只使用非 AI 的 diff 功能。最后，查看 GitHub 上的示例截图和演示视频，确认它的界面风格符合你的审美，因为终端 UI 的观感是主观的，而 lumen 的卖点恰恰是“好看”。

官方来源

社区笔记