企业官网建设流程全解析

组里PR越来越多之后，不知道你们有没有一种感觉：代码评审正在从“质量保障”慢慢变成“流程负担”。早上打开GitHub，挂着十几个待review的PR，每一条都要点开diff从头看到尾，忙起来根本没时间细看，只能粗略扫一眼就点Approve。可真正的问题往往不是评审人水平不行，而是人的精力就那么多，让一个后端开发连续看五六个PR之后，后面几个基本就是走马观花。后来我把Hermes这类自动化代码评审agent接入到GitHub的PR流程里，让机器先把低级问题、边界缺陷、安全隐患过滤掉，再让人类评审专注于架构和业务逻辑，整套流程才顺起来。

这篇文章就以“Hermes”这个自动化代码评审agent项目为例，讲讲它到底怎么工作、怎么接入GitHub的PR流程、配置里有哪些关键参数，以及我在实际部署和使用中踩过的坑。如果你也想给团队的PR流程配一个“机器人评审员”，这篇文章可以直接照着抄作业。

1. 代码评审自动化：Hermes解决的真实痛点

1.1 人肉评审越来越不靠谱的过程

代码评审最大的问题不是“没人看”，而是“人看得不够准”。一个中型团队每天产生十几个PR很常见，每个PR涉及几十个文件的改动，跨语言、跨模块、还牵扯业务上下文。指望每个评审人都对所有代码了如指掌，本来就不现实。我在好几个项目里观察下来，人肉评审的质量曲线基本上是“前两个PR认真看，中间的凭经验扫，后面的直接LGTM”。这个锅不该让开发者背，PR数量超过精力上限之后，质量下降是必然结果。

还有个更隐蔽的问题：评审标准不一致。同一个项目的代码规范，每个人理解都不一样。有人care命名，有人care异常处理，有人只关心自己的模块有没有被改坏。于是同一个PR，有人Approve、有人Request Changes，最后review feedback全靠PR作者运气。规则一直在那里，但执行完全靠人，人和人的神经敏感度差太多了。

1.2 机器评审和人工评审的边界在哪里

Hermes这类工具能做什么，我先说清楚边界，免得大家抱着不切实际的期待。它擅长处理的是可以被规则和上下文推断覆盖的问题：明显的空指针风险、数组越界、资源未释放、错误处理缺失、危险函数调用、硬编码密钥、单测覆盖明显不足、代码风格偏离团队规范、重复代码等。这类问题本质上有迹可循，大模型加上静态分析工具可以判断得比较稳。

它做不到的是替人做产品决策和架构权衡，比如“这个模块到底该不该拆成微服务”、“新方案和现有业务模型的兼容性该怎么取舍”，这些需要业务上下文和长期项目经验，机器读了diff也给不了靠谱答案。所以我把Hermes定位成“前置过滤器”而不是“终结评审者”——它先把60%的常规问题拦下来，人类评审专家只需要集中精力看剩下的核心争议点。这比指望机器完全代替人类评审靠谱得多。

1.3 Hermes项目的角色定位

Hermes本质上是一个跑在服务端的自动化代码审查agent。它把自己挂在GitHub仓库上，监听Pull Request相关事件，每次有PR创建或更新的时候，把这次的代码diff拉下来，交给规则引擎和大模型一起分析，然后把审查意见以评论、review summary、check run的形式回写到PR页面上。这样做的好处是所有动作都发生在PR界面里，开发者不用切到别的平台就能看到机器人的意见。

和传统的静态检查工具（比如ESLint、SonarQube）最大的区别是：Hermes背后接了大模型，能用自然语言理解代码的“意图”。传统的lint只能查格式和已知模式，而Hermes能针对一段代码的逻辑缺陷说出“这里如果用户传入空数组会导致后续遍历越界”，这个粒度完全不一样。

2. Hermes的核心工作流程拆解

2.1 一个PR从创建到审查完成的完整链路

要理解Hermes的配置，先得弄明白它处理一个PR时到底做了什么。我在部署前把这条链路完整梳理了一遍，按顺序大概是这样的：

1. PR事件触发。有人创建PR或者push新的commit到已有PR，GitHub把webhook事件推给Hermes服务，或者Hermes通过轮询/定时任务的方式从GitHub API拉取状态变化的PR。

2. 获取并解析diff。Hermes调用GitHub REST API获取这个PR的.diff或.patch文件，按文件解析出新增行、删除行和上下文行。这里有个很多AI评审工具忽略的点：分析的范围应聚焦在“变更行”而不是整个文件，否则大模型读的文件内容太多，容易产生无关评论，而且消耗的token量巨大。

