企业官网建设流程全解析

做code review这件事，我见过太多团队从热情到摆烂的完整过程。刚推行的时候，大家规规矩矩提PR、等评审、逐行过diff；三个月之后，review就从“仔仔细细看逻辑”变成了“点个approved算给面子”。不是大家不想审，是真的挤不出时间——尤其当你的PR动不动就改十几个文件、几百行代码的时候，逐行看完再给出有效反馈，基本就是半天起步的时间成本。open-code-review这个项目，就是冲着这个痛点来的：它不是要替代人来做评审，而是用自动化检查把低级问题先筛掉，让评审者的注意力集中在真实需要人脑判断的设计、边界条件和业务逻辑上。

我在几个不同类型的项目里实际跑过这套工具，有内部业务系统，也有对外开源项目，落地效果差异很大，但总体的规律是一致的：凡是先把工具本身的定位搞清楚、再逐步调整规则的团队，review流畅度提升都很明显；凡是抱着“装个工具就能解决一切评审问题”的心态去用的团队，大概率用两次就丢在一边，还觉得这玩意不过如此。所以这篇文章，我会把open-code-review从设计思路、规则原理到实际运行的完整链路都拆开讲一遍，包括怎么接入CI、怎么写自定义规则、遇到误报怎么处理。适合正在被代码审查效率问题困扰的开发者，也适合打算在团队里推行规范评审制度的Tech Lead参考。

1. 先冷静聊聊代码审查到底卡在哪

1.1 人工审查的三个效率黑洞

先说第一个黑洞：上下文切换。写代码是一个连续的心理状态流，你脑子里装着当前任务的各种中间变量，比如“这个接口为什么这么设计”“这个边界条件为什么这么处理”。但当你切过去看别人的PR时，等于把这份状态全部清空，重新加载一块陌生代码的上下文。这个加载过程非常消耗精力，而且通常一天内会发生很多次。我观察过团队里的评审数据，大部分review评论集中在前5个文件，后面十几个文件基本是一扫而过。不是评审者偷懒，是认知资源真的有限。

第二个黑洞是重复劳动。你会发现每个PR里永远存在几类低级问题：命名不规范、魔法数字、未使用的变量、逻辑分支没有判空、异常被吞掉。这些问题并不需要多高深的设计能力才能发现，但它们会占用掉评审者大量的阅读时间。问题在于，同样是“花30秒写一条review评论”，评论“这个函数命名改成isValidated更准确”和评论“这里处理用户并发操作的幂等方案有问题”，两者的价值差距非常大。前者完全可以交给工具去提示，后者才是人脑应该参与的地方。

第三个黑洞是反馈时效。传统review流程里，你提了PR可能半天后才有人看，看完提出的修改意见可能还要再等一轮。这种低频反馈在多人协作里会放大问题，尤其是当多个PR互相依赖的时候，一个被卡住，后面一串都动不了。自动化检查如果能在push阶段就跑完并给出提示，很多低级返工在提交前就已经被拦住了。

1.2 工具补位：把“可自动化的”和“要动脑的”分开

所以我在设计open-code-review的时候，出发点是做“带宽放大器”，而不是做“评审替代品”。说白了，就是把人工评审里最机械、最重复的那部分工作抽出来，让工具在几秒内完成，人专注于真正需要理解力和判断力的部分。

具体来说，我把代码审查的内容分成了三类。

第一类是纯客观问题：格式、命名、未使用的变量、明显错误的缩进。这类问题文本编辑器其实已经可以拦截一部分，但跨文件、跨语言、跨PR场景的检查并不总能覆盖。open-code-review把这些做成可配置的规则。

第二类是半客观问题：函数复杂度、嵌套深度、魔法数字、空指针风险、异常吞没、硬编码配置等。这类问题需要结合代码上下文做一些分析，但判断标准是相对明确的。比如“函数认知复杂度超过15就应该拆一下”这样的阈值，是可以量化的。

第三类是主观设计问题：接口抽象是否合理、模块边界是否合适、业务逻辑是否有缺陷、性能方案是否得当。这类问题完全依赖人对业务和架构的理解，工具无论如何都替代不了，但工具可以辅助——比如标记出变更规模较大、改动文件较多的PR，提醒评审者重点看某些模块。

open-code-review的定位就是处理第一类和第二类，并对第三类提供辅助信息。

1.3 一个能跑起来的工具该有怎样的边界感

