企业官网建设流程全解析

代码评审这件事，一直都是“人人都说重要，人人都想跳过”。特别是团队规模上去之后，PR越堆越多，评审质量靠自觉、靠运气、靠老员工深夜加班硬扛。我见过太多团队，评审表填得满满当当，实际真正逐行读代码的没几个人。也见过不少独立开发者，项目开源之后，来自社区的PR质量参差不齐，光靠人工一个个看，时间根本不够用。

所以我关注到 open-code-review 这个项目的时候，第一反应是——终于有人想把“评审”这件事做成可复用的工具链了。它不是一个简单的Lint工具，也不是某种CI插件的替代品，而是一套独立部署的开源代码审查服务。你可以把它理解成一个“不睡觉、不摸鱼、不碍于情面”的机械化评审搭档，把它接进团队现有的Git工作流里，让每次PR在交给人类之前，先过一遍机器的眼。

这篇文章，我会从这套工具的定位、部署、核心规则配置、实操落地到问题排查，完完整整走一遍，把我踩过的坑和实测有效的配置方式都写出来。无论你是想给团队搭建统一的代码审查入口，还是个人开源项目需要一个自动化的PR检查服务，这篇文章都值得花几分钟看完。

1. 项目定位与核心设计思路

1.1 它解决的到底是什么问题

传统代码审查的效率瓶颈，往往不在“看”这个动作，而在“看之前”的筛选和“看之后”的追踪。一个中型PR里，可能有几十个文件、上千行代码，真正需要人类判断的逻辑缺陷可能只有几处，剩下大量是格式不一致、命名混乱、明显的低阶错误、遗漏的边界条件。如果把这些低价值问题全部堆到人工评审阶段，再资深的人也会疲劳。

open-code-review 的核心设计思路，是把评审拆成两个阶段：机器先筛，人再深审。工具负责跑规则、查规范、扫基础风险点，汇总成一份结构化的评审报告，把它作为PR讨论串的置顶内容。人类评审者打开PR的时候，先看到的是已经分好优先级的问题清单，而不是一屏又一屏的原始代码差异。

这个思路的价值在于，它不试图取代人类评审，而是把人的注意力从“查错”释放到“判断”。低阶错误交给规则引擎，人类只处理那些需要业务知识、架构嗅觉、上下文理解的高阶问题。工具跑得越多，人审得越准。

1.2 整体架构与模块分工

从架构上看，open-code-review 并不是一个单体程序，而是几个功能模块的组合。虽然没有强制拆成微服务，但模块之间的边界非常清晰，这对后续的二次开发和私有化定制非常友好。

核心模块主要有四个。第一个是任务调度模块，负责监听代码托管平台的Webhook事件，把每一次PR创建、更新、合入前的事件解析成标准的审查任务，投递到内部队列。第二个是仓库适配层，它屏蔽了不同代码托管平台的API差异。无论你用的是主流的GitHub、GitLab，还是自托管的Gitea、Gitee，这一层都能把PR的元数据、文件变更列表、提交历史统一成内部数据模型。第三个是规则引擎，这是整个工具的灵魂，加载一组可配置的审查规则，对每个变更文件执行检查，输出带严重级别和定位信息的发现项。第四个是报告与通知模块，把规则引擎的输出汇总成Markdown或JSON格式的报告，调托管平台的API以评论形式发布到PR讨论区，同时可以通过邮件、Webhook等方式通知相关评审人。

模块化带来的好处很直接：你不需要理解全部代码也能用起来，缺哪里补哪里。觉得默认规则不够用，就自己写规则插件；觉得通知渠道太单一，就扩展一个新模块。我自己的做法是二次开发了一个内部通知插件，把报告转成企业内部IM的消息卡片，效果比邮件好很多。

1.3 为什么选择“自托管”而不是SaaS方案

很多人会问，既然市面上那么多代码评审SaaS服务，为什么还要自己部署一套。这个问题我想认真回答一下。首先是代码安全问题，大多数研发团队的代码仓库是私有仓库，把代码Diff内容提交给第三方评审服务，意味着代码出了安全边界。对一些合规要求严格的行业，这根本不可接受。open-code-review 完全部署在内网，所有代码数据只在内部流转，不需要担心第三方服务的数据留存策略。

