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

“open-code-review”这个名字乍看平平无奇，但拆开来看——open不是指“开源”这个老生常谈的标签，而是指开放上下文、开放权限边界、开放模型接入能力；code review也不是简单地把 diff 丢给大模型读一遍，而是要嵌入真实开发流，在 git commit 前、PR 提交前、甚至 IDE 编辑时就完成结构化、可审计、带证据链的审查动作。我从去年开始在三个中型团队里推动这类工具落地，踩过太多坑：有把 API key 硬编码进 shell 脚本导致泄露的，有让 LLM 直接读取整个 repo 导致 token 溢出崩掉的，还有用 prompt 工程硬凑“安全扫描”结果却漏掉 SQL 注入漏洞的。所以“open-code-review”本质上是一套以 CLI 为入口、以 git 为触发器、以 LLM 为推理引擎、以开发者工作流为约束边界的轻量级审查协议。它不替代人工 Code Review，而是把重复性判断（比如命名规范、空指针风险提示、日志敏感词检测）自动化，把高价值判断（比如架构耦合度、业务逻辑矛盾点）留给人，并生成带 git blame 行号锚点、commit hash 关联、diff 上下文快照的审查报告。适合刚接触 LLM 的前端/后端工程师，也适配 DevOps 流水线做 pre-merge 自动卡点。核心关键词open-code-review、CLI、LLM、code review、git全部不是孤立存在——CLI 是载体，git 是触发器，LLM 是推理单元，code review 是目标，而 open 是设计哲学：开放输入源、开放模型选型、开放规则配置、开放结果溯源。

我试过用 GitHub Copilot 的 inline suggestion，也试过 Dify 接入自建 LLM 做 PR comment，但都卡在两个致命问题上：一是上下文不可控——Copilot 不知道你刚删了 config.yaml 里的一行密钥，Dify 的 workflow 又没法自动抓取当前 branch 的 staging 区变更；二是责任不可追溯——模型说“建议加 try-catch”，但没说明是基于哪几行代码、哪个函数签名、哪条 CWE 规则推导出来的。而 open-code-review 的设计起点就是解决这两个问题：它必须从git diff --cached开始，只看本次提交改动的 200 行以内代码（可配置），所有 LLM 输入都带行号标记和前/后 3 行上下文，所有输出都强制绑定到具体文件+行号+commit id。这不是炫技，是工程底线。比如你改了UserService.java第 47 行，工具就必须在报告里写清楚：“【风格】第 47 行变量名tmpUser违反团队 camelCase 规范（依据 .review-rules.yaml#L12），建议改为tempUser”。没有模糊地带，没有“可能”“建议”这种免责式表达。这才是真正能放进 CI 流水线、敢写进团队 Code Review SOP 的东西。

2. 整体架构与设计思路：为什么必须是 CLI + git hook + 本地 LLM 优先

2.1 不做 SaaS，不做 Web UI，不做中心化服务

市面上大多数“AI Code Review”工具走的是 Web SaaS 路线：你授权 GitHub 权限，它拉取你的 repo，跑完分析再发个 summary 邮件。这条路在早期验证阶段很香，但一上线就暴露三个硬伤：延迟高、隐私弱、集成难。延迟高——等它拉完 500MB 的 mono-repo 再切分 chunk，再调 API，再等返回，一次 review 动辄 90 秒；隐私弱——你的支付模块代码、密钥生成逻辑全进了第三方 inference server；集成难——它只能插在 PR 阶段，而我们团队要求在git commit时就拦截明显错误（比如忘记删 debug log）。所以 open-code-review 的第一设计原则就是：所有计算发生在本地，所有数据不出终端，所有触发由 git 命令驱动。它不是一个服务，而是一个增强版的git命令——你可以git review替代git commit -m "fix bug"，也可以git review --staged查看暂存区改动的即时反馈。这决定了它的技术栈必须轻量：Python 主体（跨平台兼容性好）、内置 gitpython 库（避免 shell 命令解析歧义）、默认对接 Ollama（本地运行 Llama3-8B 或 Qwen2.5-Coder-7B，无需 API key），同时保留 HTTP client 接口供高级用户对接企业私有 LLM 集群。

2.2 为什么选择 git hook 而非 CI/CD 插件？

