团队里的代码评审，多数时候就是走过场。改天再review，上下文早就忘了，只能看看格式、命名、有没有明显的空指针，真正的逻辑漏洞、性能隐患、安全风险反而没人管。上线出问题，Code Review背锅，但大家心里都清楚，问题出在“人根本看不完”。

我一直在琢磨怎么把这活儿自动化。试了几条路线之后，最终落地的方案是OpenClaw + DeepSeek + Ollama 三件套，用来给 Spring Boot 项目做自动代码审查。这套流水线跑起来之后，每次提交代码，AI 会自动拉取变更、做静态分析、跑业务规则检查，最后生成一份带严重级别和修改建议的审查报告，直接推给我们。三个月跑下来，累计拦截了几十处真正值得改的问题，比之前一年人工评审发现的都多。

这篇帖子就把这套方案从架构设计到实际踩坑完整讲一遍，适合对 Spring Boot 项目有维护压力、又不想把代码上传到不明平台的人参考。

1. 三个工具的角色分工与整体架构设计

先说选型思路。市面上能自动 review 代码的工具不少，但多数是云端 SaaS，把整个仓库传上去，这对很多团队来说是无法接受的。我们需要的是一条可控的本地流水线，模型可以部分本地化，流程可以自定义，审查规则可以沉淀成团队资产。

最终确定的三件套，正好覆盖三个层次：

• OpenClaw负责编排。它是自动化 agent 框架，能调用本地命令、读写文件、访问 API，是整套流程的“调度中枢”。你可以把它理解成一套可以写流程脚本的机器人框架，git 操作、文件扫描、调用模型、输出报告，都由它来串。
• DeepSeek负责深度推理。代码审查里最难的环节是“理解业务逻辑”，比如发现某个 SQL 查询没有加索引、某个事务边界没控制好、某个敏感操作缺少权限校验，这需要模型有较强的代码语义理解能力。DeepSeek 在这里承担复杂逻辑分析的角色。
• Ollama负责本地化审查。所有代码先做脱敏处理，然后用本地模型跑第一轮机械检查：格式规范、命名风格、明显的反模式、常见漏洞特征库匹配。代码不出内网，这就是它存在的意义。

整体架构并不复杂，就是一条单向管道：

提交代码触发检查任务，OpenClaw 负责把代码变更拉下来；然后做分层审查，先本地模型后云端模型；最后汇总结果，标记严重级别，推送到团队群里。整套流程全部命令行可控，不需要额外的 Web 界面，这对用惯了命令行的后端团队来说非常友好。

考虑到工具的特性差异，我给这套编排设计了“先本地后云端、先机械后语义”的顺序，避免把什么问题都丢给大模型，既省成本又能提高问题定位的准确率。现在把架构定下来之后，下一步就是环境搭建和工具链打通。

2. 环境搭建与工具链打通的关键细节

很多人在这一步就被卡住了，其实拆开看都不难，主要是几个工具的配置容易互相干扰。我把整个过程按顺序拆开，照着做就能跑通。

2.1 OpenClaw 的初始化与工作目录规划

OpenClaw 建议用 Docker 方式部署，省去本机依赖的麻烦。工作目录我建议单独建一个code-review-workspace，里面分成repo、reports、rules、logs四个子目录，分别放代码仓库、生成报告、审查规则配置和运行日志。

这个目录规划看着不起眼，实际用起来非常重要。刚开始我把仓库直接放在临时目录，结果 OpenClaw 在多次运行后把历史版本和临时文件搞混了，审查范围经常乱掉。后来固定工作目录，每次审查前清空repo，再重新 clone，问题就彻底消失了。

OpenClaw 的配置集中在config.yaml，核心是声明工具权限。我们要允许它执行 git 命令（拉代码、看 diff）、文件读写（扫描代码、写报告）、调用 HTTP API（请求 DeepSeek）。权限配置的原则是最小化，不要给它超级权限，毕竟它操作的是代码仓库。我在配置里单独建了一个review-bot用户，只给repo目录的读写权限，其他目录一律拒绝。

