gh-news：把 GitHub 通知收进终端里的 TUI triage 面板
GitHub notifications 很容易变成一个低频但持续漏水的工作流。浏览器里的 inbox 能用，但它经常和代码上下文分离：你在 terminal 里看 branch、跑 test、切 repo，然后又切回网页判断哪条 PR mention 真的要处理。等通知多起来，最麻烦的不是打开链接，而是先把它们按 repo、reason、参与度和当前任务过滤一遍。
今天看的是 chmouel/gh-news。它是一个 Rust 写的 gh CLI extension，用 ratatui 做终端 TUI，把 GitHub notifications 放进一个可键盘操作的列表里。你可以在 terminal 里按 repo 分组、预览 issue / PR / discussion / commit 细节，批量标记已读，pin 重要通知，snooze 暂时不处理的线程，也可以用 regex filter 和 named views 把不同工作上下文拆开。
按 GitHub repository API、repository page、README、Latest Release、LICENSE、Cargo.toml 和默认分支 Git history 在 2026-07-31 能核验的公开信息，chmouel/gh-news 当前有 31 stars、6 forks。仓库主语言是 Rust，许可证是 Apache-2.0。仓库创建于 2026-01-18 08:47:48 UTC，最近公开 push 是 2026-07-31 09:30:57 UTC。默认分支 main 的当前 HEAD 是 e34ba1d，提交时间 2026-07-31 09:30:55 UTC。最新 GitHub Release 是 v0.18.0，发布时间 2026-07-22 15:06:52 UTC；Cargo.toml 里的 package name 是 gh-news，version 为 0.18.0。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | chmouel/gh-news |
| 定位 | GitHub notifications 的 terminal TUI 和 gh CLI extension |
| Stars | 31 |
| Forks | 6 |
| 主要语言 | Rust |
| 许可证 | Apache-2.0 |
| GitHub 创建时间 | 2026-01-18 08:47:48 UTC |
| 最新 push | 2026-07-31 09:30:57 UTC |
| 当前默认分支提交 | e34ba1d，2026-07-31 09:30:55 UTC |
| 最新 GitHub Release | v0.18.0，2026-07-22 15:06:52 UTC |
| Cargo package | gh-news 0.18.0 |
| 关键词 | GitHub notifications、gh extension、Rust、ratatui、terminal、TUI |
它解决的是通知分诊，不只是通知查看
gh-news 的 README 把功能列得很直白：terminal-based UI、gh extension 安装、vim-style navigation、multi-select、auto-refresh、preview、regex filtering、pin、repository grouping、mute、snooze、custom actions、named views、saved triage sessions、static display mode、configuration doctor。换句话说，它不是简单把 GitHub 通知拉出来打印一遍，而是在 terminal 里做一个小型分诊台。
这对经常处理多个 repo 的人有用。GitHub 通知的噪音通常不是来自单条消息，而是来自上下文切换：某个 repo 的 CI 失败、另一个 repo 的 review request、一个 discussion mention、一个 issue comment，全都混在同一个 inbox 里。gh-news 允许你先按 repo 分组，再用 filter 或 named view 切到当前要看的工作面。
比较实用的是 preview。README 说明它会用 GraphQL 为 issues、PRs、discussions、commits 拉取更丰富的详情；当通知来自评论时，preview 会显示触发通知的评论，而不是只把你丢到 issue 或 PR 的开头。这一点很小，但非常符合真实使用：大多数时候你想知道“谁刚才说了什么”，而不是重新读完整条线程。
它保留了 CLI 工作流的连续性
安装路径很轻：
gh extension install chmouel/gh-news然后运行：
gh news因为它挂在 gh CLI 下面，认证也顺着已有 GitHub CLI 工作流走。README 写明 token 查找顺序是 GH_TOKEN、GITHUB_TOKEN、gh 配置文件、最后调用 gh auth token。对已经在 terminal 里用 gh pr checkout、gh run watch、gh repo view 的人来说，这比再开一个单独应用更自然。
另一个顺手的地方是它不强迫你只用全屏 TUI。README 里有 --static-display，可以把通知打印出来用于脚本和 pipeline；也有 --check-config 检查 filters、actions、token access 和 views。也就是说，它既可以作为日常 inbox，也可以被塞进 shell alias、tmux pane、status 脚本或定时检查里。
分组、snooze 和 named views 比“标为已读”更重要
处理通知最容易犯的错误，是把 inbox 清空当成目标。实际工作里，更常见的需求是延后、隐藏、保留和切换上下文。gh-news 在这几个方向下了功夫。
Repository grouping 可以让你先折叠不相关的项目，只看当前维护的几个 repo。Pin 适合把晚点必须回来的线程留在眼前。Snooze 则解决“现在不该处理，但也不该永久已读”的情况。Mute threads 和 mute repositories 通过 GitHub API 处理，适合长期减少噪音。
Named views 和 saved triage sessions 是更程序员式的设计。你可以为不同工作流保存过滤视图，比如只看参与中的通知、只看某个组织、只看 Actions workflow run、只看当前项目的 PR。比起每次重新搜索，它更像在 terminal 里切 workspace。
Custom actions 让它可以接到自己的工具链
README 还提到 custom actions with command templates。这个能力很适合把通知分诊接到本地工具链里：例如对某类 PR 运行自定义脚本，打开内部 dashboard，或者把特定 repo 的通知交给另一个 CLI 处理。项目本身不需要内置所有动作，只要能把当前通知的上下文传给命令，就能融入个人工作流。
当然，这也意味着配置需要更谨慎。任何会调用本地命令的通知工具，都应该确认 token scope、命令模板和 shell 环境不会让不可信内容变成自动执行。gh-news 有 configuration doctor，这类检查在打开 custom actions 前值得先跑一遍。
需要注意的边界
第一，项目还很小。31 stars、6 forks、2026 年 1 月创建，虽然最近仍在频繁更新，但它还不是那种大量团队验证过的基础设施。更适合作为个人开发者或小团队的 inbox 工具试用。
第二，它依赖 GitHub API 和 token。README 提到状态栏会显示 rate limit 剩余额度，后台刷新失败也会报告错误；如果你的组织通知量很大、token scope 很严格，最好先小范围跑起来，确认 API quota 和权限是否符合预期。
第三，TUI 不会替你判断优先级。它能让通知按 repo、filter、pin、snooze 变得可控，但真正该不该立即 review、是否要 merge、是否能静音某个 repo，还是人的判断。
第四，功能多意味着要配置。只想偶尔看一眼 GitHub inbox 的人，浏览器页面可能已经够用；gh-news 更适合那些每天在 terminal 里处理 GitHub 事项、并且已经觉得网页 inbox 打断节奏的人。
总结
chmouel/gh-news 的价值不在于“终端里也能看通知”这个表面功能，而在于它把 GitHub inbox 变成了一个可以过滤、预览、批量处理、暂缓和保存上下文的 TUI。它很小，但切中的摩擦很具体。
如果你的 GitHub 通知量不大，或者你主要在浏览器里工作，它可能不是必需品。但如果你的日常已经围绕 gh、tmux、shell 和多个 repo 展开，gh-news 值得试一下。把通知分诊留在 terminal 里，有时就是少一次上下文切换。