3. 语言识别与规则匹配。按文件扩展名判断语言类型，匹配对应的规则集。比如Python仓库重点检查异常处理、资源释放；TypeScript重点检查类型安全、可选链使用；Go重点检查错误返回和并发安全。

4. 静态分析前置处理。Hermes会先跑一轮基于AST的静态检查，把能确定的问题直接提取出来，这些问题不需要大模型判断，速度快、准确率高。

5. 大模型深度分析。把代码diff片段、相关文件上下文、规则集、团队规范描述一起组装成prompt，发给配置好的LLM服务（OpenAI兼容接口都可以，目前社区里比较多见的是接通用国产大模型或自建服务）。大模型返回的分析结果是结构化的，一般包含问题级别、文件位置、问题描述、修改建议代码。

6. 信息聚合与去重。把静态检查结果和大模型的结果合并，同类型问题做归类整理，同一文件重复报的问题只保留信息最全的一次。

7. 审查结果汇报。把最终结果以三种形式回写：直接在PR的diff里对特定行发inline评论、在PR页面上提供一个汇总review summary、把conslusion写到commit的check run里作为CI状态的一部分。

这七步里最容易被忽略的是第3步和第6步。没有规则匹配，会拿到一堆不符合上下文的废话评论；没有去重，哪怕是同一个变量名在3个位置出现拼写问题，机器人也会逐条刷屏，开发者体验非常差。一个“好用”的Hermes部署例子里，去重和分级这两层过滤是绝对少不了的。

2.2 为什么选择“事件驱动”而不是“定时全量扫描”

Hermes的接入形态有两种思路：一种是在GitHub上安装一个App，让它订阅pull_request事件，实时响应；另一种是起一个定时任务，每隔几分钟扫一次未评审的PR。实际团队使用中，我强烈建议用事件驱动。

原因是评审及时性问题。代码评审的价值高度依赖“时间窗口”——PR刚提交的时候，作者对代码的上下文记忆最清晰，这时候给出review意见，改起来的成本最低。如果等到定时扫描跑到才给反馈，作者可能已经切去开发别的功能了，回来再改这个PR，光恢复上下文就要花不少时间。事件驱动的模式能做到“PR一更新，机器人秒回评论”，体验和真人评审基本同步。

好在现在GitHub Actions天然支持事件触发的方式，Hermes服务端只需要提供可调用的接口，由workflow在pull_request事件时触发HTTP请求即可。这样你不用自己搭建常驻服务去接收webhook，直接用GitHub的托管Runner跑流程，运维成本低了很多。

3. Hermes部署的完整实操：从零到接入第一个PR

3.1 部署前需要准备的东西

Hermes的典型部署方式是“一个轻量级服务 + LLM API + GitHub凭证”。我先列一下全套清单，然后逐项说每个组件的用途和选型建议：

• 运行时环境：目前社区版本主要支持Node.js 18+和Python 3.10+。如果只是本地测试，装好对应运行时就行；如果放到服务器上长期跑，建议用Docker方式部署，它会把运行时依赖、配置文件、prompt模板都打进镜像里，升级方便。
• 一个大模型API：Hermes不捆绑模型，通过OpenAI兼容接口连接。你可以用GPT系列、Claude、DeepSeek或者其他任何提供OpenAI兼容API的服务。这个配置只影响审查质量，不影响工具流程。
• GitHub Token或者GitHub App凭证：用于读取PR内容和回写评审。如果是个人仓库测试，直接用Fine-grained personal access token，勾选Pull requests: Read and write和Contents: Read两个权限即可。如果是团队仓库，强烈建议注册一个专用的GitHub App，这样权限粒度更清晰，也方便按仓库授权。
• Redis或数据库（可选）：Hermes本身如果要做跨PR的重复问题检测（比如同一个文件在最近的PR里刚刚提过同样的问题，这次就不重复报了），需要一个存储来记历史。小团队刚上手阶段可以先用SQLite，跑得挺稳。

3.2 CLI本地运行：最快看到效果的方式

我不建议团队一上来就把Hermes接到全仓库的CI上，第一步应该是在本地跑起来，先看看机器人对你代码的评审质量，再决定要不要全量接入。Hermes提供了一套CLI命令，最常用的是review。