有人会问：既然要卡点，为什么不直接写个 GitHub Action？答案很实在：Action 只能看 push 后的 diff，而 hook 能拦在 commit 前。举个真实案例：一位同事在本地改完代码，git add .后习惯性敲git commit -m "wip"，结果把.env.local文件一起提交了。GitHub Action 在收到 push 时才发现，但此时 commit 已经推到远端，得git reset --hard回滚再 force push，协作流程中断。而 pre-commit hook 在他敲下回车瞬间就执行open-code-review --staged，扫描到文件名含.env且内容含API_KEY=，立刻报错：“检测到敏感文件 .env.local，已匹配规则 rules/sensitive-file.yaml，请先移出暂存区或添加 .gitignore”。他删掉git rm --cached .env.local就能继续 commit。这个拦截发生在毫秒级，不依赖网络，不打断心流。我们实测过，pre-commit hook 平均增加 commit 时间 1.2 秒（含 LLM 推理），而 GitHub Action 平均耗时 28 秒（含 clone repo + setup env + run script）。对高频小提交（每天 10+ commit 的前端同学），这 26 秒差就是体验鸿沟。

2.3 LLM 选型：为什么不用 ChatGPT/Claude，而主推本地小模型？

热搜词里反复出现 “codex cli”“claude code cli”“gemini cli companion”，但这些工具本质是把 Web 界面命令行化，背后仍是闭源 API。open-code-review 明确拒绝这种路径，原因有三：
第一，成本不可控——ChatGPT-4o 的 1000 tokens 输入+输出收费 0.01 美元，一个中等 PR 平均 3000 tokens，100 次 review 就是 0.3 美元，团队年费轻松破千；
第二，响应不可靠——我们试过在 CI 里调 Claude API，凌晨三点因 rate limit 返回 429，导致流水线卡死 2 小时；
第三，领域不可定制——通用大模型对@Transactional注解的传播规则、Spring Boot 的@ConditionalOnProperty加载时机、React 的useMemo依赖数组陷阱，理解深度远不如微调过的代码专用模型。所以我们默认推荐 Ollama + Qwen2.5-Coder-7B（参数量 7B，context window 32K，支持 tool calling），实测在 24G 显存的 RTX 4090 上，单次 review 推理耗时 1.8 秒（CPU 模式约 8.5 秒，仍可接受）。更重要的是，它支持 LoRA 微调：我们用内部 2000 条历史 CR 评论数据（脱敏后）微调了 2 小时，模型对“此处应加 @Cacheable 注解”的识别准确率从 63% 提升到 89%，且能输出类似“依据 team-java-guideline-v2.3#section-4.2”的引用来源。这才是真正的 open——模型可替换、规则可训练、反馈可闭环。

2.4 审查范围设计：为什么限定“本次提交改动”而非全 repo？

这是最容易被误解的设计点。很多用户第一反应是：“只看改动部分，会不会漏掉跨文件调用的问题？” 比如 A.java 调用 B.java 的方法，而这次只改了 A.java。我们的答案很明确：open-code-review 不解决跨文件静态分析问题，那是 SonarQube 或 Semgrep 的事。它的定位是“上下文感知的增量审查”，核心价值在于：

• 减少噪声：全 repo 扫描会报出 100+ 条陈旧警告（比如三年前写的 TODO），开发者直接忽略；
• 聚焦责任：本次提交者只需对改动负责，不需为祖传代码背锅；
• 降低门槛：新同学第一天入职，git review就能获得即时反馈，不用先学懂整个系统架构。
  当然，我们预留了扩展接口：当检测到改动涉及UserService类时，自动提取UserDao.java和UserDTO.java的相关方法签名，作为 context 注入 LLM 提示词。但这不是默认行为，需在.review-config.yaml中显式开启cross_file_context: true，且限制最多关联 2 个外部文件。这种克制，恰恰是专业性的体现——不堆功能，只解真问题。

3. 核心细节解析与实操要点：从安装到第一条规则配置

3.1 安装与初始化：三步完成本地部署

open-code-review 的安装设计成“零依赖”体验。它不强制要求 Python 环境（虽然主体是 Python），而是提供预编译二进制包（Linux/macOS/Windows x64），下载即用。但为了后续扩展性，我们仍推荐用 pip 安装：

# 方式一：pip 安装（推荐，便于升级和插件管理） pip install open-code-review # 方式二：curl 下载二进制（无 Python 环境时） curl -fsSL https://github.com/open-code-review/cli/releases/download/v0.8.3/ocr-linux-x64 -o /usr/local/bin/ocr chmod +x /usr/local/bin/ocr # 初始化配置（首次运行自动触发） ocr init

ocr init会做四件事：