在动手写代码之前，我给这个项目定了四条设计边界，后来事实证明这些边界非常重要。

第一条，只报客观问题，不替人做审美判断。工具可以提示“这个函数过长”，但不会说“这段代码风格很糟糕”。后者缺乏明确的定义，容易出现误报，误报攒多了，信任感就崩了。

第二条，所有规则必须可解释。每一条提示都必须说明触发原因、问题级别、修改建议，最好再附上相关代码片段。没有上下文的问题提示，对评审者来说就是噪音。

第三条，要能增量分析，只审变更，不审整个项目。全量扫描虽然覆盖面广，但速度慢、噪音大，而且跟“本次PR改了什么”这个审查场景脱节。

第四条，规则可以关、可以调、可以加。因为不同团队的技术栈、代码风格、团队规模都不一样，一套演示级的默认规则不可能适配所有场景。所以从架构上就要把“规则”设计成可插拔的模块，而不是写死在Main里。

这四条边界，决定了整个项目的架构走向。

2. 整体架构与设计思路拆解

2.1 一次审查请求的生命周期

open-code-review的运行流程，我尽量设计得简单直接。整个过程可以拆成五步。

第一步，解析git仓库状态。工具会读取当前工作区的git元数据，确定审查范围。一般是拿两个commit做差集，比如对比origin/main和当前分支HEAD之间的变化，也可以是审查暂存区或者工作区未提交的改动。

第二步，提取diff内容。通过git diff命令拿到变更文件列表、增删行的具体内容，以及每个变更块在文件中的上下文信息。这一步是整个工具的数据基础。

第三步，把diff内容交给语言解析器。根据文件扩展名选择对应的解析器，将代码转成抽象语法树（AST）。解析过程只针对变更文件和这些文件的相关片段，避免全量扫描。

第四步，规则引擎依次执行所有启用的规则。每一条规则接收AST节点和变更上下文，输出问题记录。问题记录包含文件路径、行号、严重级别、消息文本和建议。

第五步，结果聚合与报告生成。所有问题记录按文件和级别聚合，统计出摘要信息，渲染成Markdown格式报告。同时设置退出码，方便CI流程判断本次审查是否通过。

整个过程中，前面的步骤都是互不依赖的纯函数式流程，后面扩展其他功能也比较方便。

2.2 技术栈选型：为什么是Python加AST

选Python其实没有太多纠结。第一，Python写CLI工具非常顺手，标准库够用，第三方生态成熟，团队里几乎人人都能看懂、能改。第二，Python内置的ast模块可以解析Python代码本身，写Python项目的检查规则几乎零成本。第三，对于非Python语言，我接了tree-sitter的Python绑定，可以解析JavaScript、TypeScript、Go、Java等主流语言。

这里有个关键决定：检查逻辑要构建在AST之上，而不是简单的正则匹配。

正则匹配看起来轻量，适合做快速预筛，比如找“TODO注释”或者“硬编码字符串”，但一旦涉及语义判断就会失灵。举个例子，你想检查“变量名是否是驼峰命名”，用正则去匹配代码文本很容易把字符串里的字母组合也算进去，或者误伤函数名、类名、注释里的文本。而AST把代码结构抽象成语法节点，可以准确地区分“变量声明”“函数定义”“函数调用”“字符串字面量”等不同语义，判断起来准确率高得多。

当然，AST解析也有成本。tree-sitter需要加载语法规则文件，对大型代码库做全量AST遍历内存开销不小。所以实际实现里我用了混合策略：轻量级的文本检查（比如禁止某个API、提示日志格式）用正则做第一轮过滤，只有通过预筛的内容才进入AST，做精确的语义判断。这样保证了单个文件的检查时间控制在几十毫秒级，一个几百个文件的PR整体检查也就一两秒。

2.3 规则引擎设计：一个规则就是一组判断逻辑

整个规则引擎的核心数据结构很简单，每个规则由三个部分组成：元信息、检查函数、报告器。

元信息描述规则的基本属性，包括规则名称、适用语言、默认级别、是否启用。检查函数负责接收AST节点和上下文对象，执行实际判断逻辑，返回是否触发问题。报告器把触发结果转成最终的用户提示，补充规则说明和修改建议。

技术上我用的是经典的责任链模式：一个规则列表依次执行，每个规则拿到AST节点后，只扫描跟自己相关的节点类型。比如检查异常吞没的规则只关注Try语句节点，检查函数长度的规则只关注函数定义节点，这样每条规则都保持简单，互不干扰。

