代码审查（code review）大概是所有研发团队都绕不过去的一环，但真正把它做好的团队少之又少。大多数团队要么走个过场，要么干脆不看，等代码上线出问题了才追悔莫及。我这次要分享的 open-code-review 项目，就是我为了解决“代码审查流于形式”这个老大难问题，从零动手做的一套开源自动化代码审查辅助工具。它的核心目标很简单：把代码审查里那些机械的、重复的、肉眼容易漏掉的事情交给程序去干，让工程师把宝贵的注意力留给真正需要人脑判断的部分。这篇文章会完整复盘这个项目的设计思路、核心模块的实现细节、踩过的坑，以及我从实际使用中总结出来的经验教训，希望能给正在纠结如何做好代码审查的同学一些参考。
1. 为什么需要一套自动化的代码审查助手
1.1 代码审查的现状：流于形式是最大问题
先说一个我观察到的普遍现象。大部分团队其实都有代码审查流程，PR 关联评审人，reviewer 标注几个意见，点个 approve，流程就算走完了。问题在于，这种形式化的流程根本没起到它应有的作用。
我见过很多次这样的场景：一个改动几百行的大 PR，评审人根本没时间逐行看，只看了个标题和 diff 概览，随便挑两三个点说一下就打发了。更常见的情况是，reviewer 关注的点和代码里真正的问题严重脱节，大家纠结命名和缩进，却没人发现一个配置文件的改动会导致生产环境行为发生变化。代码审查变成了一种“仪式”，而不是质量防线。
另一个让人头疼的问题是审查结果不沉淀。今天这个 PR 里发现的坑，明天在另一个 PR 里还会再犯。没有工具把这些经验固化下来，团队的知识都是在人脑子里流转，一旦人员流动，经验就流失了。我当时就在想，能不能有一个东西，能把团队的经验、规范、容易踩的坑，自动化地施加到每一次代码变更上。
这其实不是什么新概念，市面上各种静态扫描工具早就存在。但问题也恰恰出在这里——通用静态扫描工具太重、太泛。拉一套刚配置完就能把仓库警告数量刷到几千条，开发者打开一看全是历史债务，根本分不清哪些和当前改动有关，效率反而更低。团队真正需要的不是“全量体检”，而是“围绕这次 diff 的针对性审查”。
这就是 open-code-review 的出发点。它不是又要做一个包罗万象的静态分析平台，而是一个轻量级的、面向代码变更的审查助手。它做的事情可以用一句话概括：分析你这几十行到底改了什么，然后立刻告诉你，这几十行里有没有你们团队明确规定过的坑。
1.2 open-code-review 的目标与边界
项目目标定得很纯粹：降低代码审查的负担，让审查结论更聚焦。具体拆解下来有几层目标。
第一层，在开发者提交 PR 后，自动完成对变更集的解析和基础检查。比如有没有调试残留代码、有没有不小心提交的临时文件、有没有明显的 API 误用模式，这些不需要人去看，程序能快速扫出来。
第二层，把团队积累的规则变成自动检查项。很多团队都会在文档里写一堆“开发规范”，但规则写在 wiki 里就等于没写，没人会照着背。open-code-review 的做法是把这些规范写进规则引擎，有真实代码违反了，就在 PR 评论里用具体的行号和代码片段指出来。
第三层，也是我认为最重要的，是把审查结果整理成“人读得懂”的样子。一次代码变更可能触发几十条检查结果，如果全部乱七八糟地丢到评论里，开发者第一反应是关掉页面。open-code-review 必须把重复的、同类的、低价值的结果聚合压缩，最终输出几条高质量的、可执行的建议。
当然，边界也必须要说清楚。我从来不认为自动化工具能取代人来做代码审查。程序不懂业务，不理解架构中长期演进的需求，更不会从一个 PR 里看出团队协作的隐患。open-code-review 定位是“助理”，不是“法官”。它能做的只是把脏活累活先干完，让人类评审者接到一个已经被过滤过的、重点关注真正问题的 PR。这个定位在我自己团队里是反复强调过的，避免大家过度期待，也避免工具越界产生不信任感。
2. 整体设计思路：先拆解再组装
2.1 核心流程：diff 分析、规则匹配、结果聚合、评论推送
整个 open-code-review 的处理流程，其实拆开看就是一个标准的管道：读取变更、解析变更、分析变更、输出结论。
第一步是读取变更信息。在 CI 环境下，我需要拿到当前审查对象的基线信息，包括源分支、目标分支，以及本次 MR 的编号。通过这些信息，调用代码托管平台提供的接口去获取这个 MR 对应的 diff 数据。diff 数据是整个分析流程的唯一输入，后面所有工作都基于这堆文本展开。
第二步是解析变更。这一步看起来简单，实际上坑很多。git diff 输出的格式是统一的，但要准确对齐到“哪个文件的哪一行”并没有那么直接。一个 diff block 里有多个 hunk，每个 hunk 里有新增行、删除行、上下文行，而且行号在原文件和新文件中是错位跳动的。我在这部分花了不少心思，因为后续规则引擎要产生精准的评论，必须拿到“新文件中第几行”这种级别的位置信息。一旦这里算错，规则判断得再准，评论落在错误的代码行上，整个工具的可信度就崩了。
第三步是规则匹配。解析出来的每个新增代码片段，会经过两个分析通道。简单规则走正则和文本匹配，复杂规则走抽象语法树分析。两条通道的结果统一汇入规则引擎，由引擎根据权重和优先级做筛选。这里值得注意的是，我做了范围限制，只分析本次新增的代码，不扫历史代码。这一点非常关键，避免了对存量代码的低质量噪音。
第四步是结果聚合。几十条规则跑完之后，会产生一批原始问题对象。聚合模块会把它们按文件和规则类型分组。聚合其实有两个维度，一是“合并同类项”，比如同一个位置同时触发了三条相关规则，就要并成一条综合评论，二是“砍掉低价值结果”，比如有的规则误报率比较高，或者影响级别比较低，就会降级处理，不往评论里写。
最后一步是评论推送。open-code-review 在 CI 里运行时，会调用托管平台的 API，在对应的 MR 上添加审查评论。这里又有讲究。全部结果直接堆在一个评论里，读起来很累；放在多个评论里，又会刷屏。所以实际操作中，我采取了“一条汇总评论 + 少量行级评论”的混合策略。汇总评论给整体结论和问题分组，行级评论给最关键的几条具体定位。开发者看到的是有层次的输出，而不是一屏乱码。
2.2 技术选型：为什么要自己造轮子
在做技术选型时，我第一个考虑的问题是：市面上能不能直接找到一个满足要求的工具？我当时调研了圈内比较主流的静态扫描、代码质量检查、MR 机器人之类的开源项目，发现要么太重，部署要一堆服务依赖，要么规则体系太封闭，想定制团队专属规则非常别扭，要么就是商业产品，定价不适合团队长期使用。与其后面对一堆不合适的代码做二次开发，不如踏实自己做一个足够聚焦的工具。
语言选型上，我最终选择了 Python。原因很现实，Python 在文本处理、规则定义上极其灵活，生态里现成的 AST 解析库覆盖了主流语言，而且写自定义规则的门槛低，团队成员即使不是深度程序员也能看懂规则脚本。对这个小工具来说，不需要微服务、不需要高并发，Python 单进程跑完全够用，开发和维护成本最低。
解析层用了抽象语法树，而不是全程正则，这是吃过亏之后做的决定。正则适合处理“形态稳定”的场景，比如检查有没有 TODO 标记、有没有 debugger 语句，但处理“模式复杂”的场景就彻底不行了。举个例子，判断一个函数调用是不是被 try-except 包裹，这种结构关系仅靠文本正则基本无解，但用 AST 遍历就一目了然。后来我把所有涉及代码结构的规则都重构到 AST 上，准确率提升了一个量级。
还有一个让我认真考虑的问题：需不需要自己维护一个 Web 服务和数据库来存储历史问题趋势。我挣扎了一段时间，最后决定不要。open-code-review 走轻量路线，在 CI 环境里跑完即走，结果写到 MR 评论里就够了。历史趋势、指标大盘这类功能属于管理层需求，和“让开发者快速收到有用意见”的核心诉求是冲突的。做完术业有专攻的减法，反而让工具更好推广。
2.3 工程结构：按插拔式思路组织
为了让这个工具能长期演进而不会烂掉，我把工程结构按照“内核 + 适配器”的思路来组织。
项目根目录下是入口程序，以及配置目录。配置目录里有规则定义和全局设置。核心代码在 core 目录里，分成几个模块：diff 解析、AST 解析、规则引擎、结果聚合、评论输出。不同模块之间通过结构化对象传参，不共享任何全局变量，这样单个模块能独立测试，也能独立替换。
与外部系统打交道的地方单独放在 adapters 目录。比如调用代码托管平台 API 的部分，就封装成独立的类。这么做的好处是，如果将来要兼容不同的 CI 环境或平台，只需要替换 adapter 这一个环节，核心分析逻辑完全不用动。
插件目录是我后期加上的。初衷是让团队能够在不修改核心代码的前提下，添加自己的专属检查。实现上借鉴了插件化扫描的思路，一个插件就是一个 Python 模块，暴露统一的接口，核心引擎自动加载。用了一段时间以后，这个机制成了整个项目里使用频率最高的部分，没有之一。
open-code-review/ ├── cli.py # 命令行入口，负责参数解析和环境识别 ├── config/ │ ├── settings.toml # 全局配置，比如目标分支、文件白名单 │ └── rules/ │ ├── builtin_rules.yaml │ └── team_rules.yaml ├── core/ │ ├── diff_parser.py # 解析 git diff，定位到文件和行号 │ ├── tree_parser.py # 基于 AST 做代码结构分析 │ ├── rule_engine.py # 规则的加载、匹配、优先级处理 │ ├── aggregator.py # 结果聚合、噪音过滤 │ └── reporter.py # 生成汇总报告和行级评论 ├── adapters/ │ ├── platform_api.py # 统一封装托管平台 API │ └── ci_env.py # 读取 CI 环境变量 ├── plugins/ # 团队自定义插件目录 └── tests/3. 核心模块的落地实现
3.1 变更解析：先让程序“看明白”改了什么
变更解析是后续所有分析的地基。这一步的错误率达到最高，也是最容易被低估的隐患。git diff 的标准格式大家都见过，但真正写解析器时，你才会意识到里面各种边界情况有多折磨人。
我设计的 diff 解析器核心是一个状态机，逐行读取 unified diff 文本。遇到 diff 开始标记时，识别出变更文件的两个路径，旧路径和新路径。遇到 hunk 头时，解析出旧文件起始行、新文件起始行和各自的行数。之后读取具体的行内容，行首是空格、加号还是减号，分别记录为上下文行、新增行和删除行。
最关键的是行号对齐。hunk 头里给的起始行号是旧文件的，但新增行的行号要落到新文件上。处理方式其实不复杂：维护两个计数器，旧文件行号和新文件行号同步递增，读到减号行时旧号加一，读到加号行时新号加一，读完加号行后两个行号会重新对齐。我来回验证了很多次这个逻辑，最终出的行号能和平台上的对应行完全对上。
这里分享一个我踩过的坑：文件重命名。在很多场景下，代码重构会导致整个文件的移动，diff 里会显示类似旧的路径删除、新的路径新增，如果用朴素的逻辑去判断，就会把整个文件当成新增代码，扫出一大堆无聊的规则命中，看的人血压都高了。我的解法是通过rename from和rename to这类标记识别出重命名情况，对重命名后的文件里的纯内容比对做过滤，只分析真正变化的行。这个处理合并到核心逻辑之后，崩溃性的误报瞬间降下来了。
文件类型过滤也在这个阶段完成。只分析设定的语言扩展名，是编译产物、锁文件、自动生成的文件一律跳过。这一步的意义在减少噪音。规则是死的，但审查对象的范围是活的，谁也不想看到生成文件里的几千行 minified 代码触发莫名其妙的问题。
3.2 规则引擎：把团队规范变成自动化检查
规则引擎的设计决定了一个审查工具是“能用”还是“好用”。我最初设计的规则结构非常简单，每条规则本质上就是一段文本描述加一个判定函数。
内置规则里最简单的就是“文本模式类”，比如检查是否存在调试输出语句。规则定义里写明要匹配的内容，和文件名过滤条件。这种规则实现成本低，准确率也比较高，因为调试输出这类特征非常明显。
复杂一点的是“AST 结构类”规则，这类检查跑在语法树上，能解答“这段代码的真实结构是什么”这种问题。比如团队规范里规定禁止用断言做参数校验，我就在规则函数里遍历函数定义，检查函数体前面几个语句的调用链，判断是否命中断言调用。这种规则用正则很难做好，但 AST 做起来很干净，准确率和召回率都让人放心。
规则定义我统一用文件组织，比如内置规则和自定义规则分成两个文件管理。每条规则字段包括规则 ID、严重级别、适用语言、触发分析和消息模板。其中消息模板非常关键，它直接决定了开发者看到的是有指导性的建议，还是一条冷冰冰的“违反 XX 规则”。我个人花了很多时间打磨消息文本，不是我矫情，而是在工程实践里，措辞的差异直接影响了开发者愿不愿意看你的评论。
rules: - id: NO_DEBUG_LOGGING severity: warning languages: [python, javascript, typescript] type: text_pattern pattern: "console.log(\"DEBUG" message: "检测到调试日志残留，请确认是否应该保留在提交中。" - id: AVOID_BARE_EXCEPT severity: error languages: [python] type: ast_pattern handler: check_bare_except message: "裸的 except 会吞掉意外异常，建议至少捕获一个具体的异常类型。"规则引擎在匹配前还会做一次“上下文过滤”。举个例子，某条规则说得对，但它只在业务代码目录里生效，对测试目录就应该放行。这个过滤逻辑写在规则的 metadata 里，引擎在加载规则时会一并读取。实际使用中，这种颗粒度的控制比简单按文件后缀过滤要实用得多，能有效避免“规则说不能用某某模式，但测试里所有地方都用这个模式”的尴尬情况。
3.3 评论聚合：审查噪音的克星
评论聚合这个模块，是我认为 open-code-review 区别于大多数“扫描器”的地方。很多人做自动化检查，目标就是把发现的问题全部列出来，但我后来发现这种做法在真实工作流里行不通。
先说最简单的噪音问题。一个新文件的几十行代码，可能同时触发四五条不同规则，如果每条都单独发评论，阅读体验非常糟糕。聚合模块做的第一件事就是按文件和行号合并。同一个代码片段，在同一个位置触发的多个问题，统统合并成一条评论里的几个要点。
第二个要处理的是跨文件重复。同一个问题模式经常出现在新引入的多个文件里，比如新加一批接口文件里都有某个相同的错误处理模式。如果逐文件报，开发者会觉得又臭又长。聚合结果里我会把它归为一类，写成一句“这类模式在以下 x 个文件中出现”，再给一个统一的修改建议。这种表达的信息量高得多。
第三个要处理的是严重级别过滤。内置规则集里，error 级别意味着必须修复或解释，warning 级别是建议关注，info 级别单纯是提示。默认输出全部，但我给了配置项，可以在配置里把 info 或者低优先级规则完全关掉，或者只在汇总评论里出现。很多团队拿到工具第一反应是关掉大部分默认规则，我太理解了，因为工具默认行为就应该保守，一行代码让它安静，它也绝不多嘴。
聚合结果最终会生成两层评论：一层是汇总大会，按问题的类型和严重级别给出整体说明；另一层是最关键的三五条行内评论。行内评论数量我可以直接写死上限，宁可漏掉一些次要建议，也不能让一次审查变成瀑布流。这是我自己在使用过程中定下的规矩：工具的评论如果超过十行，基本没人看全。
3.4 与 CI 平台打通：让机器人准时上班
一个本地跑起来很好的工具，如果不集成到自动流程里，价值会大打折扣。open-code-review 的 CI 集成设计核心原则是“零人工干预、结果自动回填”。
在 CI 环境里执行时，第一件事是识别环境变量。这些变量在大多数主流 CI 体系里都有，无非是仓库名字、MR 编号、当前分支、目标分支。不同的 CI 平台变量名不一样，所以适配器层做了统一封装，核心代码不关心具体跑在哪个平台。
第二步是构造 API 请求，拉取 MR 的 diff 和元信息。这里有一个值得强调的细节，在 CI 场景下，我强烈推荐使用只读的访问令牌而不是用仓库维护者的账号。我在实践里遇到过权限过大导致的安全隐患，后来就把权限收得很紧，只保留读取 MR 信息和提交评论这两项。这一点是硬性教训，做自动化一定要坚持最小权限原则。
推送评论时，我还在报告里附带一条特殊前缀，比如“这是一个自动生成的审查摘要”。这样开发者一眼就能区分机器人和人的评论优先级。CI 平台上也有一些自动出现的审查反馈机制，比如在 MR 详情里有机器人的评论，怎么做都不重要，重要的是形成稳定习惯。
我额外做了一个“审查环境感知”的小功能。当工具检测到它运行在本地模式，而不是 CI 模式时，它会把审查结果输出为一个本地报告文件，而不是尝试去调用远程 API 提交评论。这样开发者在本地提交前就能先跑一遍，发现问题在本地改掉，CI 上自然就少了一堆问题。这个功能投入产出比极高，强烈推荐想自建类似工具的人抄一下。
4. 从零搭建一个可用版本
4.1 初始化项目与依赖
在这个阶段，目标不是做完整工具，而是拼出一个能走通核心流程的最小版本。我的做法是先初始化一个 Python 工程，把依赖装好，让基本的 diff 解析能跑到结果。
依赖方面，我选了几个精确计算的库，一行没多余的。
文本解析用标准库就够，diff 本身就是文本，不需要第三方包。AST 分析用现成库，不同语言对应库不一样，我只装了最核心的两个语言解析库。请求库用的轻量 HTTP 客户端，用于和平台 API 打交道。配置解析用自带格式解析库，主要是我喜欢这类语法，写配置省事。
安装依赖这件事情看起来简单，但踩过坑。其中一个坑是 AST 库的版本兼容问题。某次直接按文档装了最新版本，结果发现接口签名跟文档对不上，一调用就报错。建议在搭建阶段就把版本锁定写进依赖描述文件里，别图省事用“最新版本”。环境一致是后续所有调试的基础，不然排查一个问题要花三倍时间。
pip install python-dotenv requests tree-sitter tree-sitter-python tree-sitter-javascript4.2 实现最小可用流程
我写最小版本时，先跑通了这样一个流程：本地给一个 diff 文件，解析出变更行列表，对每个文件跑一遍内置规则，输出一个 JSON 报告。这个流程串起来之后，剩余的工作就是在它上面不断加模块。
入口脚本的逻辑一点都不复杂。接收参数，如果是本地模式，直接读本地 diff 文件；如果是 CI 模式，调适配器拉取远程变更。然后初始化解析器，传入 diff 文本，得到变更对象。之后调用规则引擎，匹配出问题列表。最后交给聚合器和报告器输出结果。
这里有一个关键的抽象，所有模块都通过“标准数据结构”接缝。我定义了一个对象叫变更项，里面包含文件路径、新增行号、差异类型和原始代码行。后续所有规则都只认这个对象。这个抽象让插件开发和模块替换都非常顺畅，团队里的人后来写自定义规则时就写这个对象，完全不需要了解底层解析细节。
写最小流程时还要注意一个细节：错误处理必须全局兜住。规则引擎在解析代码时，经常遇到语法解析失败的情况，比如代码根本编译不过去。此时如果抛异常，整个流程就中断了。我的处理方式是每条规则的执行都被 try-catch 包裹，单条规则失败只记录日志，不影响其他规则继续跑。
def main(): args = parse_args() if args.local: diff_text = read_file(args.diff_file) else: diff_text = fetch_mr_diff(args.mr_id) changes = DiffParser().parse(diff_text) rule_engine = RuleEngine() findings = rule_engine.run(changes) report = Aggregator().aggregate(findings) if args.local: write_json_report(report, args.output) else: PlatformApi().post_mr_comments(report, args.mr_id)4.3 自定义规则：从官方默认到团队专属
开箱自带的规则只是一小碟开胃菜，真正让这个工具发光的是自定义规则。因为每个团队的工程规范都不一样，一个团队视作铁律的东西，在另一个团队可能根本无所谓。
自定义规则有两种写法，写得简单的是直接在配置里声明规则结构体。这种适合做“文本模式”检查。团队普遍规定代码中禁止出现某个工具残留的注释标记，这种直接配置就行，一行模式匹配就搞定。
复杂逻辑需要写 Python 插件。插件机制本身就是加载一个 Python 模块，然后读取模块里定义好的规则函数。函数签名很简单，接收一个变更对象，返回一个列表。我在文档里给插件作者提供了完整的对象字段清单和演示代码，大大降低了团队其他人写自定义规则的认知负担。
在这里多说一句，规则不是写得越多越好。我见过团队为了显摆工具能力，一口气加了几十条自定义规则，结果误报成堆，大家怨声载道。我的经验是：规则从两条最痛的开始，跑一两周，观察实际命中情况，确认误报率可控之后，再加下一条。规则的生命周期管理同样重要，过时的规则要敢于删掉，不然以后每个 PR 都要忽略一堆废话评论，比没有工具还难受。
5. 常见问题与排查心得
5.1 误报率居高不下怎么办
这是所有自动审查工具都会遇到的第一道坎。刚上线那一周，我自己也被自家工具搞得很心烦。一半以上的评论是没用的，团队里已经有人在群里吐槽“机器人乱报”。
排查之后发现，误报来源主要是几个方面。一是规则本身太笼统，比如“禁止使用全局变量”这种规则，在小型脚本里适用，在大型项目里到处都是全局状态，报得满屏都是，价值极低。二是规则没有做好文件名过滤，比如“禁止使用某某模式”这条规则，它对生产代码合理，但测试代码里就应该豁免。三是行号对齐存在偏差，导致评论定位在错误的行上。
解决方案我总结成了一套组合拳。第一，为每条规则增加“置信度”配置，置信度低的规则即使命中也不出现在评论里，只记录日志，观察一段时间后再决定要不要升级。第二，把所有规则按“阻断性”和“提示性”区分开。阻断性的必须修复才能回归，提示性的可能看起来有用，但是错报也比比皆是，默认就关掉。第三，建立基线机制。工具允许配置一个基线文件，凡是基线里已经存在的历史问题，新版本不再重复报警，只报告新增的问题。这个机制一上，误报数量立刻断崖式下降。
5.2 开发者不看机器评论怎么办
工具上线几个月后，我发现一个新的尴尬情况：评论确实发出来了，但很多开发者压根不点开看，直接在汇总评论下面留一句“机器人评论忽略”。这种感觉很难受，说明工具提供了信息，但没有“被消费”。
复盘下来，原因不在于工具本身，而在于反馈机制。开发者每天收到大量通知，机器人的评论如果和人的评论混在一起，很容易被淹没。我采取的办法是把机器人评论做成“入口式”的，而不是“信息流式”的。即在 PR 的描述区置顶一条简洁的汇总评论，写明这次审查发现了多少问题、有哪些严重级别、完整的详细报告通过链接访问。开发者只需要扫一眼摘要，就决定是否值得深入。
另外，我用了一个小技巧来提升阅读率：评论中尽量带具体的修法，而不是只说“有什么问题”。比如一条评论会写成“这里调用了裸异常捕获，会导致错误被静默吞掉，建议改成至少捕获 ValueError 这类具体异常类型”，这比“存在裸异常”有用得多。开发者看到的是可执行的建议，而不是审判，自然愿意跟进。
5.3 性能问题：大仓库分析卡死
open-code-review 跑在大仓库上时，遇到了非常现实的性能瓶颈。最典型的情况是，一个大 MR 包含几千行改动，涉及几十个文件，每个文件都要跑 AST 解析，结果一次审查要十几分钟，CI 流程都变慢了。
这里我做的第一件事是加并发。规则引擎处理不同文件之间没有依赖关系，所以用线程池并行处理是天然合适的。我调整之后，单个文件的平均耗时降得很明显。但同时我也意识到，并发再高，也不如少干活有效。于是加了更精细的过滤，只对变更真正的文件做解析，某些自动生成的大文件干脆不分析。
还有一个思路值得分享：缓存。对历史 MR 的 diff 结果做个缓存，如果本次 MR 的 diff 和上次分析过的某次 diff 完全一致，就直接复用上次的分析结果。这个场景不常见，但一遇到确实能省下大量时间。真正最有效的办法还是把大 MR 拆小，这是流程层面的优化，比工具层面所有优化都更管用。我在给团队的建议里明确写了：一个 MR 超过三百行，就应该拆。
5.4 安全与权限：机器人账号别给太大权力
安全这一点必须单独说。open-code-review 需要调用代码托管平台的 API 来读 MR、写评论，那么它就要持有一个访问令牌。如果这个令牌权限过大，比如能直接推送代码、能修改仓库设置，那一旦令牌泄露，等于把整个仓库的安全拱手让人。
我在实践里踩过一次坑。早期图方便，直接在 CI 配置里写了一个拥有仓库写权限的令牌，跑得倒是很顺畅。后来安全扫描工具提示这个令牌出现在日志里了，吓得我立刻撤销并换了新令牌。这件事之后我养成了习惯，为此专门给机器人创建了一个独立的受限账号，令牌只授予“读取 MR 信息、提交评论”这两项权限。此外，令牌从不出现在代码仓库里，而是放在 CI 平台的加密变量中。这个是底线。
6. 写在最后的经验之谈
open-code-review 从最初的“周末写着玩”，到后来真正在团队日常流程里稳定运行，中间经历的摸索比我预期的要多得多。回头看，最大的心得其实是：做代码审查自动化，技术占比最多只有三成，剩下七成都是围绕“人”在做设计。你写的每一条评论，面对的都不是代码，而是屏幕对面一位急着发版本的工程师。工具说话越精准、越克制、越有建设性，就越能得到尊重，反过来也能沉淀出更多有效的工程经验。
我现在给身边想尝试类似方案的朋友的建议，通常是这句话：先别急着堆规则，先把你最痛的那类问题自动化掉，再看团队是否买账。一个五分钟能跑完、每周帮你抓出两个真实问题的轻量小工具，远胜过一个功能庞大但没人愿意看的重型平台。下一步我个人还会继续扩展的方向，一个是把 AST 层面的人工经验更多地沉淀成可复用的规则包，另一个是尝试让机器人在开发者提出疑问时能结合上下文给出更细致的解释。代码审查永远需要人，但围绕它的那些低质量劳动，是真的可以被技术认真替代一次的。