# 安装Hermes CLI（假设项目支持npm全局安装） npm install -g @hermes/cli # 登录，配置GitHub Token和模型API Key hermes auth login --github-token ghp_xxx --llm-api-key sk-xxx # 指定目标仓库和PR编号，执行一次本地评审 hermes review --repo owner/my-repo --pr 123

执行完这个命令之后，Hermes会在终端输出本次的分析摘要，比如发现了几个错误级别问题、几个建议、分别在哪些文件的哪一行。确认输出质量符合预期之后，再加--post参数把结果写到PR评论里。

hermes review --repo owner/my-repo --pr 123 --post

这里有个细节要注意：本地执行时，Hermes是用你当前登录的账号去发评论的，所以评论作者会显示成你的账号，而不是机器人账号。要解决这个问题，得注册一个专门的GitHub账号或者GitHub App当作“机器人身份”。我建议从第一天就准备一个独立的账号，不然后面审查记录里到处混着个人账号的消息，很不好清理。

3.3 用Docker部署常驻服务

本地跑通了CLI之后，就要把它升级成“团队公共设施”。服务器上用Docker部署的方式大致是这样：把Hermes的代码仓库clone到服务器，构建镜像，然后把API key、GitHub凭证、模型endpoint作为环境变量传进去。

git clone https://github.com/hermes-review/hermes.git cd hermes docker build -t hermes-review . # 创建配置文件目录，准备挂载配置 mkdir -p /etc/hermes cp config.example.yml /etc/hermes/config.yml # 启动Hermes服务 docker run -d \ --name hermes \ -p 8080:8080 \ -e GITHUB_TOKEN=ghp_xxx \ -e LLM_API_KEY=sk-xxx \ -e LLM_BASE_URL=https://api.your-llm-service.com/v1 \ -e LLM_MODEL=deepseek-chat \ -v /etc/hermes/config.yml:/app/config.yml \ hermes-review

启动之后，Hermes服务默认会在8080端口监听GitHub的webhook事件。接下来去GitHub仓库的Settings -> Webhooks页面，新增一个webhook，Payload URL填http://你的服务器地址:8080/webhook/github，Content type选application/json，事件只勾选Pull requests即可。

我可以直接说，自己第一次配置webhook的时候漏掉了最重要的一步：Secret。在GitHub创建webhook时填一个Secret，Hermes服务端会校验请求头的签名，防止别人伪造webhook请求。很多公网上的Hermes服务被拿到仓库权限，就是因为webhook没有配Secret，攻击者可以直接给服务端塞伪造的PR事件。

3.4 最小可用配置解析

Hermes跑起来需要两套配置：一套是服务端的连接配置（已经通过环境变量传了），另一套是每个仓库的代码评审规则，文件名叫.hermes.yml，放在仓库根目录。这个文件控制机器人在这个仓库里审什么、不审什么。我拆一个比较典型的最小配置：

# .hermes.yml 仓库根目录 version: 2 # 审查开关：当PR满足任一ignore条件时跳过 ignore: paths: - "package-lock.json" - "yarn.lock" - "*.min.js" - "dist/**" - "build/**" - "CHANGELOG.md" title_matches: - "^docs\\(.*\\):" - "^chore\\(release\\):" # 触发审查的事件 on: pull_request: opened: true synchronize: true reopened: true # 按文件类型配置语言 language_map: ".ts": typescript ".tsx": typescript ".js": javascript ".py": python ".go": go ".java": java # 评审等级控制 severity: error: ["blocking"] # error级别的问题会阻止合入 warning: ["critical", "suggestion"] # 大模型上下文窗口限制 analysis: max_diff_files: 20 # 单个PR最多分析文件数，超过则截断 max_lines_per_file: 500 # 单文件最多分析行数，超过部分跳过 max_comment_per_review: 15 # 单次review最多发表的评论数

这个配置文件里的每一项都能展开讲不少，我挑几个踩过坑的重点。ignore.paths这个配置非常实用。像package-lock.json、yarn.lock这种生成文件，在依赖升级的PR里动不动就是上千行diff，你不忽略掉，Hermes每回都要拿几千行流水账给大模型分析，钱花了，评论还全是噪音。真实场景里这个ignore列表应该是慢慢长出来的——每被某个PR气到一次，就加一条规则。

severity决定了机器人评审的“严格程度”，新接入的团队建议先全部用warning级别，跑一两周统计一下机器人的报错准确率，再逐步放宽对具体文件的分析。