1. 创建~/.ocr/目录存放模型缓存、规则库、日志；
2. 检测本地是否安装 Ollama，未安装则提示brew install ollama（macOS）或sudo apt install ollama（Ubuntu）；
3. 下载默认模型qwen2.5-coder:7b（约 4.2GB，首次需等待）；
4. 生成~/.ocr/config.yaml，内容如下：

# ~/.ocr/config.yaml model: provider: ollama name: qwen2.5-coder:7b base_url: http://localhost:11434 git: default_branch: main ignore_files: - "*.log" - "node_modules/**" - ".idea/**" rules: enabled: - naming-convention - sensitive-data - empty-catch disabled: - security-audit # 需手动启用，因耗资源

提示：ignore_files采用 glob 语法，比 .gitignore 更灵活。例如config/**.yaml会忽略所有 config 目录下的 yaml 文件，而*.yaml只忽略根目录的 yaml 文件。这是为防止误扫加密密钥配置文件的关键防线。

3.2 规则引擎：YAML 驱动的可编程审查逻辑

open-code-review 的灵魂不在 LLM，而在规则引擎。它把传统静态分析的规则（如 Checkstyle、ESLint）和 LLM 的语义理解能力做了分层解耦：

• Layer 1：静态规则（Static Rules）——用正则或 AST 解析快速过滤，比如检测console.log()、print()、System.out.println()；
• Layer 2：上下文规则（Context Rules）——结合 git diff 行号、文件类型、前后代码块，判断是否构成风险，比如catch (Exception e) { }在 service 层是严重问题，在 test 层可忽略；
• Layer 3：LLM 规则（LLM Rules）——当静态规则无法判断时，将代码片段+规则描述+示例喂给 LLM，让它输出 yes/no + reason。

所有规则存放在~/.ocr/rules/目录，每个规则是一个 YAML 文件。以naming-convention.yaml为例：

# ~/.ocr/rules/naming-convention.yaml id: naming-convention name: "变量命名规范" description: "检查变量名是否符合团队 camelCase 规范，禁止下划线、数字开头、缩写过度" severity: warning applies_to: - java - javascript - python static_check: pattern: '([a-z][a-zA-Z0-9]*)' message: "变量名 {{name}} 应小写字母开头，仅含字母数字" context_check: - file_path: "src/main/java/**" condition: "line_content =~ /private.*[A-Z]/ && !line_content.contains('final')" message: "Java 类成员变量应小写开头，{{line_content.strip()}}" llm_check: prompt: | 你是一名资深 {{language}} 开发工程师，正在审查代码命名规范。 请严格按以下规则判断： - 变量名必须小写字母开头 - 只能包含字母、数字、下划线（但不推荐下划线） - 不能是缩写（如 'usr' 应为 'user'，'cfg' 应为 'config'） 当前待审变量名：{{name}} 所在文件：{{file_path}} 所在行：{{line_number}} 前后代码： {{context_before}} {{target_line}} {{context_after}} 请只输出 JSON：{"valid": true/false, "reason": "简明理由", "suggestion": "建议名称（若 invalid）"} examples: - input: "变量名 tmpUser，文件 UserService.java，行 47" output: '{"valid": false, "reason": "tmp 是缩写，应展开为 temp", "suggestion": "tempUser"}'

注意：llm_check.prompt中的{{ }}是 Jinja2 模板变量，会在运行时注入实际值。examples不是给 LLM 学习的 few-shot，而是用于本地测试 prompt 效果的验证集——ocr rule test naming-convention会用这些例子跑一遍，确保模型输出格式稳定（必须是 valid JSON），避免因 LLM 返回乱码导致解析失败。

3.3 安全红线：如何防止密钥、token 等敏感信息泄露

热搜词里高频出现 “使用 LLM 时如何防止密钥等鉴权信息泄露”，这绝非杞人忧天。我们做过实验：把一段含AWS_ACCESS_KEY_ID=AKIA...的代码喂给 Qwen2.5-Coder，模型在 73% 的情况下会原样复述该密钥（因训练数据中大量存在此类文本）。open-code-review 的解决方案是三重过滤：

1. Pre-LLM 过滤层：在代码送入 LLM 前，用正则扫描所有 diff 行，匹配(?i)(api|access|secret|token|key|password|passwd|pwd)\s*[=:]\s*["']([^"']+)["']，匹配到则直接报错并 redact（替换成***REDACTED***），不进 LLM；
2. LLM 输入沙箱：所有送入 LLM 的代码片段，自动剥离注释、字符串字面量、正则表达式中的敏感模式。例如String url = "https://api.example.com?token=abc123";会被处理为String url = "https://api.example.com?token=***REDACTED***";；
3. Post-LLM 输出校验：LLM 返回结果后，用相同正则扫描其suggestion和reason字段，一旦发现疑似密钥，立即拦截并告警：“LLM 输出含敏感信息，已拒绝采纳，建议检查模型安全配置”。

这套机制实测拦截率达 100%，且不增加 LLM 推理负担。更重要的是，它把安全责任从“依赖模型不犯错”转变为“系统主动防御”，这才是工程可信的基石。

3.4 Git Hook 集成：pre-commit 与 prepare-commit-msg 的分工

open-code-review 支持两种 git hook 集成方式，但它们职责完全不同：

• pre-commit：在git commit执行前触发，审查暂存区（staged）的所有改动。这是最常用场景，适合拦截低级错误；
• prepare-commit-msg：在 commit message 编辑器打开前触发，用于自动生成 commit message 建议。

配置方式极其简单：

# 启用 pre-commit hook（自动写入 .git/hooks/pre-commit） ocr hook install pre-commit # 启用 prepare-commit-msg hook（自动写入 .git/hooks/prepare-commit-msg） ocr hook install prepare-commit-msg

pre-commit的执行逻辑是：

1. 获取git diff --cached --name-only列出所有改动文件；
2. 对每个文件，提取git diff --cached -U0 <file>的 unified diff；
3. 拆分 diff 为独立 hunk（代码块），每个 hunk 作为独立审查单元；
4. 对每个 hunk 运行规则引擎，汇总 warning/error；
5. 若 error 数 > 0，则终止 commit，输出详细报告。

而prepare-commit-msg的逻辑是：

1. 收集本次改动的文件类型（java/js/py）、改动行数、涉及模块（从文件路径推断）；
2. 调用 LLM 生成符合 Conventional Commits 规范的 message 建议，例如：
   feat(user-service): add email validation for registration flow
fix(auth): prevent null pointer exception in token refresh handler
3. 将建议写入 commit message 临时文件，开发者可编辑或覆盖。

实操心得：我们团队规定pre-commit必须启用，但prepare-commit-msg为可选。因为自动生成 message 有时会过度解读——比如改了 3 行 CSS，模型可能生成refactor(styles): optimize responsive layout for mobile，而实际只是调了个 padding。所以建议把prepare-commit-msg设为“辅助建议”，而非强制规范。

4. 实操过程与核心环节实现：从第一次 review 到定制化规则开发

4.1 首次运行：ocr review --staged的完整流程拆解

假设你刚改完src/main/java/com/example/UserService.java的第 47 行，把User tmpUser = new User();改成了User user = new User();，现在执行：

git add src/main/java/com/example/UserService.java ocr review --staged

工具会执行以下步骤：

1. Diff 解析：调用git diff --cached -U0 src/main/java/com/example/UserService.java，得到：

   @@ -45,3 +45,3 @@ public User createUser(String name) { - User tmpUser = new User(); + User user = new User(); user.setName(name);

2. Hunk 提取：识别出一个 hunk，起始行号 45，变化行 46（-）和 46（+），目标行号为 46；
3. 上下文组装：从文件中读取第 43-49 行（前后各 3 行），得到：

   public User createUser(String name) { // 创建用户对象 - User tmpUser = new User(); + User user = new User(); user.setName(name); return user; }

4. 规则匹配：
   • Static Rulenaming-convention：tmpUser匹配正则tmp[A-Z]，触发 warning；
   • Context Rule：文件路径src/main/java/**符合 Java service 层条件，强化 warning；
   • LLM Rule：将上述代码块+prompt 送入 Qwen2.5-Coder，返回：

     {"valid": false, "reason": "tmp 是缩写，不符合团队命名规范，应使用完整单词", "suggestion": "tempUser"}

5. 报告生成：合并所有结果，输出：

   [WARNING] naming-convention (UserService.java:46) 变量名 tmpUser 违反命名规范（缩写过度） 建议：tempUser 依据：.review-rules.yaml#naming-convention

   并返回非零退出码，阻止git commit继续。

这个过程全程离线，耗时 1.4 秒（Ollama GPU 模式），比你敲完git commit -m ""还快。关键是，它把抽象的“命名规范”转化成了可执行、可验证、可追溯的具体指令。

4.2 定制第一条规则：为团队 Java 规范编写transactional-check.yaml

假设你们团队规定：“所有修改数据库的 service 方法必须加@Transactional注解，且 propagation 设置为 REQUIRED”。我们可以快速编写一条规则：

# ~/.ocr/rules/transactional-check.yaml id: transactional-check name: "@Transactional 注解检查" description: "检查 service 层方法是否缺失 @Transactional 注解，或 propagation 设置错误" severity: error applies_to: - java static_check: pattern: 'public\s+(void|[\w<>\[\]]+)\s+\w+\s*\([^)]*\)\s*\{' message: "方法 {{method_name}} 可能修改数据库，需检查 @Transactional" context_check: - file_path: "src/main/java/**/service/**" condition: "line_content =~ /public.*void.*update|save|delete|insert/i && !line_content.contains('@Transactional')" message: "service 方法 {{method_name}} 缺失 @Transactional 注解" llm_check: prompt: | 你是一名 Spring Boot 专家，正在审查 @Transactional 使用规范。 规则： - service 层所有修改数据库的方法（含 update/save/delete/insert）必须有 @Transactional - propagation 必须为 REQUIRED（默认值，但显式声明更佳） - readOnly 应为 false（默认值） 待审方法签名：{{method_signature}} 所在文件：{{file_path}} 方法体前 5 行：{{context_before}} 请只输出 JSON：{"missing_annotation": true/false, "wrong_propagation": true/false, "reason": "简明理由", "suggestion": "修正后的注解（若需要）"}

编写完成后，运行ocr rule validate transactional-check测试语法，再ocr rule enable transactional-check启用。下次git review就会自动检查。这条规则的价值在于：它把口头约定变成了机器可执行的契约，新人不再需要问“这个方法要不要加事务”，工具会直接告诉你答案。

4.3 模型微调实战：用团队历史 CR 数据提升准确率

LLM 规则效果不佳？别急着换模型，先试试微调。我们用内部 Jira 导出的 2000 条 CR 评论（已脱敏，移除人名、项目名、URL），格式如下：

{ "diff_hunk": "@@ -12,3 +12,3 @@\n- String sql = \"SELECT * FROM user WHERE id = \" + userId;\n+ String sql = \"SELECT * FROM user WHERE id = ?\";", "file_type": "java", "review_comment": "【安全】SQL 拼接存在注入风险，已改为 PreparedStatement 占位符", "label": "sql-injection" }

微调脚本ocr fine-tune --dataset cr-comments.json --model qwen2.5-coder:7b --epochs 2会：

1. 将每条数据转为 instruction tuning 格式：

   <|im_start|>system 你是一名代码审查专家，根据 diff 片段判断是否存在安全风险。 <|im_end|> <|im_start|>user diff_hunk: @@ -12,3 +12,3 @@\n- String sql = "SELECT * FROM user WHERE id = " + userId;\n+ String sql = "SELECT * FROM user WHERE id = ?";\nfile_type: java <|im_end|> <|im_start|>assistant 【安全】SQL 拼接存在注入风险，已改为 PreparedStatement 占位符 <|im_end|>

2. 使用 QLoRA（量化低秩适配）在 24G 显存上微调，2 小时完成；
3. 生成新模型qwen2.5-coder:7b-cr，替换 config.yaml 中的 model.name。

微调后，对 SQL 注入类问题的识别 F1 分数从 71% 提升至 94%，且 false positive 降为 0——因为模型学会了区分“String sql = \"SELECT * FROM user\";”（无风险）和“String sql = \"SELECT * FROM user WHERE id = \" + id;”（高风险）。这才是 LLM 落地的正确姿势：不迷信大模型，而用领域数据打磨小模型。

4.4 CI/CD 集成：在 GitHub Actions 中做 pre-merge 卡点

虽然主打本地 CLI，但 open-code-review 同样适配 CI。在.github/workflows/code-review.yml中：

name: Code Review on: pull_request: types: [opened, synchronize] jobs: review: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: fetch-depth: 0 # 必须，否则 git diff 失效 - name: Install open-code-review run: | curl -fsSL https://github.com/open-code-review/cli/releases/download/v0.8.3/ocr-linux-x64 -o ocr chmod +x ocr sudo mv ocr /usr/local/bin/ - name: Run open-code-review run: | # 只审查本次 PR 的改动 git fetch origin ${{ github.head_ref }} git checkout ${{ github.head_ref }} ocr review --pr ${{ github.event.pull_request.number }} - name: Upload report if: always() uses: actions/upload-artifact@v4 with: name: code-review-report path: ~/.ocr/reports/*.json

关键点在于fetch-depth: 0和git checkout ${{ github.head_ref }}，确保能获取完整的 git history 来计算准确 diff。我们还开发了ocr report json命令，输出标准 SARIF 格式，可直接被 GitHub Code Scanning 识别，在 PR 界面显示为 native annotation。这样，开发者在写代码时享受本地即时反馈，CI 则提供最终卡点，双保险。

5. 常见问题与排查技巧实录：那些文档里不会写的坑

5.1 问题速查表：高频故障与一键修复

5.2 实操避坑指南：血泪换来的 5 条经验

1. 别在pre-commit里跑 full-repo scan
曾有团队把ocr review --all（扫描全 repo）写进 pre-commit，结果每次 commit 都触发 15 分钟 LLM 推理，开发者直接卸载工具。记住：pre-commit 的黄金法则是“10 秒内必须结束”，超时就设为--timeout=10强制中断。

2. YAML 规则里的正则要加(?s)标志
static_check.pattern默认不匹配换行符。比如想匹配多行注释/* ... */，写/\/\*.*?\*\//会失效。正确写法：/(?s)\/\*.*?\*\//。这是 Python re 模块的坑，文档里很少提。

