超越 Git Diff：使用 Stage CLI 简化 AI 生成的代码审查

AI 编码代理的兴起从根本上改变了我们的编码方式，但它也带来了新的瓶颈：审查过程。当一个代理为了实现单个功能而在整个仓库中修改数十个文件时，生成的 git diff 往往是一团混乱的更改，按文件路径而非逻辑意图组织。对于开发者而言，这意味着花更多时间在脑中重构代理的逻辑，而不是实际审查代码。

为了解决这个问题，Charles 和 Dean 推出了 Stage CLI，一款开源工具，旨在弥合 AI 生成的更改与人类理解之间的鸿沟。Stage CLI 摒弃了传统的仓库树结构顺序 diff，提供了“章节”体验，使开发者能够以结构化、叙事的方式审查更改。

传统 Diff 的问题

在标准的 IDE 或 CLI 工具中，diff 以文件列表的形式呈现。如果 AI 代理在 src/utils/ 中更新了一个工具函数，在 src/components/ 中更新了一个组件，并在 tests/ 中更新了一个测试，这些更改会被文件系统结构分隔。审查者必须在文件之间来回切换才能理解单一的逻辑更改。

“对于 AI 生成的代码，最难的部分是审查它。一旦代理因不同原因更改多个文件，普通的 git diff 就会变得混乱。将更改分组为‘章节’似乎是个正确的思路。”

Stage CLI 的工作原理

Stage CLI 作为您现有 AI 工作流的本地扩展运行。它并不取代您的编码代理，而是指示代理执行一组特定任务：

  1. Analyze Changes: 代理读取当前分支的更改。
  2. Logical Decomposition: 代理将这些更改拆分为独立的、基于代码更改意图而非文件位置的逻辑“章节”。
  3. Browser-Based Review: 该工具在本地浏览器中打开这些章节，提供丰富的可视化界面用于审查代码。

这种方法使开发者能够遵循实现的“故事”——可能从数据模型的更改开始，随后是业务逻辑，最后是 UI 更新——而不受触及文件的限制。

社区反馈与观点

Stage CLI 的推出在开发者中引发了关于如何最佳处理 AI 生成代码的热烈讨论。

“CLI” 与浏览器的争论

一个争议点在于工具的交付方式。虽然称为“CLI”，但它会触发基于浏览器的体验。一些用户，如 @adamtaylor_13 和 @tim-projects，表示更倾向于终端原生的体验，认为离开终端的摩擦可能会阻碍部分高级用户。

逻辑分组的价值

尽管界面偏好各异，但大家普遍认为 逻辑分组 的概念极具价值。@pi-victor，类似 TUI 工具 Parley 的创建者，承认虽然他们的工具支持对 diff 进行评论，但缺乏 Stage CLI 提供的“章节”组织方式。

性能与规模

对于处理大规模更改的独立开发者而言，性能是关键因素。用户 @ihatemodels 分享了他们的工作流：使用 GitHub 网页审查提交，然后将评论反馈给 Claude Code。他们指出，对于涉及数百甚至数千行的提交，UI 中的性能和虚拟化（窗口化）至关重要，以防工具变得不可用。

AI 审查的未来

围绕 Stage CLI 的讨论指向了一个更大的趋势：对审查的“苏格拉底式”方法的需求。随着 AI 代理能力的提升，工程负责人的目标从单纯捕获 bug 转向确保人类和 AI 都对系统保持深刻理解。

正如 @mkw5053 所建议的，挑战在于在最大化交付速度和质量的同时，确保初级开发者变得“更有能力，而不仅仅是更高产”。像 Stage CLI 这样的工具是迈向这一目标的第一步，将审查过程从扫描 diff 的繁琐任务转变为结构化的教育和质量保证练习。

Sources