3.5 GitHub Actions作为事件触发器

如果不想自己搭服务器接收webhook，还有一个更轻的做法：写一个GitHub Actions的workflow文件，在pull_request事件触发时直接跑Hermes CLI。这种方式对中小团队特别友好，因为跳过了一整层服务端部署。

# .github/workflows/hermes-review.yml name: Hermes PR Review on: pull_request: types: [opened, synchronize, reopened] jobs: review: runs-on: ubuntu-latest permissions: contents: read pull-requests: write issues: write steps: - name: Checkout uses: actions/checkout@v4 - name: Set up Node.js uses: actions/setup-node@v4 with: node-version: "20" - name: Install Hermes run: npm install -g @hermes/cli - name: Run Hermes Review env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} LLM_API_KEY: ${{ secrets.LLM_API_KEY }} LLM_BASE_URL: ${{ secrets.LLM_BASE_URL }} LLM_MODEL: ${{ secrets.LLM_MODEL }} run: | hermes review \ --repo ${{ github.repository }} \ --pr ${{ github.event.pull_request.number }} \ --post

这套配置还需要到仓库的Secrets里添加LLM_API_KEY、LLM_BASE_URL和LLM_MODEL三个变量。GITHUB_TOKEN不需要额外新建，workflow里直接用内置的就行，但要注意权限：在workflow文件里的permissions字段要显式声明pull-requests: write，否则GitHub默认只给只读权限，Hermes发评论会被拒绝。这个权限坑是我在配置Actions方案时遇到最多的报错来源，报错信息长得像Resource not accessible by integration，实际上就是权限没给够。

4. 玩法升级：规则定制、Prompt调优和review质量治理

4.1 让Hermes懂团队规范：规则文件不只是开关

.hermes.yml里那套配置只是基础框架，真正决定审查质量的是自定义规则。Hermes允许在配置里写custom_rules，每一条规则其实是一段给大模型的指令。比如你的团队要求“所有Python函数必须带类型注解”，你可以写一条这样的规则：

custom_rules: - id: PY_ANNOTATION_REQUIRED name: Python Typing Rules pattern: "def .*" message: > 此函数的参数和返回值必须添加类型注解。Python文件里的每个def 函数，如果参数或返回值没有类型注解，请报告为warning级别。 上下文如果是需要在函数内部动态推导类型并且无法简单标注的场景， 可以忽略本条规则，并说明原因。 severity: warning applies_to: - "**/*.py"

这种自定义规则的工作方式不是“正则匹配报错”，而是把规则描述作为系统提示的一部分给到大模型，让模型在阅读diff时判断是否命中。所以写规则的时候要注意：不能只写“必须做什么”，还要写清楚豁免场景。比如上面的类型注解规则，如果遇到装饰器包了一层导致注解无法解析的情况，模型如果没被告知豁免，就会死板地报一大堆“假阳性”意见。

我还强烈建议在配置里加入一个“自动带过”的规则白名单。像README修改、简单配置值调整这种改动，Hermes默认还是要跑一轮LLM分析，但这类PR真没什么好审的。配置一条：

skip_if: only_contains: - "**/*.md" - "README*" - ".gitignore"

这样PR里的改动如果只涉及文档类文件，仓库的workflow可以直接跳过Hermes，省时省token。

4.2 大模型review的提示词：质量差异的根源

Hermes虽然在部署上已经把大量逻辑做好了，但有一个可变因素完全掌握在使用者手里——传给大模型的提示词。Hermes支持在.hermes.yml里配置system_prompt覆盖默认的审查指令。

我一开始用默认提示词跑出来的结果偏“教科书式”——给出的建议倒是没错，但很多不贴合实际项目场景，怎么说呢，太学术了。后来我把system_prompt改成了下面这个样子，质量提了一截：

system_prompt: | 你是一个资深的前后端全栈代码评审专家，正在审查GitHub上的Pull Request。 你的审查重点是： 1. 只关注这个PR引入的实际变更，不要对未修改区域的既有代码提意见，除非这个PR逻辑会直接影响那部分代码的运行行为。 2. 优先报告会导致线上事故或功能异常的问题，其次才是代码风格、可维护性、性能优化建议。 3. 对每个问题必须说明“为什么这是问题”、在什么输入或场景下会触发，并给出最小修复建议。 4. 如果不确定或缺少上下文，宁可不说，也不要猜测性地丢一句“建议改成XX”。 5. 使用的语言跟随PR的commit message语言，如果commit是英文，评论用英文；如果commit是中文，评论用中文。

