如何（不）用 AI 处理 Pull Request 和代码评审 | Paul Bakker
有了编程智能体（coding agent，能自动写代码、改代码的 AI 工具）帮忙，多数团队产出的 Pull Request 数量猛增。那这么多 PR，我们该怎么评审？
看一个由智能体参与生成的 PR 描述，通常是把所有改动罗列一遍。内容倒是齐全，但特别长。光搞清楚这个 PR 到底要干什么，就得花不少时间。
难道我们要整天读这些长篇总结，再逐行读完全部代码（不管是不是 AI 写的），来确认它符合预期？还是说，可以把时间花得更聪明一点？
首先要回答的问题是：这个 PR 最终由谁负责？答案应该是发起 PR 的开发者本人。过程中用没用智能体、怎么用的，都不重要。开发者必须清楚这次改动的含义、影响范围、潜在风险等等。他们不必记得智能体写下的每一行，但必须知道改动了或新增了哪些公开 API、有没有行为变化、有没有遗留缺口。他们还应该做足够的测试和验证——这件事完全可以用编程智能体来做。智能体很擅长找 bug，团队的时间不该花在这上面。
团队内部得有足够的信任，相信每个人都会尽到自己的责任。代码评审不该被当成检查「某人有没有干活」的关卡。
接着要问的是：代码审查到底是为了什么？
前面说过，负责 PR 的开发者本就应该先把质量关。想清楚设计、影响面、代码本身，验证行为是否正确，等等。在这个过程中，编码代理就是你的同伴，帮你抓出过去只能靠代码审查才能发现的 bug。既然我们已经用代理审查过代码，那在创建 PR 之前，再让团队其他成员来审查就没什么意义了。作者本人和他的编码代理都已经验证过的代码，还指望别人能找出什么明显的 bug 吗？
与其要求 PR 作者自己达到这种质量水平，不如等 PR 创建后直接跑一个审查代理？在我看来，这样做只会增加延迟，还会造成上下文切换。你手边就有一个编码代理，随时可以帮你在提交前改进 PR。用它就行了！
我不是说在 PR 流程里放一个审查代理不好。但我觉得，提交明显没准备好的 PR、指望审查代理来救场，这种做法不可取（除非你明确说明情况）。如果团队还会收到 PR 通知、可能已经开始看了，那就更糟了。
团队应该参与的是真正重要的决策，以及我们自己拿不准的地方。PR 描述里要清楚写明你希望团队反馈什么。比如：
-
“我新增了这个公共接口 X。有没有更好的命名建议？我也考虑过 Y 和 Z。”
-
“这个属性的默认值翻转了，应该是安全的，因为我们已经迁移了 X。你能想到我可能遗漏的失败场景吗？”
-
“我在引入这个新功能，需要用户先做 X。你觉得有没有办法把这一步自动化？”
这样一来，审查者就清楚该关注什么、需要给什么反馈。否则，你想让人评论的点可能被埋在次要改动里，根本没人注意到。
很多拉取请求（PR）并没有什么特别需要帮忙的地方。这类 PR 该怎么处理？
最起码，它应该有一句描述，说明改了什么、为什么改，并且表明不需要进一步审查。如果团队之间足够信任，系统在合并前和部署时的验证也足够充分，那就直接合并，不用再审。如果还没到这种信任程度，至少把 PR 描述写清楚，也能让审查轻松一些。
对了，这些描述最好还是手写 :-)
用工具和智能体来判断一项改动有多大风险，往往很有用。比如，可以用工具静态检查是否存在公共 API 变更——这类改动永远值得额外关注。借助工具和智能体把注意力集中到真正重要的事情上，这样我们人类就能把时间花在真正有意思的问题上。