# 面对突然出现如此多需要审阅和做 Review 的代码,该怎么应对?

本页为原文的机器翻译，未经人工译者审核。历史信息可能已发生变化。

面对突然出现如此多需要审阅和做 Review 的代码,该怎么应对?
瓶颈已经从写代码转移到审阅代码,开发团队的大量工作就是判断开发出了什么以及是如何开发的。

我发现的一个对我和团队都有帮助的办法,是给撰写 PR Description 的智能体添加指令(无论是 Cursor 里的 command,还是通过 LinearB 的 GitStream),遵循一套 4 步方法:

1. 我们要解决什么问题 
2. 改了什么、在哪里改的(哪些文件)
3. 实际上是怎么工作的(流程)
4. 有哪些风险

一旦在 Description 阶段就把 PR 说明得如此细致,理解代码的路径就会短得多、容易得多,我已经知道我期望在代码本身中看到什么,有时甚至在我看任何一行代码之前,就发现了智能体自己提出的架构问题或风险

这个办法对我们效果非常好,以至于当我把它分享给其他团队负责人时,他们决定在整个 R&D 部门对每一个提交的 PR 都采用它 😇

Original: https://ofershap.github.io/posts/a-four-step-pr-description-for-faster-code-reviews/
Source: https://www.linkedin.com/posts/ofershap_%D7%90%D7%99%D7%9A-%D7%A0%D7%9C%D7%97%D7%9E%D7%99%D7%9D-%D7%91%D7%9E%D7%A6%D7%91-%D7%94%D7%96%D7%94-%D7%A9%D7%99%D7%A9-%D7%A4%D7%AA%D7%90%D7%95%D7%9D-%D7%9B%D7%9C-%D7%9B%D7%9A-%D7%94%D7%A8%D7%91%D7%94-activity-7488097566912364545-K7N5
Published: 2026-07-29T08:06:22.077000+03:00