这个提示词解决了两个核心痛点：第一是上下文范围控制，默认情况下大模型很容易对没改动过的老代码“指指点点”，加了这个限制之后有效减少无关评论；第二是确定性，要求模型对没有把握的问题闭嘴不要瞎猜，机器人review最烦的就是说了十个问题，五个是误报，开发者以后就不看它的评论了。准确性永远大于数量。

4.3 三种审查输出的解读与配合

Hermes把review结果写到PR上的时候，是分三层的，这三层的信息密度从高到低排列：

• Inline comments：挂在diff的具体代码行旁边的评论，对应的是精确到代码行的问题。这类评论最适合开发者直接回复、讨论和修订。
• Review summary：在PR详情页的“Files changed”标签页上方给出的整体评审意见，包括对PR的综合评价（好坏、是否有风险点）、分类汇总的问题列表、以及优先处理的建议。这个建议很值得认真读，它是模型对本次改动“大方向”的判断。
• Check run：在PR底部的checks区域显示一个绿色的success或红色的failure。这个结果不会被普通开发者主动查看，但它可以接入branch protection规则——当Hermes的检查为failure时，PR就不能被merge。

从团队运营的角度，我建议把第三方human review和Hermes做任务切分：Hermes负责在代码层面拦截低级bug和规范问题，人类的approval负责业务正确性。在分支保护规则里，把Hermes的check设置为“必须通过”，同时保留至少1个human approver。这个双闸门模式团队接受度最高——没人会抱怨机器人太苛刻，因为它挑出来的问题通常是真的问题；同时人的权责也清晰，毕竟最终拍板的是人。

5. 真实部署中会遇到的问题和排查方法

5.1 GitHub API连接与权限报错

Hermes跑起来之后，第一类大概率遇到的是权限问题。常见报错和排查路径我列个表：

我遇到比较隐蔽的一个问题是：用GitHub App的方式接入时，虽然已经在App配置里给了权限，但在安装App到仓库时没有勾选对应仓库，或者仓库的settings页显示App已安装但实际上权限版本是旧的。这种问题排查起来最耗时间，因为日志里权限都是正常的，只是GitHub根本没把webhook推过来。检查的顺序应该是：先看仓库Settings -> GitHub Apps里App是否已安装，再看App的Webhooks页面有没有最近一次的delivery记录。

5.2 大模型API调用失败与超时

Hermes这类AI评审工具依赖外部大模型API，这一环出问题的方式五花八门：

• timeout/Connection timed out：服务器到模型API服务的网络不通。常见于自建机房部署、模型服务在国内而服务器在海外等场景。排查方法就是curl一下你配置的LLM_BASE_URL，看看是否直接返回数据。
• 401 Invalid API key：API密钥配置错误。检查环境变量有没有被正确加载，在配置里用了特殊字符的话，注意shell转义。
• 429 Rate limit exceeded：调用频率超限。这类最常出现在刚接入CI/CD、多个PR同时触发review的场景。缓解方案是把Hermes服务的内存缓存打开，同一个PR短时间内的重复推送不要重复调用模型；或者把workflow里加一个concurrency限制，同一PR只允许一个review任务在跑。

concurrency: group: hermes-review-${{ github.event.pull_request.number }} cancel-in-progress: false

加了这个concurrency配置之后，开发者连续往PR里push代码时，GitHub不会同时启动多个Hermes任务，节省了不少API配额，也避免了一个PR瞬间收到好几轮评论的尴尬。

5.3 审查质量相关的调优

如果跑了一段时间，你觉得机器人审得不好，问题不一定要归因于Hermes本身，很可能是配置的问题。排查思路按这个优先级来：

1. 看是不是模型选型的问题。同样一段代码，不同模型的代码理解能力差距非常大。如果用的是小型或偏对话的模型，它擅长闲聊不一定擅长代码diff分析。换一个偏代码方向的模型试试，往往效果提升最明显。

2. 看system_prompt是否约束住了模型。有没有明确要求模型只审变更行？有没有告知项目语言风格？没有这些约束，模型“自由发挥”的空间就很广，自然容易跑偏。

3. 看每次触发时传给模型的内容到底有多大。Hermes默认会把变更的代码包进prompt，但部分语言如果函数体特别大，模型在看到上下文的同时需要处理的代码行很多，会超出它的注意力窗口。遇到超大函数时，建议在analysis配置里把max_lines_per_file调低，让模型聚焦在“变更的代码块”而不是“整个文件”。