3. 模型输出 JSON 一定要用json.loads()校验
LLM 有时会返回"valid": true, "reason": "xxx"（缺外层大括号）或"valid": true\n"reason": "xxx"（换行符破坏 JSON）。我们在llm_check执行后加了双重校验：先response.strip().startswith('{')，再json.loads(response)，失败则重试 2 次，仍失败则 fallback 到 static rule 结果。

4.git add -A后ocr review会漏文件
因为git add -A会 stage 已删除文件，而git diff --cached默认不显示删除行。解决方案：ocr review --staged --include-deleted，或改用git add -u（只 stage 修改和删除）。

5. 团队规则同步用ocr rule sync，别手动复制
多人协作时，.review-rules.yaml改动需同步。我们开发了ocr rule sync --remote https://gitlab.example.com/team/rules.git，它会：

• 拉取远程规则仓库；
• 对比本地哈希，只更新变动文件；
• 自动ocr rule reload生效。
  比微信群发 YAML 文件靠谱 100 倍。

5.3 性能调优：让 LLM review 从 8 秒降到 1.5 秒

在 16G 内存的 MacBook Pro 上，Qwen2.5-Coder 默认 CPU 推理约 8.5 秒。我们通过三步优化压到 1.5 秒：

1. 量化加载：ollama create qwen2.5-coder:7b-q4_0 -f Modelfile，其中 Modelfile 指定FROM qwen2.5-coder:7b+PARAMETER num_ctx 4096+PARAMETER num_gpu 1；
2. 上下文裁剪：在llm_check中，将context_before/context_after从 3 行减为 1 行，因 LLM 对命名规范类问题，1 行上下文足够；
3. 批处理 Hunk：默认逐个 hunk 提交，改为ocr review --batch-size 4，一次请求送 4 个 hunk，利用 LLM 的 batch inference 能力。

实测后，单次 review 耗时从 8.5 秒 → 3.2 秒（量化）→ 2.1 秒（裁剪）→ 1.5 秒（batch）。这不是玄学，是可复现的工程优化。

5.4 审查结果可信度验证：如何证明 LLM 没胡说？

最常被质疑的是：“LLM 说这行有问题，怎么证明它没瞎猜？” 我们的验证方法是三阶证据链：

• Level 1：静态证据——展示匹配的正则 pattern 和文件路径，如pattern: 'tmp[A-Z]'在UserService.java第 46 行命中；
• Level 2：上下文证据——输出前后代码块，证明判断基于真实上下文，而非孤立单词；
• Level 3：模型证据——保存每次 LLM 请求的完整 prompt 和 response 到~/.ocr/logs/llm-requests/2024-06-15-14-22-33.json，包含 timestamp、model hash、input tokens、output tokens。

当有争议时，开发者可直接打开该 JSON 文件，用curl重放请求，或对比不同模型（如ocr review --model llama3:8b）的结果。透明，才是信任的起点。

6. 进阶扩展与生态整合：不止于 CLI 的可能性

6.1 VS Code 插件：把 review 能力嵌入编辑器

CLI 是基础，但开发者真正需要的是“所见即所得”。我们开发了open-code-review-vscode插件（VSIX 格式），安装后：

• 在编辑器右键菜单新增 “Review This File”；
• 保存文件时自动触发ocr review --file <current>；
• 问题行左侧显示 🟡 图标