GitHub 为什么把代码和评论并排放在一起？它在替评审者保留哪一层上下文 (2026)

你在 GitHub 上评审一个 Pull Request 时，眼前同时有两种问题：代码这一行写得对不对，以及这次改动究竟想解决什么。前一个问题在 Files changed 里，后一个问题通常写在 Pull Request 描述里。讨论和合并条件又可能分散在 Conversation、检查结果和评审状态中。

GitHub 在 2026 年 3 月 19 日的更新，把 Overview、Comments、Merge status 和 Alerts 做成了可以停靠的面板。评审者可以在 Files changed 页面打开这些信息，继续看代码和讨论，不必为了查上下文离开当前页面。1

GitHub Pull Request 的代码差异与 Comments 面板并排显示 — *GitHub 官方 Changelog 展示的真实界面：左侧是 `SearchResults.tsx` 的代码差异，右侧是 Comments 面板，面板中同时保留普通讨论、行级讨论和 Suggested change。1*

这个改动值得看的地方，在于 GitHub 把评审者原本需要在脑中来回搬运的几种关系，放回了代码发生的地方：这行代码对应哪条意见，这条意见属于哪次改动，局部判断最后怎样影响合并决定。

先看 GitHub 把什么放回了同一视野

GitHub 的评审文档把 Pull Request 评审拆成几类动作：评审者可以对整个 Pull Request 留下总体反馈，可以评论具体代码行，也可以提出作者能够一键应用的精确修改。评审完成后，评审者还要提交 Comment、Approve 或 Request changes 之一，告诉作者下一步如何处理。2

这几类动作原本各自有位置。GitHub 现在把它们和代码差异放得更近：

产品动作	界面留下的线索	评审者少做哪一步重建	可能的失效方式
打开 Comments 面板	总体讨论、代码行评论、回复和评论筛选留在代码旁边	不必在 `Files changed` 和 `Conversation` 之间来回切换，才能判断一条意见属于哪段讨论。3	评论虽然贴着代码，意见仍可能只写「这里有问题」，没有说明用户风险或修改理由。
打开 Overview 面板	Pull Request 的 Summary、What changed、Why 和 Test plan 与差异同屏	不必先离开代码，再凭记忆把目标带回来。1	描述很长或已经过时，面板只会把更多文字挤进评审视野。
标记文件为 Viewed	文件级的阅读进度和剩余文件数量可见	不必靠记忆判断自己看过哪些文件。2	标记 Viewed 代表看过文件，不能代表评审者已经理解了改动。
打开 Merge status 面板	所需审批、检查结果和阻塞合并的原因集中显示	不必把局部评论和最终合并门槛分成两套状态来记。1	状态清楚，风险判断仍可能没有说清楚；「检查通过」也不等于「改动适合合并」。

表格里的「少做一步重建」，就是这个设计的认知价值：界面替评审者保存了对象之间的关系，评审者可以把时间用在判断上。

评论贴着代码，保留的是共同上下文

一条脱离代码的评论，读者需要补上至少三件事：评论在说哪一段代码，作者当时想完成什么，以及评论要求改变什么。评论越晚出现，原来的代码和讨论越可能已经被其他信息覆盖。评审者只看到「请改一下」时，还要重新寻找意见的对象和范围。

GitHub 的行级评论把讨论锚在具体代码位置。GitHub 还允许评审者提出精确的 Suggested change，作者可以直接应用这项修改；普通评论和高层讨论也能在新的 Comments 面板中查看，回复时可以引用已有评论。2 3

这几项功能共同保存了一个「共同上下文」：参与者看到的是同一段代码、同一条意见和同一条回复链。这里的共同上下文，不是让所有人得出同一个答案，而是让大家先对「我们正在讨论什么」达成一致。

一项发表在 ACM 的代码评审研究，通过 16 次访谈和 4 组焦点小组，考察软件工程师如何对代码质量承担责任。研究者识别出个人标准、职业操守、对代码质量的自豪感和维护个人声誉四类内在驱动力；在同伴评审中，责任会从写代码时的个人层面转向评审过程中的集体层面。4

这项研究研究的是代码评审中的责任关系，研究对象也不是 GitHub 的新面板。它能支持的判断更窄：评审是一项共同作出质量判断的活动。GitHub 把评论、回复和具体代码放在一起，正好为这种共同判断留下可回看的对象和记录。

三个面板，分别保留三种判断线索

Comments 面板保留「问题指向哪里」

Comments 面板最直接的作用，是把讨论从单独的时间线带回代码现场。GitHub 的更新说明，评审者可以从新的 Files changed 页面查看总体评论和评审评论，也可以直接新增评论；评论还可以按已解决和未解决状态筛选。3

GitHub Pull Request 的 Merge status 面板显示审批、检查和合并阻塞原因 — GitHub 官方 Changelog 展示的真实界面：右侧 Merge status 面板同时显示 Review required、All checks have passed 和 Merging is blocked。它把评审意见与合并门槛放在同一页面，却没有替团队完成风险判断。1

Comments 面板留下的是「谁对哪段改动提出了什么问题」的线索。这个线索能帮助作者找到修改位置，也能让后来加入讨论的人读回原来的理由。它降低的是寻找对象和恢复对话的成本。

评论锚点仍然有边界。代码会继续变化，原来的行可能被移动、修改或删除；一条贴得很准的评论也可能只指出实现细节，没有说清楚它会让用户遇到什么问题。界面保存了讨论位置，评审者仍然要补上判断依据。