规则的严重级别我分了三级。P0是必须处理的严重问题，比如明显的空指针风险、禁止的API调用、调试代码遗留。P1是建议处理的问题，比如函数过长、复杂度超阈值。P2是可选的优化建议，比如变量命名可改进、存在重复代码片段。评审的时候，评审者可以直接看P0和P1级别的报告，P2可以作为补充参考，不至于被噪音淹没。

2.3 规则引擎设计：一次检查的完整路径

具体到一次运行，规则引擎的执行过程是这样的。第一步，把从git diff拿到的变更文件按照语言分组，比如Python文件进ast解析器，JavaScript文件进tree-sitter解析器。第二步，对每个文件生成AST之后，工具会把diff中的变更行号映射到AST节点上——这一步很关键，因为只有变更行的节点才需要被规则检查，其他无关代码不进入检查范围。第三步，规则引擎遍历所有规则，在每个AST节点上调用规则对应的检查函数。第四步，收集问题记录，聚合结果。

这种做法的好处是，工具天然支持增量分析。无论整个代码库有多大，每次只检查变更涉及的节点，因此性能稳定。而且变更行号映射还能解决一个常见问题：同一个函数里，如果只改了其中一行，规则是应该提醒整个函数的问题，还是只提醒改动行的问题？我采用了一个折中策略——如果变更行在函数内部，就把该函数纳入检查范围，但报告时标记出变更行，让评审者知道这个问题和本次改动的关联性。如果函数的复杂度问题早就存在，不是本次引入的，也会单独标记成“既有问题”，避免让开发者觉得“我改一行你揪出整个函数的老问题”。

在规则执行完之后，结果聚合层会做三件事：按文件和行号排序，给同一条规则触发的多处问题做合并去重，以及生成一份变更摘要。变更摘要是给评审者看的快速入口——比如“本次变更涉及12个文件，其中3个文件存在P0级问题，建议优先查看”。这种方式比在几百行diff里慢慢翻要高效得多。

3. 核心规则集拆解与实现细节

3.1 认知复杂度检查：这条规则的标准不是拍脑袋定的

先说认知复杂度这个规则。很多人会问，为什么不用圈复杂度？圈复杂度只统计独立路径数量，它会机械地把每个if、for、while、catch都加1，结果就是很多代码明明可读性很好，复杂度却虚高，逼着人把代码拆得稀碎。比如一个只包含顺序逻辑但用了短路运算的表达式，圈复杂度会算得很高，但人读起来其实很顺畅。

认知复杂度则更贴近人类理解代码时的真实感受。它只统计会破坏线性阅读流畅性的结构，比如多层嵌套、多个分支、连续的条件表达式，而且嵌套层级越深，累加值越高。这个指标更符合“这段代码读起来费不费劲”的主观体验。

在open-code-review里，我对Python、JavaScript、Go三种语言都做了认知复杂度计算。默认阈值定为15，参考了行业内常用标准。超过阈值就提示“该函数认知复杂度为18，超过阈值15，建议拆分为多个子函数”，并且会在报告里列出主要的复杂度来源行，比如哪一层if嵌套贡献了分数，这样开发者知道从哪儿下手改。

3.2 增量分析如何精准定位到变更节点

增量分析是open-code-review的核心能力，实现逻辑是这样的。从git diff里，我们会拿到变更文件、变更块（hunk）、变更行号列表三个层次的信息。拿到这些信息后，工具按语言把变更文件分发给AST解析器，生成完整AST之后，再遍历所有节点，记录每个节点在源代码中的起始行和结束行。

然后做一次区间匹配：变更行号如果是某个AST节点的行号区间子集，就把这个节点标记为“受影响节点”。这个匹配逻辑虽然朴素，但非常有效。比如你改了某个函数内部的一个条件语句，这个条件语句所属的if节点、函数节点都会被标记为受影响。规则引擎扫描时就只检查这些受影响的节点，一个无关节点都不碰。

这种设计还有一个好处：可以追踪“问题是不是本次改动引入的”。还是回到那个场景——函数本来就写得乱，但这次你只改了一行日志。工具会识别出，虽然函数复杂度超标的结论成立，但该函数并非本次新增代码，因此默认给一个“既有问题”标签，降低优先级。只有当复杂度问题和新增代码直接相关，比如新加了多层嵌套，才会标记为“新增问题”。这样避免了开发者打开PR看到一堆历史遗留问题而产生抵触心理。

