开源CLI代码审查工具：基于LLM与AST的自动化git diff分析

1. 项目概述：一个真正能落地的开源代码审查 CLI 工具

“open-code-review”这个名字乍看平平无奇，但拆开来看——open不是指“开源”这个宽泛概念，而是指开放上下文、开放权限边界、开放模型接入能力；code review也不是走形式的 PR 点赞，而是聚焦于可复现、可审计、可嵌入开发流的自动化审查动作。我从去年开始在三个不同规模的团队里推动这类工具落地，从最初用 shell 脚本拼凑 prompt，到后来基于 LLM 构建轻量级审查 agent，再到今天真正把“open-code-review”当作一个可交付、可配置、可审计的工程化 CLI 组件来设计和使用。它不是另一个 chat-in-terminal 的玩具，而是一个能插进 git commit-prep 阶段、能对接 CI 流水线、能在 code diff 上精准定位风险点的“审查协作者”。核心关键词CLI、LLM、code review、git全部落在实处：它必须是命令行原生的（不依赖 GUI 或 Web 页面），必须能灵活切换本地或远程 LLM（支持 Ollama、LM Studio、OpenRouter、自托管 vLLM 等），必须理解 git diff 的语义结构（而非简单丢一整段代码），且所有审查逻辑必须对开发者透明、可调试、可回溯。适合三类人直接上手：一线写业务代码的工程师（想在 push 前快速过一遍逻辑漏洞）、技术负责人（需要统一审查基线但不想强推 IDE 插件）、以及 DevOps/SRE 团队（希望把代码质量卡点前移到 pre-commit 阶段）。它解决的不是“有没有 AI”，而是“AI 审查结果能不能被信任、能不能被验证、能不能被追责”。

2. 整体设计思路与架构选型逻辑

2.1 为什么必须是 CLI，而不是 Web 或 IDE 插件？

很多人第一反应是：“做个 VS Code 插件不更方便？”——这恰恰是早期踩过的最大坑。我们试过基于 Codex CLI 封装的 VS Code 扩展，表面流畅，实际问题集中爆发在三处：一是上下文隔离失效，插件自动读取整个 workspace，导致 LLM 接收到大量无关文件（比如 node_modules、build 目录），不仅拖慢响应，更引发 prompt 注入风险（恶意 package.json 可诱导模型执行非预期行为）；二是权限边界模糊，插件默认拥有编辑器全部权限，一旦模型返回错误建议（如误删 import 语句），用户一键采纳就直接改写源码，缺乏中间确认与 diff 预览；三是不可审计性，所有请求都经由插件 SDK 中转，日志只记录“调用了某 API”，无法还原原始 diff 内容、prompt 模板、模型参数（temperature/top_p），出问题后根本没法复现。而 CLI 天然具备三大优势：进程隔离（每次运行都是干净环境）、输入可控（只传 git diff 输出，不碰文件系统其他部分）、日志可追溯（所有参数、输入、输出全量落盘）。我们最终定稿的open-code-review默认不写任何文件，只输出结构化 JSON + 彩色 ANSI 文本，所有修改建议都以git apply --reverse可撤销的 patch 格式呈现，这是信任建立的第一步。

2.2 LLM 接入层为何放弃“统一 API 抽象”，坚持多后端直连？

网络热词里频繁出现的 “codex cli”、“zcode cli”、“trae cli”，本质都是试图用一层抽象封装所有 LLM 提供商。但我们实测发现，这种设计在 code review 场景下反而成为性能瓶颈和故障源头。原因很实在：不同模型对token 计算方式、stop sequence 处理、JSON schema 强制能力、streaming 响应格式完全不一致。比如 DeepSeek-Coder-33B-Instruct 在处理长 diff 时要求显式设置max_tokens=2048，而 Qwen2.5-Coder-7B 则在temperature=0.1下会随机截断 JSON 输出；Ollama 的/api/chat接口返回done字段标识结束，而 OpenRouter 的 streaming 响应需靠data: [DONE]行判断。如果强行用统一 client 封装，要么牺牲精度（统一降级为 text-only 输出，丢失结构化能力），要么引入大量适配胶水代码（每个 provider 单独写 parser），维护成本远超收益。因此open-code-review的 LLM 层采用“协议直连”策略：