其次是定制能力的问题。SaaS服务提供的规则和报告格式都是固定的，你只能从它给定的选项里选，做不到“按团队自己的规范来定义什么是对、什么是错”。自托管方案则完全相反，规则文件就是普通代码，团队规范可以映射成审查规则，新成员入职看的规范文档，就是这套规则的注释。

当然，自托管也有代价，需要自己维护服务、监控运行状态、处理升级和备份。但以一个中型团队半年跑下来的经验看，这个维护成本是完全可控的，一个普通的后端工程师每周花一个小时就足够了。

2. 环境准备与快速部署

2.1 部署前需要准备的东西

open-code-review 的部署方式比较灵活，官方推荐的是 Docker 方式，这也是一般团队最容易上手的方式。在开始之前，有几个前置条件是必须准备好的。

第一，一台能够运行 Docker 的服务器，规格不需要太高。我实测下来，一个日均10个PR、单PR变更文件在20个以内的中等规模团队，2核4G的实例跑得相当轻松。如果你团队规模更大、仓库更多，建议从4核8G起步。第二，要有一个可以创建 Webhook 的代码托管平台，GitHub、GitLab、Gitea 均可。注意如果是内网自托管的 GitLab，需要确保服务器能访问到 GitLab 的 API 端点。第三，一个机器人账号的访问令牌(Token)，用于拉取代码、读取PR信息、发布评审评论。建议单独创建一个专用账号，而不是用个人账号，这样即使令牌泄露也不会影响真实用户的数据，而且权限可以收窄到只读仓库和发表评论。

另外建议预留一个 MySQL 或 PostgreSQL 数据库实例，虽然工具默认可能使用内置的轻量级数据库，但生产环境用它长期跑下来，我还是建议换成独立数据库。这样数据更可靠，后续如果要接入监控和备份体系也方便得多。

2.2 Docker Compose 一键部署

官方的部署方式比较友好，提供了一个 docker-compose.yml 的示例文件。我这里是结合生产环境使用后的修正版，结构更清晰，资源限制也更合理。

version: "3.8" services: open-code-review: image: open-code-review/open-code-review:latest container_name: open-code-review restart: always ports: - "8080:8080" environment: - OCR_DB_DRIVER=mysql - OCR_DB_DSN=ocr_user:your_password@tcp(mysql:3306)/ocr_db?charset=utf8mb4&parseTime=True&loc=Local - OCR_PLATFORM_TYPE=github - OCR_PLATFORM_API_URL=https://api.github.com - OCR_PLATFORM_TOKEN=${GITHUB_BOT_TOKEN} - OCR_WEBHOOK_SECRET=${WEBHOOK_SECRET} - OCR_LOG_LEVEL=info volumes: - ./rules:/app/rules - ./reports:/app/reports depends_on: - mysql networks: - ocr-net mysql: image: mysql:8.0 container_name: ocr-mysql restart: always environment: - MYSQL_DATABASE=ocr_db - MYSQL_USER=ocr_user - MYSQL_PASSWORD=your_password - MYSQL_ROOT_PASSWORD=root_password volumes: - mysql-data:/var/lib/mysql networks: - ocr-net volumes: mysql-data: networks: ocr-net: driver: bridge

这个配置里有几个细节需要特别注意。环境变量里的OCR_PLATFORM_TYPE决定了工具使用哪个托管平台的API接口，如果使用的是 GitLab，要改成gitlab，同时OCR_PLATFORM_API_URL要改成你们 GitLab 实例的地址。OCR_WEBHOOK_SECRET是Webhook签名密钥，在托管平台上配置Webhook时要用同一个值，防止别人伪造请求打进来。

启动命令很简单，在 docker-compose.yml 所在目录执行：

docker-compose up -d

第一次启动会拉取镜像和初始化数据库，可能需要一两分钟。启动完成后可以检查容器状态：

docker-compose ps

确保两个容器都是 Up 状态。然后打开http://你的服务器IP:8080，如果看到服务的管理界面，就说明部署成功了。

2.3 数据库初始化与迁移

如果你使用独立数据库，在正式接入仓库之前，建议先确认数据库初始化成功。open-code-review 在首次启动时会自动建表，不需要手动执行 SQL 脚本。但如果你使用的是 MySQL 8.0 以上版本，需要注意字符集配置，推荐在连接串中显式指定charset=utf8mb4，否则遇到仓库名或分支名包含中文时，可能出现乱码问题。