2.2 Ollama 本地模型的安装与适配

Ollama 的安装没什么好说的，一条命令搞定。关键是选对模型。

代码审查场景，我推荐使用专门的代码模型而非通用对话模型。实测下来，通用模型在回答常识问题的时候表现不错，但让它严格按指定格式输出问题列表时，经常跑偏。代码模型在指令遵循和代码语义理解上更可靠，输出也更规范。

考虑到内网机器的资源限制，7B 级别的模型是性价比最高的选择，显存占用约 6GB 到 8GB，普通开发机就能跑。如果机器资源紧张，4B 级别的模型也能用，但对复杂逻辑的分析能力会明显下降。

还有几个模型参数建议固定下来，不然每次审查结果差异会很大：

• temperature设为 0.1，审查场景需要确定性输出，温度太高模型会“自由发挥”，同一个问题每次表述都不一样。
• num_ctx设为 8192，代码文件往往较长，上下文窗口太短会导致模型看不到关键代码就下结论。

2.3 DeepSeek API 接入与双模型协同策略

DeepSeek 走官方 API 接入，需要准备一个 API Key。配置的时候注意设置合理的超时时间，代码审查的代码块往往比较大，生成速度比普通对话慢，默认超时经常打断请求。我设置了 120 秒超时加 2 次重试，稳定性明显提升。

运行方式上，我的策略是让 Ollama 覆盖第一轮检查，DeepSeek 只处理 Ollama 标记为“存疑”的文件。这样设计的好处有两点：

一是成本控制。如果所有文件都走云端 API，一次全量审查要耗费大量 token，而大部分规范类问题本地模型就能发现，没必要让云端重复劳动。

二是质量分层。本地模型做机械式的特征匹配，它擅长的是“这段代码看起来哪里不对”；DeepSeek 做语义分析，它擅长的是“这段代码在业务场景下为什么不对”。两层互补，漏报率能降一个量级。

环境配置好之后，接下来要解决的核心问题就是审查流水线本身：从哪开始、怎么分析、如何输出结果，以及如何让这个过程不偏航。

3. 核心审查流水线的完整搭建：从 git diff 到报告输出

审查流水线是整个方案的心脏。很多人以为自动 code review 就是把代码全量丢给模型让它找问题，实际上完全不是这样。没有约束的模型审查，跟让一个实习生凭感觉看代码差不多——输出看着挺专业，但一细看全是空话。

我的做法是严格分阶段执行：先圈定审查范围，再提取上下文，然后分层执行检查，最后统一汇总输出。

3.1 变更范围圈定：基于 git diff 的精准定位

每次审查的第一步不是读代码，而是先搞清楚这次改了什么。我们只针对git diff涉及的代码块做审查，而不是对全仓库做扫描。全量扫描的问题有两个：一是耗时太长，二是会把历史遗留问题和新改动引入的问题混在一起，开发人员根本不知道哪些是“本次必须改的”。

具体流程按顺序执行：

1. 拉取最新代码，切换目标分支
2. 执行git diff main...HEAD获取当前分支相对主分支的全部变更
3. 过滤出 Java 文件和配置文件（Spring Boot 项目中application.yml的变更同样值得审查）
4. 统计变更文件清单，写入logs/changed-files.txt，后续所有步骤都以这个清单为准

实测效果：一次中等规模的迭代，改动文件数在 30 个左右，变更代码量在 3000 行上下，整套流水线在 8 分钟左右跑完，完全在可接受范围内。如果改成全量扫描，时间直接翻十倍，而且结果根本没法看。

3.2 上下文工程：让模型“看得懂”项目再下结论

模型审查最大的问题是“缺少上下文”。把一段代码裸丢给模型，它只能看到局部，看不到这个类是干什么的、被谁调用、属于哪条业务链路。所以我设计了一个上下文增强层，在真实审查前先把项目信息喂给模型。

对于每个待审查文件，我从工程里提取三类信息：

