Stage CLI 实战指南：用章节式审阅告别 AI 代码 Review 噩梦
当你使用 Claude Code 或 Cursor 生成了几百行代码变更后，有没有这种体验：git diff 刷出满满一屏幕，你得从上到下逐行扫一遍——改动跨了三个文件，逻辑跳跃，有些改动能看懂意图，有些完全不知道 AI 为什么这么改。Review AI 生成的代码比 review 人类代码更累，因为 AI 不会给你写 commit message 解释每段改动的想法。
Stage CLI（npm 包名 stagereview）正是为此而生。它不只是一个 diff 查看器，而是把 AI 生成的代码变更自动拆解成逻辑章节，每个章节都有自己的上下文和 review 要点。你可以在浏览器里按章节分段审阅，不用再从海量 diff 中手动找重点。
快速安装
Stage CLI 通过 npm 全局安装，一条命令搞定：
npm install -g stagereview
安装完成后，就可以在任何 AI Agent 中使用它的斜杠命令。
如果你使用支持 Skill 的 AI Agent（如 Claude Code），还可以添加官方 Skill 来获得更完整的体验：
npx skills add ReviewStage/stage-cli
核心用法：/stage-chapters
Stage 的核心命令是 /stage-chapters。在 AI Agent 对话中直接输入这个命令，它会做三件事：
- 分析当前 Git 仓库的本地变更（staged + unstaged + untracked）
- 自动将变更分组为逻辑章节（按文件关联、功能模块、代码结构）
- 在浏览器中打开审阅界面，每个章节附带上下文和评审建议
/stage-chapters
浏览器界面打开后，你会看到类似这样分章节展示的 diff 视图：
- 章节 1：添加用户认证中间件 — 涉及
auth.ts,middleware.ts - 章节 2：重构数据库查询逻辑 — 涉及
queries/user.ts,queries/order.ts - 章节 3：更新 API 路由配置 — 涉及
routes/auth.ts,routes/index.ts
每个章节都独立可折叠、可评论，review 体验大幅提升。
高级用法
指定 diff 范围
默认情况下，/stage-chapters 会包含所有未提交的变更（staged + unstaged + untracked）。但有时你只想 review 特定范围的改动：
/stage-chapters --ref staged /stage-chapters --ref unstaged
这在分步提交时特别有用——先审查 staged 的代码确认无误后提交，再处理下一批。
分支间差异对比
如果你需要对比两个分支的差异，Stage 也支持：
/stage-chapters --base main /stage-chapters main feature /stage-chapters main..feature /stage-chapters --base main --compare feature
这种场景通常出现在 PR review 时，你想快速了解 feature 分支相对于 main 分支做了哪些改动。
自定义基准分支
如果仓库的默认分支不是 main（比如有些团队用 master 或 develop），可以显式指定：
/stage-chapters --base develop
实战场景
场景 1：AI 完成大规模重构后审阅
假设你让 Claude Code 把一个模块从 Express 风格迁移到 Fastify：
/stage-chapters
Stage 会自动把重构拆解为：
- 路由定义迁移（
routes/*.ts） - 中间件适配（
middleware/*.ts） - 错误处理统一（
errors.ts） - 测试用例更新（
tests/*.ts）
每个章节独立审阅，你可以先审查最关键的「路由迁移」章节，跳过熟悉的部分，而不是在 30 个文件的 diff 中手动翻找。
场景 2：分阶段审查后再提交
开发中积累了大量未提交的变更，你想分批 review 和提交：
/stage-chapters --ref staged /stage-chapters --ref unstaged
这种方式特别适合边 review 边提交的工作流——你不需要一次性审查所有变更，可以按自己的节奏分批消化。
场景 3：PR 快速预审
在正式发起 PR 之前，先用自己的环境跑一遍预审：
/stage-chapters --base main
在浏览器里按章节过一遍所有改动，确认逻辑正确后再 push 和开 PR。这比直接在 GitHub 上修改 PR 要快得多。
为什么章节式审阅更适合 AI 代码？
AI 生成的代码有几个特点，让传统的逐行 diff review 变得低效：
- 改动量大：AI 一次性可能跨 5-10 个文件产生变更，
git diff输出可达数百行 - 逻辑跳跃：AI 的代码生成顺序和人类的阅读顺序不同，你常需要在不同文件间来回跳
- 缺少意图说明：AI 不会告诉你「为什么这样改」，你得自己反推
Stage 的章节式方案从根源上解决了这些问题：
- 按逻辑分组而非文件排列，降低了认知负担
- 每个章节目录独立，方便分段审阅
- 配合浏览器 UI，可以快速导航、标记、回溯
对比传统 git diff 工具和 Stage 的体验：
| 维度 | git diff / IDE diff | Stage CLI 章节审阅 |
|---|---|---|
| 组织方式 | 按文件排序 | 按逻辑分组 |
| 查看效率 | 逐行扫描 | 按章节跳跃 |
| 大变更体验 | 信息过载 | 分块消化 |
| AI 代码适配 | 无特别优化 | 天然适配 |
| 多分支对比 | git diff 手动参数 | 内置支持 |
卸除与注意事项
如果以后不再需要：
npx skills remove ReviewStage/stage-cli npm uninstall -g stagereview
一些小贴士：
- Stage CLI 目前是纯本地工具，所有变更数据不会离开你的机器
- 如果你的仓库很大（>1000 个文件），首次分析可能需要几秒钟
- 对未跟踪（untracked）的文件，Stage 默认会包含在
work模式下——如果你只想看已跟踪文件的变更，用--ref unstaged或--ref staged
小结
Stage CLI 解决的是一个具体且普遍的痛点：AI Agent 代码变更的审阅体验太差了。它用「章节化」的思路，把原本需要手动从 diff 中提取的逻辑单元自动化分组，让开发者能像读一本书的目录一样 review AI 写的代码。
对于每天和 AI 编码助手打交道的开发者来说，这不是一个「可有可无」的工具——它可能直接决定了你 review 代码的速度和质量。206 个 GitHub stars 和 MIT 开源许可证意味着它已经获得了社区初步认可，值得你 clone 下来试一试。
友情提示：Stage CLI 目前还在早期阶段（v0.x），部分仓库结构可能需要手动调整分组策略。建议先从个人项目开始试用，体验章节式审阅的效率提升后再推广到团队项目。