3.3 典型规则集：从空指针到硬编码字符串

我把目前内置的规则按场景分成了几个组，每组挑几条有代表性的说说。

可维护性规则组里，除了认知复杂度，还有“函数长度”和“文件头注释缺失”两条。函数长度默认阈值是60行，比行数更重要的是识别出来“这个函数是否承担了太多职责”——我会额外计算函数内部是否包含多个独立的逻辑块，如果同一个函数里既做参数校验、又查数据库、又拼响应，即使行数没超标也会提示考虑拆分。

安全性规则组里，重点规则包括“禁止使用exec/eval”“禁止弱哈希算法”“检测SQL拼接”。实现上主要依赖AST识别调用的是哪个模块的哪个方法，再做白名单拦截。这类规则基本不会误报，触发就一定是问题。

错误处理规则组里，“异常吞没”这条最值得展开。Python里常见的异常吞没写法有几种：裸except然后pass、except后只打日志不处理、程序退出时静默忽略。AST里判断裸except非常简单，但“只打日志不处理”这种半吞没模式就需要结合上下文分析：先检查except块内的语句列表，如果只包含logger或print调用，就会被判定为疑似吞没。

硬编码规则组里，“魔法数字”和“硬编码URL”是高频噪声来源。所以这两条规则在默认配置下是关闭的，因为我发现误报率太高：测试用例里哪里都是数字，配置表里全是常量，白名单很难维护。最后我换了个思路：默认只识别函数签名中出现的魔法数字、在条件判断中直接出现的数字，以及在非测试文件中出现的URL，并且允许用户用ignore_patterns维护白名单。

3.4 自定义规则怎么写

整个设计里，自定义规则是开放性的核心，也是最值得投入的地方。我提供了一个规则基类，用户只需要继承并实现check方法，然后在配置里注册，规则就能被引擎加载。

给一个简化示例，拿“检测日志级别使用错误”来说：

from open_code_review.rules import rule, RuleContext @rule( name="no-logging-at-debug-in-exception", languages=["python"], level="P1", ) def check(context: RuleContext): """捕获异常场景下不应使用debug级别日志""" error_frames = context.tree.get_nodes_by_type("ExceptHandler") for frame in error_frames: log_calls = frame.children_by_type("Call") for call in log_calls: if call.function_name == "debug": context.report( message="异常处理块中使用了debug级别日志，建议使用error级别", node=call, )

实际API比这复杂一些，但思路就是这样：从AST里找特定类型的节点，判断是否满足条件，然后report。写一次之后，团队里任何一个人都能按照同样的套路写新规则，时间久了就沉淀成团队自己的代码规约资产。

4. 从安装到接入CI的完整实操指南

4.1 本地安装与第一次运行

open-code-review提供了两条安装路径。如果是Python环境，直接pip安装就行：

pip install open-code-review

安装之后命令行入口是ocr。如果不方便装Python依赖，也可以在GitHub Releases页面下载对应平台的单文件二进制版本，解压后直接放到PATH目录里，这个方式比较适合CI里面不想处理依赖的情况。

验证安装是否成功，可以先看一下版本：

ocr --version

然后随便进一个git仓库试试最基础的检查。假设你想检查当前分支和main分支之间的差异：

cd your-repo ocr check --base origin/main --head HEAD

首次运行会自动下载用到的语言解析器文件（如果之前没缓存的话），会有一点网络耗时。跑完之后会在终端直接输出Markdown格式的审查报告，同时把完整报告写到默认的.ocr-report.md文件里。

4.2 基础配置与个性化调参

默认配置设计得比较保守，也就是在不调整的情况下，它只会报告少量高确信度的问题。如果你希望规则严格一些，或者需要关掉某些老项目里高频误报的规则，建议从配置文件开始。

工具支持两种配置文件格式：TOML和YAML，项目根目录放.open-code-review.toml或.open-code-review.yml都行。默认查找顺序是当前目录，然后是父目录，你要是在CI里用，也可以显式指定配置文件路径。

下面是一个典型的配置示例：

# .open-code-review.toml [base] # 默认对比分支 base_ref = "origin/main" # 报告输出路径 output_file = ".ocr-report.md" # 退出码策略：有P0才置为非零（standalone），或只要有问题就非零（strict） exit_mode = "standalone" [severity] # 认知复杂度阈值 max_cognitive_complexity = 15 # 函数最大行数 max_function_length = 60 # 嵌套深度阈值 max_nesting_depth = 4 [rules] # 完全禁用的规则 disabled = ["magic-number", "missing-file-header"] [rules.no_hardcoded_string] enabled = false [rules.no_bare_except] # 白名单：允许某些模块里出现裸except allow_modules = ["legacy_db_adapter.py", "vendor_sdk/*"]