4. 看review结果是否经过过滤。Hermes内置了一个基于规则的“评论分类器”，它会根据大模型返回的消息格式、置信度评分、问题类型，过滤掉低质量评论。这个分类器如果是开关状态，试着打开；如果已经打开，可以调低confidence_threshold参数来减少误报。

5.4 接入初期常见的“评论风暴”

小组刚开始接Hermes的那一周，最容易出现的场面就是：一个PR进来，机器人一次性发了15条评论，开发者的PR通知都被刷屏了。这里要区分两种情况：如果评论确实是“真问题”，只是数量多，那说明项目的存量技术债比较重，要做的不是限流，而是让开发者分批处理。我在团队里定了一条“机器人评论分级处理”的规则：error级别的评论必须先解决才能merge；warning中critical的评论当周必须处理；suggestion类的评论可以在PR描述里回复“已读，暂不处理”并说明原因，机器人在后续review中不会重复提。

如果评论里混着大量的“假阳性”，比如模型的建议不符合项目实际使用的设计模式，那就要去补一条自定义规则告诉它：“本项目约定所有仓库层方法都返回Result对象而非抛出异常，如果代码中已经正确处理了Result，不要建议改为异常捕获。”这个调优过程是持续的，跑一个月之后，机器人的评论数量和噪音量会明显下降。

6. 实测效果：用数据看看Hermes到底值不值

接入Hermes两个月后，我做了一次简单的数据分析，把机器人review的数据导出来统计了一下。用的是GitHub API拉取的PR review时间线和评论数据，大概看一下几个指标的变化趋势：

• 机器人平均每次review提出的问题数从初期的12.4个/PR降到5.7个/PR，一方面是规则补全后误报减少，另一方面开发者确实把规范性问题和潜在隐患提前解决了，机器人能捞到的问题就少了。
• PR从“第一次提交”到“合并进主干”的中位时间从原来的18小时缩短到9.5小时。我分析主要原因不是代码改得快了，而是“无效评审循环”减少了——以前人工review经常花两三天才给反馈，现在机器人秒回，大部分问题在提交当天就被堵住了，不会到第二天才被review发现问题再打回修改。
• 引入Hermes之前，我们的bug中大概有一成是“历史代码回归导致”的，即改了一处旧逻辑，没注意到会影响别的调用点。接入之后这类bug明显减少了，原因是机器人review会结合变更代码的调用方上下文，对“疑似遗漏的调用方影响”给提示，这在人肉review时经常被忽略。

当然，我也要泼一盆冷水：Hermes不会神奇地把你们项目的bug清零。它更多的价值是把“一眼能发现的问题”自动化、常态化地处理掉，让本来被这些琐碎评审工作占据的人力释放出来，去认真思考真正的架构问题。建议把预期锚定在这上面，而不要想着“人工review的成本全省了”然后砍掉代码评审制度。

7. 一些给实操者的建议和避坑经验

7.1 别急着全量接入，先灰度跑两周

我见过太多团队接了一个自动化评审工具，第一天就打开全局分支保护，结果机器人的误报把所有人的工作节奏都搅乱了，第二天就被管理员下线。稳妥的方案是：先在非核心仓库灰度跑，或者用paths配置限定只review后端代码、先不review前端代码，跑两周看看问题和规则库该怎么调。等误报率降到团队能接受的范围，再扩展到核心仓库。

7.2 规则库要有人维护，不能只靠默认配置

自动化评审工具和静态检查工具一样，规则库是需要持续维护的资产。每个团队的项目特点、技术栈、编码约定的差异，靠默认配置根本cover不住。我在团队里让CI负责人每个月花半天时间过一遍机器人近一个月的“假阳性”案例，把集中的问题反映到规则库里。这样三个月后，这个工具对你们项目的适配度会越来高，而不是永远停留在“网上下的默认配置”。

7.3 用review文档沉淀团队知识

最后分享一个自己比较得意的小实践。我们把Hermes每次review生成的高质量建议（特别是那种包含完整场景分析、触发条件、修复代码的问题）直接同步到一个“代码评审知识库”文档里，按微服务模块和语言分类。新同学入职的时候看这个文档，比自己翻三个月PR学到的项目“暗坑”多得多——相当于把散落在无数次评审里的团队知识，变成了一个可以检索的技术资料库。这个衍生价值是在接入Hermes之前没有预料到的。