• 类级别注释和声明，帮助模型理解这个文件的核心职责
• import 列表，让模型知道这段代码依赖了哪些框架、版本，有些安全问题是版本依赖引起的
• 调用关系摘要，扫描同目录下引用该类的其他代码，梳理清楚之后，模型才知道这段代码在业务流程中的位置

这一步不涉及复杂的 AST 解析，直接用 grep 和简单的文本分析就能完成。准确率不需要 100%，能提供足够背景信息让模型做出合理判断就行。实测下来，加了上下文之后，模型对“误用 @Transactional”“缺少幂等控制”这类业务级问题的识别率提升了很多。

3.3 分层检查执行：本地规则过滤 + 云端语义分析

整个流水线的核心逻辑是两层检查，我分别称之为“规则层”和“语义层”。

规则层由 Ollama 本地模型执行，主要负责以下几类问题：

• 空指针风险：方法调用链上缺少 null 判断
• 资源未关闭：IO 流、数据库连接没有在 finally 或 try-with-resources 中释放
• 配置硬编码：敏感信息直接写在 Java 代码里
• 明显的性能反模式：循环内执行 SQL、大对象未释放

规则层输出的结果不是直接作为正式报告，而是打上“待确认”标记。所有规则命中的代码块会带上文件路径、行号、问题类型，交给下一层复核。

语义层由 DeepSeek 执行，输入包括：命中的代码块、代码上下文信息，以及明确的指令，比如判断这个规则命中是否成立，排除误报，补充规则层遗漏的更深层问题。这一步的输出才是真正有分量的内容。

我举个例子说明这种分层设计为什么有效。规则层发现某段代码在循环内调用了一个仓库方法，标记为“疑似 N+1 查询问题”。但它无法判断这是否真是 N+1——如果仓库方法有缓存，这就不是问题。语义层拿到的上下文恰恰包含了 Bean 定义和缓存注解信息，于是它作出了判断：“这个场景下不会触发真正的 N+1 查询，但循环内调用远程接口的做法仍有性能隐患，建议改为批量拉取”。这种深度的审查结论，单靠任何一层都做不到。

3.4 报告生成与严重级别定义

报告采用 Markdown 格式，方便直接在 Git 提交记录中查看。报告的核心结构分成四块，每块用表格呈现：

每条问题记录包含文件、行号、严重级别、问题描述、修改建议和参考代码片段。我特别强调所有报告必须给出参考代码片段，没有修改建议的审查意见等于没说。模型输出如果不带代码片段，OpenClaw 会自动追加一条“缺失修复建议”的标记，提醒审查人员这是未完成的检查项。

流水线跑通只是第一步。真正让这套方案从一个玩具变成团队工具，最关键的其实是规则库的积累和提示词的打磨，这部分值得单开一章记录。

4. 审查规则沉淀：让 AI 从“偶尔聪明”变成“稳定可靠”

这套方案运行一段时间之后，我发现一个规律：模型本身的审查质量是波动上升的，每次升级都能带来一波惊喜，但很多问题仍然会漏掉——尤其那些跟团队业务绑定的特殊规则。

靠模型自觉是远远不够的。要让它稳定可靠，就必须把审查逻辑从“模型临场发挥”变成“规则驱动”，两条腿走路：通用规则靠模型，定制规则靠规则文件。

4.1 规则文件的加载机制与优先级设计

我在工作区建了一个rules目录，所有规则以 YAML 格式存文件。OpenClaw 每次执行流水线时，会把该目录下所有规则文件读取后注入到提示词上下文中，并约定一个优先级：

• P0 级规则：跟业务强相关，比如“所有对外接口的请求参数必须做合法性校验”“所有事务方法必须在 Service 层，Controller 层禁止直接操作实体”
• P1 级规则：跟技术规范相关，比如“禁止使用@Autowired字段注入，改用构造器注入”“禁止在循环中调用远程服务”
• P2 级规则：跟代码风格相关，比如“新增的类必须补充类注释”“Utils 工具类必须私有构造器”

刚开始不需要贪多，先定义 5 到 8 条最核心的规则，跑一段时间再逐步加。规则太多模型会“消化不良”，反而漏掉关键问题。

4.2 提示词模板的设计要点：防止模型敷衍

提示词的写法直接决定审查质量。我在多次实验之后，总结出一套行之有效的提示词结构，每条审查请求至少包含四个部分：

第一部分是角色定义。明确告诉模型，它是一名 Spring Boot 项目的资深代码审查专家，关注点是业务正确性、性能、可维护性，而不是简单的语法问题。

第二部分是项目上下文。把前面提取的工程信息放进去，包括项目类型、使用的主要框架版本、当前审查的分支等。

第三部分是待审查代码。这里注意，不要直接把整个 class 文件丢进去，而是把变更代码块和它依赖的关键类摘要一起给模型。代码块超过 300 行时，拆成多段依次审查，避免超出上下文窗口导致后半段代码被忽略。

第四部分是输出格式约束。这一步最容易出问题。模型一旦不按格式输出，后续的报告解析逻辑就会崩。我要求的格式是严格的 JSON 结构，每个问题标注category（问题类别）、severity（严重级别）、line（行号）、reason（原因说明）、suggestion（修改建议）、code（参考代码）。

固定格式还有一个隐藏好处：方便后续做数据分析。我每两周统计一次所有问题的类别分布，发现在性能类别上的漏报率逐渐降低，说明规则库的沉淀确实在起作用。

4.3 冷启动阶段的规则入库标准

很多人在搭好流水线之后，不知道规则库应该怎么积累。我的经验是，前两周不要急着加规则，而是把精力放在“收集误报和漏报”上。

具体做法是：人工 review 完一个迭代之后，把 AI 没发现的问题统一标记为“漏报”，然后分析这类问题能否抽象成一条可执行的规则。如果能，就写入规则文件；如果不能，就记录下来继续观察。

举个例子。有一次 AI 没发现代码里自定义了一个RuntimeException的子类，但这个子类没有实现序列化接口，在服务间通信时会导致序列化异常。这个问题最初靠人工发现的，后来我把它抽象成一条规则——所有自定义异常类必须实现Serializable。写入规则库之后，后续类似问题 AI 都能准确命中。

规则库的积累是个持续过程，每两到三周做一次复盘和更新，三个月下来就能覆盖团队 80% 以上的典型问题。

5. 实测效果与三类高频误报的排查记录

老规矩，先说结论再讲过程。这套方案在我们一个中等规模的 Spring Boot 服务（约 30 个接口，20 多个核心业务类）上跑了三个月，累计完成 40 多次自动审查，共拦截确认问题 80 余处，其中 Blocker 和 Critical 级别有 15 处。这个数量比之前全年人工评审发现的问题还多。

但有价值的不只是发现问题的数量，更是在反复调优过程中沉淀下来的三类高频误报排查经验，它们直接决定这套工具能否长期被团队接受。

5.1 误报一：@Transactional自调用问题被反复漏报

这是第一周就发现的高频问题。规则层命中率非常低，后来我分析了原因：自调用问题在代码层面没有任何特殊标记，本地模型识别不出来，而语义层只能基于规则层传过来的“可疑点”判断，规则层没报，语义层自然不会看。

解决方案是给规则层加一个前置扫描任务：在把代码喂给模型之前，先用固定模式匹配所有加了@Transactional的方法，然后检查方法内部是否有调用同类其他方法的逻辑。如果有，直接标记为“疑似自调用”，交给 DeepSeek 判断是否真的导致事务失效。

这个前置扫描任务后来扩展成了“规则前置处理器”，所有需要精确匹配的检查项都走这个逻辑，不再依赖模型做模式匹配。

5.2 误报二：构造器注入和字段注入被混为一谈

第二类高频误报是 Spring Bean 注入方式的问题。规则层总是把@Autowired字段注入标记为“违反构造器注入规范”，但实际代码中有某些类被 Spring 通过反射实例化，字段注入是唯一可行方案。

这类误报处理的关键不是删掉规则，而是给规则加“豁免条件”。我在规则文件中增加了exclude_patterns字段，允许配置豁免场景。比如代码中类名包含Factory、Config或Aspect时，字段注入规则跳过检查。

误报如果不处理，团队会逐渐对报告失去信任。花两周时间把这些边界条件补齐，打磨出一份精准的报告，比一次性输出一百条无效建议有价值得多。

5.3 误报三：Mock 代码和测试代码被当成生产代码审查

最后一个典型误报来源是测试目录里的代码。起初流水线只通过git diff过滤文件后缀，没有区分src/main和src/test。结果测试代码里的 Mock 引用、断言写法经常触发各种规范类规则，团队每周都要在报告里忽略一堆无关紧要的警告。

处理方式是在流水线里加了目录过滤。变更文件来自src/test目录时，只做 P2 级别检查，重点看断言是否合理、是否有断言遗漏；来自src/main目录时，执行完整的三层检查。这个调整让报告噪音率显著下降，团队对工具的信任度也随之回升。

6. 接入团队流程的落地建议与避坑经验

前面讲的都是技术实现，但真正把自动 review 接入团队日常开发，是会卡在流程上的。分享几条我们在落地过程中的实用经验。

6.1 从“自动拦截”改为“建议参考”，逐步建立信任

强烈建议不要把自动审查直接设为合并请求的硬性门禁。第一次跑这套流水线，团队第一反应一定是不信任，认为 AI 在“制造噪音”。最好的方式是从“建议参考”开始跑两周，让团队在人工 review 的同时看看 AI 的发现，逐渐建立信任。

两周之后，把 Blocker 和 Critical 级别的问题设为合并警告，但不强制拦截。再跑一个月，如果报告的准确率稳定在 80% 以上，再考虑将关键级别问题设为合并阻断项。我们目前采取的正是这种策略——阻断项只保留两条核心规则（存在安全漏洞、存在必然导致线上事故的缺陷），其余问题只提示不阻断。

6.2 成本控制与性能调优的实测数据

一个月全量接入后，API 的调用成本完全在可接受范围内，核心原因就是分层设计极大地压缩了云端模型的调用量。只有规则层命中且无法判断的问题才会走云端分析，一次常规审查的调用量稳定在一个很低的水平。

Ollama 服务端建议至少分配 8GB 内存，加载 7B 模型后的推理速度约为每秒 20 到 40 个 token，单次完整流水线运行时间在 5 到 8 分钟。如果团队追求更快的反馈速度，可以在流水线前加一层增量逻辑：只对最近一次提交的变更做规则层的快速检查，语义层延迟到合并请求创建时再执行。

6.3 敏感信息过滤：这套工具兜底的安全底线

代码审查场景里有个容易被忽略的问题：如果代码里有数据库密码、API Key 等敏感信息，直接传给云端模型就是事故。我在流水线里加了一个脱敏层，所有本地文件和提交信息在发送到 DeepSeek 之前，先做一次正则扫描，匹配到敏感字段后替换为占位符。

匹配的字段包括：password字段、secret字段、access-key、token、Authorization头信息。替换逻辑很简单，命中的值的长度大于 6 位就替换为******。有了这层保障，我们才敢放心让代码走云端分析。

我强烈建议每个想搭这套流水线的人都加上这个步骤。AI 审查再聪明，也不能以泄露密钥为代价。

6.4 一条关于模型选择的最终建议

如果你所在的团队也打算尝试这条路线，我给一个最省心的建议：先用 Ollama 配合开源的代码专用模型把流水线跑通，不要一上来就依赖云端 API。先把流程、规则、报告格式这些基础设施理顺，再接入 DeepSeek 提升语义分析能力。

这样做的原因很实际：本地模型的自由调用不受限，跑错不心疼，适合反复调优；等规则库稳定了，再把有区分度的问题交给云端模型，效果会好很多。

回头看我搭这套系统的过程，最让我意外的反而是一个非技术因素：团队里最抵触“AI 审查代码”的同事，在连续看过几份报告之后就改变了态度，原因是一次他没注意到的空指针风险，AI 在合并前就标出来了。工具说到底只是放大镜，规则和审查维度才是真正决定它能看多远的东西。