每天打开 GitHub看到几十个待审查的 Pull Request是一件很让人头疼的事情。代码量少的时候还好一旦 PR 动辄几百上千行光是通读一遍就得好几个小时更别说还要逐行检查逻辑、风格、潜在的坑。我在维护几个开源项目、也带过一段时间团队之后越来越觉得“人工纯手动审查”这件事成本实在太高了。后来我开始在项目里引入自动化代码评审工具尝试了一圈之后目前稳定跑着的是一套基于 Hermes 的 GitHub PR 审查方案。这篇文章就完整记录一下我从选型、部署、配置到实际使用的全过程包括踩过的坑和一些调优经验。Hermes 本质上是一个自动化代码评审 Agent它可以监听你的 GitHub 仓库每当有人提交 PR 或者更新 PR 时自动拉取 diff 和上下文调用大模型对代码进行审查然后把结论以评论的形式贴回 PR 里。整个过程中人只需要在最后看报告、确认意见。这样一来常规问题格式、明显的逻辑缺陷、缺少错误处理、潜在的注入风险等在人工介入之前就被拦截了一遍Reviewer 的精力可以集中到真正需要判断的地方。这个项目适合谁如果你是一个开源项目的维护者日常收到大量外部贡献者的 PR需要一个高效的初审工具或者你是团队里的技术负责人想在合并代码前多一道保险再或者你只是对 AI 辅助编程感兴趣想看看大模型到底能不能真的当代码审查员——Hermes 这套玩法都值得试一下。我自己用了大概三个月它帮我筛掉了很多低级问题也让我重新思考了“人工审查”这件事的边界。1. Hermes 到底是什么能帮我解决什么问题1.1 我的使用场景先说一个具体的场景。我之前维护的一个项目核心模块的代码审查压力特别大。贡献者来自五湖四海有人写 Python 很溜但不懂 JavaScript 的坑有人是后端转前端风格千差万别。每周大概有 20 到 30 个 PR我一个人不可能全部仔细看但草草合入又怕埋雷。引入 Hermes 之后我的流程变成了这样贡献者提交 PRHermes 自动进行第一轮检查通常几分钟内就会在 PR 下面留下审查意见比如“这里存在潜在的空指针风险”或者“这个函数的复杂度太高建议拆分”。我看到有提醒之后再点进去结合 Hermes 的评论快速定位只花很少的时间就能完成确认。整个节奏和我之前亲力亲为的体验完全不同。1.2 Hermes 的核心能力我在评估阶段列过一个需求清单Hermes 基本都覆盖了Diff 级审查而不是文件级审查它能看懂“这次改动到底改了什么”只针对新增和修改的代码做审查不会把历史遗留问题全部翻出来当然也可以配置让它顺带检查上下文。多语言支持我测试过 Python、JavaScript、Go、TypeScript效果都不错。理论上常见语言都能处理因为底层用的是大模型理解能力跟着模型走。行内评论审查结果可以精确到某一行代码直接在对应行下面贴评论比汇总报告更直观。可配置的规则和严重程度不同的团队对代码风格和质量的容忍度不一样Hermes 允许配置发出提醒的阈值例如只提醒 Error 级别的问题。模型可替换底层大模型可以自由切换。我最早用的是一个通用模型后来切到 DeepSeek成本下降很明显中文注释和提示词的理解也更好。1.3 为什么我选了 Hermes 而不是自己写脚本之前我试过自己写自动化检查脚本比如用 eslint、golint、ruff 这些工具配合 GitHub Actions在 CI 阶段跑静态检查。那套方案的问题在于规则匹配是固定的能发现语法和风格问题但对“这个函数逻辑有没有 bug”“这段代码有没有性能隐患”这类需要理解语义的问题完全无能为力。我也试过直接调大模型 API自己拼 prompt、拉 diff、生成评论然后往 GitHub PR 上发评论。这个方法看着可行但实现细节特别繁琐GitHub 认证、diff 解析、评论盖楼、去重、并发控制样样都要自己写。而 Hermes 把这些都封装好了我可以专注在“如何调教好审查”这件事本身。选工具就应该这样没必要重复造轮子除非现有的轮子完全带不动你。2. 部署 Hermes 之前的准备工作2.1 运行环境的选择Hermes 可以安装在 Linux 服务器上也可以在本地电脑用 Docker 跑。我个人的建议是如果你的仓库是私有仓库或者团队内部使用优先部署到一台长期运行的服务器或 NAS 上这样即使你不在电脑前PR 来了也会自动被审查。硬件要求不高我一开始用了一台 2 核 4G 内存的轻量云服务器跑 Hermes 加几个小服务完全没压力。真正的开销在模型 API 调用不在部署本身。如果你只有 Windows 电脑也可以通过 WSL 2 或者直接装 Docker Desktop 来运行效果一样。2.2 创建 GitHub TokenHermes 需要以某种身份访问你的 GitHub 仓库。两个选择个人访问令牌PAT简单方便适合个人仓库或者小型项目。直接授予对目标仓库的读写权限即可。GitHub App适合团队和组织级使用权限控制更细可以只授权特定的几个仓库审查起来更安全。我最初用的是 PAT因为配置最快。后来考虑到团队协作时 token 需要共享改成了 GitHub App 的形式。其实 Hermes 两种模式都支持看你的场景。配置 PAT 时需要勾选repo相关的权限这样才能读取 PR 内容、发表评论。注意一点窗口关闭之后就看不到完整 token 了只能重新生成务必保存好。2.3 准备模型 API KeyHermes 本身不生成审查结论它负责组织代码上下文和调用模型。所以你需要一个能调用的模型 API。目前比较主流的方案DeepSeek 官方 API性价比高中英文代码理解都不错我用的是这个。OpenAI 兼容接口国内很多模型服务商都提供 OpenAI 兼容接口直接填 endpoint 和 key 就可以。本地模型如果你机器配置足够或者你有 GPU也可以用 Ollama 之类的方式跑本地模型。好处是数据不出内网适合对代码保密要求高的项目。我用 DeepSeek 是因为它的 API 价格在同类里确实便宜而且长上下文处理能力强——审查大 PR 的时候动辄好几万 token 的输入价格敏感的话必须考虑这一点。3. 从下载到跑通的完整安装流程3.1 使用 Docker Compose 一站式部署Hermes 官方推荐使用 Docker Compose 部署这种方式最大的好处是依赖隔离、升级方便。安装完 Docker 和 Compose 之后我建了一个目录里面放一个docker-compose.yml内容大致如下version: 3.8 services: hermes: image: hermes-agent/hermes:latest container_name: hermes restart: unless-stopped ports: - 8080:8080 environment: - HERMES_CONFIG_PATH/app/config.yaml - HERMES_STORAGE_PATH/data volumes: - ./config.yaml:/app/config.yaml - ./data:/data第一次跑之前需要先准备好config.yaml。你可以从项目的示例配置里复制一份然后按需修改。我习惯把配置文件和容器的映射目录分开方便后续备份。3.2 初始化配置的关键字段配置文件是 Hermes 的核心下面是一个简化版的配置骨架server: port: 8080 github: token: ghp_你的token app_id: 123456 # 如果用 GitHub App 模式才需要 app_private_key: /path/to/private-key.pem models: provider: deepseek api_key: sk-你的api_key endpoint: https://api.deepseek.com model_name: deepseek-chat temperature: 0.1 review: trigger: [opened, synchronize] # 哪些事件触发审查 languages: [python, javascript, go, typescript] max_diff_size: 5000 # 单次审查的最大 diff 行数 ignore_paths: - *.lock - package-lock.json - dist/ severity_threshold: warning重点解释几个字段server.portHermes 的 Web 服务端口用于接收 GitHub Webhook 或者轮询任务。review.trigger指的是 GitHub Webhook 事件。opened代表创建 PR 时触发synchronize代表 PR 代码更新时触发。我一般两个都要因为开发者经常 push 新 commit 进来每次更新都重新审查一遍才有意义。max_diff_size这是防止烧钱的限制。如果某次 PR 改了几万行全量审查的 token 消耗会非常大设置上限后超过的部分就跳过改成提示人工审查。severity_threshold低于这个级别的问题不予评论比如只显示 warning 以上级别的问题。可以避免模型对无关紧要的小问题“刷屏”。3.3 启动服务并验证是否正常工作配置好之后在目录下执行docker compose up -d然后查看日志docker compose logs -f hermes如果一切正常你能看到类似下面的日志[INFO] Connected to GitHub successfully [INFO] Listening for webhook events on :8080 [INFO] Model provider deepseek is available这说明 GitHub 连接成功、模型 API 也验证通过了。我第一次运行的时候还顺手验证了一下直接往仓库里提交了一个 PR几分钟之后看 Hermes 是不是真的会自动评论。这比看任何文档都直观。3.4 配置 GitHub Webhook 让 PR 事件自动触达Hermes 有两种方式获知 PR 事件一种是配置 Webhook让 GitHub 主动把消息推给 Hermes另一种是轮询让 Hermes 定时去 GitHub 查询。Webhook 实时性更好我选择用它。在 GitHub 仓库的 Settings → Webhooks 里添加一个 WebhookPayload URL填你的 Hermes 地址比如http://你的服务器IP:8080/webhookContent type选application/jsonEvents勾选 Let me select individual events至少勾上Pull requests要注意的是如果 Hermes 部署在内网而 GitHub 无法访问内网你就得用内网穿透或者将 Hermes 部署到公网可达的服务器。对于私有代码我更推荐把 Hermes 部署在能访问 GitHub 但代码本身只保存在自己内部的服务器上并在防火墙层面做好访问控制。4. 配置自动化代码评审规则4.1 理解 Hermes 审查的原理在深入配置之前有必要理解 Hermes 是怎么“看懂”代码的。它做的不是简单的正则匹配或规则引擎而是将 PR 的 diff、相关文件内容、函数上下文等组合成一个结构化的 prompt发送给大模型让模型返回审查意见。所以模型的选择非常关键。我在调试中发现temperature这个参数对审查质量影响很大。如果设置得太高比如 0.7模型的创造性太强容易“幻觉”也就是编造一些并不存在的问题设置得低一些我目前用 0.1审查结果更保守、更可靠虽然可能会有少量误报但整体可接受。另外Hermes 还会为每个 PR 建立一个“会话上下文”连续的对话可以引用之前的结果避免同一个问题在多个 commit 里被反复提交。4.2 自定义提示词与规则有些人觉得现成的提示词就够了但实际用下来不同语言、不同项目的风格差异很大还是建议花时间调一调。Hermes 允许在配置里自定义系统提示词比如我给自己项目的 Python 代码加了这些要求review: custom_prompt: | 你是一名高级 Python 代码审查人员。在审查时请重点关注 1. 内存泄漏和资源未关闭问题 2. 明显的逻辑错误和边界条件遗漏 3. 并发安全问题 4. 对第三方库的错误使用 5. 可能出现的空指针None问题 6. SQL 注入等安全风险 7. 代码可读性和命名问题仅提示最严重的 输出格式要求 - 每条意见包含所在文件、行号、严重程度critical/warning/info、问题描述、修改建议 - 如果文件没有问题不要输出任何评论 - 评论要简洁不要长篇大论这段话的意思是只要模型发现这些问题就以结构化的方式反馈。特别重要的一句话是“如果文件没有问题不要输出任何评论”这能避免模型没事找事、在 PR 下刷存在感。4.3 针对不同文件的忽略规则不是所有文件都需要 AI 审查。我在配置里默认忽略了锁文件package-lock.json、poetry.lock等生成文件dist/、build/大型测试快照文件这样能显著减少不必要的 token 消耗因为锁文件动不动就有几千行让模型看它纯属浪费钱。这也是一个重要的调优思路把审查资源集中在“值得看”的代码上。我在实际使用中发现忽略规则写得太宽也有问题。有一次我误把某个业务包的目录名加进了ignore_paths结果那段时间这个包的代码改动完全没有人审一直到一次线上事故排查时才发现亏得代码本身问题不大不然后果很严重。所以加忽略规则时务必谨慎宁可多审也不要漏审。4.4 多人协作时的通知方式Hermes 的审查结果可以多种方式通知默认是在 PR 页面留下评论也可以配置成将审查摘要发送到钉钉、飞书、Slack 等聊天工具。团队协作时建议开一个代码审查专用群机器人把摘要推送到群里相关人员直接打开群里跳转链接就能看到详细意见。我配置过飞书机器人。Hermes 只需要一个 Webhook 地址审查完成后向这个地址发一条消息摘要包含 PR 链接、审查结论、问题数量。这个功能特别适合“异步协作”的团队不会一直打断当前工作有空时集中处理。5. 一次真实的 PR 审查实操记录5.1 我准备的一个测试 PR为了让第一次体验不至于太混乱我特意造了一个包含各种问题的测试 PR。下面是这个 PR 的代码简化版def process_user_data(users): results [] for user in users: data fetch_user_data(user[id]) if data[status] active: value data[value] result value * 2 results.append(result) return results # 疑似缩进错误导致循环只执行一次这行代码的问题人工审查时很容易一眼带过但是一个小错误。当我把它提交上去Hermes 在约两分钟内给出了评论指出了缩进问题可能会导致只处理第一个用户。function getUser(id: number) { return db.query(SELECT * FROM users WHERE id ${id}) }这个更严重存在 SQL 注入风险。Hermes 果然也发现了并且给出了使用参数化查询的建议。5.2 Hermes 的完整审查输出上面的 PR 提交后我打开 PR 页面看到 Hermes 留下了这样一份审查总结摘录## Hermes Code Review Summary ### Critical - [P0] src/api/user.ts 第 12 行存在 SQL 注入风险 建议改用参数化查询db.query(SELECT * FROM users WHERE id ?, [id]) ### Warning - [P1] src/process.py 第 8 行return results 缩进疑似有误 当前代码会在第一次循环时直接返回导致只处理第一个用户 建议将 return 与循环对齐 ### Info - 当前 PR 整体质量尚可未发现明显性能问题这个输出结构非常直观严重程度分级、具体到行号、有修改建议。我只需要快速浏览就能判断哪些需要处理、哪些可以忽略。5.3 对审查结果的判断与处理这里说一个很重要的心态AI 审查不是“圣旨”它的结论需要人来判断。比如有一次 Hermes 报了一个 “memcpy 使用不当可能存在缓冲区溢出”的 warning我看了代码发现是性能优化的关键部分而且外层已经严格保证了长度所以这个 warning 我不会直接照改而是补充了一行注释说明为什么这里是安全的。还有一次 Hermes 把某个对象属性访问报成“潜在空指针”原因是它没有足够的跨文件上下文。这种情况下我会手动确认没问题就 ignore。关键是Hermes 能把 90% 的真正问题捞出来剩下的 10% 由人工兜底这个效果已经非常值得了。5.4 与 CI/CD 流水线的集成Hermes 不只是被动“评论”也可以接入 CI 流程让它在必要时阻止合并。比如当审查出 critical 级别的问题时让 GitHub Actions 的检查标记为 failed这样 PR 就不能被直接 merge。实现方式很简单如果你用的是 GitHub Actions加入一个步骤读取 Hermes 审查的状态即可。我在配置中启用了“将 critical 级别问题作为检查失败”的选项合并按钮就会红起来。这在一定程度上强制保护了代码质量。当然这里要特别注意“误报导致阻断合并”的问题解决办法是允许人工在评论中回复一条指令例如/hermes-ignore来标记为已确认的问题这样即使有 critical 检查只要人工确认过CI 也可以放行。6. 常见问题与排查技巧实录6.1 我踩过的坑GitHub Token 权限不足第一次配置时我用了一个只读 token结果 Webhook 连接正常但审查完成后评论发不出去日志里报 403。排查了很久才发现是 token 权限不够。换成repo完整权限之后问题马上解决。后来我为了安全又换成了 GitHub App它的权限是独立的不会像 PAT 那样暴露个人账户的所有仓库。尤其当团队里有多个成员时建议一定要用 GitHub App 模式而不是大家共享一个 PAT。6.2 模型 API 限流与超时大模型 API 在高并发时会遇到限流Rate Limit。当多个 PR 同时触发审查时Hermes 会并发调用模型。我一开始把并发开到 10结果频繁报 429。解决方案有两个一个是降低并发数另一个是接入支持高并发的模型服务。我的做法是在 Hermes 配置里限制并发数量为 3同时对每个 PR 设置超时时间。虽然多个 PR 可能会排队但总比报错重试好。我遇到过最尴尬的情况是向某个模型服务商充值后控制台显示有余额但 API 一直返回 401。排查了半天发现是粗心配置了旧的 API key重新生成之后一切正常。所以遇到鉴权问题第一步永远是检查 key 是不是最新的。6.3 大 PR 审查超时怎么办如果 PR 太大单次审查的 token 数会超过模型上下文限制。Hermes 的处理方式是分批chunk读取 diff逐文件审查后再汇总。但即使这样超时仍然可能发生。我通常会配置较大的超时容忍时间并且在max_diff_size里做一个限制超过阈值的 PR 不自动审查而是提示人工处理。与其让模型看一半就放弃不如规规矩矩地让人类工程师来。6.4 常见问题速查表问题现象可能原因解决方法审查评论发不出去日志 403GitHub Token 权限不足更换为带repo权限的 Token或使用 GitHub App模型 API 报 401/429API Key 过期或限流重新生成 Key降低并发数审查结果完全不评论severity_threshold设置过高将阈值降为warning或info看了很多不相关的问题自定义 prompt 缺少限制语在 prompt 中强调“只报告真正的问题”PR 太大导致审查超时diff 超过模型上下文窗口设置好的max_diff_size及分批策略或改为人工想忽略某些文件的噪音评论未配置ignore_paths在配置中添加锁文件、生成目录等6.5 进阶用法与本地代码规范引擎配合Hermes 不是来替代 eslint、ruff 这类工具的而是作为它们的补充。我目前的组合是提交前本地 IDE 里跑 lint 和格式化解决一切能自动修复的问题。PR 阶段先让 Hermes 做一轮语义级审查发现逻辑和安全隐患。人工介入只看 Hermes 挑出来的问题结合自己的判断决定是否修改。这个组合的好处是机器管“标准”AI 管“语义”人管“决策”。每一层都有自己的职责不会互相重叠交叉。7. 我的实际体会与后续扩展建议用了三个多月我在几个不同语言、不同规模的项目上都跑过 Hermes。最直观的感受是它把我的 PR 审查时间从平均 40 分钟压缩到了 10 分钟左右而且减少了那种“看了一遍完全没发现问题、合入之后才被别人指出”的挫败感。有一点需要提醒的是不要指望 AI 审查能发现所有问题它更像是一个极其勤快的实习生帮你把铺天盖地的代码挨个过了一遍把可疑的地方圈出来但最后的判断和决定权始终在你手中。我遇到过它漏掉一个非常隐蔽的事务并发问题也遇到过它提出了一个我完全没想到的资源释放优化点让代码质量提升不少。后续我还打算把它接到更多自己的仓库里也在考虑写一个适配公司内部代码规范的自定义规则集。如果你也在被 PR 审查折磨真心建议给 Hermes 一个机会从一个测试仓库开始跑起来调一调提示词感受一下“AI 帮你审代码”到底是什么体验。等它真正融进你的工作流你会发现自己多出了不少可以用来认真思考的时间。