Linear 发布 Diffs，主打快速聚焦的代码评审

我们为什么打造 Diffs

创办 Linear 时，我们就想改善构建软件的体验——这个领域长期以来充满摩擦。我们执着于让核心工作流用起来快速、流畅、愉悦。

其他环节都在提速，代码评审却依然慢得让人难受。编码智能体带来的 PR 数量不断增长，让本就吃力的流程更加不堪重负。以至于用智能体省下来的时间，全被评审吞掉了。

Diffs 的设计目标，是让代码评审保持快速，同时不牺牲工作的严谨性。

在设计 Diffs 时，我们对评审应该是什么样，有这样几条简短的信念：

一开始，我们把重点放在摩擦最明显的地方。

评审请求会淹没在邮箱里，而队列对什么紧急毫无提示，因为列表里的每个 PR 看起来都差不多。提请求的人不该非得在 Slack 私信里刷屏才能引起你的注意。

评审就放在 Linear 里，和你其他工作待在一起，优先级一目了然，因为所有争夺你注意力的事情也都在那儿。每个 Diff 都关联着产生它的 issue 和项目，所以你能看出它是否卡住了某件关键的事，并据此和其他手头工作权衡。

大型 PR 通常按文件系统生成文件的顺序来评审，格式变动和重构噪音混在实质性修改里。评审者的注意力在 diff 看完之前就耗尽了，剩下的要么草草扫过，要么走个形式盖章通过。堆叠 diff 作为一种变通办法出现了，但为了弥补工具处理不了大 diff 的缺陷，付出的管理成本太高。

Linear 的引导式评审把 diff 拆成若干章节，按照工作推进的思考顺序排列。它先给你看改动的核心，再带你走过由此产生的后果，辅助性改动和胶水代码则单独放在一边。一个 2,000 行的 PR 可以一口气读完。

结构化 diff 高亮会剔除与程序行为无关的格式变动，于是留在页面上的就是真正的改动，而不是它周围的噪音。

评审者的主要工作，是弄清楚这个改动到底为什么应该存在，而不只是检查代码对不对。当上下文分散在多个工具和标签页里时，这个过程会更慢。

因为评审就在 Linear 里，激发这次改动的 issue、项目和客户信号就在旁边。不用跨工具追来追去，因为 Linear 已经把全貌拼好，并为你整理好了结构。

智能体已经接手了大部分逐行检查正确性的工作，而这过去要占用大量时间。越来越留给人的，是代码之上的一层判断：这个改动是否契合团队现有的架构体系，是否解决了客户真正报告的问题。Diffs 消除了评审周围的摩擦，让评审者有时间、有精力去做这种判断工作。

Linear Diffs 是 Linear 多年来打造的工作空间的最新一步，产品交付的每个环节都在同一个地方完成。后续还会有更多工作流功能上线。

从今天起，所有 Linear 套餐均可使用，设置步骤见更新日志。