前段时间我把团队 PR 的评审流程重新捋了一遍最后在 CI 里给每个改动都加了一道由 open-code-review 负责的自动评审。说实话这个决定刚开始被同事当成偷懒机器看一眼怎么够 但三个月跑下来数据反而支撑住了这个方向首轮人工评审时长从平均 38 分钟降到了 20 分钟以内漏在代码里的低级错误也少了大半。这篇文章不是来吹AI 会取代 code review的。恰恰相反我想聊的是 open-code-review 这类开源工具在真实评审流程里到底应该站在哪个位置、怎么接、怎么配置、会踩哪些坑以及它和人工评审之间的边界到底在哪。如果你正要给团队搭一套开源 code review 辅助流程或者你只是一个人维护项目但希望 MR 被打开之前先有人把一眼能看出来的问题拦下来这篇文章应该能让你少走不少弯路。1. 先说结论open-code-review 解决的是评审里的常识过滤层1.1 人工评审的低效区间不在看不懂代码而在找一遍常识问题我带过的评审里真正消耗时间的从来不是架构讨论而是这类问题某处把生产环境的密钥直接写进了代码一个debugger语句被留在了主干变量名拼错了但整个团队看惯了所以没人提新接的 HTTP 客户端忘了设置超时时间一个改动同时改了格式、重构、业务逻辑reviewer 根本看不出重点。这些问题有个共同点它们不需要理解业务上下文只需要按规则对一遍。但人工做这件事非常不划算。评审者打开 diff 之后前二十分钟很可能都在机械地找这类低级问题等真正需要动脑子的业务逻辑讨论时注意力已经消耗得差不多了。这是 open-code-review 这类工具最值得站的位置它不应该替你做架构评审也不应该基于历史代码生成一堆建议优化性能的废话。它应该先帮人把常识错误这一层过滤掉让人的注意力留给真正需要人的部分。1.2 我理解的 open-code-review 不是机器人评审官之前我也试过几个商业代码评审服务用下来最别扭的地方是它们通常需要你把整个仓库推送到第三方服务器然后给你返回一大段看起来很有道理的评论。这听着很酷但实际落地时有两个问题。第一代码安全。很多团队没办法接受完整仓库被外部服务过一遍哪怕是有保密协议的商业服务审批流程也很麻烦。第二反馈太重。大模型特别喜欢把代码里所有可疑点全列出来50 行 diff 能给你提 30 条意见。你本来只想要人帮你看一眼有没有低级错误结果收到一篇论文。所以当我决定上开源方案时我对 open-code-review 的定位想得很清楚本地可执行、规则可配置、输出必须简短。它不是一个替你写代码的 AI它是一个把一眼就能看出来的问题自动标注出来的过滤器。人工评审仍然存在只是评审者不再需要从零开始。2. open-code-review 的核心工作流一条命令背后的四个模块2.1 先看一条命令我在本地跑的最基础命令长这样ocr check \ --base main \ --head feature/xxx \ --config .open-code-review.yml它会解析main到feature/xxx之间的 diff对每个变更块跑一遍内置规则然后把命中结果输出成结构化文本[ { rule: no-debugger, severity: warning, file: src/api/client.go, line: 88, message: debugger 语句被提交到主干 } ]如果什么都没命中输出就是空。这个设计我很喜欢因为它很容易接进 CI命令退出码、JSON 输出、Markdown 报告都可以作为后续流程的判断依据。2.2 四个核心模块拆开看open-code-review 能跑通靠的不是一个巨大的检查器而是下面这四块相互独立的逻辑模块负责的事常见问题Diff 解析器从 Git 历史中提取变更文件、变更块、新增行/删除行上下文不足导致规则误判规则引擎按配置逐条执行检查决定命中还是放过规则写得过宽或过窄评论生成器把命中结果整理为固定格式的评审意见格式不统一后续难以自动处理上下文聚合器收集本次改动涉及的函数、引用、配置文件关系只做文件级检查时会漏跨文件问题我把这四个模块单独拎出来说是因为很多刚开始用的人会在规则引擎上花太多时间却忽略了 Diff 解析器和上下文聚合器才是决定准确率的关键。比如一个规则要判断新增代码里是否调用了dangerouslySetInnerHTML如果 Diff 解析器只给规则一行一行的字符串规则根本不知道这行代码是不是在注释里、是不是在测试目录下。open-code-review 的做法是给每条规则传一个change对象里面包含文件路径、变更类型、原始代码块、当前代码块、行号等结构化信息。规则要判断的是变更内容而不是整份文件。2.3 为什么这套逻辑适合以开源方式落地当初选型的时候我也纠结过到底是自己写一套脚本还是直接用现成工具。自己写的优势是完全定制劣势是维护成本极高。代码评审规则不是写一次就完事的你会不断发现新坑某类正则误报太多、某个目录应该排除、某个内部框架有特殊写法。这些迭代如果都堆在一个人的脚本里三个月后就没人敢动了。open-code-review 这类开源项目的好处是它的核心框架是稳定的规则和配置是分离的。你不需要懂 Git 对象模型不需要自己解析 diff不需要处理不同平台的换行符差异只需要维护一份规则配置。框架升级你跟着升就行规则逻辑是你的资产不会被锁死在某个商业平台里。我当时还特意确认了一件事这工具是不是真的能在没有外网的情况下运行。答案是能。它不强制联网没有遥测所有检查都在本地进程里完成。这一点对很多内网开发环境来说很重要。3. 本地接入的完整过程从 clone 到第一次跑通3.1 安装别一上来就想跑满配open-code-review 的安装方式很简单我用了一个简单的二进制文件# 示例Go 安装方式 go install github.com/your-org/open-code-reviewv1.2.0 # 验证 ocr --version如果你是给别人做分享也可以直接从 release 页面拉对应平台的压缩包比如 Linux amd64 就是curl -sL \ https://github.com/your-org/open-code-review/releases/download/v1.2.0/ocr_linux_amd64.tar.gz \ | tar xz这里我给一个非常个人的建议第一次装的时候不要配任何自定义规则直接用默认配置跑一遍再说。原因很简单你连工具默认的行为边界都没摸清上来就写 20 条自定义规则后面只会分不清哪些误报是规则写错了、哪些是工具本身的问题。3.2 最小配置先把不想被管的地方写清楚我建议的最小配置不是一堆规则而是一份ignore清单和两条规则。一份合理的最小配置大概长这样version: 1 ignore: paths: - vendor/** - dist/** - node_modules/** - *.lock rules: no-debugger: pattern: debugger hardcoded-secret: pattern: (?i)(password|token|api_key)\\s*[:]\\s*\[^\]\ severity: error这份配置里的规则数量只有两条但已经能挡住不少最常见的低级问题。重要的是我一开始就把vendor和dist目录排除掉了。如果忽略清单不写清楚后续所有规则的误报率都会被人为放大因为你会在生成的构建产物里反复命中一堆无意义的检查结果。3.3 我第一次跑完的真实感受准确率可以但噪音要人工消第一次在真实仓库上跑默认规则命中了 70 多处。如果只看数量你会觉得这也太吵了。但仔细看下来真正值得处理的其实只有 20 多条剩下 40 多条全是需要排除目录、排除注释、排除测试代码的命中。这个比例我没觉得意外。代码检查工具第一天跑都是这个状态关键是你要有一套消化噪音的流程而不是因为噪音多就放弃。我当时的处理顺序是把明显不需要管的目录加进ignore.paths把命中场景太宽的规则降级从error改成warning给部分规则加上exclude条件比如测试目录内忽略某些规则把剩下真正有价值的命中逐条提交给对应负责人修复。这个过程花了一个下午。但之后的效果是持续的第二周开始新提的 PR 几乎不会再出现密钥或 debugger 这类问题。因为人可能会忘记检查但配置不会。4. 接到 CI让每个 PR 自动拿到第一轮意见本地跑通只是第一步真正让 open-code-review 产生价值的地方是 CI。我的目标很简单每次有人提 PR工具自动跑一遍在 PR 下面给出评论。如果发现error级别的问题直接让 CI 失败。4.1 一个最小可用的 GitHub Actions 工作流以 GitHub Actions 为例我用的工作流文件大概长这样name: open-code-review on: pull_request: types: [opened, synchronize] jobs: review: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkoutv4 with: fetch-depth: 0 - name: Run open-code-review id: ocr run: | curl -sL https://github.com/your-org/open-code-review/releases/download/v1.2.0/ocr_linux_amd64.tar.gz | tar xz ./ocr check \ --base origin/${{ github.event.pull_request.base.ref }} \ --head HEAD \ --config .open-code-review.yml \ --format markdown \ --output ocr-report.md echo exit$? $GITHUB_OUTPUT - name: Comment on PR if: always() uses: actions/github-scriptv7 with: script: | const fs require(fs); const body fs.readFileSync(ocr-report.md, utf8); if (body.trim().length 0) { await github.rest.issues.createComment({ issue_number: context.issue.number, owner: context.repo.owner, repo: context.repo.repo, body }); }这里有一个关键点fetch-depth: 0。如果不用fetch-depth: 0GitHub Actions 默认只拉取最后一次提交的代码ocr check --base origin/main根本拿不到完整历史diff 解析会直接失败或者给出一个不完整的对比结果。还有一个小细节我是后来才注意到的评论脚本里我用了if: always()因为它必须保证即使ocr返回非 0 退出码也能把报告写到 PR 评论里而不是只让 CI 静默失败。4.2 评论格式为什么非要用 Conventional Commentsopen-code-review 默认输出的是 Conventional Comments 格式这是它最开始吸引我的点之一。普通工具会直接输出一句这里有问题而它输出的是带标签的结构化意见:warning: [issue] 硬编码密钥可能被提交到仓库当然我实际用的是 Markdown 版本核心区别在于每条评论会带上类型标签| 类型 | 含义 | |---|---| | suggestion | 建议修改不强阻塞 | | issue | 必须处理阻塞合并 | | nitpick | 非功能性细节供参考 |为什么这个重要因为它让评论可以被程序化处理。我的 CI 里并没有把所有评论都当成阻塞项只有issue级别的规则命中才会让ocr check返回非 0。suggestion和nitpick只出现在 PR 评论里给人看不卡流程。如果没有统一的评论格式后面无论接机器人还是人工筛选都要重新做一轮文本解析成本就上去了。4.3 多平台接入时的差异如果你的代码库不在 GitHub而是在 GitLab 或者 Gitea 上流程大体一致但有两个坑要注意。第一个是 base 分支的获取方式。在 GitLab CI 里合并请求的ref和 GitHub 不太一样你需要在工作流里显式地去 la 取目标分支git fetch origin $CI_MERGE_REQUEST_TARGET_BRANCH_NAME第二个是评论接口。GitLab/Gitea 的 API 字段、权限模型各不相同你通常不能在 CI 里直接用github-script得换成对应平台的 action 或者用 API token 自己调。这时候 open-code-review 的输出标准化就派上用场了我只需要把同一个 JSON 报告转换一下就能适配不同平台。5. 规则设计决定工具值不值得留用的关键5.1 高价值规则长什么样跑了三个月后我发现真正值得保留的规则其实不是那种大而全的规则而是下面这四类类别示例为什么高价值安全底线硬编码密钥、http 明文链接、任意eval出了就是事故必须机器拦调试残留debugger、console.log、TODO 未清根源不是逻辑是流程遗漏依赖卫生锁文件未提交、依赖版本未固定改一次环境崩溃一片必须卡性能反模式循环内同步请求、N1 查询模式人工看 diff 很难发现机器可识别以硬编码密钥为例规则的匹配模式不能太天真。你不能只搜password否则会在文档、测试用例、示例代码里疯狂误报。后来我调整成只检查新增行且只检查赋值给变量的字符串字面量并排除测试目录和文档目录。这样误报率从 15% 降到了 2% 左右。5.2 我删掉的三类规则有保留必然有放弃。以下三类规则是我在真实使用后陆续删掉的第一类是纯代码风格规则比如单引号还是双引号、缩进用 2 空格还是 4 空格。这类问题完全应该交给 formatter 或 linter放进 code review 工具里只会制造噪音。第二类是没有上下文就必误报的规则。我一开始写了一条规则要求所有 HTTP 请求必须显式设置超时时间。结果内部有很多封装好的 SDK它们已经统一设置了超时每条未设置超时的调用其实都走的是封装层。工具不知道这层封装关系于是每 10 个命中里有 8 个是误报。第三类是结果无法被执行的规则。比如函数参数不要超过 5 个这种度量类规则。它可能真的是个问题但修复成本很高而且常常牵涉到重构不适合由机器在 PR 阶段直接拦住。这种规则更适合定期汇总成报告由团队决定要不要处理而不是阻塞合并。5.3 自己写规则的最小闭环open-code-review 的规则并不只是写个正则。它允许你写一个接收change对象、返回评论数组的脚本规则。我写了一个最小例子export function audit(ctx) { const comments []; for (const change of ctx.changes) { if (!change.file.endsWith(.js)) continue; if (!change.content.includes(eval()) continue; comments.push({ rule: no-eval, severity: error, file: change.file, line: change.line, message: 不建议直接调用 eval建议改用 new Function 或白名单匹配, }); } return comments; }这个规则只扫描变更里的新增行不会因为历史代码里的eval命中。这就避免了每次跑都报一堆历史问题的尴尬。我在写自定义规则时养成了一个习惯每写一条规则至少准备两个测试用例一个是必须命中的正例一个是不能命中的负例。比如不应该使用dangerouslySetInnerHTML这条规则正例是一行div.innerHTML userInput负例是文件里出现了这个字符串但它是注释或者它在测试用例里。测试负例的次数要占一半以上因为代码检查工具经常不是规则不够而是太能管了。6. 三个月下来的数据、边界与后续想做的事6.1 一组真实的变化数据把 open-code-review 接进流程三个月我记录了几个比较粗糙的数字指标接入前接入三个月后PR 首轮人工评审平均时长约 38 分钟约 19 分钟每周因低级错误被打回的 PR 数3-4 个0-1 个每条 PR 平均机器评论条数无12 条左右机器评论中实际被人工确认有效的比例无约 85%12 条看起来不少但拆开看大部分是suggestion级别的建议真正需要阻塞的issue平均只有 2-3 条。人工评审省下来的时间主要不是因为机器把意见全提了而是因为打开 PR 时常见的坑已经被标好了评审者可以直接进入这些意见有没有道理和业务逻辑有没有问题这两个更高价值的环节。6.2 它解决不了的事我必须强调open-code-review 解决不了以下这些问题它不理解业务语义。一个改动是不是符合需求、数据库字段命名和业务名词是否一致、统计逻辑有没有把用户群体算错这些它完全无能为力。它不适合做架构评审。比如这里是不是应该用事件驱动而不是直接调用内部 API这种问题工具只会看到表面的调用关系看不到团队对系统边界的约定。它也会产生新问题如果把规则写得过于严格会让团队形成反正 CI 会拦我提交前不看一眼的心态。这是流程设计上的风险需要用规则的分级和人工评审兜底来平衡。还有一个很实际的问题工具的规则覆盖不到那些你还没意识到是问题的问题。它只能按照已经定义好的规则去匹配所以它不是创新工具而是执行工具。真正的评审智慧仍然来自人。6.3 后续我想做的扩展接下来我想做两件事。第一是把规则按业务域拆成单独的文件。现在所有规则都堆在一个.open-code-review.yml里已经有点长了。我计划按security.yml、performance.yml、style.yml、team-practice.yml拆分然后在主配置里引入这样不同团队可以共用基础规则再各自叠加自己的团队实践。第二是做一份误报反馈周报。open-code-review 支持把未命中和误报的记录导出成 JSON我打算每周收集一次看看哪些规则在过去一周误报率最高判断它们要不要删除或优化。这比凭感觉调规则靠谱得多。如果你也在考虑给团队铺一套开源 code review 辅助流程我的建议很直接不要一开始就追求自动发现所有问题先把自己最近一个月在评审里提得最多的三类问题固化成规则跑起来再慢慢迭代。工具的意义不是替你思考而是把从思考到执行的重复劳动省下来让你更愿意把每一次评审都当成一次有价值的交流。
前段时间我把团队 PR 的评审流程重新捋了一遍最后在 CI 里给每个改动都加了一道由 open-code-review 负责的自动评审。说实话这个决定刚开始被同事当成偷懒机器看一眼怎么够 但三个月跑下来数据反而支撑住了这个方向首轮人工评审时长从平均 38 分钟降到了 20 分钟以内漏在代码里的低级错误也少了大半。这篇文章不是来吹AI 会取代 code review的。恰恰相反我想聊的是 open-code-review 这类开源工具在真实评审流程里到底应该站在哪个位置、怎么接、怎么配置、会踩哪些坑以及它和人工评审之间的边界到底在哪。如果你正要给团队搭一套开源 code review 辅助流程或者你只是一个人维护项目但希望 MR 被打开之前先有人把一眼能看出来的问题拦下来这篇文章应该能让你少走不少弯路。1. 先说结论open-code-review 解决的是评审里的常识过滤层1.1 人工评审的低效区间不在看不懂代码而在找一遍常识问题我带过的评审里真正消耗时间的从来不是架构讨论而是这类问题某处把生产环境的密钥直接写进了代码一个debugger语句被留在了主干变量名拼错了但整个团队看惯了所以没人提新接的 HTTP 客户端忘了设置超时时间一个改动同时改了格式、重构、业务逻辑reviewer 根本看不出重点。这些问题有个共同点它们不需要理解业务上下文只需要按规则对一遍。但人工做这件事非常不划算。评审者打开 diff 之后前二十分钟很可能都在机械地找这类低级问题等真正需要动脑子的业务逻辑讨论时注意力已经消耗得差不多了。这是 open-code-review 这类工具最值得站的位置它不应该替你做架构评审也不应该基于历史代码生成一堆建议优化性能的废话。它应该先帮人把常识错误这一层过滤掉让人的注意力留给真正需要人的部分。1.2 我理解的 open-code-review 不是机器人评审官之前我也试过几个商业代码评审服务用下来最别扭的地方是它们通常需要你把整个仓库推送到第三方服务器然后给你返回一大段看起来很有道理的评论。这听着很酷但实际落地时有两个问题。第一代码安全。很多团队没办法接受完整仓库被外部服务过一遍哪怕是有保密协议的商业服务审批流程也很麻烦。第二反馈太重。大模型特别喜欢把代码里所有可疑点全列出来50 行 diff 能给你提 30 条意见。你本来只想要人帮你看一眼有没有低级错误结果收到一篇论文。所以当我决定上开源方案时我对 open-code-review 的定位想得很清楚本地可执行、规则可配置、输出必须简短。它不是一个替你写代码的 AI它是一个把一眼就能看出来的问题自动标注出来的过滤器。人工评审仍然存在只是评审者不再需要从零开始。2. open-code-review 的核心工作流一条命令背后的四个模块2.1 先看一条命令我在本地跑的最基础命令长这样ocr check \ --base main \ --head feature/xxx \ --config .open-code-review.yml它会解析main到feature/xxx之间的 diff对每个变更块跑一遍内置规则然后把命中结果输出成结构化文本[ { rule: no-debugger, severity: warning, file: src/api/client.go, line: 88, message: debugger 语句被提交到主干 } ]如果什么都没命中输出就是空。这个设计我很喜欢因为它很容易接进 CI命令退出码、JSON 输出、Markdown 报告都可以作为后续流程的判断依据。2.2 四个核心模块拆开看open-code-review 能跑通靠的不是一个巨大的检查器而是下面这四块相互独立的逻辑模块负责的事常见问题Diff 解析器从 Git 历史中提取变更文件、变更块、新增行/删除行上下文不足导致规则误判规则引擎按配置逐条执行检查决定命中还是放过规则写得过宽或过窄评论生成器把命中结果整理为固定格式的评审意见格式不统一后续难以自动处理上下文聚合器收集本次改动涉及的函数、引用、配置文件关系只做文件级检查时会漏跨文件问题我把这四个模块单独拎出来说是因为很多刚开始用的人会在规则引擎上花太多时间却忽略了 Diff 解析器和上下文聚合器才是决定准确率的关键。比如一个规则要判断新增代码里是否调用了dangerouslySetInnerHTML如果 Diff 解析器只给规则一行一行的字符串规则根本不知道这行代码是不是在注释里、是不是在测试目录下。open-code-review 的做法是给每条规则传一个change对象里面包含文件路径、变更类型、原始代码块、当前代码块、行号等结构化信息。规则要判断的是变更内容而不是整份文件。2.3 为什么这套逻辑适合以开源方式落地当初选型的时候我也纠结过到底是自己写一套脚本还是直接用现成工具。自己写的优势是完全定制劣势是维护成本极高。代码评审规则不是写一次就完事的你会不断发现新坑某类正则误报太多、某个目录应该排除、某个内部框架有特殊写法。这些迭代如果都堆在一个人的脚本里三个月后就没人敢动了。open-code-review 这类开源项目的好处是它的核心框架是稳定的规则和配置是分离的。你不需要懂 Git 对象模型不需要自己解析 diff不需要处理不同平台的换行符差异只需要维护一份规则配置。框架升级你跟着升就行规则逻辑是你的资产不会被锁死在某个商业平台里。我当时还特意确认了一件事这工具是不是真的能在没有外网的情况下运行。答案是能。它不强制联网没有遥测所有检查都在本地进程里完成。这一点对很多内网开发环境来说很重要。3. 本地接入的完整过程从 clone 到第一次跑通3.1 安装别一上来就想跑满配open-code-review 的安装方式很简单我用了一个简单的二进制文件# 示例Go 安装方式 go install github.com/your-org/open-code-reviewv1.2.0 # 验证 ocr --version如果你是给别人做分享也可以直接从 release 页面拉对应平台的压缩包比如 Linux amd64 就是curl -sL \ https://github.com/your-org/open-code-review/releases/download/v1.2.0/ocr_linux_amd64.tar.gz \ | tar xz这里我给一个非常个人的建议第一次装的时候不要配任何自定义规则直接用默认配置跑一遍再说。原因很简单你连工具默认的行为边界都没摸清上来就写 20 条自定义规则后面只会分不清哪些误报是规则写错了、哪些是工具本身的问题。3.2 最小配置先把不想被管的地方写清楚我建议的最小配置不是一堆规则而是一份ignore清单和两条规则。一份合理的最小配置大概长这样version: 1 ignore: paths: - vendor/** - dist/** - node_modules/** - *.lock rules: no-debugger: pattern: debugger hardcoded-secret: pattern: (?i)(password|token|api_key)\\s*[:]\\s*\[^\]\ severity: error这份配置里的规则数量只有两条但已经能挡住不少最常见的低级问题。重要的是我一开始就把vendor和dist目录排除掉了。如果忽略清单不写清楚后续所有规则的误报率都会被人为放大因为你会在生成的构建产物里反复命中一堆无意义的检查结果。3.3 我第一次跑完的真实感受准确率可以但噪音要人工消第一次在真实仓库上跑默认规则命中了 70 多处。如果只看数量你会觉得这也太吵了。但仔细看下来真正值得处理的其实只有 20 多条剩下 40 多条全是需要排除目录、排除注释、排除测试代码的命中。这个比例我没觉得意外。代码检查工具第一天跑都是这个状态关键是你要有一套消化噪音的流程而不是因为噪音多就放弃。我当时的处理顺序是把明显不需要管的目录加进ignore.paths把命中场景太宽的规则降级从error改成warning给部分规则加上exclude条件比如测试目录内忽略某些规则把剩下真正有价值的命中逐条提交给对应负责人修复。这个过程花了一个下午。但之后的效果是持续的第二周开始新提的 PR 几乎不会再出现密钥或 debugger 这类问题。因为人可能会忘记检查但配置不会。4. 接到 CI让每个 PR 自动拿到第一轮意见本地跑通只是第一步真正让 open-code-review 产生价值的地方是 CI。我的目标很简单每次有人提 PR工具自动跑一遍在 PR 下面给出评论。如果发现error级别的问题直接让 CI 失败。4.1 一个最小可用的 GitHub Actions 工作流以 GitHub Actions 为例我用的工作流文件大概长这样name: open-code-review on: pull_request: types: [opened, synchronize] jobs: review: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkoutv4 with: fetch-depth: 0 - name: Run open-code-review id: ocr run: | curl -sL https://github.com/your-org/open-code-review/releases/download/v1.2.0/ocr_linux_amd64.tar.gz | tar xz ./ocr check \ --base origin/${{ github.event.pull_request.base.ref }} \ --head HEAD \ --config .open-code-review.yml \ --format markdown \ --output ocr-report.md echo exit$? $GITHUB_OUTPUT - name: Comment on PR if: always() uses: actions/github-scriptv7 with: script: | const fs require(fs); const body fs.readFileSync(ocr-report.md, utf8); if (body.trim().length 0) { await github.rest.issues.createComment({ issue_number: context.issue.number, owner: context.repo.owner, repo: context.repo.repo, body }); }这里有一个关键点fetch-depth: 0。如果不用fetch-depth: 0GitHub Actions 默认只拉取最后一次提交的代码ocr check --base origin/main根本拿不到完整历史diff 解析会直接失败或者给出一个不完整的对比结果。还有一个小细节我是后来才注意到的评论脚本里我用了if: always()因为它必须保证即使ocr返回非 0 退出码也能把报告写到 PR 评论里而不是只让 CI 静默失败。4.2 评论格式为什么非要用 Conventional Commentsopen-code-review 默认输出的是 Conventional Comments 格式这是它最开始吸引我的点之一。普通工具会直接输出一句这里有问题而它输出的是带标签的结构化意见:warning: [issue] 硬编码密钥可能被提交到仓库当然我实际用的是 Markdown 版本核心区别在于每条评论会带上类型标签| 类型 | 含义 | |---|---| | suggestion | 建议修改不强阻塞 | | issue | 必须处理阻塞合并 | | nitpick | 非功能性细节供参考 |为什么这个重要因为它让评论可以被程序化处理。我的 CI 里并没有把所有评论都当成阻塞项只有issue级别的规则命中才会让ocr check返回非 0。suggestion和nitpick只出现在 PR 评论里给人看不卡流程。如果没有统一的评论格式后面无论接机器人还是人工筛选都要重新做一轮文本解析成本就上去了。4.3 多平台接入时的差异如果你的代码库不在 GitHub而是在 GitLab 或者 Gitea 上流程大体一致但有两个坑要注意。第一个是 base 分支的获取方式。在 GitLab CI 里合并请求的ref和 GitHub 不太一样你需要在工作流里显式地去 la 取目标分支git fetch origin $CI_MERGE_REQUEST_TARGET_BRANCH_NAME第二个是评论接口。GitLab/Gitea 的 API 字段、权限模型各不相同你通常不能在 CI 里直接用github-script得换成对应平台的 action 或者用 API token 自己调。这时候 open-code-review 的输出标准化就派上用场了我只需要把同一个 JSON 报告转换一下就能适配不同平台。5. 规则设计决定工具值不值得留用的关键5.1 高价值规则长什么样跑了三个月后我发现真正值得保留的规则其实不是那种大而全的规则而是下面这四类类别示例为什么高价值安全底线硬编码密钥、http 明文链接、任意eval出了就是事故必须机器拦调试残留debugger、console.log、TODO 未清根源不是逻辑是流程遗漏依赖卫生锁文件未提交、依赖版本未固定改一次环境崩溃一片必须卡性能反模式循环内同步请求、N1 查询模式人工看 diff 很难发现机器可识别以硬编码密钥为例规则的匹配模式不能太天真。你不能只搜password否则会在文档、测试用例、示例代码里疯狂误报。后来我调整成只检查新增行且只检查赋值给变量的字符串字面量并排除测试目录和文档目录。这样误报率从 15% 降到了 2% 左右。5.2 我删掉的三类规则有保留必然有放弃。以下三类规则是我在真实使用后陆续删掉的第一类是纯代码风格规则比如单引号还是双引号、缩进用 2 空格还是 4 空格。这类问题完全应该交给 formatter 或 linter放进 code review 工具里只会制造噪音。第二类是没有上下文就必误报的规则。我一开始写了一条规则要求所有 HTTP 请求必须显式设置超时时间。结果内部有很多封装好的 SDK它们已经统一设置了超时每条未设置超时的调用其实都走的是封装层。工具不知道这层封装关系于是每 10 个命中里有 8 个是误报。第三类是结果无法被执行的规则。比如函数参数不要超过 5 个这种度量类规则。它可能真的是个问题但修复成本很高而且常常牵涉到重构不适合由机器在 PR 阶段直接拦住。这种规则更适合定期汇总成报告由团队决定要不要处理而不是阻塞合并。5.3 自己写规则的最小闭环open-code-review 的规则并不只是写个正则。它允许你写一个接收change对象、返回评论数组的脚本规则。我写了一个最小例子export function audit(ctx) { const comments []; for (const change of ctx.changes) { if (!change.file.endsWith(.js)) continue; if (!change.content.includes(eval()) continue; comments.push({ rule: no-eval, severity: error, file: change.file, line: change.line, message: 不建议直接调用 eval建议改用 new Function 或白名单匹配, }); } return comments; }这个规则只扫描变更里的新增行不会因为历史代码里的eval命中。这就避免了每次跑都报一堆历史问题的尴尬。我在写自定义规则时养成了一个习惯每写一条规则至少准备两个测试用例一个是必须命中的正例一个是不能命中的负例。比如不应该使用dangerouslySetInnerHTML这条规则正例是一行div.innerHTML userInput负例是文件里出现了这个字符串但它是注释或者它在测试用例里。测试负例的次数要占一半以上因为代码检查工具经常不是规则不够而是太能管了。6. 三个月下来的数据、边界与后续想做的事6.1 一组真实的变化数据把 open-code-review 接进流程三个月我记录了几个比较粗糙的数字指标接入前接入三个月后PR 首轮人工评审平均时长约 38 分钟约 19 分钟每周因低级错误被打回的 PR 数3-4 个0-1 个每条 PR 平均机器评论条数无12 条左右机器评论中实际被人工确认有效的比例无约 85%12 条看起来不少但拆开看大部分是suggestion级别的建议真正需要阻塞的issue平均只有 2-3 条。人工评审省下来的时间主要不是因为机器把意见全提了而是因为打开 PR 时常见的坑已经被标好了评审者可以直接进入这些意见有没有道理和业务逻辑有没有问题这两个更高价值的环节。6.2 它解决不了的事我必须强调open-code-review 解决不了以下这些问题它不理解业务语义。一个改动是不是符合需求、数据库字段命名和业务名词是否一致、统计逻辑有没有把用户群体算错这些它完全无能为力。它不适合做架构评审。比如这里是不是应该用事件驱动而不是直接调用内部 API这种问题工具只会看到表面的调用关系看不到团队对系统边界的约定。它也会产生新问题如果把规则写得过于严格会让团队形成反正 CI 会拦我提交前不看一眼的心态。这是流程设计上的风险需要用规则的分级和人工评审兜底来平衡。还有一个很实际的问题工具的规则覆盖不到那些你还没意识到是问题的问题。它只能按照已经定义好的规则去匹配所以它不是创新工具而是执行工具。真正的评审智慧仍然来自人。6.3 后续我想做的扩展接下来我想做两件事。第一是把规则按业务域拆成单独的文件。现在所有规则都堆在一个.open-code-review.yml里已经有点长了。我计划按security.yml、performance.yml、style.yml、team-practice.yml拆分然后在主配置里引入这样不同团队可以共用基础规则再各自叠加自己的团队实践。第二是做一份误报反馈周报。open-code-review 支持把未命中和误报的记录导出成 JSON我打算每周收集一次看看哪些规则在过去一周误报率最高判断它们要不要删除或优化。这比凭感觉调规则靠谱得多。如果你也在考虑给团队铺一套开源 code review 辅助流程我的建议很直接不要一开始就追求自动发现所有问题先把自己最近一个月在评审里提得最多的三类问题固化成规则跑起来再慢慢迭代。工具的意义不是替你思考而是把从思考到执行的重复劳动省下来让你更愿意把每一次评审都当成一次有价值的交流。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
