代码 review 最怕的不是看到很多红绿行，而是看不清这些行究竟落在哪个函数、哪个测试、哪个配置块里。这个问题在 AI coding agent 参与之后更明显：agent 一次可能改十几个文件，传统 git diff 只给三行上下文，reviewer 还要不断回编辑器里找函数边界。

今天介绍的 juanibiapina/deltoids 就是在这个缝隙里做文章的工具。它是一个 Rust 编写的 diff filter / review TUI / agent edit trace 工具箱。GitHub 搜索结果当前显示项目约 20 stars、1 fork，主要语言是 Rust，许可是 MIT。仓库仍在高频更新，Cargo.toml 的 workspace 版本是 0.8.1，CHANGELOG.md 里 0.8.1 标记为 2026 年 5 月 27 日发布；最新 tag 也能看到 v0.8.1。

项目概览

属性详情
仓库juanibiapina/deltoids
定位面向 agentic coding 的 diff pager、review TUI 和编辑 trace 工具
Stars约 20
Forks1
主要语言Rust
许可MIT
当前版本0.8.1
安装方式Homebrew、shell installer、cargo install --git

它解决的是 diff 的“方位感”问题

普通 unified diff 很适合机器处理，也很适合快速看小改动。但如果改动落在一个 150 行函数中间，默认上下文经常不够。你看到的是几行局部变动，却不知道它属于哪个 handler、哪个 test case、哪个 Terraform block，最后还是要切回编辑器。

deltoids 的核心思路是：不要只按固定行数显示上下文，而是用 tree-sitter 找到改动所在的代码结构。README 里说，hunk 会扩展到相关上下文，通常是 enclosing function 或 struct，最多到 200 行。这样你在 pager 里就能看到“这段改动属于哪里”，而不是只看到孤立的红绿行。

这听起来很小，但对 review 很实用。AI agent 改代码时，错误常常不是单行语法问题，而是改动放错层级、漏了相邻分支、把测试 case 的意图改歪。函数级上下文能让 reviewer 更快判断这次修改是否真的落在正确范围内。

作为 git pager 使用

最直接的用法是把 unified diff pipe 给 deltoids：

git diff | deltoids | less -R
git show HEAD~1 | deltoids | less -R
git log -p | deltoids | less -R

也可以把它设成 Git pager：

git config --global core.pager 'deltoids | less -R'

README 还给了 lazygit 配置方式。对于已经习惯在终端里看 diff 的人来说，这种接入方式很低摩擦：它不是替换 Git 工作流，而是把 diff 输出做得更有上下文。

它还提供 deltoids review。这不是单纯输出 ANSI diff，而是一个可滚动的 TUI，用来审阅本地 diff。项目在 CHANGELOG.md 中记录了 review TUI、trace TUI 的鼠标支持、窗格标题等更新，说明作者不只在做算法，也在打磨终端交互。

为什么它适合 AI agent 场景

deltoids 的名字里没有 MCP，也不是一个 coding agent，但它明显是围绕 agent workflow 设计的。README 列出的工具包括：

  • deltoids pager：给 less 或 core.pager 用的 ANSI diff filter。
  • deltoids review：审阅 diff 的 TUI。
  • deltoids edit / deltoids write：供 coding agent 调用的文件编辑和写入工具。
  • deltoids hashread / deltoids hashedit：带行内容 hash anchor 的读取和编辑工具。
  • deltoids traces：实时浏览 agent 编辑 trace。

这里最有意思的是 trace 部分。edit 和 write 是 agent 工具的 CLI 版本，调用时可以为每次修改记录 reason，再通过 deltoids traces 单独查看。这样 reviewer 看到的就不只是最终 diff，还能看到 agent 是怎样一步步改文件的。

Claude Code 集成也很明确：插件会记录 Write 和 Edit 调用，并按 Claude session 分组；继续同一个 session 时，会继续追加到同一条 trace。它不会替代 Claude Code 的界面，但给本地复盘留了一条独立路径。

hash anchor 是一个务实细节

AI agent 做文本编辑时，一个经典问题是位置漂移。它先读了第 42 行，后来文件被别的操作改过，第 42 行不再是原来的内容；如果编辑工具只靠行号，可能会把改动插到错误位置。

deltoids 的 hashread / hashedit 试图把这个问题压低。hashread 输出形如 LINEhh 的行锚点，里面包含行号和短内容 hash；hashedit 在真正拼接修改前会验证 anchor。如果 anchor 过期，整批修改会被拒绝，而不是悄悄写进错误位置。

这不是全能并发控制，但很适合 agent 工具层。它让“我基于刚才读到的文本修改”变成可以验证的动作，而不是单纯相信行号还没变。

边界：它还在活跃开发

README 顶部有一个很直接的 warning：项目仍在 active development，diff output 可能还会有问题，有疑问时需要用另一个 pager 验证。这句话值得在使用前认真看。

所以我不会把 deltoids 当成审计链路里的唯一真相。它更适合作为 review 体验增强工具：用它快速获得函数级上下文、看 agent trace、发现可疑位置；最终仍要用 git diff、测试、构建和人工判断确认结果。

另外，它依赖 tree-sitter 对语言结构的理解。项目已经引入了 Rust、TypeScript、JavaScript、Python、Go、C/C++、Java、Ruby、Lua、Bash、JSON、YAML、TOML、HCL、CSS、Markdown 等 grammar，但每种语言的结构边界都可能有细节差异。越是复杂的语法和生成代码，越应该保留二次验证。

适合哪些人

deltoids 适合这些场景：

  • 你经常在终端里用 git diff、git show、git log -p 看代码。
  • 你希望 diff 默认显示函数、结构、测试 case 或配置块上下文。
  • 你会让 AI agent 做多文件修改，需要更容易复盘每一步编辑。
  • 你在使用 Claude Code 或 pi 这类可以接入插件/工具的 agent workflow。
  • 你愿意接受一个活跃开发中的小工具，并在关键 review 中保留备选 pager。

如果你的主要 review 场景是 GitHub PR 页面，或者团队已经高度依赖 IDE 内置 review，deltoids 的价值会小一些。它最适合 terminal-first、agent-heavy、需要快速理解局部改动背景的工作流。

总结

juanibiapina/deltoids 的亮点不是“让 AI 自动 review”，而是把人类 reviewer 经常缺失的上下文补回来。它用 tree-sitter 扩展 diff hunk，让你看到改动所在的函数或结构；又通过 edit/write/hashread/hashedit/traces，把 agent 的修改过程留成更容易检查的痕迹。

我喜欢它的克制：它没有试图替代 Git，也没有把 review 包装成玄学评分，而是解决一个很具体的问题：当 agent 改完代码后，人该怎样更快看懂这些改动。对现在的 AI coding workflow 来说，这类“小而准”的工具往往比又一个全功能 agent 更有实际价值。

项目地址：https://github.com/juanibiapina/deltoids