此外有一点值得提醒：不要在生产数据库上使用默认的弱密码，虽然这是常识，但我见过不止一个团队因为嫌麻烦，把上图中的your_password原封不动保留下来，结果被扫漏洞的脚本拖走了数据。部署完成后，第一件事就是修改数据库密码，同时检查 open-code-review 所在服务器不要直接暴露公网端口，安全组只放行必要的IP访问 8080 端口。

3. 接入代码仓库与核心规则配置

3.1 创建机器人账号与配置 Webhook

把工具接入仓库的第一步，是给它一个身份。不管你是用 GitHub 还是 GitLab，都需要单独创建一个机器人账号。以 GitHub 为例，建议创建一个名为ocr-bot的账号，然后进入 Settings -> Developer settings -> Personal access tokens，生成一个新的 Token。Token 的权限范围建议只勾选repo和read:user，前者用来读取仓库代码和发布评论，后者用来确认账号身份。

拿到 Token 之后，有两种方式注入到 open-code-review。第一种是通过环境变量（像我上面 docker-compose 里写的那样）；第二种是通过管理界面的配置项填写。我建议在你的服务器上用.env文件管理 Token，然后 docker-compose 通过env_file引入，这样可以避免 Token 写死在代码仓库里。

接下来进入代码托管平台，配置 Webhook。在 GitHub 仓库的 Settings -> Webhooks 页面，点击 Add webhook，Payload URL 填http://你的服务器IP:8080/webhook，Content type 选择application/json，Secret 填上面配置的OCR_WEBHOOK_SECRET。在触发事件那里，建议只选择Pull requests和Pull request reviews，不需要监听Push事件，否则每次代码提交都会触发一次审查，有点浪费资源。

配置完成后，GitHub 会发送一个ping事件来验证 Webhook 是否配置成功。正常情况下 open-code-review 会返回 200 状态码，管理界面的日志里能看到received ping event的记录。

3.2 规则文件结构与管理方式

open-code-review 的规则引擎是非常灵活的，规则不是硬编码在程序里的，而是以配置文件的形式存放在./rules目录下。默认情况下，每次服务启动时都会加载这个目录下所有的规则文件。

规则文件使用 YAML 格式编写，一个文件可以包含一条或多条规则。我把常用的规则按类别拆分成了几个文件，团队在维护的时候可以各管各的，互不干扰：

• rules/style.yaml：风格类规则，检查命名、格式、import顺序等
• rules/security.yaml：安全类规则，检查SQL注入、敏感信息硬编码等
• rules/bugrisk.yaml：缺陷风险类规则，检查明显的逻辑错误、空指针风险等
• rules/performance.yaml：性能类规则，检查明显的低效写法

为了让规则文件生效，你需要在管理界面的“规则集”配置中把上述规则文件分别关联到对应的语言上。比如rules/security.yaml同时关联到 Java、Go、Python 项目，而rules/style.yaml只关联到 Java 项目，因为团队还没有统一其他语言的风格规范。

下面是一条实际规则的 YAML 示例，用来检查 Java 代码中禁止使用printStackTrace()打印异常堆栈：

- id: JAVA-SEC-001 name: AvoidPrintStackTrace description: 禁止使用 e.printStackTrace()，应使用日志框架记录异常 severity: warning # 可选: error / warning / info language: java type: regex pattern: ".*\\.printStackTrace\\(\\)" message: "检测到 printStackTrace() 调用，请使用日志框架输出异常信息" enabled: true

这里type: regex表示通过正则表达式匹配代码内容，适合简单模式匹配的场景。但如果你要处理“判断一个变量是否在某个作用域内被使用时未判空”这类复杂场景，正则就非常吃力了。这时候需要用type: ast规则，让工具基于代码的语法树执行更复杂的分析。

3.3 从浅到深：三类规则的写法

我把实际用过的规则按复杂程度分成了三级，方便团队从零开始搭建自己的规则库。

第一级是“字符串匹配级”，也就是上面示例里的正则类规则。这一级规则的优点是编写成本极低，只要你能用正则描述出特征，就能在几分钟内新增一条规则。缺点是误报率较高，比如你想检查println的使用，但正则很难区分是调试代码还是有意保留。我一般用它处理非常明确的坏味道：禁止使用System.out、禁止明文密码字段、禁止 TODO 注释超过三个月等。

