2026 年的代码洪流
从 2026 年初开始，Maciek Pekala 感觉到了地面的移动。模型变强了，Agent 随之变强，几乎在一夜之间，他的团队代码吞吐量暴涨。1 月到 3 月，产生的 issue 和合并的 PR 数量都上涨了 50%。
这令人兴奋，也是一个问题。这么多代码在流动，评审队列积压的压力让他有冲动走个过场就说「looks good」，但这与 Linear 对质量的真实 obsession 相悖。他的问题变成了：如何在不降低标准的前提下，跟上这么多评审？
Linear Diffs：把 Diff 变成叙事
Linear Diffs 是 Linear 推出的代码评审工具。核心思路是：把代码变更分组、串联成逻辑流畅的叙事，而不是扔给你一面红绿相间的墙让你自己理解。
Pekala 的日常用法：
第一步：理解为什么做这个变更。评审请求进来，先搞清楚驱动的因素——客户反馈、Bug 报告、Slack 上有人提的想法。Linear Reviews 里只需一键就能看到这些上下文。
第二步：看得到就看的部分。如果变更涉及 UI 或新流程，直接打开预览构建，感受行为。截图、录屏标记看起来或感觉不对劲的地方，让作者直接看到反馈。
第三步：读 Diff。先扫一遍感知大小和范围。如果变更较大，切到 guided review 模式。Linear 把变更分组为可读的块，可以跟随逻辑而不是在红绿墙里跳来跳去。
第四步：不再逐行读。找 Bug 和检查逻辑正确性这件事，现在主要由 Agent 完成。Pekala 把这部分时间拿回来了，用在真正需要判断的事情上：变更是否适合系统，是否真的解决了问题，是否有替代方案，边缘 case 如何，用户体验如何。
评审变了：代码是有用的，而不只是正确的
在所有关于工程师角色变化的讨论中，这种向判断力的转变是最真实发生在他工作中的。成为一个有价值的评审者，意味着需要更多产品直觉、更深入了解客户痛点和真实世界的影响。这是一件好事，因为它提升了工程师这个角色的层次。
当 Pekala 发现变更实际上在解决错误的问题时——有人或 Agent 太字面地理解了需求，需要退回去从不同角度处理——他会在 Linear 里发起讨论，把更多人拉进来。当变更大致在轨道上时，他留评论表达想法，作者可以直接在 Linear 里用 Agent 处理这些评论，他也可以参与澄清反馈。
质量代码审查的意义已经变了
结果：即使 PR 数量更高，他对质量有信心。代码评审现在意味着代码是有用的，而不只是正确的。他更享受在评审中花时间判断我们交付的是否真的值得出现在产品里，而不只是它能不能 work。
这是他在 Agent 时代最真实的感受。