GitHub 重构 Pull Request 概览页
GitHub New pull request overview page in public preview
面对越来越长的 Pull Request，开发者往往需要在数十条评论和时间线事件中反复滚动，只为找到合并按钮。GitHub 推出了全新的 Overview 页面预览版，旨在彻底改变这一体验。新功能将合并状态和下一步操作浓缩在页面顶部的紧凑摘要中，让合并框的信息展示空间减少一半以上。此外，用户现在可以按最新评论优先排序，或仅筛选未解决的对话，从而快速聚焦关键问题。这不仅是一次界面调整，更是对代码审查流程的深度优化，帮助开发者在复杂的协作中保持专注，不再迷失在信息洪流里。
在漫长的 Pull Request 中，检查阻碍因素往往意味着需要滚动经过数十条评论和时间线事件，仅仅为了到达合并框。
HN 评论区
128- capevace
我们一直在构建自己的 Review Pipeline，包括自动化审查指南、风险检测等等。
围绕 Code Review 还有太多工作要做，GitHub 居然没做更多，这让我非常惊讶。
他们本就有足够的覆盖面，也积累了多年的真实审查数据。然而，PR 本身却完全没有利用任何新出现的、能提升审查效率的方法。
Agents 正左右开山地疯狂生成 PR，而我却仍在这里盯着 35 个 PR 的原始 diff，最后反倒成了那个被指责的瓶颈。
- gz09
我倒希望他们能先专注于修复 PR 的那些回退问题……
举个例子：最近引入了一个很恶心的 bug，当你点击“Merge when ready”时，代码真正进入合并队列的概率似乎只有 60-70%。如果发生这种情况，你通常要到第二天发现代码还没合并时才会察觉。
他们的支持团队在一个月前就已经向我们确认了这个问题，但截至目前仍未修复。
- habosa
这是一个重大改进，但依然不够好。6 年多前我就创建了 CodeApprove（https://codeapprove.com），原因就是因为 GitHub 的 PR 页面实在太烂，我忍不住想把它做得更好。
在我看来，正确的设计其实很简单：
- 所有信息都在一页，信息密度要高
- 聚焦于代码和未解决的讨论，可能再加上 CI 检查
- 支持键盘导航
Graphite 已经非常接近了！但这些年它变得有些杂乱。CodeApprove 也远非完美（我很久没在 UX 上花太多精力了），但我希望 GitHub 能做得更好一点。
- locallylinear
不知道，我只是问我的 agent，PR 的状态如何，比如哪些检查失败了、还有哪些未解决的评论等等。
但这看起来还行。
如果非要说的话，我认为应该把更好的 UX 投入到代码审查上，甚至是在我请求审查之前，先审查“我”（agent）写的代码。在一个我们正逐渐远离 IDE，转而使用终端应用或桌面应用来写代码的世界里，我往往直到代码上了 GitHub 才能看到它。但我仍然执着于保留某种形式的审查需求，尤其是那些重要的部分。
是的，一年前的我会对我刚才说的话感到震惊。
- johnnypangs
我不喜欢他们把评论线程的顺序反转了，却没有提供原生的预览功能。现在，我不需要滚到底部去找合并按钮了，反而要滚到底部去看预览。
- verst
我用这个功能几周了，但不是很喜欢。对我来说，导航到 PR 讨论/评论的点击次数太多了。
- pscanf
我试过了，但我不明白为什么会有那么多吹捧，这基本上就是旧 UI 加上几个小布局改动。它肯定没有解决 AI 开发工作流的需求。
- ethin
我希望 GitHub 别总想着把 UI 做得漂漂亮亮，而是试着让平台重新变得稳固可靠。