我做了十来年研发也在大厂带过团队说实话PR 审查一直是我觉得最值得做但又最难坚持做好的环节。代码写得漂不漂亮架构有没有腐坏潜藏的 Bug 会不会在深夜上线时突然爆出来大多都能在 PR 阶段看出端倪。但问题在于代码评审极度依赖资深工程师的经验和耐心而这两样东西在迭代压力面前都是稀缺品。所以当“Hermes”这种能把 GitHub PR 审查自动化的智能体出现时我第一时间就去试了用下来的感受是它不是在替代评审者而是在帮评审者把那些重复、机械、容易遗漏的检查项扛下来让人把精力集中在真正需要“人”来判断的设计和业务逻辑上。这里说的 Hermes是一个可以部署在自己服务器上、对接 GitHub 仓库的自动化代码评审智能体。它能在你提交 PR 之后自动拉取变更内容、分析代码风格、检测潜在问题、检查单测覆盖然后把评审意见直接发回 PR 评论区。对团队来说相当于给每个 PR 都配了一个不知疲倦的“前置把关人”。这篇内容我会把我从选型、部署到调参、踩坑的完整过程写出来包括配置代码、权限模型、流水线接入方式以及我在真实项目中遇到的那些坑希望能帮你少走点弯路。1. 内容整体设计与思路拆解1.1 项目背景PR 审查为什么需要自动化先聊个我自己的经历。之前带一个二十人左右的研发团队每天大概有三十到五十个 PR 需要处理。团队里真正能给出高质量评审意见的其实就是那三四个资深工程师。可他们自己也有开发任务每天光评审就要花掉两三个小时。更现实的问题是人脑在处理重复性审查时很容易疲劳比如忘记检查是否引入了新的安全问题、是否缺少对应的单元测试、是否符合团队的 Commit 规范、是否有调试代码被误提交。这些错误不致命但合并到主干之后往往要花更大力气去修。我在做过一次统计后发现线上事故中大概有三成左右如果当时 PR 审查再严格一点是完全可以避免的。自动化的思路其实不复杂把 PR 审查中那些相对客观、可规则化的检查项交给程序去做。比如静态代码扫描、依赖安全检查、代码格式校验、测试覆盖率的差额计算这些都有成熟的工具。但真正的难点在于“汇总”和“解读”——分散的工具会产生大量输出评审者不可能逐个去翻。Hermes 这类智能体做的就是把多个检查源的结果汇总起来用自然语言生成一份有优先级、有上下文、甚至带修复建议的评审意见然后以机器人身份发到 PR 里。它的核心价值不是“多了一个检查工具”而是“多了一个会总结、会判断、会沟通的虚拟评审者”。1.2 Hermes 的核心能力与它在工作流中的位置我在试用 Hermes 之前也担心它是不是又一个“看起来很美好”的玩具。但实际用下来它在好几个维度上都做到了能落地的程度。首先是代码变更分析它能基于 GitHub 的 PR Diff 数据识别出改动涉及的文件、函数、模块判断改动的影响范围。其次是规则动态匹配不是所有仓库都用同一套规范Hermes 允许你为每个仓库甚至每个分支配置不同的审查规则集比如后端仓库要求强制补充单元测试前端仓库则侧重检查样式和资源体积。第三是自动评论与交互它能直接把意见写到 PR review 里还支持在评论里 它进行追问比如让它解释某条告警的具体原因、给出修改示例。它在工作流里应该处于“预审”和“人工评审”之间。当开发者提交 PR 后Hermes 先跑一轮自动检查把能发现的问题都标出来。然后真正的评审者打开 PR 时面对的不是一片空白而是一份已经整理好的“体检报告”。评审者只需要重点看 Hermes 标记为 High 级别的问题以及它对整体设计逻辑的判断是否合理。这样一来人工评审效率至少提升一倍而且评审质量会更稳定不太会出现“今天心情好就审得细明天赶版本就草草看一眼”的情况。1.3 适合谁来用以及在什么场景下收益最大如果你问我什么团队最适合引入 Hermes我的答案是有一定研发规模、PR 数量多、但又没有专职 QA 或架构师团队的中小型研发组织。大型团队往往有完善的 CI/CD 平台和专业的工具链但 Hermes 依然可以作为“最后一公里”的汇总层嵌入进去。而三五人的初创团队大家写代码都靠默契倒也未必需要这么重的自动化评审。但一旦超过十个人PR 开始变多代码风格开始分裂线上问题开始变频繁这时候引入 Hermes 的投入产出比会非常明显。从场景来看收益最大的是三个地方一是开源项目的维护者他们每天要处理大量外部贡献者的 PR没时间逐行审查Hermes 可以先做一轮预筛二是版本发布前的代码冻结阶段自动评审能避免因为人的疲惫导致漏审三是跨时区协作的团队当核心评审者不在线时Hermes 可以先给出初步意见让提交者及时修改而不是干等十几个小时。我实际把 Hermes 接入了一个跨三个时区的团队仓库PR 的平均首轮响应时间从原来的八小时缩短到了二十分钟以内这个提升是非常直观的。2. 核心细节解析与实操要点2.1 理解 Hermes 的运行机制并不是“魔法”而是一套流水线我刚开始接触这类智能体时总以为它是一个带 GUI 的在线服务登录网页、绑定仓库、点个按钮就完事了。但 Hermes 更接近一个“可编程的审查代理”它由几个核心组件构成入口监听器、代码分析引擎、规则引擎、LLM 对话服务和消息回写模块。入口监听器负责接收 GitHub Webhook 事件比如pull_request、issue_comment、pull_request_review_comment等。每来一个事件它会先做一次基础过滤比如判断 PR 是否处于 Draft 状态、变更文件数量是否超过阈值、提交者是否在白名单内。过滤之后它会触发分析引擎把 PR 的元数据、Diff 内容、相关文件的历史改动记录收集起来。接下来是规则引擎它会基于你配置的规则文件来执行静态检查比如禁止console.log进主干、要求新增文件必须包含版权头、不允许引入高危依赖版本等。这些规则的结果会连同 Diff 一起打包发送给 LLM由模型生成综合性的评审意见。这里有一个关键设计Hermes 并不完全依赖 LLM 的“智能”来发现所有问题而是让 LLM 做“信息综合与表达”真正的硬性检查还是靠确定性规则。这样设计的好处是规则的执行结果永远是稳定可预期的不会因为模型版本更新导致检查行为漂移而 LLM 负责的则是把零散的检查结果串联成有逻辑的评审建议这是它对开发者最有价值的地方。理解了这一点你才会明白为什么配置规则文件是使用 Hermes 的核心功课。2.2 权限模型与安全边界不是每个机器人都该拥有写权限接入 GitHub 时我见过不少人图省事直接把 Personal Access Token 配上去结果这个 Token 拥有仓库的所有权限一旦泄漏整个仓库的代码都能被恶意篡改。正确的做法是使用 GitHub App 或 Least Privilege Token把权限精确到“能读取 PR 内容、能写入评论”这个最小范围。GitHub App 的模型会更适合 Hermes因为它的权限是 Per-repository 维度的独立授权且可以随时吊销不会像 Personal Token 那样一把钥匙开所有门。在创建 GitHub App 时我会把 Repository permissions 里的 Pull requests 设置为 Read and writeContents 设置为 Read-onlyIssues 设置为 Read-onlyWebhooks 设置为 Active。这样 Hermes 可以读取代码内容来做检查但没有权限直接篡改分支代码最多只能提交 review 意见。即使被攻破攻击者也拿不到代码推送权限可以极大降低供应链攻击的风险。还有一个安全细节容易被忽略Webhook Secret。配置 GitHub Webhook 时一定要填一个足够复杂的 SecretHermes 在收到请求时会先验证签名。如果不验证签名任何人都可以伪造一个假的 PR 事件发到你的服务器上导致 Hermes 做出误判甚至被诱导执行恶意指令。我在部署时见过有人跳过这一步后来被刷了上万条垃圾评论排查了很久才发现是 Webhook 没验签。这个教训分享出来希望大家别在安全上省这几分钟的功夫。2.3 审查规则的设计原则少即是多先硬后软关于规则配置我最想强调的一点是不要一上来就把几十条规则堆进去。我见过一些团队照搬大厂的规范文件结果第一轮跑下来PR 里被机器人刷了上百条评论开发者的第一反应不是“这是个好工具”而是“这玩意太吵了关掉吧”。真正可行的路径是“先硬后软”第一阶段只启用确定性高、误报率低的硬性规则比如禁止提交密钥、检测调试代码、校验代码格式等团队适应了机器人的存在再逐渐加入复杂度更高的软性规则比如函数圈复杂度阈值、循环依赖检测、重复代码提示。规则的阈值设定也要结合团队实际情况。比如“新增代码不允许超过 500 行的函数”这种规则如果你是做算法密集型项目很可能会频繁误报。我会先跑一周的“观察模式”只记录问题但不评论然后统计哪些规则命中的是真实问题哪些是噪音再根据数据来微调阈值。用数据说话而不是拍脑袋定规则这样团队对机器人的信任度才会建立起来。2.4 工具链整合从零散 CLI 到统一流水线很多团队本来已经使用了 ESLint、Pylint、Checkstyle、SonarQube 等工具那 Hermes 是不是重复造轮子我的理解是它不是替换这些工具而是作为它们的“上层聚合器”。与其让每个工具单独向 PR 中提交一条评论不如让它们各自把结果输出到文件或统一接口然后让 Hermes 收集这些结构化结果去重、合并、按优先级排序最终生成一条综合评论。在实操中我一般会把本地检查工具的配置统一到一个Makefile或 CI 脚本里让它们支持 JSON 格式输出。比如 ESLint 可以配置--format jsonPylint 可以配置--output-formatjson。然后 Hermes 在分析时不仅读 Diff还会把这些检查工具的 JSON 文件一并加载进来。这样一来开发者看到的评审意见是“ESLint 发现 3 处错误其中 2 处是高危建议优先修复 xxx 文件”而不是一条条割裂的机器日志。体验上的提升是巨大的。3. 实操过程与核心环节实现3.1 环境准备服务器、依赖和网络规划我先说一下我推荐的部署环境。因为 Hermes 的对话引擎需要调用 LLM 服务整个链路对网络要求比较高所以最好部署在一台配置尚可、网络稳定的 Linux 服务器上。我使用的是 Ubuntu 22.04 LTS配置是 4 核 8G这个规格跑起来比较宽松。如果只是小规模仓库2 核 4G 也能跑但首次分析大 PR 时可能会等得久一点。另外需要准备好 Python建议 3.10 以上和 Node.js建议 18 以上。因为 Hermes 的部分组件是用 Python 写的而 GitHub 官方 CLI 和部分集成脚本依赖 Node.js。安装依赖的时候我习惯用一个独立的虚拟环境避免把系统 Python 环境弄乱。命令大致是这样# 安装 Python 虚拟环境 python3 -m venv hermes-env source hermes-env/bin/activate # 安装 Hermes 主框架和插件 pip install hermes-agent[github] # 验证安装 hermes --version如果你本地还没有 Node.js可以考虑用 nvm 管理版本curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash source ~/.bashrc nvm install 18 nvm use 18提示网络状况不佳可能导致依赖下载缓慢建议配置镜像源或提前做好 proxy 规划。但请注意不要使用任何不规范的加速工具避免引入安全风险。3.2 创建 GitHub App 并完成授权流程这是接入过程中最容易出错的一步我拆细一点讲。先去 GitHub 的 Settings - Developer settings - GitHub Apps点击 New GitHub App。App name 随意比如hermes-review-bot。Homepage URL 可以填你的服务器地址或仓库地址。Webhook URL 填 Hermes 服务对外暴露的地址比如https://your-domain.com/webhook。Webhook secret 填一个高强度随机字符串注意保存好。在 Permissions 设置中按下面的表去配置权限项值说明Pull requestsRead and write允许提交 PR 评审意见ContentsRead-only允许读取代码内容IssuesRead-only允许读取 Issue 关联信息ChecksRead-only允许读取 CI 状态MetadataRead-onlyGitHub App 默认强制勾选创建完成后GitHub 会生成一个 App ID 和私钥文件。私钥要放到服务器上的安全目录比如~/.config/hermes/private-key.pem然后确保文件权限是 600只有运行用户可读。这一步不能省私钥泄漏等于把仓库的读取权限交出去了。接下来要把 App 安装到目标仓库。进入你的 GitHub App 页面选择 Install App然后选择要授权的组织或仓库。安装成功后GitHub 会提供一个 Installation ID把 App ID、Installation ID 和私钥路径都填到 Hermes 的配置文件中它就能以机器人身份操作 GitHub 了。3.3 Hermes 的配置项详解从 Token 到审查开关Hermes 的配置文件支持 YAML 或环境变量两种方式。我更推荐用 YAML因为它可以把多个配置项组织在一起方便团队 review 和版本化管理。核心配置大概长这样github: app_id: 123456 installation_id: 789012 private_key_path: /home/hermes/.config/hermes/private-key.pem webhook_secret: your-strong-secret review: enabled: true parallel_reviews: 3 max_files_per_pr: 100 skip_draft: true skip_title_patterns: - ^\\[WIP\\] - ^wip: llm: provider: openai model: gpt-4o-mini temperature: 0.2 max_tokens: 2048 api_key_env: LLM_API_KEY rules: enabled: true config_path: /etc/hermes/rules.yaml notifications: slack_webhook_url: comment_on_review: truereview段里的parallel_reviews表示同时分析的 PR 数量如果你对接的是大仓库建议设小一点避免瞬时并发太高导致服务崩溃。skip_draft和skip_title_patterns可以避免机器人过早介入草案阶段的 PR。llm段的temperature我建议设在 0.2 左右太低会显得机械太高会输出一些天马行空的建议。max_tokens控制每条评审意见的最大长度设太大既费 token 又容易让评论变得冗长。配置完成后可以用 Hermes 自带的自检命令测试连接hermes doctor这个命令会检查配置文件是否能解析、私钥是否存在、GitHub API 是否能连通、LLM 服务的 Key 是否有效。我在第一次运行时连 node 版本不兼容的问题都被它查出来了省了不少排查时间。3.4 编写第一批规则关键用户和条件表达式规则文件是 Hermes 的灵魂。以我常用的一个仓库为例我配置了这样几条规则# /etc/hermes/rules.yaml rules: - name: block-console-log description: 阻止 console.log 进入主干 scope: *.js,*.ts condition: contains(text, console.log) severity: warning message: 检测到 console.log请使用统一的 logger 模块。 - name: ensure-unit-test description: 新增源文件必须包含对应测试 scope: src/**/*.py condition: added_file_count 0 and not has_corresponding_test severity: error message: 请为新增的源文件补充单元测试。 - name: avoid-secrets description: 检测疑似密钥 scope: * condition: matches(text, (?i)(api[_-]?key|secret|password)\\s*[:]\\s*[\\\][A-Za-z0-9/]{16,}) severity: critical message: 疑似密钥出现在代码中请立即移除并轮换密钥。规则文件用起来要特别注意作用域和条件表达式的匹配逻辑。scope支持 Glob 通配符可以有效减少误报condition里的函数比如contains、matches、added_file_count需要查一下 Hermes 支持的内置函数列表不同版本可能略有差异。我一开始用错了函数名导致规则一直没生效后来在日志里看到 rule compilation error 才反应过来。另外严重级别建议严格区分。critical级别的规则直接阻塞合并且通知到群warning级别只在评论中提示info级别通常只是给出优化建议不干扰合并流程。这套分级逻辑能让机器人既不漏掉关键问题也不会刷屏影响体验。3.5 真实仓库接入示例从 Webhook 到第一条评论当配置完成后接入一个仓库的流程就快了。先在 GitHub 上确认 Hermes App 已经安装在目标仓库里然后手动创建一个测试分支改一个文件提交 PR观察 Webhook 是否到达。我在一台测试服务器上跑的命令是# 检查 Hermes 服务日志 journalctl -u hermes -f日志里应该能看到类似这样的流程收到pull_request事件 - 开始分析 PR 123 - 拉取 Diff 完成 - 规则引擎执行完成 - 调用 LLM 生成意见 - 提交 review。我第一次跑通时看到 PR 里出现机器人的评论还是有点激动的评论内容不仅指出了问题所在的具体行号还附了一句“建议使用logger.info()替代print()”这个建议质量已经能顶得上一个中级工程师的水平了。这里有个细节GitHub 的 PR review 有COMMENT、APPROVE、REQUEST_CHANGES三种状态。Hermes 默认用的是COMMENT模式也就是只给意见但不阻塞合并。如果你想让它更“强权”一点可以配置成REQUEST_CHANGES但这需要团队提前约定好否则很容易引发开发者抵触情绪。我建议刚开始先用COMMENT模式跑两周等团队认可它的输出质量后再逐步升级权限。4. 常见问题与排查技巧实录4.1 Webhook 收不到事件先查网络和签名这是接入时出现频率最高的问题。如果你在 GitHub 后台发送测试 Webhook但 Hermes 日志里没有任何记录我会按照下面的步骤逐一排查先确认外网能否访问你的 Webhook 地址用 curl 测一下curl -X POST https://your-domain.com/webhook -d {test: true} -H Content-Type: application/json如果返回 404说明路由没配对如果返回 403说明验签失败检查 Webhook Secret 是否一致。还要注意网关上有没有防火墙或反向代理挡住请求。一个容易踩的坑是GitHub 的 Webhook 有自己的超时时间如果你的服务器响应太慢GitHub 会重试但有可能跳过一次导致事件丢失。我建议把 Hermes 服务放在反向代理后面并配置超时时间不低于 30 秒确保长时间分析任务不会在网关层被掐断。如果网络没问题再看签名校验。GitHub 发来的请求带X-Hub-Signature-256头Hermes 依赖配置里的 secret 来计算 HMAC 并比对。如果 secret 不匹配请求会被拒绝。曾有位同事在环境变量里多写了一个空格导致一直验签失败这类问题很隐蔽建议大家调试时先打印一下配置解析后的字符串长度。4.2 LLM 响应超时或报错降级方案很重要Hermes 的核心亮点是 LLM 生成的评审意见但这也意味着它依赖外部服务的稳定性。我在用的时候遇到过 LLM API 偶发超时导致整个评审流程卡住。后来我在配置里开启了“降级模式”也就是当 LLM 不可用时Hermes 自动只推送规则引擎的硬性检查结果而不是完全静默。对于团队来说迟到的硬性检查结果总比没有结果要好。另外max_tokens设得过大时一次请求的响应时间会明显变长尤其是 diff 较大的 PR。我的经验是控制在 1500 到 2048 之间既能覆盖大部分评审内容的长度又不至于让请求迟迟不返回。如果遇到长文件分析超时也可以调整max_files_per_pr参数对超大 PR 做抽样分析避免资源被一个 PR 占满。4.3 误报太多怎么办建立负面清单与白名单机制机器人刚上线时开发者最大的槽点就是“误报太多”。ESLint 把某个临时使用的 debug 变量判为错误或者规则引擎把一个测试专用的固定密钥当成真实密钥告警。这时候如果强行保留规则团队很快就会产生“机器人过敏症”看到评论直接忽略。我的建议是建立一份负面清单把那些经过人工确认属于误报的情况记录进去同时允许在源码注释中加上免责声明例如// hermes:ignore rule-name告诉机器人这行是经过确认的例外。白名单机制也很重要比如node_modules、生成文件、vendor 目录等不应该被审查的路径务必在规则条件里提前排除。有一次我把一个自动生成的 API 客户端文件也加入了审查结果每次跑都报几百条 error十分影响体验。加上排除配置后噪音立刻降低了 90% 以上。4.4 合并冲突时的评审行为当 PR 出现合并冲突时GitHub 的diff接口通常还是能返回变更内容但部分行号信息可能已经失真。Hermes 在分析时如果发现冲突标记残留比如文件里出现、、这样的标记会直接提示开发者先解决冲突再请求审查。这个规则非常实用因为现实里真的经常有人把半成品的冲突解决提交上来。如果你发现机器人在冲突状态下生成的评论准确率下降可以在规则里增加一条condition: contains(text, ) - severity: error提示开发者先处理冲突。这本身就是一条很好的硬性规则。4.5 排查工具与日志速查表为了最大化排查效率这里整理了一个速查表当你遇到问题时可以直接对照症状可能原因排查动作收不到任何 Webhook网关未暴露、Secret 不匹配、服务未启动检查journalctl -u hermes -f手动 curl 测试收到事件但评论未生成LLM 调用失败、规则编译错误、评论权限不足查看日志中llm_error或permission_denied关键字评论内容过于泛泛temperature过高、上下文信息不足降到 0.2 以下并确认 Diff 数据是否正确传给 LLM部分文件始终不审查未配置Contents: Read-only权限检查 GitHub App 权限配置重新安装 App评论在 PR 上重复出现没有做事件去重开启 Hermes 的幂等模式用 PR ID commit SHA 做键分析非常慢PR 过大、parallel_reviews过高降低并行数增加max_files_per_pr限制我在实际运行中还发现日志里最容易被忽略的是权限报错。GitHub App 的权限变更后有时需要重新安装 App 才能生效否则即使你在配置里写了新权限GitHub 后台仍保存旧的授权范围。遇到权限问题时先 return 到 GitHub 的 App 安装页面重新保存一次安装多半能解决。5. 规则演进的路线图从“能跑”到“好用”5.1 数据驱动地迭代规则集接入 Hermes 的前一两周我强烈建议开启“统计模式”也就是让 Hermes 把每次评审的问题类型、涉及文件、严重级别都记录下来。然后每周导出一次统计报告看哪些规则命中率高且被开发者接受哪些规则触发频繁但开发者普遍觉得“无所谓”。逐步淘汰后者固化前者。这就像养一只宠物规则集是需要持续投喂和训练的不能指望一蹴而就。我自己的经验是第一周 30% 的规则会被删掉或大幅放宽20% 的规则会提升严重级别剩下 50% 可能会保持原样并补充新的边界条件。这个动态调整的过程比一开始就追求“完美规则集”要高效得多。5.2 结合 CI 状态和测试覆盖做组合判断单一规则的能力是有限的组合规则才能发挥真正的威力。比如单测覆盖率检查器通常只报告“覆盖率下降了 2%”但 Hermes 可以把“覆盖率下降”和“本次改动涉及核心支付模块”这两个信息组合起来生成一条有更高优先级的评审意见“本次改动涉及支付模块核心路径且单测覆盖率下降 2.3%建议补充至少一个端到端测试用例。”这种信息综合能力是传统的 CI 检查工具给不了的。我最满意的一个落地案例是业务团队接入了 Hermes 之后把“pr-title-format”“commit-message-format”“test-in-diff”“dependency-check”四类规则全部打开并且让 LLM 基于这些结构化输出做总结。效果是 PR 的无效往返次数提交后被打回修改的次数下降了四成左右因为很多明面上的问题在机器评论阶段就被解决掉了。5.3 人机协作的最佳实践机器人提问题人来定方向我从来不建议让机器人直接 approve 合并请求因为代码的架构合理性、业务意图、性能权衡这些东西机器人还远达不到“理解业务”的程度。但机器人的确可以做一件事把 PR 拆解出“事实核查”和“主观判断”两个层面。事实核查包括有没有留下调试代码、有没有引入已知漏洞依赖、有没有破坏单元测试、有没有遗漏必要注释。这些交给 Hermes 解决。而主观判断比如“这个接口设计是否符合团队演进方向”“这个缓存策略是否能支撑预期并发”这些必须由有经验的工程师拍板。所以我对团队的流程约定是Hermes 的评论作为必读材料但合并与否仍然由负责人判断。当机器人标记critical时线上告警群里会同步提醒确保不会在无人注意的情况下漏掉高危问题。这样既发挥机器人的效率又不让团队丧失对代码质量的最终掌控权。6. 部署完成后的运行观察与优化建议整个系统稳定运行之后我反而花了更多时间去观察它每天的评审记录。因为 LLM 的输出带有一定随机性即使 temperature 设得很低同一个 PR 在不同时间提交可能也会得到措辞不同的评论。如果想让输出更稳定可以把规则引擎的结果做得更细让 LLM 的任务从“发现所有问题”简化为“总结已发现的问题”。也就是说尽量让 LLM 做减法而非加法。团队反馈方面建议定期收集开发者的真实感受。有一次开发者说“机器人老是纠结缩进问题我改起来很烦”我才意识到某个规则的阈值太严格于是把缩进检查从 error 降为 warning争议立刻消失。工具是为人服务的不能让工具变成新的负担。这也是我在接入任何自动化系统时的一条底线。最后关于扩展。Hermes 可以对接的第三方服务不只是 Slack 通知我目前已经在尝试把它的评审结果同步到内部的周报系统自动生成本周 PR 质量趋势图。后续还计划在 CI 失败时让它自动分析可能是哪次 PR 引起的不稳定帮我们定位回归源头。这个场景如果跑通相当于从“PR 审查助手”升级成“变更风险管理助手”对研发效能提升的价值会更明显。如果你也在用或打算引入 Hermes建议先按文中的步骤把基本流程跑通再慢慢丰富规则和场景这个工具的潜力远比你第一眼看到的要大。