第二级是“AST模式级”，通过解析代码语法树，可以写出更精准的规则。典型场景是“检查所有非空接口参数是否在方法入口做了空值校验”。AST规则可以精确定位到方法定义的参数列表，然后检查方法体的第一个语句是否为空判断。在实际工作中，这类规则的维护成本比正则高一个量级，但回报也大，因为误报率大幅下降，团队成员不会因为虚假告警而对工具失去信任。

第三级是“跨文件分析级”，用于需要结合多个文件上下文才能发现的规则。比如“防止循环依赖”“识别无用的公开接口”。这类规则通常需要在语言插件或外部脚本中实现，open-code-review 提供了插件接口，允许用 Python 或 Go 编写自定义分析器。考虑到投入产出比，我建议团队前期的规则建设先集中在第一级和第二级，等运行稳定后，再根据痛点逐步做第三级。

3.4 严重级别与误报率权衡

每一类规则都必须配置严重级别，因为它直接影响报告的可信度和团队的使用心情。我在实践中的体会是：错误(error)级别的规则数量要严格控制，如果每次PR都能刷出10条以上 error，开发者的第一反应不是修复问题，而是反感这个工具、找绕过工具的方法。

我的建议是：

• error 级别的规则只保留那些“一旦存在就意味着PR绝对不能合入”的问题，比如硬编码数据库密码、SQL注入风险、明显的内存泄漏。
• warning 级别的规则是给团队提供建议，不一定每条都要修改，但需要程序员确认自己的写法是有意的。
• info 级别用于提示潜在改进空间，比如某段代码可以提取成一个通用方法，某个变量可以改成常量等。这类信息不需要付诸行动，但它能帮助团队形成长期的技术债清单。

工具在生成报告时，会按照文件维度汇总以上级别的发现项，报告顶部优先列出所有 error 和 warning，info 级别的发现项折叠在底部，避免淹没重点。

4. 审查流程与核心功能实操

4.1 一次完整的审查是怎么跑起来的

从开发者的视角看，整个流程是这样的：开发者提交PR，代码托管平台向 open-code-review 发送 webhook 请求；工具解析PR，拉取涉及的所有变更文件和对应的基线代码；规则引擎逐个文件执行检查；执行完成后生成报告，报告内容按严重级别排序，用评论方式发布到PR讨论区。

这一过程一般控制在1到3分钟之内，取决于PR的规模和规则的复杂度。我在测试中尝试过一个改动超过8000行的大PR，规则数量大约40条，执行耗时约4分钟。需要说明的是，open-code-review 默认只对新增和修改的行做检查，不会对未变更的历史代码重复扫描，这个“增量检查”的设计可以保证大部分审查都能快速返回结果。

报告发布之后，开发者可以在讨论区逐条浏览问题项，每条都包含了精确到行号的代码位置、问题描述、规则ID以及对应的修改建议。开发者不会在“工具到底在报什么毛病”上反复猜测。

4.2 审查报告怎么看

报告默认是 Markdown 格式，我复制一份实际报告的核心片段，展示一下它的结构：

## open-code-review 扫描结果 > 本次扫描共发现 2 个 error、4 个 warning、7 个 info > 扫描时间: 2025-06-11 14:23:05 ### 错误 (2) #### [JAVA-SEC-001] 检测到 printStackTrace() 调用 - 文件: `src/main/java/com/example/OrderService.java` - 行号: 87 - 建议: 使用日志框架记录异常堆栈，如 `log.error("处理订单失败", e)` #### [JAVA-DB-003] 疑似SQL注入 - 文件: `src/main/java/com/example/UserDao.java` - 行号: 45 - 建议: 使用预编译语句（PreparedStatement）替代字符串拼接 ### 警告 (4) ...

这个格式非常清晰，规则ID、文件路径、行号、修改建议都标注出来了。人类评审者看到报告后，可以直接在代码行内点评，或者在评论里@开发者修改。很多团队的做法是要求合并PR前，至少先把 error 级别的问题清零，warning 级别的问题要么修复、要么在评论里说明原因。

4.3 接入PR检查状态

仅仅发布报告是不够的，要想让团队真正重视工具的结果，最好把开源的 review 结果作为合入门的强制检查项。GitHub 支持通过 Commit Status API 来设置PR的检查状态，open-code-review 也提供了这个能力。配置好之后，PR页面会显示一个类似“open-code-review / checks”的状态，如果存在 error 级别问题，这个状态会被标记为 Failed；只有所有 error 都解决后，它才会变成 Success。