severity段里调整的是所有规则共享的基础阈值。比如你的团队代码风格偏简洁，cognitive_complexity阈值可以调到10，打算更严格也可以调到20，但我不建议一上来就压得很低，误报多了会影响团队信心。

rules段里可以逐条开关规则。disable列表和rules.规则名.enabled两种方式效果一样，按自己的阅读习惯选一种就好。

ignore配置也很重要。它可以按文件路径、函数名、代码模式做更精细的过滤：

[ignore] paths = ["tests/", "generated/"] patterns = ["^#pragma", "TODO"]

4.3 接入GitHub Actions

实际落地时，把open-code-review接到CI里的价值比本地跑更大。推送到远程的那一刻，机器人自动把审查报告贴到PR里，团队每个人都能看到，不需要任何人手动执行命令。

GitHub Actions的配置长这样：

name: code-review-check on: pull_request: types: [opened, synchronize, reopened] jobs: review: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v4 with: # 一定要拉取完整历史，否则比较不到base分支 fetch-depth: 0 - name: Install open-code-review run: pip install open-code-review - name: Run review run: | ocr check \ --base origin/${{ github.base_ref }} \ --head ${{ github.event.pull_request.head.sha }} \ --format markdown \ --output .ocr-report.md - name: Upload report uses: actions/upload-artifact@v4 with: name: ocr-report path: .ocr-report.md

这段配置里有个关键细节：actions/checkout的fetch-depth必须设成0。如果只浅克隆一个commit，git diff比较的时候没有任何历史信息，自然无法生成报告。很多人在这一步踩坑，我还见过有团队专门写issue问为什么工具只报告“无法解析git历史”，一看就是fetch-depth没设置对。

GitLab CI的配置逻辑完全一样，区别只是变量名：用CI_MERGE_REQUEST_IID来获取MR编号，用CI_MERGE_REQUEST_DIFF_BASE_SHA作为base引用。

如果在PR评论里直接贴报告，可以用后续的comment动作读取.ocr-report.md再发一条评论。不要引入额外的流程，CI阶段只需跑一遍检查，把报告当作构建产物保存，该提醒的在注释里自然出现就够了。

4.4 报告长什么样

跑完一次检查之后，终端的报告长这样（简化版）：

## open-code-review report - 检查范围: origin/main...feature/billing - 变更文件: 12 (新增 456 行, 删除 121 行) - 检查耗时: 1.8s ### Summary | Severity | Count | |----------|-------| | P0 | 1 | | P1 | 3 | | P2 | 6 | ### P0 Issues **src/payment/task.py:128** - 异常吞没: except后仅执行logging.debug操作，会隐藏底层异常。 - 建议: 至少记录exception信息并重新抛出，或显式处理失败任务。 ### P2 Issues **src/payment/util.py:33** - 魔法数字: 86400 建议定义为常量 SECONDS_PER_DAY。

这样一份报告贴到PR里，团队成员一眼就能看到优先级最高的问题。没有P0问题的时候，审查者可以专心看代码逻辑，不用再被低级问题分心。

5. 常见问题排查与实战心得

5.1 误报率太高怎么控制

误报率是这类工具能不能存活下来的生死线。第一次跑工具，团队里大概率会出现几个大呼“这也能报错”的反馈。我自己的经验是，先不要急着改规则逻辑，而是先把运行的上下文搞清楚。

最常见的一个问题是：我明明改了3个文件，报告里却有一堆文件的问题。这多半是base_ref设置不对。比如你拿origin/main和HEAD做比较，但origin/main已经在本地落后远程好几个commit了，工具会把所有和远程领先的差异全部算进去。解决办法很简单，push之前先git fetch一把，让origin/main保持最新。如果你的团队喜欢用rebase策略，也尽量在CI里比较两个具体commit id，而不是比分支名。

第二个高频场景是测试文件误报。测试代码里到处是魔法数字和硬编码字符串，这是常态。处理方式有两种：在ignore里把tests/目录排除，或者单独为tests目录配置一套阈值。我更推荐后一种，因为测试代码也有该查的问题，比如我见过某个测试里把sleep(30)硬编码成等待时间，结果线上环境一慢就挂，这类问题自动化能找出来。