• 对 Ollama：直接调用http://localhost:11434/api/chat，用标准 JSON Schema 请求体；
• 对 LM Studio：复用其内置的 OpenAI 兼容 API（http://localhost:1234/v1/chat/completions），但禁用functions参数（因其不支持 tool calling）；
• 对 OpenRouter：严格按其文档要求添加HTTP_X_TITLEheader 和model字段，且强制response_format: { "type": "json_object" }；
• 对本地 vLLM：使用openai-pythonSDK，但重写base_url并关闭stream=True（因 code review 需要完整响应做语法校验）。
  这样做的代价是配置稍复杂（需为每个 backend 写独立 config block），但换来的是100% 控制权——你能精确看到每个请求发了什么、收到什么、耗时多少、token 数多少，这对审查结果可信度至关重要。

2.3 Git 集成不是“调个 git diff”，而是深度理解变更语义

很多同类工具把git diff --cached当作输入源就完事了。但真实开发中，一次 commit 往往包含多个逻辑变更：比如同时改了 API handler、加了 DTO validation、更新了 Swagger 注释。如果把整块 diff 丢给 LLM，模型大概率会混淆上下文，把 DTO 的字段校验误判为 handler 的空指针风险。open-code-review的核心突破在于diff 分片（diff chunking）+ 语义标注（semantic tagging）。它不依赖正则硬切，而是用git diff --no-color --unified=0获取最小粒度 hunk，再结合 AST 解析（对 JS/TS 用 SWC，Python 用 ast.parse，Java 用 JavaParser）识别每个 hunk 修改的代码元素类型（function declaration / class property / if condition / return statement）。例如一个修改了UserService.java的 hunk，若 AST 显示改动发生在@Transactional方法体内，且新增了Optional.ofNullable(...).orElseThrow()调用，工具会自动标注该 hunk 为["transactional", "null-safety"]，并在 prompt 中显式提示模型：“请重点检查事务边界内空值处理的完备性”。这种基于 AST 的语义增强，使 LLM 审查准确率提升约 37%（内部 A/B 测试数据），尤其对并发、事务、资源释放类缺陷识别效果显著。

2.4 “Open” 的真实含义：开放 prompt、开放规则、开放反馈闭环

标题里的 “open” 最容易被误解为“开源代码”。但对我们而言，真正的开放性体现在三个可触达层面：

• Prompt 开放：所有审查 prompt 模板（如security-audit.j2,performance-anti-pattern.j2）均存于~/.open-code-review/prompts/，支持 Jinja2 语法，用户可直接修改变量、增删 section、调整 temperature；
• 规则开放：内置 23 条静态规则（如 “禁止在循环内创建新对象”、“SQL 查询必须带 LIMIT”），每条规则对应一个 YAML 文件（rules/java-loop-object.yml），含pattern（AST 匹配表达式）、severity（block/warn/info）、suggestion（修复模板），支持用户新增规则并热加载；
• 反馈开放：每次审查后生成review-feedback.json，含input_hash（diff 内容 SHA256）、model_id、prompt_used（实际渲染后的完整 prompt）、output_raw（原始模型响应）。用户可将误报案例提交至feedback/目录，工具自动聚类相似 pattern，生成 retraining hint 提供给微调 pipeline。
  这种开放不是摆设——我们团队已基于用户反馈迭代了 4 版 prompt 模板，将 “N+1 查询” 类误报率从 62% 降至 8%。真正的 open，是让使用者能参与定义“什么是好代码”。

3. 核心细节解析与实操要点

3.1 安装与初始化：零依赖、纯二进制、跨平台

open-code-review采用 Rust 编写，编译产物为单文件二进制（Linux/macOS/Windows 全平台），不依赖 Python、Node.js 或 Java 运行时。安装只需两步：

1. 下载对应平台 release（如open-code-review-v0.8.3-x86_64-unknown-linux-musl.tar.gz）；
2. 解压后将open-code-review二进制放入$PATH（推荐~/bin/）。

提示：不要用cargo install！虽然支持，但会拉取 127 个 crate 编译，耗时 8+ 分钟且易因网络失败。release 包已静态链接所有依赖（包括 OpenSSL、zlib），解压即用。

初始化命令open-code-review init会创建默认配置目录~/.open-code-review/，结构如下：

~/.open-code-review/ ├── config.yaml # 主配置（LLM backend、git 设置、默认规则集） ├── prompts/ # 所有 prompt 模板（.j2 文件） ├── rules/ # 自定义规则定义（YAML） ├── models/ # 本地模型缓存（Ollama 拉取的模型 tarball） └── feedback/ # 用户反馈收集目录

首次运行会引导你选择 LLM backend（交互式菜单），并生成config.yaml示例。关键配置项说明：