结合 GitHub 的 Branch protection rules，你可以在开发分支上开启“Require status checks to pass before merging”选项，并勾选 open-code-review 检查项。这样一旦工具发现 error 级别问题，代码就无法被合入，从流程上保证了质量问题不会流到主干。

对于 GitLab，也有对应的 Merge request approval rules 和 External status checks 机制，原理类似，配置上略有差异。我团队在迁移到 GitLab 自托管之后，通过 External status checks 实现了同等的硬门禁效果。这个强制门禁的落地，才是工具价值最大化的一步。

4.4 自定义规则的最佳实践

如果你准备开始搭建团队的规则库，我的建议是在最开始的两周内不要贪多求全，先推10到15条规则，覆盖团队最痛的点。太多了团队成员会反感，太少了没效果。

我实际搭建时，第一步是跑了半个月左右的“监控模式”，即工具只输出报告但不阻止合并。我需要观察两条数据：一是规则的命中数量是否合理，如果某条规则一周内命中了几十次，那可能不是团队代码有问题，而是规则本身不符合团队的实际写法；二是看开发者的反馈，他们是否觉得这些提示有帮助，是否有规则让他们产生了“这个工具不懂业务，只是死板地报问题”的印象。

根据反馈调整完之后，再把规则正式接入合入门禁。先宽松后收紧，一步步建立团队信任。这个节奏和做技术方案很像——先小范围试点，拿到数据，再逐步推广。

5. 常见问题与排查技巧实录

5.1 Webhook 一直收不到请求

这是部署过程中最常遇到的问题。如果你在托管平台上创建了 Webhook，但 open-code-review 的日志里始终没有收到请求，先按下面的顺序排查：

第一，确认外网能否访问到你服务器的 8080 端口。最简单的方法是用 curl 检查：

curl -v http://你的服务器IP:8080/webhook

只要返回结果不是连接超时，就说明端口是通的。有些云服务器默认安全组没有放行8080端口，需要到控制台检查入方向规则。

第二，检查 docker-compose.yml 里的端口映射是否正确。如果宿主机上多个服务同时占用了8080端口，容器可能无法启动或者端口映射失败，这时候可以用docker-compose ps看看容器状态。

第三，确认 Webhook 的 Payload URL 是否拼写正确。有个很容易踩的坑是漏掉了/webhook这个路径，只填了根地址，导致托管平台请求的是不存在的路由。

第四，检查 Secret 是否匹配，如果托管平台和 open-code-review 配置的 Secret 不一致，工具会认为请求不合法而拒绝处理。

5.2 报告大量出现误报怎么处理

误报率高是规则引擎工具最常见的问题，处理不当很容易让团队彻底放弃这个工具。我的经验是先区分误报的类型，再决定对策。

如果是正则规则产生的误报，比如System.out这条规则在某个项目中报出了日志辅助类里的打印语句，但这类语句在项目里是故意保留的，那就需要优化规则的正则表达式，增加上下文约束，比如不匹配测试目录下的文件，或者不匹配main方法中的输出语句。

如果是 AST 规则的误报，那么大概率需要调整代码分析器的上下文判断。比如“空指针风险”检查在某个已有的防御式编程写法上报了错，说明规则没有识别出前置判断逻辑。这时要在规则配置中修改语义判断条件，或者为特定代码模式添加白名单。

还有个通用技巧是给规则设置“排除路径”。在规则配置中增加一个exclude_files字段，把第三方的代码生成目录、自动生成的SDK代码等排除在外，这些目录本来就不应该走审查规则。我实际配置中，会把target/、build/、vendor/、node_modules/、generated/这类目录全部加进排除列表，误报率能下降一半以上。

5.3 扫描大PR时耗时过长

有几次，团队拿一个超过5000行变更的巨型PR来跑，结果等了近20分钟还没结果，开发者都开始烦躁了。排查后发现，是某个跨文件分析规则在庞大的变更集上做了大量的重复计算，性能退化严重。

针对这个场景，有几个实用的优化方向。一是提升规则引擎的并发度，在配置文件中增加扫描并发数，但注意不要提升太多，避免数据库连接池被打满；二是拆分规则执行阶段，把耗时较长的跨文件分析规则延迟到常规规则跑完之后再单独执行；三是给规则引擎增加超时保护，单文件的检查如果超过预设时间就跳过，并记录为超时项。

