搜索“拉取请求应该有多少行”时，你会一遍遍看到同一个答案：控制在 400 行以内。有时说是 200 到 400 行，有时说“几百行”。这些说法总是被当作定论。
我们想知道这个数字从何而来。追根溯源并不费事。
这个数字可以追溯到一项研究。代码审查工具供应商 SmartBear 与思科的一个团队合作开展了这项研究。十个月里，三大洲的 50 名开发者在每次变更进入版本控制前都要对其进行审查。研究收集了 2,500 次审查的数据，涉及 320 万行代码，所有审查都通过 SmartBear 自家的审查工具进行。
研究的主要发现是：审查行数超过约 200 行后，缺陷密度会大幅下降。SmartBear 目前的指导建议据此提出：每次审查不超过 200 到 400 行，因为超过 400 行后，发现缺陷的能力会减弱。
这是一项有真实数据支撑的研究。但大部分证据也就到此为止。
这项研究中的缺陷密度，指的是每单位审查代码中发现的缺陷数。因此，超过 200 行后数值下降，意味着审查者每行代码发现的缺陷更少。SmartBear 将其解读为审查者注意力开始涣散。我们的理解也一样。
它无法告诉你代码中的 Bug 是否更少，也无法判断这个 PR 是否不该发布。它衡量的是人们读代码的效果，而不是变更本身的风险。
还有几点值得了解：
- 这是 2006 年一个产品中的一个团队，在提交前使用专用工具进行审查。如今在 GitHub 上，带有 CI 和长讨论串的拉取请求，是另一回事。
- Jason Cohen 对这项研究的介绍说，统计方法和实验控制写在书里，而不是文章中。
- SmartBear 页面上常与 400 行说法一同出现的“70% 到 90% 的缺陷发现率”，没有注明来源。
- 发布这个数字的公司，也在销售用于审查代码的工具。
这些情况并不能证明这个数字有误，但说明它只是一个起点，不是定律。
有两家供应商公布了较新的数据，乍看之下两者互相矛盾。
LinearB 的 2026 年基准数据涵盖了 4,813 个团队的 8,109,244 个拉取请求。他们按第 75 百分位数评定 PR 大小：少于 100 行为卓越，100 到 155 行为良好，156 到 228 行为一般，超过 228 行则有待改进。页面没有说明行数统计的是新增行、删除行，还是两者都算。
Graphite 在一篇2023 年的文章中提出，理想的 PR 中位数是 50 行，范围为 25 到 100 行。他们发现，50 行的变更比 250 行的变更审查和合并快约 40%。他们根据 1,000 万个 PR 的样本制作的回退图表显示，回退最少的 PR 有 25 到 50 行。不过，绝对差距很小：几乎所有大小的 PR，回退率都在约 1% 到 1.6% 之间。他们也指出，自家用户的 PR 倾向于较小。
两者其实并不冲突。LinearB 报告的是团队 PR 大小的第 75 百分位数，Graphite 报告的是中位数。一个团队四分之三的 PR 少于 100 行，同时中位数为 50 行，这两种情况完全可以并存。它们是同一分布的两种观察方式。
两家供应商都在销售用于衡量 PR 大小和审查速度的工具。数字不会因此就变错，但发布这些数字的人，确实会从你关注这项指标中获利。
LinearB 的数据还有一点值得一提。在他们的细分数据中，第 75 百分位 PR 的行数，未经辅助时约为 157 行，由智能体编写时约为 293 行，经 AI 辅助时约为 408 行。他们明确指出，这只是相关性，不代表因果关系。这的确说明，“合适”的大小取决于代码是如何编写的。
我们找到的来源中，没有一个显示超过 400 行的 PR 更可能带有 Bug 发布。思科的研究关注的是审查质量，供应商的数据关注的是速度和回退。两者都没有追踪代码合并后的情况。
行数衡量的是代码行数，而不是审查所需的精力。一个移动目录的 2,000 行 PR，比修改支付流程的 60 行变更更容易审查。生成文件、锁文件和迁移文件会抬高计数，却不会增加审查负担。Graphite 自己的回退图表还有一段奇怪的长尾：超过 10,000 行的 PR 看起来稍微更安全，作者猜测这是因为最大的变更多半是重构。
- 把 200 到 400 行视为一次审查时段的合理上限，而不是硬性规定。这是证据支撑最充分的数字，衡量的是阅读，而不是发布。
- 衡量你们自己的中位数和第 75 百分位数。这正是供应商报告的指标，也是唯一能描述你们团队的数据。
- 统计时排除锁文件、生成文件和纯移动操作。
- 变更必须很大时，说明应该从哪里开始读。在描述中写一句简短的“从这里开始”，比随意拆分 PR 更有用。
- 关注代码行里写了什么。一个加入分支繁多函数且没有测试的小 PR，比一个主要由删除代码组成的长 PR 问题更大。
最后这一点正是我们开发DebtDraft的原因。它是一个 GitHub Action，会在每个拉取请求上发布一条持续更新的评论，其中包含健康评分，以及仅展示该 PR 修改行的视图。这个工具是我们做的，所以请据此权衡我们的看法。
那么你们的数字是多少？你会把一个拉取请求控制在多少行？到多少行时，PR 会让你觉得难以应付？