代码太多，PR 太多。AI，请帮忙！

Source: Dev.to

“代码审查”瓶颈

随着 Cursor 或 Antigravity 等工具的出现，写代码变得前所未有的轻松和快速。它们可以在几秒钟内生成模板代码、测试以及整个模块（前提是你礼貌地请求它们）。

然而，问题在于：质量检查仍然由人来完成，而我们阅读和理解他人代码的能力仍然停留在原点。

于是，Pull Request（PR）的数量不断增长，而审查团队的吞吐量却保持不变。代码审查正逐渐成为瓶颈。这是一个循环：AI 造成了代码量过大的问题，所以合理的假设是 AI 应该帮助我们清理这堆烂摊子。

工具箱：Google Genkit 与 Go

Google 最近推出了一套用于 AI 开发的新生态系统，包括 Agent Development Kit (ADK) 和 Genkit。作为一名 Go 开发者，对我来说最大的惊喜是这些工具都配备了官方的 Go 库。

实验：自制 AI 审查员

仅出于好玩，并且想试用一下新库，我构建了一个简单的 CLI 代理，充当首轮代码审查员。

审查员的概念很简单：

• 通过 GitLab API 获取 Merge Request 的 diff。
• 将这些上下文喂给 Genkit 中的模型。
• 让模型识别 bug、风格指南违规或潜在的安全问题。
• 将反馈以评论的形式回写到 GitLab。

源码已开源，地址如下：

在 CI/CD 中的工作方式

关键特性是易于集成。该工具以普通二进制文件运行，因此可以作为 .gitlab-ci.yml 中的独立阶段加入。

stages:
  - review

review-code:
  stage: review
  image:
    name: registry.gitlab.com/romanyx/reviewer:latest
  script:
    - /app/reviewer
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      when: manual
  variables:
    GITLAB_TOKEN: $GITLAB_TOKEN
    GEMINI_API_KEY: $GEMINI_API_KEY
    PROJECT_ID: $CI_PROJECT_ID
    MR_ID: $CI_MERGE_REQUEST_IID
    REVIEWER_PROMPT: |
      You are a Principal Golang Engineer acting as a code reviewer.
      Your task is to analyze the changes in this Merge Request and provide constructive feedback.
      Follow https://github.com/uber-go/guide/blob/master/style.md guides, Golang best practices and SOLID principles.
      If the code is good, don't do any comments.

当创建 Merge Request 时，流水线会被触发。机器人会扫描改动，并在发现问题的代码行直接留下评论。

结果如何？

下面是机器人实际运行的示例： 。

机器人在需求触发下遍历了改动，标记出需要关注的区域。当然，它并不能取代深度的架构审查（尽管在合适的工作流和更充分的上下文下或许可以），也无法替代对业务背景的理解。但它作为第一轮审查非常有效，能够捕捉到一些简单错误，让我们免去手动检查的麻烦。

值得使用吗？

这取决于具体场景。传统的 linter 是确定性的：它们非常适合捕获语法错误、未使用的变量或格式问题。它们运行快速、免费，并且基于规则的准确率是 100 %。

而 LLM 则是概率性的；它们可能会产生幻觉或遗漏问题。它们不是像编译器那样的“守门人”，但可以充当“第二双眼睛”，全天候运行且永不疲倦。

结论

这次实验表明，将 LLM 融入日常工作流非常容易，尤其是配合 Go 与 Genkit。我们无法阻止 LLM 生成代码的洪流，但完全可以构建更好的工具来管理它。如果你的 Merge Request 收件箱已经爆满，也许是时候把部分任务交给机器人了。