RepoDaily · 2026-07-31 · Developer tool / CLI

tuicr:用 Vim 键位在终端里完成代码评审,并直接推送到 GitHub 与 GitLab

#15 Developer tool / CLI Rust +232 agavra/tuicr 打开仓库

一款 Rust 终端评审工具,呈现 GitHub 式连续 diff,支持按行、区间、文件和整体发表评论,完成后可推送至 GitHub/GitLab、复制为结构化 Markdown 或输出到 stdout。

项目类型Developer tool / CLI
最适合习惯在终端中工作、使用 git、jj 或 mercurial 进行代码评审、并最终提交到 GitHub 或 GitLab 的开发者。
风险等级低 — MIT 许可、单二进制、本地优先、forge 推送可选。
评估时间30 分钟即可完成安装、打开 diff、推送或复制导出一次评审。

核心问题: 你的团队是否希望拥有一套键盘优先的评审流程,既不用打开浏览器,又不丢失 GitHub/GitLab 的行内评论能力?

92/100

RepoDaily 采用评分

RepoDaily 将该项目的采用分评为 92/100(强):分数来自文章来源、安装路径、生产风险、差异化、许可证清晰度以及 AI/Agent 适配度。

基于 RepoDaily 来源和采用说明的方向性评分,不是基准测试。风险: 低
100证据质量

包含 5 个来源、覆盖 3 类来源;如有 RepoDaily 独有模块,会进一步提高证据分。

100可安装/可试用性

检测到 6 个工作流步骤、5 个下一步动作,以及 5 个命令/安装信号。

69维护可信度

趋势热度为 +232 stars;如内容中有 release、issue 或维护信号,会提高维护可信度。

100生产准备度

采纳风险标记为 low,并包含 5 条安全说明与 3 条跳过条件。

100差异化

3 个机会视角、4 个替代方案,以及 4 个类型化模块支撑差异化判断。

82许可证清晰度

文章中包含许可证来源或许可证表述。

72Agent / AI 适配度

文章正文和元数据中检测到 4 个 AI/Agent 相关信号。

项目概览

tuicr(读音同 "tweaker")是一款用 Rust 编写的终端代码评审工具。它以 GitHub 风格的连续 diff 呈现所有改动文件,让你在一个滚动流中通览全部变更;支持在行、区间、文件和评审级别添加评论,完成后可推送至 GitHub 或 GitLab、复制为结构化 Markdown、或通过 stdout 管道交给下游 Agent。

它瞄准的是一个具体痛点:浏览器评审丢失了模态编辑器的速度,而 `git diff` 与 `gh pr review` 又缺少在上下文中撰写行内评论的界面。tuicr 用完整的 vim 键位来补位——不只是 `j`/`k`,还包含可视模式、`{N}G`、`Ctrl-d`/`Ctrl-u`,以及 0.19.0 起加入的评论框可选 vim 模态编辑。它会自动识别 git、jj 与 mercurial,适合混合工具链的团队。

0.19.1 于 2026-07-13 发布,距本次榜单时间仅两周,期间持续修复 forge 后端、键位、会话识别与 diff 渲染相关的问题。项目采用 MIT 许可,以单一静态二进制覆盖 Linux、macOS 与 Windows 五个目标架构,并通过 Homebrew、Cargo、Mise、Nix 以及带 SHA-256 校验的 curl 安装脚本分发。

解决什么问题

  • 浏览器评审对键盘优先的开发者来说太慢,缺少模态导航与在终端内撰写行内评论的能力。
  • `git diff` 和 `gh pr review` 能展示改动,但没有在上下文中按行、区间、文件撰写结构化评论的界面。
  • 跨 VCS 评审极少见:同时使用 jj 或 mercurial 的团队往往需要另寻工具或干脆没有 TUI。
  • 跨天的评审状态常常丢失;tuicr 以文件或 hunk 粒度持久化追踪状态。
  • 若没有专门的导出目标,把结构化评审交给 Agent 或静态分析工具非常别扭。

