代码审查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 层面的人工经验更多地沉淀成可复用的规则包另一个是尝试让机器人在开发者提出疑问时能结合上下文给出更细致的解释。代码审查永远需要人但围绕它的那些低质量劳动是真的可以被技术认真替代一次的。