Overview 面板保留「这次改动为什么存在」

代码差异很容易把注意力吸到局部：变量名、条件分支、测试用例和格式变化都能占满一屏。Overview 面板让评审者在查看差异时继续参考 Pull Request 描述，里面可以包含目标、实现说明和测试计划。1

这条线索补上了「局部代码和整体目标是什么关系」。同一段代码可能在一个目标下是必要改动，在另一个目标下却是范围扩大。没有目标，评审者只能逐行找问题；有了目标，评审者才有机会判断这段实现是否解决了正确的问题。

Overview 面板也会失效。Pull Request 描述由作者填写，文字可能只写实现步骤，缺少用户场景、取舍理由或已知限制。面板把背景放得更近，却不会自动提高背景的质量。产品在这里能做的是降低查找成本，团队仍要维护描述内容。

Merge status 面板保留「什么时候可以结束」

评审者对一行代码的意见，最后要进入一个更大的决定：这次 Pull Request 是否达到合并条件。GitHub 的 Merge status 面板会显示所需审批、检查结果和阻塞合并的原因。官方示例中，面板同时列出「Review required」「All checks have passed」和「Merging is blocked」。1

这个面板把两类信息放在了一起：自动检查已经发现什么，组织规则还要求什么。于是，评审者可以把「代码看起来没问题」和「现在是否满足合并条件」分开判断。

这里也有一条重要边界：状态面板表达的是规则和结果，团队还要判断规则是否覆盖了真正的风险。所有检查通过，可能只说明测试、构建和扫描通过；它无法代替对产品行为、异常路径和用户影响的评审。状态面板把结束条件说清楚，产品判断仍然需要人的解释。

为什么「同屏」有用，为什么同屏还不够

从认知角度看，GitHub 这次更新做的是一种外部认知：把原本需要保存在工作记忆里的关系放在界面上。评审者可以直接看到代码差异和评论，打开 Overview 查看目标，再打开 Merge status 检查合并门槛。每次判断需要的上下文都更容易被重新取得。

这能减少两种常见的认知工作：

找回对象。 评审者不必先想起某条评论对应哪段代码，再回到差异中寻找它。
找回关系。 评审者可以在看到具体实现时查阅改动目标，在看到评论时确认最终合并状态。

但外部认知只会把信息放到眼前，无法替评审者排序。面板越多，视野里的信息也越多；评论、描述、检查结果和规则同时出现时，评审者仍然要决定当前任务需要哪一层上下文。研究中的「集体责任」也依赖真实的同伴互动，单纯增加 AI 或自动检查并不会自动复现这种关系。4

所以，GitHub 的设计价值可以压缩成一句话：它把评审中最容易丢失的关系放回了评审对象旁边。 这句话比「信息更集中」更具体，因为它指出了产品究竟保留什么：评论和代码的关系、目标和实现的关系、局部意见和合并决定的关系。

把这个机制带回设计评审

下次评审一个需要协作、判断和交接的产品方案，可以用下面五个问题检查「同屏上下文」是否真的有用：

评审问题	要找的证据	失败信号
用户当前要判断的对象是什么？	页面把对象、状态和当前动作放在同一视野	用户需要先猜自己正在看哪一个对象，才能理解旁边的反馈。
这条反馈能回到具体证据吗？	反馈有明确的对象、位置、状态或时间点	评论写着「体验不好」，评审者还要重新寻找问题发生在哪里。
用户为什么要做这次改变，是否仍然可见？	目标、约束、取舍理由与当前方案保持近距离	方案评审退化成逐项挑错，没人能说明改动服务哪个目标。
局部判断怎样连接到最终决定？	页面清楚显示审批条件、检查结果、风险或下一步	每条局部意见都有记录，却没有人知道何时可以结束。
同屏信息是否超过当前任务需要？	用户可以收起、筛选或按任务打开上下文	所有面板默认展开，重要信息与背景文字争夺同一注意力。

这五个问题把「上下文」从一个抽象的体验词，变成了可以检查的界面关系。产品设计者要先确定用户正在作哪一个判断，再决定哪些信息值得与判断对象同屏。

结尾：把关系放回现场，评审才有共同对象

GitHub 的 Pull Request 评审界面持续把更多信息拉回 Files changed：Comments 面板保存讨论和代码之间的对应关系，Overview 面板保存目标和实现之间的对应关系，Merge status 面板保存局部意见和最终合并条件之间的对应关系。1 3

认知上的收益，落在「少靠记忆拼回关系」这件事上。评审者仍然要阅读代码、理解目标、判断风险，也要和团队共同决定是否合并；界面只是把这些判断所需的线索放得更近，让讨论更容易围绕同一个对象展开。

设计任何协作工具时，可以先问一句：用户下一步要作的判断，所需的上下文是否已经和判断对象放在一起？ 如果答案是否定的，用户每次切换页面、回看记录和寻找来源，都会把一部分判断工作变成记忆工作。

References

1
View code and comments side-by-side in pull request Files changed pagegithub.blog
2
Giving reviews - GitHub Docsdocs.github.com
3
Access all pull request comments without leaving the new Files changed pagegithub.blog
4
Accountability in Code Review: The Role of Intrinsic Drivers and the Impact of LLMsdl.acm.org