给 GitHub 仓库接一个 AI Code Review 机器人：Actions 实战配置
AI 写代码越来越快，瓶颈反而卡在「谁来审」上。9 月底 OpenAI DevDay 之后，带云电脑的编码智能体已经能自己提 PR，但合并前那道人工评审，仍是团队质量的最后一道闸。把这道闸的初筛交给 AI，是性价比极高的一步——不需要买重型平台，一个 GitHub Actions 工作流就够。 工作流长什么样 核心是三步：触发 PR、拉取 diff、调模型评审、把结果写回评论。在仓库 .github/workflows/ai-review.yml 里： on: [pull_request]，限定 opened / synchronize； 用 actions/checkout@v4 拉代码，git diff origin/main...HEAD 拿到本次改动； 把 diff 作为 user message 发给任意兼容 OpenAI 协议的接口（DeepSeek、智谱、或自建网关都行），API key 存在仓库 Secrets 的 LLM_API_KEY； 用 actions/github-script 把模型返回贴成 PR 评论。 提示词只抓四件事：明显 bug、空指针或越界、安全性（注入、硬编码密钥）、以及「这次改动是否超过了它该做的范围」。 两个容易踩的坑 第一，别让它写风格意见。一旦允许模型评论「变量名不够语义化」，PR 评论区会被无效意见淹没，开发者很快把机器人静音。把输出限定为「必须修改」与「建议确认」两档。 第二，控制 diff 体积。一次改两千行的 PR 直接喂模型，既慢又贵还漏看。超过 800 行就只评审变更文件的关键函数，或拆成多轮。 落地建议 先在内部仓库灰度两周，让团队投票保留哪些意见类型。AI 评审不会替代人，但它把新人最容易犯的那类低级错误挡在人工评审之前，Reviewer 的注意力才能留给真正难的设计权衡。这才是它该待的位置。 补充一个实操细节：首次接入时，建议先把评审设为「仅建议、不拦截」，运行一周收集机器人给出的意见，让团队投票保留哪几类。那些真正挡住 bug 的意见留下，只会制造噪音的删掉。此外，对大改动 PR 可以只做增量评审——用 git diff 限定到本次变更的函数，避免模型把精力花在历史代码上，也省 token。 ...