最近我开始觉得，有些 AI 生成的 PR 确实有点浪费我的时间。 提交的人可能只花了五分钟生成一份修改，我却要花一个小时 review，确认它到底有没有解决问题。 这种情况出现在 good first issue 上尤其让人头疼，毕竟这个标签原本是为了让新人更容易开始参与项目。 自动搜索 GitHub issue 的脚本也可能通过 help wanted，甚至 bug 这样的标签找到任务，所以类似的情况也会出现在这些标签下。
我觉得这个标签原本的想法挺好的。 维护者挑出一些相对小而且明确的问题，贡献者可以借此熟悉代码和贡献流程。 实际的修改可能只有几行，但阅读相关代码、讨论实现方式也是这个过程的一部分。 有了 AI 之后，这些步骤就很容易被跳过去。 有人拿着 issue 的描述，让 AI 生成一个解决方案，然后就直接提了 PR，自己可能都没弄明白改的是什么。
问题在于，review 这些代码还是要花时间。 即使修改看起来合理，也附带了测试，我仍然需要确认它有没有遵循项目已有的做法，类似的代码是不是已经处理过这个问题，以及测试有没有覆盖我们真正关心的行为。 如果贡献者没有考虑过这些，我就得自己过一遍，再向对方解释哪些地方需要调整。 Diff 小并不代表 review 就快，尤其是我还得先弄清楚，对方到底理解了多少自己提交的代码。
我最初的反应是去看这个人在 GitHub 上的其他贡献。 如果一个 PR 看起来像是 AI 生成的，而作者在过去一个月又提交了大量 PR，我就会倾向于直接关闭它。 站在维护者的角度，对方可能都没花多少时间检查的东西，我却要花一个小时去看，确实有点说不过去。 但光看 PR 数量，也不能知道对方针对这次修改到底考虑了什么，所以我开始想，能不能在详细 review 之前，用一个更合适的方式来判断。
我正在考虑的一种方式，是问问对方怎么发现这个问题，以及动手修复之前考虑过哪些事情。 我在 badges/shields#12304 里尝试了这个做法。 这个 PR 想要屏蔽 dynamic XML service 中 XML parser 输出到控制台的警告和错误，也附带了测试和预期行为的说明，但我更想知道贡献者是怎么得出这份实现的。 从项目的 issue 列表里找问题，本来就是很正常的参与方式。 我更在意的是找到问题之后做了什么：有没有读相关代码，有没有看类似的实现，以及有没有想过项目为什么要这样处理？
在那个 PR 里，我真正想听到的是，对方有没有检查过其他 endpoint 是怎么处理类似错误的。 让我在意的地方是，这份实现只解决了当前文件里的问题，没有把项目已有的做法考虑进去。 这里也涉及给 AI 的上下文。 如果只提供一段 issue 描述和一个看起来相关的文件，AI 可能会给出一份单独看没什么问题的局部修复。 但总得有人去看看项目的其他部分，判断这个方案到底合不合适。 如果贡献者把这部分工作留给维护者，那这个 PR 就提得有点早了。
我并不指望第一次参与项目的人就熟悉我们的所有约定。 即使读过相关代码， 也还是可能漏掉一些东西，这些都可以在 review 的时候讨论。 但我希望对方至少能够解释自己的选择，并且根据反馈继续修改。 比起判断每一行代码是不是 AI 写的，我觉得问这些问题更有用。 不同 issue 的答案会不一样，也能让我更清楚地知道，对方有没有认真想过这次修改。 光是一份写得很漂亮的 PR 描述，还不足以让我放心。
更让人疲惫的是，有时候你认真写了 review，对方还是把你的意见交给 AI，再把生成的回复贴回来。 这样几轮下来，你会发现自己好像一直在跟 AI 对话，提交 PR 的人只是负责在中间转发。 回复看起来很完整，但你仍然不知道对方到底理解了多少，下一轮讨论也未必能推进什么。 连解释实现的过程都可以交给 AI，光靠追问，也不一定能判断贡献者有没有认真参与。
想下来，我还是觉得 good first issue 现在变得有点尴尬。 这个标签让小任务更容易被找到，AI 又让这些任务的代码更容易被生成，但维护者对合入代码的责任并没有因此减少。 接下来我应该会在花太多时间看实现之前，多问问贡献者是怎么思考这个问题的。 但这也只能作为一个起点，对方回复得详细，并不代表他已经理解了自己的修改。 我愿意帮助一个人熟悉项目，但也需要对方花些精力，理解自己提交的代码。 否则，即使是一个小问题，review 花的时间也可能比我自己动手修还长。