用 Copilot 实现维护者视角的代码审查

我是如何教会GitHub Copilot代码审查像维护者一样思考的

对vibe coding好坏的议论先搁一边，但它确实惠及了开源生态。曾经，为陌生的代码库做贡献令人生畏，这意味着再受欢迎的开源项目的维护者也很难获得社区帮助。但现在有了AI编码工具，贡献的门槛大大降低了。实际上，我们用Rust构建的开源AI agent框架goose反而面临了截然相反的问题——收到的贡献这么多，简直忙不过来！这虽然是个"幸福的烦恼"，但我们想确保每位贡献者都有良好的体验。问题是，我们自己人手不足，无法完成所有审核。幸运的是，GitHub已经为我们准备了一个Copilot Code Review agent，可以在每个PR一提交就立即进行审核。

我启用了这个功能，以为大家会喜欢，但坦白说效果不理想。其他维护者说这些审核意见太多太杂，大部分评论质量都很低。他们问我们能不能把它关掉。

从帮助工程师与AI合作的经验中，我学到了一件事：你不能放弃。你不应该禁用。你应该调优。你要教会模型如何按你的方式工作，而不是寄希望于碰运气。

在评估它的一些审核意见后，我发现问题相当一致：

评论篇幅冗长，令人不堪其扰

评论篇幅冗长，令人不堪其扰

充斥着太多"也许"和"考虑"这样表达低把握度的措辞

充斥着太多"也许"和"考虑"这样表达低把握度的措辞

只有约五分之一的评论是贡献者可能会遗漏的真正问题

我不怪Copilot。它怎么会知道我们关心什么呢？我们根本没告诉它！幸运的是，有办法改正这一点。

Copilot通过 .github/copilot-instructions.md 文件支持自定义指令。我在这个文件里精确指定了我们希望它的行为方式。

我首先教Copilot我们对人工审核者的期望原则。

这立即减少了噪声。它停止了猜测，开始专注于清晰、有把握的反馈。

然后我明确告诉它要优先关注什么。这些是我们在审核中真正在乎的领域。同样，Copilot要是没有这种背景，它怎么会知道呢？

有了这个列表，Copilot停止了吹毛求疵，开始抓住真正的问题。

项目特定的背景

Copilot不会凭空知道你的设置。你必须告诉它正在审核什么样的项目。

这种背景帮助它理解我们的架构和最重要的模式。

Copilot在CI完成前就开始审核PR，所以没有背景的情况下，它会对CI已经检查的东西做出评论（或更糟的是，对CI做出假设）。我添加了这一部分，让它知道什么已经被覆盖。

下一部分至关重要。我告诉它哪些不用费事评论。这些行为恰恰是产生大量噪声的地方。

为了解决冗长的问题，我提供了对我们期望的结构的洞察。我们不需要长篇大论。只需用一两句话让我们知道哪里有问题。

这种格式使每条评论都简短、具体、便于采取行动。

最后，我允许它在不确定时保持沉默。LLM迫不及待地想帮你。但有时候这种帮助应该是以沉默的形式出现的。

调优Copilot后，变化是立竿见影的。噪声大幅下降，评论变得更有用。

然而，这还不是它的最终形态。随着更多PR到来，我观察了Copilot的反应，发现了一些新的模式，它需要更多的指导。每一次，我都会更新指令文件，添加额外的规则。这是我们当前代码审核指令的版本。

如果你决定为自己的仓库设置这个功能，预期你也会做同样的事。这不是一次性的修复。随着项目的演变，你需要观察、调整，并继续教它。

如果AI在你的代码库中不太适用，别急着放弃它。你很可能可以通过以下建议让它为你所用：

• 具体化。模糊的指令会导致模糊的结果。
• 设置置信度阈值来帮助过滤噪声。
• 告诉它CI已经覆盖了什么，这样它就不会重复工作。
• 包括来自你实际代码库的真实例子来教它。
• 持续迭代，你会随着时间不断改进结果。