hunk：为 agent 生成的变更集设计的终端审阅器

它解决什么问题：agent 时代的审阅瓶颈

当编码 agent 一次性生成几十个文件的改动时，传统的 diff 工具会让人迷失在碎片化的输出里。hunk 的定位是 review-first，也就是把审阅作为第一优先级的交互体验，而不是把 diff 当作纯文本输出。它面向的是 agentic coder，也就是那些让 AI 写代码、自己负责检查的人类。这类用户的痛点在于：变更集往往跨多个文件，且需要核对 agent 的注释或 AI 生成的说明。hunk 把多文件流、侧边栏导航和行内注释整合到一个终端界面，试图减少在多个终端窗口或工具之间切换的成本。

底层机制：OpenTUI 与 Pierre diffs 的组合

hunk 构建在 OpenTUI 之上，这是一个终端 UI 框架，负责渲染交互组件；diff 解析则使用 @pierre/diffs 这个 npm 包。README 没有深入说明两者的具体分工，但从功能列表可以推断：OpenTUI 提供了鼠标支持、响应式布局和菜单渲染，而 Pierre diffs 负责生成结构化的差异数据。这种组合让 hunk 能实现 split、stack 和 responsive auto 三种布局，后者会根据终端宽度自动切换。值得注意的一点是，hunk 的语法高亮在 x86-64 平台上要求 CPU 支持 SSE4.2，这意味着 2008 年以前的 Intel 或 2011 年以前的 AMD 处理器无法运行。这个硬件下限在同类工具中很少见，可能是因为使用了某种 SIMD 优化的高亮库。

安装与启动：多种方式，但注意版本冲突

安装方式很丰富：npm 全局安装 `npm i -g hunkdiff`，macOS 和 Linux 可以用 `curl -fsSL https://hunk.dev/install.sh | sh` 下载预编译二进制并校验校验和，Homebrew 用 `brew install hunk`，mise 用户用 `mise use -g hunk`，Nix 用户则从 flake.nix 获取 default 包。README 特别提醒，如果之前通过 `modem-dev/tap` 安装过，必须先 `brew uninstall modem-dev/tap/hunk`，否则可能冲突。启动命令很简单：`hunk` 显示帮助，`hunk --version` 打印版本。要注意的是，npm 安装需要 Node.js 18+，但 install script、Homebrew、mise 和 Nix 都提供独立二进制，不需要 Node 运行时。如果你之前用过 `hunk update`，它会用你最初安装时的包管理器来更新，mise、Nix 和源码安装则只会打印更新命令。

Git 工作流：镜像 diff 命令但打开 UI

hunk 镜像了 Git 的 diff 风格命令，但把输出变成交互式 UI。`hunk diff` 审查当前仓库的改动，包括未跟踪文件；`hunk diff --watch` 会在工作树变化时自动重载；`hunk show` 审查最新提交，`hunk show HEAD~1` 审查更早的提交。还有 `--fast` 实验性标志，用于把部分语法高亮卸载到其他进程。对于直接比较文件，`hunk diff before.ts after.ts` 可以对比两个文件，加上 `--watch` 会在任一文件变化时自动刷新。另外，`git diff --no-color | hunk patch -` 可以从 stdin 读取补丁。这个设计让 Git 用户几乎零学习成本，因为命令名称和参数与 Git 一致，只是输出变成了终端 UI。

超越 Git：Jujutsu、Sapling 与原始补丁

hunk 不只是 Git 工具。它会自动检测 Jujutsu 和 Sapling 工作区，`hunk diff [revset]` 和 `hunk show [revset]` 会使用原生的 revset 语法。如果你需要强制指定，可以在配置里设置 `vcs = "git"`、`vcs = "jj"` 或 `vcs = "sl"`。对于原始补丁，`hunk patch -` 可以从 stdin 读取。这个多 VCS 支持在同类工具中较少见，但有一个明显的权衡：watch 模式在 Jujutsu 和 Sapling 下使用轮询而非文件系统监听，这意味着刷新延迟可能更高，且更耗 CPU。如果你主要使用 jj 或 sl，并且依赖 watch 模式，需要评估这个延迟是否可接受。

Agent 工作流：让 AI 参与审阅

hunk 的核心特色之一是支持 agent 和 AI 的注释。工作流程是：先在另一个终端运行 `hunk diff` 或 `hunk show`，然后让 agent 读取 `hunk skill path` 返回的技能文件，再指示 agent 使用该技能与正在运行的 hunk 会话交互。README 提供了一个通用提示词模板："Load the Hunk skill and use it for this review. Run `hunk skill path` to get the skill path." 对于更完整的 live-session 和 `--agent-context` 工作流，需要查看 docs/agent-workflows.md。此外，实验性的富文本 STML 注释体需要以 `--experimental` 标志启动审阅，普通 agent 注释仍是默认。这个机制把终端审阅工具变成了一个可编程的审查界面，但它的实际效果取决于 agent 对技能文件的理解程度，这一点 README 没有给出验证数据。

与 lumen、difftastic 等工具的差异

README 提供了一张功能对比表，列出了 hunk 与 lumen、difftastic、delta、diff-so-fancy 和 GNU diff 的差异。其中 lumen 是唯一在 review-first 交互 UI、多文件流和侧边栏、鼠标支持、运行时视图切换这些能力上与 hunk 并列的工具，但 lumen 缺少行内 agent/AI 注释和响应式自动分栏布局。difftastic 和 delta 更专注于语法高亮和 diff 渲染，但它们不是交互式审阅工具，也没有多文件流。delta 通常作为 Git 的分页器使用，difftastic 则用于计算结构化的差异。hunk 的定位明显不同：它不是为了替代 delta 或 difftastic，而是为了填补 agent 生成的大规模变更集的审阅空白。如果你只需要快速查看单个文件的差异，difftastic 或 delta 可能更轻量；如果你需要审阅整个变更集并标注 AI 注释，hunk 或 lumen 是更合适的选择。

维护与升级成本：活跃但需留意兼容性

仓库的 last push 是 2026-08-25，最近发布了 v0.20.0、v0.19.1 和 v0.19.0，说明项目处于活跃开发状态。版本号 0.x 意味着 API 和功能可能在没有预警的情况下变化。升级路径相对简单：`hunk update` 会使用最初安装的包管理器来更新，`hunk update --check` 只报告版本。但如果你通过 npm 安装，每次升级都可能引入新的依赖要求，比如 Node.js 版本。许可证是 MIT，这意味着你可以自由使用、修改和分发，但需要注意，hunk 依赖的 OpenTUI 和 @pierre/diffs 也有各自的许可证，虽然 README 没有提及，但如果你要嵌入到商业产品中，需要单独检查这些依赖的许可条款。

编辑结论

hunk 适合那些频繁审阅 agent 生成的大批量变更、并且愿意在终端里完成整个审阅流程的开发者。它不适合只需要快速查看单个文件差异、或者完全依赖 GUI 审阅工具的人。在采用之前，先确认你的 CPU 满足 x86-64 下的 SSE4.2 要求，并检查你的 Node.js 版本是否在 18 以上（如果通过 npm 安装）。另外，如果你使用 Jujutsu 或 Sapling，注意 hunk 目前对这些版本库的 watch 模式采用轮询而非文件系统监听，实时性可能不如 Git 场景。最后，建议先用 `hunk diff` 在真实仓库上跑一遍，确认它与你的终端模拟器兼容，再决定是否纳入日常工具链。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes