拉取请求大小分析器

它解决什么问题

一个 PR 塞下 30 个文件、1200 行改动时，评审者通常只会扫一眼标题然后标上「LGTM」。这不是态度问题，而是注意力的物理限制：diff 超过几百行后，误判概率显著上升，评审意见开始流于形式，真正的缺陷被埋在「看起来没问题」的假象里。更糟的是，超大 PR 往往伴随耦合改动——前端、后端、数据库迁移挤在一起，任何一个环节出问题都得整体回滚。

pull-request-size-analyzer-agent 的目标就是把这种隐性成本变成显性数据。

它如何工作

核心能力有三个：

• 规模量化：通过 GitHub GraphQL API 拉取 PR 的变更统计（diff-stat），一次请求即可拿到文件级与行级的改动分布，无需多次轮询 REST 接口。
• 阈值约束：可配置大小上限，超过即标记为不符合规范，并在 Checks API 中留下记录，让「PR 太大」从口头抱怨变成 CI 里的客观状态。
• 拆分建议：针对超标 PR 输出可执行的拆分策略，例如按目录、按功能模块、按迁移步骤切分，而不是笼统地建议「拆小一点」。

关键步骤：

1. 查询目标 PR 的变更范围，获取 additions、deletions、changedFiles 等指标。
2. 与预设阈值比对，判定是否超标。
3. 通过 Checks API 写入评审结果与指标，供团队在 PR 页面直接看到。
4. 基于 diff 结构分析改动耦合度，生成拆分方案。

它还维护团队评审速率指标，可以观察「平均评审时长」是否随 PR 增大而劣化，为流程改进提供依据。

适用边界

GraphQL 的优势在于单次请求获取关联数据，适合结构化分析场景。但它不解决评审质量问题——一个 50 行的 PR 依然可能逻辑混乱。

阈值设定需要团队自己调：太严会让正常改动频繁触礁，太松则失去约束意义。此外，拆分建议基于文件与行数等结构性信号，对「语义耦合但物理分散」的改动识别有限，最终判断仍需人工参与。