一个包含 47 个变更文件的 Pull Request 进入审查队列。审查者打开它，看到 diff，花了前 15 分钟只是理解改了什么、为什么改。哪些文件是结构重构？哪些包含实际逻辑变更？测试覆盖率足够吗？
对于每周做 10 个 PR 的团队，这个导向时间每周累计 2.5 小时。代码审查是有价值的，但搞清楚 PR 是关于什么的这个阶段不是。
工作流做了什么
PR Review Summarizer 工作流在 PR 事件触发时产生结构化审查摘要：
-
PR 开启或更新 — 通过 GitHub webhook 触发，获取完整 diff、PR 描述、关联 issue 和 commit 历史。
-
AI 分析 diff — AI 读取每个变更文件并产出：
- 摘要：2-3 段描述 PR 做了什么以及为什么
- 变更分类：文件按用途分组——测试、配置、核心逻辑、重构
- 风险评估：高/中/低风险评级及具体原因
- 潜在问题：审查者应该注意的具体问题
- 测试覆盖：新代码是否有对应测试
-
摘要发布为 PR 评论 — 分析以格式化评论发布在 PR 上，审查者打开 PR 时立即看到。
分析在 30-60 秒内完成。
省下的时间
每周 10 个 PR：无摘要的导向时间约 15 分/PR = 2.5 小时/周，有摘要约 3 分/PR = 30 分/周。每周净省 2 小时。
人类仍然做什么
AI 摘要和标记，人类审查。架构判断、业务逻辑验证、团队标准、审批——这些仍然是审查者的责任。PR 摘要增强人类审查，让每位审查者更快更专注。