五一期间我看到 dhh 发的一个帖子推荐 GitHub TUI: ghui，我安装试了一下，发现还需要安装 bun，另外功能看起来也不太够用。

我也看过 gh-dash，这东西是 gh 的一个 extension，我试了一下同样感觉体验不好，于是手痒开始让 AI 帮我用 Rust 重新写一个。

最近在工作中也写过一个 Rust 的 TUI 工具，感觉 Rust 的生态已经很成熟了，写起来也很顺手。于是就有了 ghr 这个项目。

它的目标一开始很简单：我想少在 GitHub 网页里来回点。作为一个经常看 PR、review 代码、处理 notification 的人，我每天会重复很多小动作：打开 inbox，看谁 @ 了我，扫一眼 assigned PR，点进 diff，读评论，偶尔 checkout 到本地验证一下。

这些动作单独看都不复杂，但它们很碎。浏览器适合处理一次性的探索，不太适合让我连续地做几十个维护动作。于是 ghr 慢慢变成了一个终端里的 GitHub 工作台。如果你喜欢 lazygit，那么应该也会喜欢 ghr，因为 lazygit 主要是针对 Git 相关的操作，而 ghr 主要是围绕 GitHub 上协作的 TUI，比如看 issue、comments、review 代码，merge PR 等等。我甚至想命名为 lazyhub，这样组合起来就是 GitHub 😅。

先让它打开就能用

我最早在意的不是功能有多少，而是启动体验。

如果每次打开 TUI 都要等 GitHub API 慢慢返回，那这个工具很快就会被我自己弃用。终端工具有个很残酷的标准：它必须比打开网页更快，否则手会自动去点浏览器。

所以 ghr 现在是 snapshot-first。配置、数据库、日志和 UI 状态都放在 ~/.ghr 下面。启动时先把本地 SQLite 里的 snapshot 展示出来，然后再后台刷新当前列表。这样哪怕网络慢一点，至少我能先看到上次的现场。

这个设计听起来不酷，但它很实用，后来我又回看 ghui，发现他也改成了这个方案。

完整的工作流

一开始它像一个 GitHub dashboard：Inbox、Pull Requests、Issues，几块列表摆出来。后面越写越发现，只看列表是不够的。

所以后面加了很多看起来很细的功能：

• recent items 可以跳回最近认真看过的 PR/Issue
• 我认为任何工具都应该有 command palette，然后默认会把最近用过的命令排前面
• diff 里可以直接看到 inline review comments，可以 toggle 是否显示 comments
• 任何编辑页面都会自动保存 draft，避免误操作导致的内容丢失
• 详情页可以保存滚动位置和选中的评论
• 虽然是 TUI，但是几乎所有界面上的操作也可以通过鼠标点击操作
• 在一个已经关联 GitHub remote 的本地目录，直接运行 ghr 会自动把这个 project 加到顶层列表

等等各种细节，这些功能单独拿出来都不像“大功能”，但组合起来以后，ghr 才开始有了工作流的味道。

但我也发现 TUI 的局限，比如 diff 这个功能，即使我把细节都打磨好了，但我认为一个 PR 改动比较多的情况下最好的代码 review 体验还是在 VS Code 里，通过 Pull Request 插件直接 checkout 到本地，毕竟代码的 review 还是很依赖于编辑器的功能的（这个插件是我离不开 VS Code 的一个重要原因）。

AI 让个人工具变得更奢侈

ghr 这类工具放在以前，我大概率不会写到这个程度。细节太多，投入产出不划算。

TUI 里的鼠标选择、快捷键冲突、评论编辑框、draft 保存、列表分页、缓存失效、各种 GitHub API 的形状，每一个都不难，但都要花时间。AI 让这些小改动的成本降了很多，于是个人工具可以变得更“奢侈”：它不需要证明自己有市场，只要能持续改善我的日常工作流，就值得往前推一点。

欢迎试用，欢迎提 issue，也欢迎 PR：ghr。