工作量最大的往往不是写代码本身而是怎么把代码评审这件“事后诸葛亮”的事做得让人心服口服。我最近把大部分PR初筛工作交给了一个叫Hermes的智能体让它跑GitHub PR自动化代码评审效果比预期好不少。这篇文章就是围绕这个项目展开的完整记录适合那些想给团队搭一套自动评审流水线、但又不确定从哪下手的读者参考。先说结论Hermes这类智能体本质上是把“读diff、找问题、发评论”这三件重复劳动接了过去但前提是你要把它的职责边界划清楚。下面我把整个思考过程、搭建步骤和踩过的坑都写出来。1. PR审查的痛点与自动化切入点1.1 人工审查为什么越来越力不从心代码评审这件事听起来是“多人把关质量”实际做久了就会发现它有几个天然的矛盾。第一个矛盾是时间和注意力的错配。开发者刚提交PR时脑子里还残留着上下文这时候评审最有价值。但恰恰是这个时间点团队里其他人往往在忙自己的任务让一个状态没切换过来的人去硬看几百行diff效果可想而知。等晚上或者第二天再评作者早切到别的功能上了新的上下文又覆盖了旧的回复评论、改代码的心理成本翻倍。第二个矛盾是评审标准不稳定。同一个团队里有人对命名极其敏感有人只关心逻辑正确性还有人盯着异常处理不放。同一个PR上午评和下午评评审人的心情不同产出也不同。这种不一致性被反复讨论过但始终没根治因为人没法像机器一样对着一份规则逐条执行。第三个矛盾是重复劳动太多。格式问题、明显的死代码、缺少空指针检查、日志打错级别这些基础问题其实并不需要“资深工程师”花时间看。但现实中资深工程师又确实会被这些问题刷屏真正需要他们判断的架构和业务风险反而被淹没在琐碎评论里。1.2 自动化审查适合覆盖的范围所以我不认为自动化评审的目标是“取代人工评审”它的目标应该是“吃掉低层次工作把高层次问题暴露得更明显”。我整理过一份范围清单开发团队可以参考基础规范类命名、格式、明显的重复代码、硬编码魔法值。可疑逻辑类空指针风险、未处理的错误返回、资源未释放、并发下的竞态隐患。安全红线类硬编码密钥、SQL拼接、危险的序列化入口、未鉴权的接口。一致性类新增代码是否沿用项目现有模式、日志风格是否统一、是否引入了仓库已有的工具方法重复实现。文档同步类改动是否影响了对外接口却没有同步更新注释或者使用说明。这个范围有一个共同特征它们都有相对客观的判定依据能在diff里找到具体证据。只要证据明确机器就比人更适合检查。反过来模块拆分是否合理、技术方案是否有长期隐患、当前改动和未来规划的兼容性这类需要大量业务上下文的问题暂时还是留在人工评审环节更稳妥。想清楚这一点再去选工具和设计流程才不会跑偏。很多团队一上来就让智能体“全面审查所有问题”结果评论满天飞开发体验急剧下降最后机器人被关掉这就是职责边界没划清楚。2. Hermes在PR审查链路中的角色定位2.1 Hermes智能体的核心能力拆解Hermes的名字很容易跟其他同名工具混淆这里说的场景是一个能接入大语言模型、能按指令调用外部API、并能根据执行结果继续决策的智能体。打个比方普通代码扫描工具是一只“只会叫的狗”发现固定模式就报警Hermes更像一个“实习生”你告诉它审查规范它自己去读diff、对照规则、起草评论然后交给你确认。拆开看它在这条链路里有三个关键能力第一是理解能力。它能接收上下文不只是几行正则能匹配的文本。它能理解“这里使用了共享的可变状态多个请求处理协程在并发读写可能存在数据竞争”这类语义化判断。这一点是传统静态检查工具很难做到的。第二是调用工具的能力。PR审查不是“拿到一段代码文本然后写感想”这么简单实际工程里要拉取PR元数据、获取完整diff、判断哪些文件是新增哪些是重命名、定位行号、把评论精准提交到对应代码行。这些动作背后都是GitHub REST API调用Hermes这类智能体可以按照计划一步步执行而不是靠人写死一套脚本逻辑。第三是自主决策的能力。同样是死代码出现在新增业务文件里和出现在老旧的工具类里处理建议完全不同。Hermes可以根据你配置的规则库对不同严重程度的问题区分“必须修改”和“仅供参考”甚至可以根据文件历史自动调整审查密度。当然能力再强它也只是个工具。你给它什么规格的模型、什么风格的提示词、什么粒度的权限决定了它是靠谱的助手还是话痨的复读机。2.2 为什么选择用Hermes而不是写死脚本我见过不少团队试图用“GitHub Actions Shell脚本 grep”来实现PR自动检查。对非常固定的场景比如“禁止出现password 这种赋值”脚本完全够用一秒钟跑完还不需要额外成本。但如果审查逻辑复杂一点比如要判断“这个改动是否引入了与项目现有工具方法重复的实现”脚本就力不从心了因为这个问题本质上要求阅读理解。再比如审查意见要有说服力必须写清楚“在第几行、为什么是问题、建议怎么改”脚本拼字符串勉强能做但生成的内容僵硬且经常跑题。用Hermes这类智能体的价值在于它能用同一套“认知框架”处理各种不规则的代码而不是靠规则模板穷举。不过有一点必须提醒部署和调优成本是真实存在的。脚本是零维护Hermes需要你维护提示词模板、定期根据误报反馈做调整、处理模型输出格式异常。拿“省心”来衡量它不如脚本拿“评审质量上限”来衡量它远远超过脚本。所以在正式决定之前建议先做个简单的成本收益评估维度传统脚本Hermes智能体部署成本低几十分钟中需要半天到一天维护成本规则越多越混乱需持续打磨提示词审查深度只能查固定模式能处理语义级问题误报率低但漏报率高初期误报率偏高要校准适合场景强规则检查需要理解和判断的审查我最终选择Hermes是因为我需要的不是“替代规则检查”而是“替代部分人工阅读”。明确这个定位之后所有设计决策都变得清晰了。3. 从零搭建Hermes PR审查机器人3.1 环境准备与部署方式整个项目最核心的部署对象是一个“监听GitHub事件 → 调用Hermes分析 → 把结果写回PR”的常驻服务。我把它放在一台小规格容器里跑资源占用不大但对稳定性有要求毕竟它是挂在代码评审链路上的。部署前先梳理依赖一个GitHub App推荐而不是Personal Access Token原因后面详述。一个能跑Hermes的环境。我用的容器镜像启动时挂载配置目录模型API的密钥通过环境变量注入。后端模型服务的访问凭据。这里不绑定特定厂商只要能提供对话补全接口即可建议选择对代码理解能力强的模型。一个轻量的任务队列。GitHub Webhook可能瞬间并发过来多个PR事件服务要能排队处理避免同时调用模型导致限流。基础环境具备之后部署流程和常规后端服务没有区别拉取镜像、设置环境变量、把Webhook的端口暴露出来、启动。值得单独说的是配置结构。我把整个服务的配置拆成了三层全局配置GitHub App标识、私钥路径、模型端点、并发数。规则配置按仓库或按团队组织的审查规则集用YAML维护。提示词模板用于生成最终评审意见的系统提示词。拆开的好处是改审查规则不用重启服务改提示词也不用手动翻整段配置。实际运行中规则配置和提示词模板是调整最频繁的部分保持独立能省很多事。3.2 打通GitHub Webhook事件流配好基础服务后第一步是让GitHub把PR相关的事件推过来。在GitHub App的设置里需要订阅这几个事件pull_request对应PR打开、更新、重新打开、转为就绪等子事件。pull_request_review_comment可选用于后续做自动回复或者考虑到已有评论再决定是否重复提醒。pull_request_review可选用于统计分析自动化评审和人工评审的关系。我最常用的是pull_request事件里的opened和synchronize。opened覆盖新PRsynchronize覆盖开发者根据意见新推了 commit 的场景。这两个事件齐了就能覆盖日常95%的审查需求。不建议在edited事件里触发因为PR描述编辑不一定代表代码变化白白浪费算力。我最初的处理方式很粗暴收到任何事件都立刻触发完整审查。结果发现几个问题草稿PR被频繁触发、同一PR多次推送导致重复审查、大量评论刷屏。后来加了三个过滤条件问题立刻缓解草稿状态的PR不触发作者主动标记为“Ready for review”时才审查。同一PR的并发审查用锁控制新的推送事件只会重新排队一次。如果PR的作者在描述里写了[skip review]服务直接跳过处理和记录日志。涉及具体实现GitHub App的Webhook地址是配置在应用层级的会收到当前账号下所有仓库的事件。如果你只希望对部分仓库生效需要在服务里做仓库白名单过滤否则某个“实验性仓库”的PR也会被拉去跑一轮审查解释成本很高。3.3 审查规则的配置与提示词设计审查规则是这套系统里真正的灵魂提示词是让它说人话的关键。两者缺一个整条链路跑起来都是歪的。先看审查规则我用YAML维护了一份类似下面形态的配置rules: security: enabled: true severity: blocker keywords: - password - secret - api_key null_safety: enabled: true severity: warning logging: enabled: true severity: suggestion dead_code: enabled: true severity: warning这个形态的好处是门槛低即使不懂代码的测试同学也能看懂并参与维护。但实际执行时Hermes并不是靠关键词列表机械匹配它会把这份配置和理解到的代码上下文融合起来判断。比如password出现在定义常量名和出现在硬编码字符串里严重程度显然不同这部分判断就交给了模型。提示词设计我踩过几次坑之后沉淀出一套相对好用的模板核心思路是给Hermes设定“什么人、什么立场、什么输出要求”。参考结构如下你是一名资深后端工程师负责对PR做第一轮审查。你的目标是发现明确的、有证据的问题而不是泛泛而谈。请遵守以下原则只评论当前diff中新增或修改的行不评论无关历史代码。每个发现必须给出三要素问题行号、问题类型、修改建议。严重程度标记为blocker/warning/suggestion三种blocker只用于确定会导致故障或安全问题的情况。避免重复建议。如果同一个方法里多个类似问题合并成一条评论。如果diff质量整体不错明说“没有发现阻塞性问题”不要为了显得严格而硬凑意见。输出必须是结构化JSON包含summary和comments两个字段。最后一条约束是在多次解析失败之后才加上的。如果没有结构化要求模型回复经常带着Markdown标题和解释文字后续要提取comment再提交到GitHub的review接口解析成本很高。加上之后整个流程的稳定性上了一档。另外如果团队有历史评审偏好比如“controller层不允许写业务逻辑”“所有外部接口必须做入参校验”这些都可以追加到系统提示词里。建议以“可验证”为前提否则很容易导致Hermes基于模糊印象产生臆断误报。4. 审查效果实测与误报处理4.1 能拦住哪些真实问题跑了一段时间后我把Hermes的历史评论做了个分类统计发现它拦下的问题呈现一个明显的分层。最高频的是空指针和未判空。这跟语言特性有关但凡是传参、查询返回、反序列化场景模型很容易发现“这里没有判断目标是否为null就直接调方法”。这类问题传统静态检查工具也能查一部分但Hermes能结合上下文区分哪些路径是真实可达的所以误报警少很多。第二档是资源释放与异常吞掉。比如打开文件流后没有在finally里关闭、捕获异常之后只打日志不处理、HTTP客户端连接未复用。这些问题是资深工程师一眼能看出来的但确实经常出现在代码里。Hermes盯这个比人盯得死它不会因为当天状态不好就漏看。第三档是安全敏感项。硬编码密钥、日志里打印请求体、将内部错误信息直接透传给前端。安全类问题我只保留blocker级别的输出宁缺毋滥因为一旦误报却很吓人作者就会对机器人失去信任。实测下来还有个意外收获Hermes会主动发现问题点是否真的属于“本次改动引入”。这一点很关键很多人工审查是顺手骂一下历史代码而Hermes只会对本次diff负责这反而让评论聚焦了很多。4.2 高频误报场景和对应解法任何靠模型做判断的系统都绕不开误报Hermes也不例外。但它误报的形式跟传统工具很不一样传统工具是“规则过宽”它是“理解有偏差”处理方式因此也不一样。我遇到最多的一类误报是“上下文缺失”。新加入的项目里某些工具方法在另一个模块已经被定义过了Hermes在单个PR的diff里看不到全局代码就报“重复实现”。解决方式是在提示词里加一条遇到这类跨模块判断的改为suggestion级别而不是warning并明确说明“建议开发确认是否存在已有工具方法”。第二类误报是“风格偏见”。Hermes默认偏向某些代码风格比如更细的命名、更短的方法体。团队里可能存在历史一致的风格虽然不完美但统一、可读Hermes一上来就“建议重构”这种评论对开发者毫无帮助。我的处理方式是在规则配置里增加一个style: off的全局开关默认关闭风格类建议只保留语义和错误类审查。第三类是“测试文件误伤”。Hermes对测试代码很严格经常会报“断言不够充分”“缺少边界测试”这看起来用心良苦但在快速迭代的团队里这种评论很容易被无视又消耗注意力。我的做法是测试文件的审查密度调低一档只保留明显的逻辑错误检查。一个通用的策略是设置“新规则冷静期”。每次修改提示词或者新增规则之后让Hermes先跑一周“观察模式”评论正常提交但不标记严重级别等统计误报率低于某个阈值再放开。这个机制能避免一次提示词改动引起团队集体反感。4.3 与人工审查的分工边界引进自动化评审之后最需要跟团队讲清楚的是“机器人和人的边界到底在哪”。这个不界定清楚后面全是摩擦。我的建议是采用“三级漏斗”模型层级负责方输出形式审核流程第一级基础问题Hermes自动在PR的Files Changed里精确到行的评论作者自查修改无需人工确认第二级逻辑与安全Hermes建议人工复审汇总成一次Review提交人工reviewer确认是否采纳第三级架构与业务仅人工一般的代码评审意见需要完整上下文和业务判断实际执行中Hermes在第二级只负责“提出”不执行超能力更不能合并代码。它的所有评审记录都以“review”形式提交而不是直接comment在PR尾巴上。前者能挂到具体代码行后者只会制造信息噪音。边界上还要注意一点Hermes不应该“越权”去解决争议。比如两个开发者对某种实现方式有不同意见如果Hermes基于自己的偏好站队会非常破坏团队信任。所以在提示词里我会明确写当且仅当存在文档化规范时才下确定结论否则使用商量语气。这个设置让机器人从“裁判”降格为“提醒者”团队反而更愿意接受它的输出。5. 踩坑记录与团队落地建议5.1 权限模型与密钥管理我最早图省事直接用一个高权限的Personal Access Token挂到服务上。结果一次误操作把PR的合并权限都暴露给了自动化流程虽然没出实际事故但排查权限列表时吓出一身汗。后来换成了GitHub App权限模型清晰了很多。我实际申请的最小权限组合是Contents: Read-only用于读取仓库文件内容。Pull requests: Read and write用于提交审查评论。Checks: Read and write可选如果要把审查结果上报为Check Run的话。GitHub App的好处还有一点它的访问令牌默认过期服务需要周期性通过私钥签发新token。这个机制比长期token安全得多私钥只放在服务端环境变量里配合密钥管理工具统一管控。另外提醒一句千万不要把密钥打印到日志里。我见过同行调试时把请求头打出来token直接出现在日志平台后面光换密钥就折腾了一整天。5.2 API配额与并发限制GitHub API和模型API都有配额这是自动化评审最容易被低估的问题。GitHub方面PR审查接口的限速比较严格短时间大量提交评论会被短暂封禁。我的对策是给每个PR的评审过程加了一个小步延迟每提交一条按行评论后等待几百毫秒把请求速率维持在安全水位。模型API方面长diff的审查非常耗token。一个大改动可能动辄几万token高并发时成本飙升。我的做法是限制单次审查的diff规模超过一定行数则按文件优先级抽样审查优先看安全敏感目录和核心业务逻辑目录剩下文件只做基础检查。一个典型的配置如下review_limits: max_diff_lines: 3000 priority_paths: - src/security/** - src/core/** - src/api/** fallback_mode: sample_first_n这个限制同时保护了体验和成本。否则一个大型前端PR分分钟把月度token预算烧掉一半账单出来的时候你会有一种“上了一辆下不了的车”的感觉。5.3 渐进式上线的建议最后聊上线策略。我给团队的建议从来都是“三步走”不要第一天就要求全量采用。第一步影子模式。机器人正常跑审查逻辑但只对内部测试仓库生效所有评审记录汇总到单独频道团队只看不用回。运行一周主要是看误报率是否可接受。第二步建议模式。在主力开发仓库启用但评论降级为suggestion级别不阻塞合并也不强制回复。这一阶段的目标是收集真实项目里的反馈搞清楚哪些规则在业务场景下不合理。第三步协同模式。经过两三轮规则校准之后把确定性高的问题恢复为warning甚至blocker级别同时挂到CI流水线的Check Run上让PR页面的“Checks”标签页能直观看到结果。节奏大概每阶段一到两周。很多团队栽跟头就是因为步子迈太快机器人在所有人心里留下的第一印象是“烦人”后面再怎么调优都很难翻身。另外我会定期把Hermes的评审结果和人工评审结果做比对。如果人工评审提出的问题里有超过80%是Hermes本该发现但漏掉的说明规则需要补强。反过来如果Hermes的评论采用率连一半都不到说明它管得太宽了该砍掉一部分规则。这个循环大概是每个月调整一次稳定之后人力成本几乎可以忽略。我在实际部署中还有一种体会与其把Hermes定位成“AI评审员”不如把它当成一个“高标准的新人开发在帮你预读代码”。它不懂业务但它足够较真能在你把PR发给同事之前先帮自己挡掉一轮明显的尴尬。这个心态切换之后我对它的误报宽容了很多也会花心思把它的规则调到跟团队真正的痛点对齐。自动化代码评审不是让你再也不用看代码而是让你每次打开PR页面前心里已经多了一道筛网该你认真判断的事情一件都没少。