同时，我也建议团队在流程上对大PR做拆解。开发者在提交大改动时尽量拆分成多个有逻辑边界的PR，既能降低审查难度，也能让工具在几分钟内完成扫描。如果实在拆不开，设置一个变更量阈值，超过阈值的PR直接在报告里提示“本次变更范围过大，建议人工重点审查”。

5.4 机器人账号权限不足导致无法发布评论

如果你发现扫描报告生成了，但评论没有出现在PR讨论区，大概率是Token权限不够。GitHub 的 Token 除了需要repo权限之外，某些情况下对组织（Organization）私有仓库的评论，还需要额外的组织授权。

处理方式是在组织 Settings 里找到 Third-party access，把机器人账号添加为批准的集成应用。或者在生成 Token 时就选择了组织的 Special permissions。另外，如果你的仓库开启了 Required reviewers 或 code owner 保护规则，机器人可能被限制为不能直接发表评论。这时候需要检查仓库分支保护规则，确认机器人账号在允许列表中。

GitLab 类似，机器人账号必须在项目成员中，并且至少拥有 Developer 角色，才能对 MR 发表评论。如果只授予了 Guest 权限，审查报告会报送失败。

5.5 规则更新后没有生效

在规则的配置文件目录下修改了规则文件，重启服务后却没有生效，这也是很多人会踩的坑。通常原因是没有加载最新的规则文件。open-code-review 启动时会缓存规则信息，所以修改完rules目录下的 YAML 文件后，必须执行容器重启，才能让新的规则加载：

docker-compose restart open-code-review

如果你修改的是管理界面里的规则项，注意保存后是否提示“发布规则集”，只有发布成功的修改才会实时生效。规则文件的语法错误也会导致加载失败，可以先在本地用支持 YAML 的编辑器校验格式，再放进服务器。日志里看到failed to parse rule file字样的记录，十有八九就是格式问题。

5.6 常见问题速查表

5.7 让团队接受工具的四个技巧

工具落地最难的部分，不是技术部署，而是团队接受度。我踩过几次坑之后总结出几个有效的方法。

第一，不要一开始就开全部的规则，挑一个大家公认的痛点先做。比如团队之前经常因为日志规范不统一而互相指摘，那就先上10条日志相关规则，跑两周让团队直观感受工具的价值，再逐步放开其他规则。

第二，把规则的维护权下放给团队。open-code-review 的规则文件是开放的，不同的模块可以由熟悉该模块的开发者来维护。比如中间件组维护他们相关的规则，数据访问层组维护数据库相关的规则。让开发者有归属感，而不是觉得“被别人管着”。

第三，给报告留出“反驳通道”。如果开发者觉得某条规则不合理，可以直接在 PR 评论里说明原因，团队定期review一次所有被驳回的规则告警，共同决定是否调整规则。这样工具就不只是单向的审查者，而是一个持续演进的共同体。

第四，把工具融入现有的代码评审文化中，而不是强加一个“裁判”。团队内部可以约定：工具的告警是“建议”，真正的合并决定权还是掌握在人工评审手里。工具的定位是让评审者更快聚焦问题，而不是替代评审者的判断力。

6. 从开源工具到团队代码资产

在我个人看来，open-code-review 这类工具的意义，不在于它能“自动挑出几个Bug”，而在于它把代码审查变成了一种可度量、可积累、可传承的团队资产。规则文件写在那里，团队规范就变成了一条条可验证的机器检查项；报告积累下来，就变成了团队技术债的一手统计数据；后续新人入职，看这些规则的注释比读任何文档都直观。

实际操作当中，我把它从“搭个服务跑起来”到“真正嵌入团队研发流程”的整个过程，花了两到三周。前期主要是在调规则、压误报、帮团队养成看报告的习惯；后面基本处于只维护、少干预的状态。我们团队现在每天的PR合入，基本都是绿灯状态，因为大多数问题在提交前就已经被开发者在本地或预检阶段修掉了，这在以前很难想象。

补充一个使用技巧：建议把规则库单独建一个 Git 仓库，大家通过 PR 来修改规则，这样规则演进也有迹可查。谁改了什么规则、为什么改、影响了哪些项目，都留在提交历史里。坚持半年之后，这个仓库本身就是一套完整的团队编码规范演进史。

如果你也在搭建团队或自己项目的代码审查流程，open-code-review 值得花一晚上时间部署起来跑一跑。先用监控模式观察几天，再逐步把规则调成适合自己团队的形态，你会明显感受到代码评审这件事，从“必做的仪式”变成了“真正有用的一环”。