标题：AI 时代的代码评审
弗朗西斯科·戈雅的《Duelo a garrotazos》。
看到代码评审从昔日最好的知识共享与上下文传递工具，逐渐沦为另一种官僚主义和摩擦的来源，实在令人遗憾。
你可能已经不止一次目睹过这样的场景：
-
Bob 提交了一个 PR——多半是 AI 生成的
-
GitHub 向一个或多个 CODEOWNERS 发送通知，要求评审/批准
-
Alice（或她的某个 agent）收到通知，决定处理
-
Alice 的 agent 评审 PR，并以评论的形式提出代码修改请求
-
Bob（或他的……好吧，你猜到了）看到评论，他的 agent 回复评论并提交进一步修改，过程中又弄坏了别的东西，从而触发 Alice 的更多评论
-
如此循环往复，永无止境
就算这个流程是由人类在指挥——每当有新评论或请求就去戳一下自己的 agent——也已经够糟了；但当 agent 之间自主开战的时候，场面就会变得非常难看。这些家伙可不知道什么时候该停！
每当看到这种你来我往，我的本能反应就是关掉电脑，去种种花、洗洗车，做什么都行，就是不想看着语言模型把自己活活耗死。
这是不是意味着我们从 AI 写的评论里学不到任何有用的东西？倒也未必。只是有时候这些知识 nuggets 被埋在了一大堆废话下面，人类几乎不可能从中发现它们，更别说从中学到东西了。
这是我为当今现实建立一套代码评审“礼仪”的初步尝试，希望能把乐趣带回这个我认为软件工程师可以拥有的最有价值的学习工具之一。
注：我绝不是 AI 黑粉，无论作为专业人士还是业余爱好者，我都大量使用 AI 来交付代码。但我的确认为我们把它用错了。
让我们深入聊聊。
把代码评审当作学习工具
有很多工具可以用来分享知识：技术深潜、维护文档、一对一沟通，等等。代码评审也是其中之一。
这个原则的核心，在于“投入程度”。
别人请你做事时，你投入的精力，不应超过对方在这件事上的投入。反过来，你也不该指望别人用超过你本人的投入来回你的请求。
作为 staff engineer，我每天都会收到几十个代码评审请求。GitHub 的邮件通知更是几百封地来。要是每个请求我都按“高投入”标准认真对待，那一天除了帮别人看代码，其他事就不用干了。
有了这条原则兜底，我不会被那些低投入的请求卡住——省下来的精力，可以更用心地回应真正需要认真对待的请求。同时，我在请别人帮忙时，也会用这把尺子先量量自己，想想该怎么开口。
对大家都好。
一些常见场景，以及按这条原则该怎么应对：
AI 生成的 PR，就该得到 AI 生成的评审
如果我收到一条自动发来的评审请求，PR 描述是 AI 写的，发起人也没有任何针对我的、带个人色彩的交涉，那我回过去的评审意见，也会是 100% 由 AI 生成的。
反过来也一样。如果我提交的 PR 完全是 AI 生成的，那你也尽管用 AI 来评，这本来就是理所当然的。而且对于大多数改动来说，这样的评审力度已经足够了。
但如果我花时间排查了问题，用自己的话跟你请教，麻烦别转发一堆未经加工的 AI 文本给我。别当人肉传声筒。
我既然动了脑子认真回复你，你用 AI 辅助回答自然没问题，但至少自己把内容过一遍，确认靠谱，再挑重点转发。我可不想每次提问，都收到一篇又长又空泛的“AI 作文”。最好能用自己的话把 AI 的产出重写一遍。
不过，要是你直接截个图把 Claude 终端页贴给我——地狱里应该有你的专属位置。至少我希望有。
把一段 AI 生成的大段内容读进去、消化掉，再用自己的话讲出来，这个过程真的能让你学到东西。回想一下学生时代，你像原始人一样拿笔抄黑板，把老师写的都记到笔记本上——我们以前就是这么学习的。
直接说你想让我看什么
大 PR 已经是常态了，所以别再丢给我一个 5000 行的改动，指望我逐行看完。我不会看的，真的不会了。
如果你觉得这些改动里只有一小部分需要我仔细把关，为什么不把这个大 PR 拆成小块，然后只让我看相关的那部分？
剩下的交给 Copilot 之类的工具去处理就好。
用你自己的话直接来找我
想让我看某个东西？直接私下找我，用自己的话说明需求，附上 PR 链接，但重点要讲为什么需要我看，而不是它做了什么事——Claude 能替我看懂“what”，但看不透“why”。
你可以随便用 AI 工具来帮你理解问题、摸索方向、判断可能的问题或方案，但有一点：如果你想知道我对某件事怎么看，请用你自己的话讲给我听。
写在最后
我们要意识到，自己提的每个问题、每个请求都会占用别人的时间。尤其是在现在这个生成内容变得特别容易的时代，更要留心这一点。把那些枯燥的活儿交给智能体（agent）去干，而更复杂、更有意思的问题，我们再亲自上手。