• llm.backend: 必填，支持ollama/lmstudio/openrouter/vllm；
• llm.model: 模型名，Ollama 填deepseek-coder:33b，OpenRouter 填deepseek/deepseek-coder-33b-instruct；
• git.diff_context: 控制 diff 上下文行数，默认3（太小丢失语境，太大超 token 限制）；
• review.ruleset: 指定启用的规则集，如["java-security", "js-performance"]。

注意：config.yaml中绝不存储 API Key！OpenRouter 密钥通过环境变量OPENROUTER_API_KEY注入，Ollama/LM Studio 无需密钥，vLLM 使用--api-key启动参数。这是防止密钥泄露的第一道防线——配置文件本身可提交到团队共享仓库。

3.2 Prompt 设计哲学：用结构化约束替代自由发挥

LLM 在 code review 中最大的风险不是“答错”，而是“答偏”。我们观察到，当 prompt 仅写 “Review this code for bugs” 时，模型有 41% 概率输出泛泛而谈的“建议添加注释”“变量命名可优化”，完全偏离安全/性能等核心维度。因此open-code-review的 prompt 模板强制采用“Role-Task-Constraint-Output” 四段式结构：

• Role：明确模型身份，如 “You are a senior Java backend engineer with 10 years of experience in high-concurrency financial systems.”；
• Task：限定审查范围，如 “Focus ONLY on thread-safety issues, SQL injection risks, and N+1 query patterns. Ignore style, naming, or documentation.”；
• Constraint：施加硬性限制，如 “Output MUST be valid JSON array. Each item MUST have keys: 'line', 'severity', 'message', 'suggestion'. If no issue found, return empty array [].”；
• Output：提供严格 schema 示例，如{"line": 42, "severity": "block", "message": "Possible SQL injection via string concatenation", "suggestion": "Use PreparedStatement with parameterized queries."}。

这种设计让模型输出可预测、可解析、可校验。我们实测对比：自由 prompt 的 JSON 解析失败率 29%，四段式 prompt 降至 0.3%。更重要的是，它迫使模型聚焦具体问题——当你告诉它“只查 SQL 注入”，它就不会再提“建议用 Lombok 简化 getter”。

3.3 规则引擎：AST 驱动的静态检查与 LLM 动态推理协同

open-code-review不是纯 LLM 工具，而是“静态规则 + LLM 推理” 双轨制。静态规则（rules/）负责确定性问题：

• Java：检测String.getBytes("UTF-8")是否缺少 try-catch（字符编码异常）；
• Python：检查requests.get(url, verify=False)是否禁用证书校验；
• JavaScript：识别eval()或Function()构造函数调用。

这些规则由 AST 解析器匹配，毫秒级响应，100% 准确。而 LLM 负责模糊性问题：

• “这段 Redis 缓存逻辑是否存在缓存穿透风险？”
• “这个 Kafka 消费者配置是否会导致消息重复消费？”
• “DTO 到 Entity 的转换是否遗漏了 null 安全校验？”

关键创新在于规则触发 LLM 审查：当静态规则命中某模式（如检测到JdbcTemplate.query()调用），自动提取该方法调用上下文（前后 5 行代码 + 方法签名），构造专用 prompt 交由 LLM 深度分析。例如：

静态规则触发：JdbcTemplate.query() detected at UserService.java:87 → 提取上下文： 85: public List<User> searchUsers(String keyword) { 86: String sql = "SELECT * FROM users WHERE name LIKE '%" + keyword + "%'"; 87: return jdbcTemplate.query(sql, new UserRowMapper()); 88: } → LLM prompt： You are a security auditor. This Java code uses JdbcTemplate.query() with string concatenation. Is this vulnerable to SQL injection? If yes, suggest exact replacement using PreparedStatement. Output JSON only.

这种协同机制既保证基础漏洞零漏报，又赋予 LLM 精准上下文，避免其“瞎猜”。内部测试显示，双轨制比纯 LLM 方案漏报率降低 68%，误报率降低 52%。

3.4 Git 集成实战：pre-commit hook 与 CI 流水线嵌入

open-code-review的价值不在手动运行，而在无缝融入开发流程。以下是两个生产环境验证方案：

方案一：Git pre-commit hook（开发者本地）
在.git/hooks/pre-commit中写：

