AI写的代码谁Review?我把Stage CLI测了一遍

AI写的代码谁Review？我把Stage CLI测了一遍

Sunplus的AI角落

上个月我自己做一个小工具来验证ai 在项目中应用的问题，Claude Code 半小时吐了 1200 行改动，8 个文件。

我盯着git diff滚了 15 分钟，还是漏了一个把user_id写成user_id的 typo — 上线当天就崩了。

后来我在 HN 上看到 Stage CLI，一个专门用来「读懂 AI 生成代码改动」的工具。昨天装上去测了一遍，有些东西和预期不太一样。

Stage CLI 是什么

Stage CLI 是 Stage 平台（YC 孵化，做在线 PR 代码审查）开出来的本地版。GitHub 上才建了不到两周，141 个 star，MIT 协议，完全免费。

核心思路不复杂：AI 写代码快，但人读代码的速度没跟上。传统的git diff按文件路径线性展示，几百行 diff 一口气怼到脸上，review 效率很低。

Stage CLI 的做法是把 diff 按逻辑块拆成「章节」，每个章节告诉你这几行改动是在干什么，哪些地方要重点看。

安装就两步：

npm install -g stagereview
npx skills add ReviewStage/stage-cli

然后在 Claude Code（或 Cursor、Codex、Gemini 等任意 AI agent）里跑/stage-chapters，Stage CLI 就会读取当前分支的改动，拆成章节，在浏览器里打开一个可视化界面。

我用上周那个搞崩的工具项目重新跑了一遍。同样的 8 个文件、1200 行改动，Stage CLI 给我拆成了 3 个章节：

第 1 章：用户认证模块重构（~450 行，4 个文件）

Stage 标注了「逻辑复杂度高」，建议重点检查 token 刷新逻辑。它把auth.ts、session.ts、middleware.ts、types.ts里和认证相关的改动归到一起，而不是按文件一个个来。

第 2 章：API 请求层封装（~380 行，2 个文件）

标注「重复模式较多」，但逻辑风险低。新增的apiClient.ts和修改的fetcher.ts被正确识别为同一批重构。

第 3 章：数据模型调整（~370 行，2 个文件）

这里 Stage 给出了一个「需人工确认」标记 — 最后果然就是user_id→user_id那个 typo 所在的位置。虽然它没直接告诉我「这里拼错了」，但把这段代码单独拎出来让我集中注意力看，比我对着git diff从上往下扫要精准得多。

整体体验下来，3 个章节的划分基本合理。唯一一次分得不太对的是把一个import语句归到了无关的章节里，不算什么大问题。

从我测的结果看，Stage CLI 在三种情况下最好用：

1. AI 批量生成的大改动

Claude Code 一次性改 5 个以上文件的时候，git diff基本没法看。Stage 把跨文件的关联改动聚合到一个章节里，review 的逻辑是连贯的。

2. 跨模块的重构

比如让 AI 把整个项目的错误处理统一改成自定义 Error 类，可能改了 20 个文件。Stage 会按错误处理的调用链来分组，而不是按文件路径。

3. 接手别人用 AI 写的代码

团队里有人用 Cursor 写了一段自己没参与的逻辑，在 PR 里看到的 diff 缺少上下文。Stage 的章节说明能帮人快速理解这段改动的意图。

Stage CLI 在 HN 拿了 45 个赞、32 条评论，讨论比产品本身还有意思。

最热的一条争论就是：这到底算不算 CLI？

有人说「从终端输入命令、在浏览器里看结果，这叫什么 CLI？」。Stage 团队的回应也挺直白 — 与其花时间做 TUI（终端 UI），不如先把交互体验做好。他们觉得浏览器渲染 diff 的体验远好于纯终端，选择先把核心价值做出来。

另一个高频吐槽是大 diff 性能不行。有开发者说几百上千行 diff 的时候界面卡顿明显。Stage 团队在 GitHub issue 里已经认了这个坑，正在做虚拟化滚动优化。

还有人说git diff不就行了吗？这也是我看到 Stage 之前的第一反应。但实际用下来区别很明显：git diff是按文件顺序的线性视图，Stage 是按改动意图组织的结构化视图。就跟看邮件列表 vs 看 Notion 页面的区别。

测了一下午，几个比较实际的限制：

性能：超过 500 行 diff 的时候加载变慢，超过 800 行开始有明显延迟。Stage 团队说估计要到 0.3 版本才能解决，目前 0.1.2。

必须配 AI agent 用：Stage CLI 本身只是个章节拆分的工具，它不写代码、不分析代码质量。章节说明依赖使用的 agent（Claude Code/Cursor 等）来生成，agent 不行的话效果打折扣。

不是自动审查机器人：这是它和 CodeRabbit/Greptile 最大的区别。Stage 不做自动化检测、不帮你找 bug。它的定位是「帮人更好地做审查」，不是「替代人审查」。如果要自动找 SQL 注入、检测安全漏洞，Stage 做不了这个。

没有 diff 对比高亮：Stage 的界面更偏「文档阅读」体验，不是传统 diff 工具那种左红右绿的行级对比。习惯用 GitLens 或者 GitHub PR 的人可能会不适应。

如果团队已经重度使用 AI 编程，每天都有 AI 生成的代码要 review —装一个不亏。免费、开源、安装 30 秒。不改变工作流，需要的时候跑一下就行。

但如果只是偶尔让 AI 补几行代码，git diff完全够用。Stage CLI 解决的是 AI 编程体量上来之后才出现的痛点。

我个人会把 Stage CLI 作为 review 的第一步 — 先用它快速理解改动结构，然后再进 GitHub PR 看细节。相当于把「读完 diff 理解意图」这个步骤从 15 分钟压缩到 3-5 分钟。

后面我准备测一下：让 Claude Code 自己 review 自己写的代码，看 Stage + Claude Code 的组合能不能做出一个自动化程度更高的 review 流程。感兴趣的可以先装个 Stage CLI 试试，跑一次/stage-chapters就知道适不适合自己了。

安装命令：npm install -g stagereview

GitHub：github.com/ReviewStage/stage-cli