工作原理

  1. 通过 `brew install agavra/tap/tuicr`、`cargo install tuicr`、tuicr.dev/install.sh 的 curl 脚本、Mise 或 Nix 完成安装。
  2. 运行 `tuicr` 从提交选择器进入;`tuicr -w` 查看未提交改动;`tuicr -r main..HEAD` 评审区间;`tuicr pr 125` / `tuicr mr 125` 打开远端 GitHub PR 或 GitLab MR。
  3. 在 TUI 内用 `j`/`k` 与各种 vim 键位导航,按 `c` 在行、区间、文件或评审级别添加评论。
  4. 按 `y` 把完成的评审复制为结构化 Markdown,或输入 `:submit` 推送到 GitHub 或 GitLab 作为真正的行内评审。
  5. 运行 `tuicr review list` 回看已保存的本地会话;当元数据可用时,工具会预选上次提交评审之后的新提交。
  6. 用 `tuicr update` 更新,或用 `tuicr update 0.18.0` 锁定版本——命令会路由到当前拥有该可执行文件的包管理器。

命令全景:文档中出现的每一种调用

  • `tuicr` — 提交选择器入口。
  • `tuicr tui` — 显式 TUI 子命令,可接 `pr`/`mr` 参数(如 `tuicr tui pr 125`、`tuicr tui mr 125`)。
  • `tuicr -w` — 未提交改动,跳过选择器。
  • `tuicr -r main..HEAD` — 评审某个提交区间。
  • `tuicr pr 125` / `tuicr mr 125` — 直接打开 GitHub PR 或 GitLab MR。
  • `tuicr --stdout` — 把评审输出到 stdout,便于脚本化。
  • `tuicr review list` — 列出已保存的本地评审会话。
  • `tuicr update` / `tuicr update 0.18.0` — 通过 Homebrew、Cargo、Mise、Nix profile 或就地替换 release 资源来更新或锁定版本。

功能对比:tuicr 与同类逐项过招

  • TUI diff 查看器:tuicr、hunk、lumen 全部支持;`gh pr review` 与 `git diff` 不支持。
  • TUI 内撰写评论:tuicr、hunk、lumen 支持;`gh pr review` 与 `git diff` 不支持。
  • Vim 键位:tuicr 支持;hunk 不支持;lumen 仅部分(只有 j/k);其余不支持。
  • 推送行内评审到 GitHub:tuicr 支持;hunk、lumen 不支持;`gh pr review` 仅部分(只能 approve/comment/request)。
  • 推送行内评审到 GitLab:仅 tuicr 支持。
  • 面向 Agent 的 Markdown 导出:tuicr 支持;hunk 通过 CLI skill;其余不支持。
  • Mercurial(hg)支持:仅 tuicr 支持。
  • 单一静态二进制:tuicr 支持;hunk 需要 Node;lumen、`gh pr review`、`git diff` 支持。

最快的试用路径

最低摩擦的路径是在 macOS 上 `brew install agavra/tap/tuicr`,或在任何 Rust 工具链下 `cargo install tuicr`。然后在有未提交改动的仓库里运行 `tuicr -w`,在任意行按 `c` 撰写一条评论,再按 `y` 复制 Markdown——整个过程不需要 GitHub 或 GitLab 凭据。确认 TUI 手感合适后,再把 `tuicr pr` 接入常规流程,用 `:submit` 进行真实推送。

