代码评审这件事做过的都懂。平时大家手上的 PR 一个个涌进来既要看逻辑对不对又要留意安全隐患还要顺手把命名、边界条件这种小毛病揪出来。一个人一天能认真看完三五条 PR 就很不错了碰上那种上千行的大改动基本就是扫一眼标题就 merge。我一直想找一个能真正把“自动化代码评审”落地的方案而不是那种只跑一遍 lint 就号称自动审查的工具。后来我把 Hermes 接到 GitHub PR 审查流程里折腾出一套能自动拉 diff、按规则分析、再以机器人身份回帖的完整链路。这篇文章就把这套做法的拆解过程、配置细节和踩坑记录都写出来给打算自己做 PR 机器人或者正在选型的团队一点参考。这套方案适合什么人两类。一类是研发团队里负责工程质量、想减轻人工评审负担的工程师另一类是个人开源项目的维护者。前者可以用来做第一道防线把重复性问题在人工评审之前就过滤掉后者相当于雇了一个不要钱的“实习审查员”能帮你盯着每个 commit 的基本质量。下面所有内容都是基于常规的 GitHub 仓库、公开 API 和个人服务器部署来写的不需要特殊环境一台能跑 Python 的小机器就够。1. 先搞清楚 Hermes 在整套流程里到底扮演什么角色1.1 它不是 CI而是一个能调用工具的智能代理很多人一听说“自动化代码审查”第一反应是接一个 CI 脚本在 GitHub Actions 里跑eslint、golint这类静态检查工具。这类工具确实有用但它们只能做语法、风格层面的规则匹配根本理解不了业务逻辑。比如一个 API 返回字段改了但前端对应解析没更新这类跨文件、跨模块的问题静态检查工具永远发现不了。Hermes 在这里的角色不是替代 lint而是站在 lint 的上层充当一个能“读懂代码意图”的智能代理。它可以被理解成一个自带工具集的大脑工具集负责拉取 PR 详情、获取 diff、读取相关文件、提交审查评论大脑则负责分析这些内容并给出判断。也就是说Hermes 的能力边界取决于你给它接什么工具、给它什么指令这也是它和固定规则 CI 的本质区别。我在实际使用中最看重的是 Hermes 的 Skill 机制。Skill 可以理解成给智能体预装的一套“职业技能包”。我给它注册了一个叫review-pr的技能这个技能把整个审查流程拆成了“获取PR→拆分diff→逐段分析→汇总结果→按规则过滤→提交评论”六个步骤。这样一来每次新 PR 进来Hermes 不用临时想怎么干而是直接调用这个技能按固定流程执行输出结果也相对稳定。1.2 为什么选择自建而不是直接用现成的机器人市面上有不少现成的 PR 审查机器人像 Sourcery、CodeRabbit 这些我也试过。它们开箱即用界面很漂亮但问题也随之而来第一它们的审查逻辑是黑盒团队规范没法深度定制第二它们大多有按量计费对一个高频提交的团队来说成本不低第三最关键的它们部署在别人服务器上代码提交到一个第三方平台很多公司和团队过不了保密这道关。自建 Hermes 审查服务的好处就是可控。代码完全在自己手里审查规则自己写LLM 模型可以接内部的、也可以接云端的审查记录可以沉淀到自己数据库。坏处嘛就是前期要花一些精力配置。不过对做过了一两个 API 对接的开发者来说这套东西其实不复杂主要就是处理三个环节GitHub 侧的事件通知、Hermes 的核心分析逻辑、以及回传评论的 API 调用。我一开始也是抱着“试试看”的心态搭的结果跑通之后发现收益远超预期。以前一个 PR 从提交到人工评审结束可能要等大半天现在 Hermes 在 PR 打开后两三分钟内就能给出第一轮意见而且那些“空指针风险”“密码硬编码”“缺少超时控制”这类低级问题它几乎一抓一个准。2. 整体架构与工作流程拆解2.1 一个“读得懂代码”的代理需要哪些部件这套审查体系架构上分四个部分缺一个都不行。第一部分是触发层。GitHub 仓库需要配置一个 webhook监听pull_request事件的opened、synchronize和ready_for_review三种动作。也就是说PR 刚创建、提交了新 commit、或者由 draft 转为正式可审时GitHub 会向我们的服务发一个 POST 请求。有人可能会问为什么不用 GitHub Actions 触发因为 Actions 跑完就销毁结果不好存而且每次冷启动慢还要处理 runner 环境。用独立的常驻服务审查状态可以保留在内存或数据库里方便后续查历史、做统计。第二部分是执行层也就是 Hermes 本体。它的核心工作是接收事件内容解析出仓库地址和 PR 编号然后调用 GitHub API 拉取完整 diff。这一步要注意的是GitHub 的 webhook payload 里并不包含完整 diff只有一个diff_url字段需要服务端主动去请求。第三部分是分析层。diff 拿到手之后Hermes 会先把文件按类型分组、按改动量排序然后对代码片段做预处理再交给大模型做语义评审。这个环节里我同时保留了一套轻量级规则引擎用正则和简单的 AST 扫描先过滤掉明显问题比如硬编码的密钥、console.log 残留、缺少 copyright 头等。这样能省不少 LLM 的调用成本因为很多低级问题不需要大模型“动脑子”。第四部分是反馈层。分析结果经过过滤、去重、按严重程度排序之后Hermes 调用 GitHub 的 API在对应 PR 的 diff 对应行上留下 review comment同时在 PR 页面生成一个总体的 review summary。2.2 PR 进来之后Hermes 内部到底跑了一遍什么我直接说我实现里的处理流程这个流程是在review-pr技能里配置好的整个逻辑核心是状态机。第一步校验事件。服务收到 webhook 后先校验 signature防伪。然后看 action 是不是我们关心的三种不是就直接丢弃。第二步拉取上下文。调用GET /repos/{owner}/{repo}/pulls/{number}拿 PR 的基础信息包括标题、描述、base 分支、head 分支。再调用GET /repos/{owner}/{repo}/pulls/{number}/files拿文件级 diff。这里我做了一个分页处理一次最多拿 30 个文件超过的话标记 “only first 30 files reviewed”避免大 PR 把内存打爆。第三步分层分析。先跑规则引擎把能正则匹配的问题收集成 pre-issues。然后按文件把 diff 切成多个片段每个片段大概在 200 行以内连同项目上下文一起发给 LLM。项目上下文包含当前仓库的 README 摘要、常用目录结构、以及我们团队的质量规范摘要这些内容会预先通过 Hermes 的文档工具加载到上下文里。第四步聚合与过滤。LLM 返回的结果是结构化的 JSON每个问题包含文件、行号、严重级别、类别、描述、修改建议。聚合阶段做两件事一是按文件行号去重把规则引擎和大模型发现的重复问题合并二是按严重级别过滤比如info级别的不上屏只保留warning及以上。第五步提交评审。调用 GitHub 的POST /repos/{owner}/{repo}/pulls/{number}/reviews以机器人的身份提交一条COMMENT类型的 review下面挂一串分行的评论。这里比逐条提交 comment 好因为会合并成一个 review 记录PR 页面上不会刷屏而且后续可以整条撤回。2.3 为什么非要先规则扫描再大模型分析这是整个方案里我自己最满意的一个设计决定多说两句。一开始我也图省事把所有代码都丢给大模型让它自己发现问题。实验了一个星期发现两个问题一是贵每轮 PR 平均要调 20 多次模型token 消耗感人二是慢同一个 500 行的 PR如果全部丢给模型动辄要两分钟才能出结果开发者在旁边等得着急。后来我改成“规则引擎先扫、大模型后判”的串行模式。纯规则引擎处理那些高确定性的问题绝不手软比如密钥泄露、eval()使用、关闭了 TLS 校验、debug 日志输出这么几类。这类问题模式固定、命中率极高、误报极少根本不需要 LLM 出场。规则扫完之后剩下那些规则覆盖不到、但需要语义理解的逻辑问题比如“这个循环里调了外部 API 但没有错误处理”“这个函数改了返回值但调用方没有同步调整”再交给大模型去判断。这个分层让成本大概降了 60%而且响应速度从两分钟降到了 20 秒左右。规则命中之后立即生成结果只有“需要动脑”的部分才走模型。这个思路不局限于 PR 审查任何用大模型做代码分析的场景都建议参考能靠规则的绝不让模型猜让模型把所有精力集中在真正需要理解的地方。3. 从零开始部署 Hermes 审查服务3.1 需要准备的账号、令牌和服务器在动手写代码之前先把权限和基础设施理清楚。这一步省事的代价是后期反复调试我吃过亏所以特别说下。GitHub 侧的东西正确的做法是创建一个 GitHub App而不是直接用个人 Access Token。GitHub App 的好处有三个权限是仓库级的可以精确指定只读 pull requests安装了之后可以收取 webhook可以以机器人身份提交评论不会占用个人账号的操作记录。创建位置在 GitHub 开发者设置里的 GitHub Apps权限需要配置权限项访问级别说明Pull requestsRead write读取 PR 详情、diff、提交评论ChecksRead-only读取检查状态后续可扩展ContentsRead-only获取仓库文件内容Webhooks由 App 配置接收 PR 事件创建好之后GitHub 会给你一个 App ID 和一个私钥文件私钥用来生成 installation token。这里有个关键点GitHub App 调用 API 时不能用私钥直接访问而是要用私钥签发一个 JWT再用 JWT 去换取 installation token。这一步很多教程没写清楚导致很多人卡在 401 上。换 token 的流程是POST /app/installations/{installation_id}/access_tokens # headers 里带 JWTinstallation_id 可以通过GET /app/installations查询也可以在你安装 App 之后从 webhook 事件里拿。LLM 侧我接的是 DeepSeek 的 API主要考虑的是上下文长度和成本比。Hermes 本身也支持其他 OpenAI 兼容的模型如果你想完全本地化也可以接 vLLM 起的模型服务。我这里说一下为什么选了 DeepSeek审查代码需要比较大的上下文窗口毕竟 diff 片段多上下文不够长就得频繁切分切得太碎又会丢失跨文件关联。DeepSeek 在长上下文和代码理解上的表现实际测试下来是满足要求的而且它的定价比那些通用旗舰模型便宜不少按我们每天几十条 PR 的量一个月账单也就是一杯咖啡的钱。服务器我用的是一台 2C4G 的 Linux 小机器系统是 UbuntuPython 3.11。不需要 GPU因为大模型推理都在云端 API 完成。部署的时候用 systemd 拉一个常驻服务就够了不需要 K8s也不需要 Docker Compose简单的东西别搞复杂。3.2 安装 Hermes 并初始化配置Hermes 的安装方式官方提供了 pip 包。我以 Python 环境为例命令顺手贴出来# 创建虚拟环境避免污染系统 Python python3 -m venv /opt/hermes-venv source /opt/hermes-venv/bin/activate # 安装核心包 pip install hermes-agent # 建工作目录 mkdir -p /opt/hermes-pr-reviewer/skills cd /opt/hermes-pr-reviewer装好之后先初始化配置文件。Hermes 会读取一个叫hermes.yaml的全局配置以及一个.env文件来加载密钥。我建议把密钥写在.env不要把密钥提交到任何仓库里。# .env 内容示例 GITHUB_APP_ID123456 GITHUB_APP_PRIVATE_KEY_PATH/opt/hermes-pr-reviewer/private-key.pem GITHUB_WEBHOOK_SECRETyour_webhook_secret LLM_API_KEYsk-xxxxx LLM_BASE_URLhttps://api.deepseek.com/v1 LLM_MODELdeepseek-chat这里GITHUB_WEBHOOK_SECRET是你创建 GitHub App 时随便填的一个随机字符串webhook 回调时 GitHub 会用它签发签名服务端要用它来校验事件真实性防止伪造请求。然后编辑hermes.yaml这里指定了 Hermes 要加载哪些技能、模型参数、以及审查策略相关的环境变量别名。我给的配置比较简单agent: name: hermes-pr-reviewer model: provider: openai base_url: ${LLM_BASE_URL} api_key: ${LLM_API_KEY} model: ${LLM_MODEL} temperature: 0.2 skills_dir: ./skills max_tokens_per_call: 40003.3 编写 review-pr 这个技能的核心逻辑Hermes 的技能本质上是一个工具描述 一个执行入口。工具描述用来告诉模型“这个技能能干什么、什么时候调用”执行入口则是一段代码。我这里用 Python 写了一个精简版本的处理器逻辑是拉取 PR 文件列表、拿到 diff、调用分析函数。# skills/review_pr/handler.py import os import httpx from hermes.sdk import BaseSkill class ReviewPrSkill(BaseSkill): name review_pr def handle(self, payload: dict): owner payload[repository][full_name].split(/)[0] repo_name payload[repository][full_name].split(/)[1] pr_number payload[pull_request][number] # 获取 installation token token self.gh.get_installation_token() # 拉取 PR 的文件列表 headers { Authorization: fBearer {token}, Accept: application/vnd.githubjson } url fhttps://api.github.com/repos/{owner}/{repo_name}/pulls/{pr_number}/files files self._paginate(url, headers, per_page30) # 对每个文件做规则扫描 LLM 推理 issues [] for f in files: patch f.get(patch) if not patch: continue issues.extend(self._scan_with_rules(f, patch)) # 聚合、过滤、提交 review final_issues self._aggregate(issues) self._submit_review(owner, repo_name, pr_number, final_issues) return {status: ok, issues: len(final_issues)}这段代码省去了中间很多内部函数但核心链路是清楚的。_scan_with_rules里我放了几组正则比如检测公钥私钥、检测 API key、检测明文密码import re RULES [ { name: hardcoded_secret, pattern: r(?i)(api[_-]?key|secret|password|token)\s*[:]\s*[\][A-Za-z0-9_\-]{16,}[\], severity: error, category: security }, { name: eval_usage, pattern: r\beval\s*\(, severity: warning, category: security }, { name: debug_log_residue, pattern: rconsole\.(log|debug)\s*\(, severity: info, category: style } ] def _scan_with_rules(self, file_obj, patch): findings [] filename file_obj[filename] for rule in RULES: for match in re.finditer(rule[pattern], patch): start_line _patch_line_to_real_line(patch, match.start()) findings.append({ path: filename, line: start_line, severity: rule[severity], category: rule[category], message: f{rule[name]} 规则命中, suggestion: 请移除敏感信息改用环境变量注入 }) return findings_patch_line_to_real_line需要解析 diff 里的行号映射关系这个函数不复杂但容易写错简单说就是把 diff 中开头的行号累加映射到实际文件行号。注意diff 的 hunk header 里有 -start,count start,count 我们要取start作为基准然后对 patch 内容逐行累加。3.4 启动服务接上 GitHub webhookSkills 写完之后把整个服务启动起来。这里我用 Flask 写了很薄的一层 webhook 接收器# serve.py import hmac, hashlib, json from flask import Flask, request app Flask(__name__) SECRET os.environ[SIGNATURE_SECRET] from hermes import run_skill app.route(/hooks/pr, methods[POST]) def pr_webhook(): body request.get_data() signature request.headers.get(X-Hub-Signature-256, ) expected sha256 hmac.new(SECRET.encode(), body, hashlib.sha256).hexdigest() if not hmac.compare_digest(signature, expected): return invalid signature, 401 payload json.loads(body) event request.headers.get(X-GitHub-Event) if event pull_request: action payload.get(action) if action in (opened, synchronize, ready_for_review): # 异步处理避免 webhook 超时 from threading import Thread Thread(targetrun_skill, args(review_pr, payload), daemonTrue).start() return ok, 200跑起来source /opt/hermes-venv/bin/activate nohup python serve.py /var/log/hermes-pr.log 21 然后回 GitHub App 配置 webhook 地址https://your-domain.example.com/hooks/pr勾选 Pull requests 事件。GitHub 有个特性和安全策略我特别提醒一句webhook 地址必须是公网可访问的 HTTPS 或 http://localhost如果服务器没有公网 IP 或域名可以用内网穿透工具临时测试但生产环境建议用代码托管平台自带的 Actions 或自有公网服务。这里不展开内网穿透的具体细节了自己搭的话注意合规。测的时候随便开一个测试分支改一个文件提一个 PR观察服务日志。如果一切正常日志里应该出现review submitted之类的记录GitHub 页面上会出现机器人头像的 review。4. 核心评审逻辑怎么让大模型输出真正有用的意见4.1 提示词里必须指明“要什么”和“不要什么”部署通了之后真正的核心在于大模型评审这一段。很多自建 PR 机器人效果差问题往往就出在提示词写得太泛。你不告诉模型你的代码规范是什么、你关心哪几类问题它就会给出一堆“可以进一步优化代码质量”这种正确的废话。我的提示词经过了好几轮迭代最后稳定在下面这个结构。系统提示词里写清楚角色定位、审查范围、输出格式和禁忌你是一名资深代码审查员擅长发现真实的缺陷和安全隐患。 审查范围仅限 diff 中修改的行。 必须按照 JSON 格式输出每个 issue 包含 path、line、severity、category、message、suggestion。 严重级别定义 - error会引入线上故障、存在安全漏洞或明显逻辑错误 - warning存在潜在风险或不符合团队规范建议修改 - info可选优化点不强制修改 注意事项 - 只输出确定的问题不确定的一律不输出 - 不要输出赞美或泛泛而谈的建议 - 每条建议必须结合具体代码不得只给空泛意见 - 如果 diff 太小或没有值得报告的问题返回空列表 []重点说一下severity和category的设计。当初我试过让模型自由发挥结果它输出什么都有有的把一个小命名问题标成 error有的把一个空指针隐患标成 info。后来我干脆在提示词里给了明确分级标准并且在解析结果时做二次校验凡是 severity 不在三个枚举值里的直接丢弃。这相当于给模型加了一道护栏保证输出可解析、可过滤、可排序。4.2 分块策略怎样让大模型既看得清又看得全一个 1000 行的 PR 不可能一次性发给模型上下文装不下模型也容易“忘掉”前面的文件内容。我试验了几种分块方式最后确定了一个最简单但效果最好的按文件粒度切分每个文件独占一次模型调用同时把仓库上下文放在每次调用的前置提示里。为什么按文件切而不是按 diff 的行数切因为按行硬切会把同一个函数的逻辑截成两半模型很难判断一个问题到底是 bug 还是跨块上下文缺失。按文件切虽然有的文件 diff 可能长达两三百行但模型看到的始终是一个完整的文件变更理解起来连贯得多。而且绝大多数 bug 都是在单文件内部就能看出来的跨文件的问题比例其实没那么高。如果遇到超长文件比如一次改了 500 行我会在切分时按照函数边界做二次切分。具体做法是先把文件内容解析成函数列表然后按函数切块每个块包含函数的完整实现和其对应 diff。这个过程可以用 Python 的ast模块做但只适用于 Python其他语言我退而求其次按空行和缩进级别粗暴切分。效果差一些但总比让模型读一半函数强。每次调用前我会固定拼上一段仓库背景比如仓库xxx/backend 语言Python 3.11 框架FastAPI 目录说明 - app/api/ 存放接口路由 - app/services/ 存放业务逻辑 - app/models/ 存放数据模型 评价规范接口错误必须返回统一错误码禁止在业务层直接拼接 SQL。这些信息是 Hermes 在做 pre-processing 时从仓库里自动拉取并生成摘要的不需要每次人工填写。如果你用 Hermes 的文档工具它甚至可以每次自动抓取 README 里“代码规范”那一节作为参考。这招对提升审查质量非常明显因为模型知道了仓库背景之后很多“为什么这么写”的问题它自己能推导出答案误报率直线下降。4.3 结果解析与严重程度校准模型返回的 JSON 字符串我用json.loads解析。实际开发中你会发现模型偶尔会输出非法 JSON比如多一个逗号、注释、或者在 JSON 前后多了反引号。我写了一个容错解析函数先尝试直接解析失败就剥离反引号代码块标记再解析再失败就用正则提取[{...}]片段。三重保证之后基本能覆盖 99% 的情况。解析之后还有一道硬过滤凡是line超出文件实际行数的丢弃凡是path不在本次 PR 变更文件列表里的丢弃凡是severity不在枚举里的丢弃。这三道过滤能把模型的“幻觉”挡掉不少虽然不能做到 100%但已经可以让误报率控制在可接受范围。这里再说一下严重程度校准策略。模型天然会高估问题严重性它会倾向于把什么都标成 error 来“表现得很认真”。我的做法是在聚合阶段强行做一个占比约束如果一轮 review 里 error 级别的问题占总问题数超过 30%就把多出来的 error 降为 warning。这么做听着不够“技术”但实际效果很好因为 error 级别在团队里会被当成必须处理的硬问题一旦太多会让人麻木反而不利于真正紧急的问题被关注。4.4 提交 review 时如何做到不刷屏、不招人烦这是最后一步但也是决定开发者愿不愿意用这个机器人的关键。一开始我的实现是一个问题提交一条 comment结果大 PR 一下冒出来 80 多条评论PR 页面直接被刷成聊天室开发者怨声载道。后来我改成一轮 review 汇总提交模式。也就是说不管发现了多少问题都作为一条review提交review 的 body 是总体摘要具体问题挂成 review comments。GitHub 的 review comments 可以指定position参数来锚定到 diff 的具体行这样问题之间有组织、不散乱开发者还可以在 GitHub 界面逐条回复、逐条解决。同时我做了一个“按严重级别限流”的配置error 级别不限制条数warning 级别每轮最多 15 条info 级别直接不上报。这样PR 页面最多看到的是一条 review 跟 20 来条评论信息密度高、可操作性强不会让人打开页面就崩溃。5. 常见问题与排查记录5.1 GitHub API 返回 401/403 怎么办这是我自己部署时遇到最多的一类问题基本都在鉴权环节。403 最常见的原因是 installation token 过期。GitHub App 的 installation token 有效期只有 1 小时如果服务常驻务必要实现 token 缓存的逻辑。我一开始偷懒每次启动时取一次 token然后无限使用结果跑了一个多小时后所有请求全部 403。后来改成了“凭证管理器”记录 token 的签发时间剩余时间小于 5 分钟就自动刷新。401 则多半是 GitHub App 私钥路径配置错或者 JWT 签发有误。JWT 签发格式网上资料不少我这里就强调一个容易错的地方JWT 的exp不能超过 10 分钟GitHub 对 JWT 的有效期卡得很严超过了才会报 401。还要注意iat必须是当前 Unix 时间戳不能差太多服务器时间不同步也会导致签名校验失败。5.2 PR 特别大请求超时怎么办有一次线上仓库来了个重构 PR改了 40 多个文件、2000 多行 diff。webhook 过来之后我的串行处理方式直接跑了 6 分钟请求超时GitHub 那边重试了三次结果服务端重复处理了三遍提交了三个重复 review特别尴尬。解决办法有两个一是把 webhook 接收和处理彻底异步化接收端只返回ok立刻把任务丢进队列后台慢慢处理。二是设置 PR 规模上限超过 30 个文件的 PR 只评审其中“核心文件”所谓核心文件就是改动量最大的前 10 个文件其余文件直接跳过。这两个方案我都用了现在哪怕 2000 行的大 PR也能在 3 分钟内完成只要不超过 3 分钟GitHub 重试机制就不会触发。5.3 大模型输出“没问题”但人眼一看就有 bug这种情况我也遇到过而且是最考验调优耐心的。你会发现模型偶尔会对着一个明显的逻辑错误说“代码看起来没问题”。排查下来原因基本有三个。第一是上下文截断模型没看到关键行。这个主要发生在 diff 超大、分块切太细的场景解决的思路是尽量按完整函数为单位切块宁可让模型的调用次数多一点也不要让它在信息不全的情况下“硬答”。第二是提示词里没有要求“逐行检查”模型跳过了某些行。我在提示词里加了一句强制指令你必须逐行阅读 diff每行都要经过“是否存在缺陷”的判断这个指令对降低漏报很有帮助。第三是模型确实没理解某个复杂逻辑这没法完全避免只能靠后面人工评审兜底。老老实实说Hermes 这种 LLM 审查做不到 100% 准确它适合当“第一道筛子”和“低级问题的守门员”绝不能替代有经验工程师的最终判断。5.4 误报太多团队成员开始无视机器人机器人刚上线那阵子我收到了大量“这是误报吧”的反馈。代码里本来的一个连接池参数机器人都能当成“魔法数字”来报警。后来我做了三件事才把误报率压下来。一是把原来“所有文件都审”改成“按风险分级审”。前端 CSS 改动、文档改动、自动生成文件的 PR 直接跳过只有涉及业务逻辑的代码文件才送给大模型深度评审。二是在提示词里补充了仓库特有的豁免规则比如我们有些地方就是故意用console.log做临时调试下一步版本会移除这种历史背景要让模型知道。三是引入“历史学习”如果某个规则连续 5 次命中且人工都不认可就自动调低该规则的优先级。这个我通过一个简单的评分表实现不用太复杂但能保证机器人的判断越来越贴近团队风格。6. 一些我的体会和后续想做的事其实回过头看这个项目的落地难度不算高真正花心思的地方是全流程的“可控性”设计权限怎么给、上下文怎么组织、输出怎么过滤、噪音怎么收敛。这些东西没有现成的开源方案能一步到位都需要结合自己团队的实际工作方式去磨。我最大的感受是自动化代码评审这件事重点不是让模型替人“拍板”而是帮人把该做但耗时的基础检查做掉让工程师能把时间留在真正需要经验和判断力的事情上。如果你现在也在做或者打算做类似的东西我建议从小处起步。先只接一个中小型仓库只对二三十个文件以内的 PR 做审查别一上来就全量铺开。先把误报压下来、把噪音降下去再逐步扩大评审范围。团队一旦觉得这个机器人靠谱它会成为你 PR 流程里离不开的一环。后面我还想再给它加两个能力一个是自动追踪上周发生的线上事故把事故涉及的代码文件加入重点审查清单另一个是让 Hermes 在给出意见之后能从候选的提交记录里学习团队实际采纳了哪些建议、拒绝哪些建议做行为层面的适配。这条路我还在折腾等跑通了再分享新的细节。