第三个场景是个人代码风格冲突。比如团队里有人喜欢长方法，认为“一种操作在一个函数里完成更直观”，认知复杂度规则就会跟人杠上。这时候作为工具维护者，我倾向于做一个“规则豁免注释”机制：

# ocr-ignore: high-complexity def legacy_process_data(): ...

规则扫描时如果发现目标节点或其上层节点存在ocr-ignore注释，就跳过这条规则。这个机制比config里的文件级排除更精细，而且保持了很好的自文档性——读代码的人看到注释就知道这里有特殊考虑。

5.2 团队落地节奏怎么控制

工具本身的配置只是一半，另一半是团队怎么用它。我的建议是三步走。

第一步，先做规则评估，别直接全员压测。在团队里找一个典型项目，跑一遍完整规则集，把报告丢给几位核心开发者看，问他们三个问题：哪些检查对你们有意义？哪些规则跟你们实际写代码的风格冲突？哪些问题你宁可自己去查也不想被机器人提醒？根据反馈把默认规则调整成团队熟悉的形态，这一步至少要花一两个下午。

第二步，从“建议模式”开始。第一周别把检查挂在CI的强制门禁上，只挂在理会。让团队成员知道有机器人会跑报告，但不强制阻断合并。这样用户能先适应工具的输出，而不是一开始就被工具拦住感到烦躁。

第三步，两周后再开启门禁模式。这时候团队已经对报告内容和规则有了预期，再把P0级问题设为合并阻断项。严格级别不要一上来就开满，给团队一个消化过程，落地阻力会小很多。

5.3 我踩过的一些坑与教训

最后分享几个实际踩过的坑。

第一个坑是“全量规则一开就拉满”。第一次做规则配置时，我试图把所有想到的规则全部打开，觉得检查越全面越好。结果跑了几个项目之后，报告里塞满了P2级别的建议，真正的P0风险反而被淹没了。后来我重新调整策略：默认只开P0和P1级别的规则，P2全部默认关闭。宁可漏掉一些建议，也不让报告变成没人看的噪音。

第二个坑是“把工具反馈当裁判”。有时候开发者和评审者会因为一条规则吵起来。“机器人说这里复杂度超标，你为什么不拆？”“机器人还说我这段写得没问题呢”。这时候工具只会暴露出团队里原有的沟通问题，它不帮任何人站队。规则是死的，技术和业务场景是活的，该人工判断的事情不要甩给工具。

第三个坑是“规则仓库长期不更新”。团队的技术栈在变，规则也该跟着变。我们曾经在项目里发现一种新的反模式，写的时候没注意到AST里能精准识别，后来把这条规则补充进去之后，连续几个PR都起作用了。规则数据本身就是团队资产，抽空维护它，它会回报你更多。

5.4 给刚开始用open-code-review的开发者一些参考

如果准备接手这个工具，下面几个思路我觉得值得参考。

第一，从核心项目的一个子目录开始，别一上来就整个仓库全跑。先在小范围确认工具跟团队的代码风格相容，再逐步扩大范围。我跟人聊的时候发现，很多工具应用失败原因不是工具不行，而是推广过程太激进。

第二，把报告当成评审材料，而不是评审结论。工具的定位是辅助信息，最终审批权永远在人手中。哪怕P0级别的问题，也只是“强烈建议确认”，不是“不许合并”。

第三，不同语言的规则适配度不同。目前Python和JavaScript的规则覆盖度最高，其次是Go和Java。如果你用的是冷门语言，要提前确认相关规则是否存在，必要时就得写自定义规则。我建议新语言接入时，至少先配置三到五条自定义规则，这样可以验证整个链路是否通畅。

我在实际使用中还有一个体会：这个工具的价值不在于它能发现多难的问题，而在于它让code review这件事变得可以量化、可以追溯。过去我们只能凭感觉说“这周的review质量怎么样”，现在有了一份机制化的报告，能知道哪些类型的问题反复出现、哪个模块是问题高发区、规则库帮助团队堵住了多少坑。这种“积累起来的能力”比任何一个单独问题的修复都有价值。

最后再分享一个小技巧：把规则库独立成git子仓库，而不是跟着主项目库走。这样主仓库升级迁移不影响规则资产，规则库的演进也能独立review和测试。等规则沉淀得足够多，你会发现它已经成了团队代码风格最好的记录者。