采纳检查清单

  • 确认你的 VCS 是 git、jj 或 mercurial——tuicr 会自动识别三者。
  • 推送功能仅支持 GitHub 与 GitLab;剪贴板与 stdout 无需 forge 即可工作。
  • 根据 0.19.x 的 changelog 核对你的平台修复:Linux 会话识别(#435)、macOS tmux 剪贴板(#413)、SSH-over-443 主机映射(#412)。
  • 如需可复现性,用 `tuicr update 0.18.0` 锁定一个已知可用版本。
  • 若通过安装脚本或手动下载的二进制更新,确认已执行 SHA-256 校验。

谁适合关注

适合关注

  • 习惯在终端中工作、希望在评审时使用 vim 模态编辑的开发者。
  • 同时使用 git 与 jj 或 mercurial、希望用同一套工具完成评审的团队。
  • 希望把结构化 Markdown 导出到 stdout 或剪贴板、交给下游 Agent 的 AI 辅助评审场景。
  • 目前要在 `git diff` 和浏览器之间反复切换、上下文不断丢失的 GitHub/GitLab 评审者。

可以先跳过

  • 只使用 GitHub 网页端评审、没有终端评审习惯的人。
  • 所使用的 forge 既不是 GitHub 也不是 GitLab,且不需要剪贴板或 stdout 导出的团队。
  • 禁止 curl 管道安装脚本、且未放行 Homebrew、Cargo、Mise 或 Nix 任一通道的组织。

风险与注意事项

MIT 许可、单二进制、本地优先,forge 集成可选。评审数据仅本地持久化,必须显式 `:submit` 才会推送。

  • MIT 许可不带来 copyleft 负担,仅需保留版权声明。
  • 单一静态二进制避免了 Linux、macOS、Windows 上的运行时依赖链。
  • 只有在显式 submit 时才会向 forge 发送数据;剪贴板与 stdout 模式完全不触网。
  • 维护活跃:0.19.1 于 2026-07-13 发布,forge、键位、会话识别均有具体修复。
  • 通过安装脚本或手动下载的二进制在就地更新前会做 SHA-256 校验。
  • `tuicr update` 只修改由识别到的包管理器(Homebrew、Cargo、Mise、Nix profile)所拥有的二进制。
  • 推送必须显式 `:submit`;剪贴板与 stdout 模式不会向 GitHub 或 GitLab 传输数据。
  • MIT 许可宽松,与大多数商业流水线兼容。
  • RELEASE.md 中记录了使用 `CARGO_REGISTRY_TOKEN` 向 crates.io 发布的流程。

替代方案比较

方案适用场景代价
hunk
需要 TUI diff 查看器与 CLI skill 支持,但不需要 vim 键位或直接 GitHub/GitLab 推送。开源;依赖 Node。
lumen
需要 Rust 编写、支持 j/k 导航、单二进制安装的 TUI,可接受没有完整 vim 模型。开源。
gh pr review
只需对 GitHub PR 做 approve/comment/request,不需要在 TUI 中撰写行内评论。免费;随 GitHub CLI 提供。
git diff
只想快速查看改动、零安装、不捕获评论。免费;随 git 提供。

这个趋势说明了什么

Agent 评审流水线

tuicr 的 `--stdout` 与剪贴板导出会产出带行/区间/文件锚点的结构化 Markdown。可将其接入 LLM 评审步骤:Agent 消费 Markdown、提出修改建议,再把 diff 反馈回 tuicr 做第二轮。

在一个真实 PR 上运行 `tuicr --stdout`,确认 Markdown 中包含行/区间锚点后再编写脚本。

跨 VCS 标准化

因为 tuicr 同时支持 git、jj、mercurial,在不同 VCS 之间迁移的团队可以保留同一套评审界面,只更换底层提交命令。

把 `tuicr -r` 指向一个 jj 式区间,确认评论持久化行为与 git 工作流一致。

离线评审模板

持久化的会话加上 Markdown 剪贴板导出,让你在飞机上也能记录评审意见,回到有 forge 访问的环境后再提交。

离线打开一个 PR、留下评论、关闭会话,回到网络后再用 `tuicr review list` 重新打开并提交。

下一步建议

安装 tuicr 并端到端评审一个 PR

挑一个你名下的 GitHub PR,通过 Homebrew 或 Cargo 安装 tuicr,运行 `tuicr pr <编号>`,用 vim 键位写三条评论,再用 `:submit` 推送。这一条链路会在一次操作中验证安装、TUI、forge 后端与评论持久化四层。

  1. 安装:`brew install agavra/tap/tuicr` 或 `cargo install tuicr`。
  2. 进入一个有未关闭 PR 的仓库。
  3. 运行 `tuicr pr <编号>` 打开 PR。
  4. 用 `j`/`k` 移到某行,按 `c` 撰写评论。
  5. 输入 `:submit` 推送评审到 GitHub,或先按 `y` 复制 Markdown。

RepoDaily 判断

tuicr 是少有的同时具备完整 vim 模态编辑、多 VCS 支持以及真实 GitHub/GitLab 推送能力的终端评审工具——一款聚焦明确、维护活跃的二进制,凭精准解决一个痛点而获得关注。

信息来源