#!/bin/bash # 检查是否有 .java 或 .py 文件变更 if git diff --cached --name-only | grep -E '\.(java|py)$' > /dev/null; then echo "Running open-code-review on staged changes..." # 仅审查变更文件，超时 60 秒自动终止 if ! output=$(open-code-review review --staged --timeout 60 2>&1); then echo "❌ open-code-review failed:" echo "$output" exit 1 fi # 检查是否返回 block 级别问题 if echo "$output" | jq -e '.[] | select(.severity == "block")' > /dev/null; then echo "⚠️ Block-level issues found. Please fix before commit." echo "$output" | jq -r '.[] | select(.severity == "block") | "\(.line): \(.message)"' exit 1 fi fi

此 hook 在 commit 前自动运行，只审查本次 staging 的 .java/.py 文件，遇到block级问题（如 SQL 注入、空指针）直接中断 commit，强制开发者修复。我们团队使用后，PR 中安全类问题下降 73%。

方案二：CI 流水线集成（GitHub Actions / GitLab CI）
在.github/workflows/code-review.yml中：

- name: Run open-code-review run: | # 下载最新 release curl -L https://github.com/xxx/open-code-review/releases/download/v0.8.3/open-code-review-v0.8.3-x86_64-unknown-linux-musl.tar.gz | tar xz chmod +x open-code-review # 配置 OpenRouter 密钥（secrets） export OPENROUTER_API_KEY=${{ secrets.OPENROUTER_API_KEY }} # 审查本次 PR 的所有 diff ./open-code-review review --pr ${{ github.event.number }} --format markdown > review-report.md if: github.event_name == 'pull_request' - name: Post review comment uses: actions/github-script@v6 with: script: | const report = require('fs').readFileSync('review-report.md', 'utf8'); await github.rest.issues.createComment({ issue_number: context.issue.number, owner: context.repo.owner, repo: context.repo.repo, body: `## 🔍 AI Code Review\n\`\`\`markdown\n${report}\n\`\`\`` })

CI 运行时，工具自动拉取 PR diff，生成 Markdown 报告并作为评论发布到 PR 页面。报告包含：

• 每个问题的代码片段（带行号高亮）；
• severity 分级（block/warn/info）；
• 一键跳转到源码位置的链接；
• 修复建议的可复制代码块。
  开发者无需离开 GitHub 页面即可处理问题，评审效率提升 40%。

4. 实操过程与核心环节实现

4.1 从零开始一次完整审查：以 Java Spring Boot 项目为例

假设你正在开发一个 Spring Boot 用户服务，刚写完一个根据用户名搜索用户的接口，准备 commit。以下是完整操作链：

Step 1：编写代码并 stage

// src/main/java/com/example/UserService.java public List<User> searchUsers(String keyword) { String sql = "SELECT * FROM users WHERE name LIKE '%" + keyword + "%'"; return jdbcTemplate.query(sql, new UserRowMapper()); }

执行git add src/main/java/com/example/UserService.java。

Step 2：运行 open-code-review

open-code-review review --staged

工具自动执行：

• 调用git diff --cached --unified=0获取最小 hunk；
• 用 JavaParser 解析 hunk，识别出jdbcTemplate.query()调用及字符串拼接模式；
• 匹配静态规则java-sql-injection，触发 LLM 审查；
• 构造 prompt 并发送至配置的 LLM backend（如 Ollama 的 deepseek-coder:33b）；
• 解析模型返回 JSON，生成结构化报告。

Step 3：查看输出结果
终端显示彩色 ANSI 输出：

🔍 Reviewing 1 file: src/main/java/com/example/UserService.java ✅ Static rule 'java-sql-injection' matched at line 87 🧠 LLM analysis in progress... ──────────────────────────────────────────────────── [ BLOCK ] Line 87 Message: Critical SQL injection vulnerability via string concatenation Suggestion: Replace with PreparedStatement: String sql = "SELECT * FROM users WHERE name LIKE ?"; return jdbcTemplate.query(sql, ps -> ps.setString(1, "%" + keyword + "%"), new UserRowMapper()); ──────────────────────────────────────────────────── 💡 Info: No other issues found

同时生成review-report.json：

[ { "file": "src/main/java/com/example/UserService.java", "line": 87, "severity": "block", "message": "Critical SQL injection vulnerability via string concatenation", "suggestion": "Replace with PreparedStatement...", "rule_id": "java-sql-injection", "model": "deepseek-coder:33b", "prompt_hash": "a1b2c3..." } ]

Step 4：应用修复建议
复制 suggestion 中的代码，替换原实现。再次git add后运行open-code-review review --staged，输出变为：

✅ No issues found. Ready to commit!

此时git commit -m "fix: prevent SQL injection in user search"才能成功。

实操心得：第一次使用建议加--debug参数，它会输出完整 prompt、raw model response、AST 解析树，帮你理解工具决策逻辑。我们发现 80% 的“模型答错”其实是 prompt 设计问题，而非模型能力不足。

4.2 LLM Backend 配置详解：Ollama 与 OpenRouter 的实操差异

不同 backend 的配置直接影响审查质量与稳定性，以下是关键参数实测对比：

Ollama 配置要点：

• num_ctx必须 ≥ 16384，否则长 diff 会被截断；
• num_gpu设为 GPU 显存支持的最大值（如 24G 显存设num_gpu: 2），未设则默认 CPU 推理，速度慢 5 倍；
• 模型拉取后，用ollama show deepseek-coder:33b确认context_length与配置一致。

OpenRouter 配置要点：

• 必须设置response_format: { "type": "json_object" }，否则模型可能返回 markdown 格式；
• max_tokens建议设为 2048，设太高（如 4096）会导致响应延迟激增；
• 使用OPENROUTER_API_KEY环境变量，绝不在 config.yaml 中明文写密钥。

注意：所有 backend 均需在config.yaml中显式声明timeout（默认 30s）。我们曾因 OpenRouter 网络抖动导致请求卡住 2 分钟，阻塞整个 CI 流水线。现在timeout是强制校验项，超时自动 fallback 到本地 qwen2.5-coder:7b。

4.3 Prompt 模板定制：如何为团队技术栈定制专属审查视角

open-code-review的 prompt 存于~/.open-code-review/prompts/，默认提供java-security.j2、js-performance.j2等。但真正发挥价值的是定制化。以我们金融团队为例，需强化“资金安全”审查，步骤如下：

Step 1：创建新模板
新建~/.open-code-review/prompts/fund-security.j2：

You are a payment system security expert at a Tier-1 bank. Your task is to audit Java code for fund-related vulnerabilities ONLY. Context: - All monetary amounts are stored as BigDecimal (never double/float) - Every fund transfer must be logged with transaction ID and balance before/after - No external API call can bypass ACID transaction boundaries Review these code snippets: {{ diff_snippet }} Constraints: - Output ONLY valid JSON array. - Each item MUST have: 'line', 'severity' ('block'/'warn'), 'message', 'suggestion'. - If no fund-security issue, return []. - NEVER mention non-fund topics (e.g., logging format, UI). Example output: [{"line": 123, "severity": "block", "message": "Double used for amount calculation", "suggestion": "Replace double with BigDecimal.setScale(2, RoundingMode.HALF_UP)"}]

Step 2：注册规则
在~/.open-code-review/rules/fund-transfer.yml中：

id: fund-transfer pattern: | ast.type == "MethodDeclaration" and ast.name in ["transfer", "withdraw", "deposit"] and not ast.body.contains("BigDecimal") severity: warn suggestion: "All fund operations must use BigDecimal for precision"

Step 3：启用新规则集
修改config.yaml：

review: ruleset: ["fund-transfer", "java-security"] prompt: "fund-security.j2" # 指定使用新模板

Step 4：验证效果
对以下代码运行审查：

public void transfer(double amount) { // ❌ 应为 BigDecimal balance -= amount; }

工具立即返回：

[ { "line": 45, "severity": "block", "message": "Double used for amount calculation", "suggestion": "Replace double with BigDecimal.setScale(2, RoundingMode.HALF_UP)" } ]

这种定制让工具真正成为团队技术规范的“活文档”，而非通用 AI 的廉价包装。

4.4 安全加固：防止密钥泄露的三层防护机制

网络热词中高频出现的 “使用 LLM 时如何防止密钥等鉴权信息泄露”，直击要害。open-code-review采用三层防护：

第一层：输入过滤（Pre-processing）
在 diff 解析阶段，自动扫描所有 hunk 是否含敏感 pattern：

• 正则匹配：(?i)(password|secret|key|token|api_key|jwt|oauth)+ 等号/冒号后内容；
• AST 检测：Java 中System.setProperty("secret.key", "...")、Python 中os.environ["API_KEY"] = "xxx"；
• 若检测到，立即剥离该 hunk，不送入 LLM，并在报告中标记：

  ⚠️ Skipped hunk at UserService.java:120 (contains API_KEY assignment)

  这确保 LLM 永远看不到密钥。

第二层：Prompt 隔离（Inference-time）
所有 prompt 模板均含硬性指令：

NEVER output any credential, key, password, or token from the input code. If you detect such content, replace it with "[REDACTED]".

实测表明，即使输入含String apiKey = "sk-xxx";，模型输出也只会是String apiKey = "[REDACTED]";。

第三层：输出净化（Post-processing）
LLM 返回后，对 raw response 执行：

• JSON 字段值扫描：对message、suggestion中所有字符串，用 same regex 过滤并替换；
• 二进制安全：所有输出文件（JSON/Markdown）均用chmod 600设置权限，仅属主可读。

实操心得：我们曾故意在测试代码中插入AWS_ACCESS_KEY_ID=AKIA...，工具全程未将其送入模型，且报告中显示[REDACTED]。真正的安全不是“相信模型不泄露”，而是“让它根本没有机会看到”。

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

5.1 模型返回 JSON 解析失败：90% 是 prompt 约束缺失

现象：终端报错Failed to parse LLM response as JSON: invalid character，或review-report.json为空。

根因分析：

• 模型未严格遵守response_format: json_object（尤其 LM Studio/Ollama）；
• prompt 中缺少硬性 JSON 约束，模型返回 markdown 表格或纯文本；
• temperature过高（>0.5）导致输出不稳定。

排查步骤：

1. 加--debug参数重跑，查看raw_model_response字段；
2. 若输出为：

   Here's the issue: - Line 87: SQL injection risk Suggestion: Use PreparedStatement

   → 说明 prompt 缺少 JSON 约束，立即编辑prompts/java-security.j2，在末尾添加：

   Output MUST be valid JSON array. If no issue, return [].

3. 若输出为：

   {"issues": [{"line": 87, "message": "..."}]}

   → 说明 schema 不匹配，工具期望扁平数组[]，而非{issues: []}。修改 prompt 中的Output JSON only为Output JSON array only。

速查表：

5.2 审查结果与预期不符：AST 解析偏差导致上下文丢失

现象：模型指出“第 87 行存在空指针”，但该行只是return jdbcTemplate.query(...)，实际风险在keyword参数未校验。

根因分析：
AST 解析器提取上下文时，只取 hunk 内代码，未关联方法参数声明。keyword的 null 检查可能在方法入口处，但不在当前 hunk 中。

解决方案：

1. 启用--context-lines 10参数，扩大上下文范围；
2. 在config.yaml中配置：

   git: diff_context: 10 # 从默认 3 改为 10 include_method_signature: true # 自动提取方法签名

3. 对于 Java，工具会自动补全：

   public List<User> searchUsers(String keyword) { ... }

   并在 prompt 中加入：

   Method signature: public List<User> searchUsers(String keyword) Parameter 'keyword' is passed to this method. Check for null safety.

   这样模型就能关联到keyword可能为 null。

实操心得：我们发现 65% 的“上下文不足”问题可通过--context-lines 10解决。但不要盲目设为 100——diff 过大导致 token 超限，模型直接拒绝响应。10 是平衡点。

5.3 CI 流水线中审查超时：网络与模型负载双重瓶颈

现象：GitHub Actions 中open-code-review运行超时（>60s），CI 失败。

根因分析：

• OpenRouter 网络波动，单次请求耗时 >30s；
• Ollama 模型加载慢（首次调用需 15s 加载到 GPU）；
• diff 过大（如重构提交含 50 个文件）。

解决方案：

1. 配置超时分级：

   # .github/workflows/code-review.yml - name: Run open-code-review run: | # 本地模型 fallback if ! timeout 30s ./open-code-review review --pr ${{ github.event.number }}; then echo "⚠️ Primary LLM failed, falling back to local qwen2.5-coder:7b" OPENROUTER_API_KEY="" ./open-code-review review --pr ${{ github.event.number }} fi

2. 限制审查范围：

   # 只审查本次 PR 中的业务代码，排除 test/config open-code-review review --pr $PR_NUMBER --include "**/src/main/**/*.{java,py,js}" --exclude "**/test/**"

3. 预热模型（Ollama）：
   在 CI job 开头加：

   # 预热 deepseek-coder:33b，避免首次调用延迟 timeout 60s ollama run deepseek-coder:33b "say hello" > /dev/null 2>&1 || true

5.4 规则误报：如何精准调整 AST 匹配表达式

现象：静态规则java-null-check误报if (user != null) { ... }，认为“已校验无需再报”。

根因分析：
规则 YAML 中的pattern表达式过于宽泛，匹配了所有!= null检查，未区分“校验后是否使用”。

修正步骤：

1. 查看规则文件~/.open-code-review/rules/java-null-check.yml