企业官网建设流程全解析

1. 项目概述：一个真正能落地的开源代码审查 CLI 工具到底长什么样？

“open-code-review”这个名字乍看平平无奇，但拆开来看——open不是指“开源”这个老生常谈的标签，而是指开放上下文、开放规则、开放反馈路径；code-review也不是简单地把 PR 描述扔给大模型跑一遍，而是要嵌入真实开发流、理解 Git 提交语义、识别变更意图、区分技术债与设计权衡。我从 2021 年开始在团队里推动 LLM 辅助代码审查，试过十几种方案：从 GitHub Copilot 的 inline suggestion，到用 LangChain 搭建的 review agent，再到接入 Dify 做 workflow 编排——最后全推倒重来，原因就一个：它们都不是“CLI”，更不是“open”。真正的 open-code-review 必须满足三个硬性条件：第一，它得是命令行工具，能直接塞进git commit -m "feat: add retry logic"后面跑；第二，它不依赖任何中心化服务，本地模型、远程 API、甚至离线量化模型都能插拔替换；第三，它的审查结论必须可追溯、可审计、可复现——不是“这段代码可能有 bug”，而是“retryDelayMs在第 47 行被硬编码为1000，而上游config.retry.maxDelayMs默认值为5000，存在配置漂移风险（依据：commit 3a8f2d1 中 config schema v2.3 定义）”。这背后不是调个 API 那么简单，它需要精准解析 Git diff 的 AST 结构、构建跨文件的符号引用图、对齐代码风格规范（比如 PEP8 或 Google Java Style）、甚至识别出“这个 try-catch 里吞掉了 InterruptedException”这种 JVM 层级的反模式。我见过太多团队把 LLM 当成万能胶水，结果 review 报告里混着“建议把if (x != null)改成Objects.nonNull(x)”，却漏掉了x其实是@Nullable注解字段、根本不能这么改——这种错误不是模型能力问题，是工具没把上下文喂对。所以 open-code-review 的核心，从来不是“用不用 LLM”，而是“怎么让 LLM 看懂你正在写的代码，而不是它自己幻想出来的代码”。

2. 整体架构设计与关键决策逻辑

2.1 为什么必须是 CLI？而不是 Web UI 或 VS Code 插件？

很多人第一反应是：“CLI 太反人类了，现在谁还敲命令？”——这话在个人小项目里成立，但在企业级交付场景里恰恰相反。我们团队去年上线的支付网关重构项目，CI 流水线里跑了 37 个检查项，其中 22 个是静态扫描，剩下 15 个全是人工 code review checklist。后来我把 open-code-review 接进 pre-commit hook，要求所有 PR 必须通过ocr --strict --policy=security才能触发 CI。结果第一个月，安全类问题拦截率从 12% 跃升到 68%，最典型的是AES/CBC/PKCS5Padding硬编码 IV 的漏洞，之前靠人眼 review 根本没人注意到——因为 IV 是写在注释里的十六进制字符串，reviewer 自然跳过。CLI 的不可替代性就在这里：它能无缝咬合在 Git 生命周期里。git commit触发 pre-commit，git push触发 pre-push，git merge前跑一次 final-scan，每个环节都卡住问题。Web UI 再漂亮，也解决不了“开发者懒得点进去查”的人性问题；VS Code 插件再智能，也绕不开“有人用 Vim、有人用 JetBrains、还有人用 Notepad++ 写 shell 脚本”的现实。CLI 是唯一能跨编辑器、跨 OS、跨 IDE 的通用接口。更重要的是，CLI 天然支持管道（pipe）和重定向。比如我们生产环境有个高频场景：git diff HEAD~1 | ocr --mode=diff --format=json | jq '.issues[] | select(.severity=="critical")'——这条命令直接从 Git diff 流里提取出高危问题，连临时文件都不用生成。而 Web UI 做不到这点，它必须先存文件、再上传、再等响应，延迟动辄秒级。CLI 的另一个隐藏价值是审计友好。所有操作都有完整命令日志，ocr --debug输出的每一步输入输出都带时间戳和哈希值，法务合规部门要查某次 release 的审查记录，直接翻.git/logs/refs/heads/main里的 commit message 就行，不用登录后台数据库导日志。

2.2 “Open” 的三层含义：开放模型、开放策略、开放反馈

很多人把 “open” 理解成“开源代码”，这没错但远远不够。open-code-review 的 “open” 是立体的：

• 开放模型层（Open Model）：不绑定任何特定 LLM。它内置三套适配器：一是本地模型适配器（支持 llama.cpp、llamafile、Ollama），二是标准 OpenAI 兼容 API（如 DeepSeek、Qwen、GLM 的官方 endpoint），三是企业私有 API（需配置--api-base https://llm.internal.company/v1）。关键在于，它用统一 prompt template 抽象层屏蔽底层差异。比如 temperature 参数，在 OpenAI API 里叫temperature，在 Ollama 里叫temperature，但在某些国产模型 SDK 里叫top_p——工具内部会自动做映射，用户只管写ocr --temperature 0.3。我实测过，同一份 diff 输入，在 Qwen2-7B（Ollama）和 DeepSeek-Coder-V2（API）上，审查结论的一致性达 89%，远高于直接调用裸 API 的 62%。这是因为工具强制所有模型走同一套 system prompt：“你是一名资深后端工程师，专注 Java/Spring Boot 项目，审查时必须引用具体行号、变量名、Git commit hash，并标注问题类型（security/bug/performance/maintainability）”。

• 开放策略层（Open Policy）：审查规则不是写死在代码里，而是 YAML 文件驱动。默认策略包policies/default.yaml只有 3 条基础规则：禁止明文密码、禁止空 catch、禁止 System.out.println。但你可以随时新增policies/security.yaml：

  rules: - id: "SEC-001" name: "JWT token validation" description: "Verify JWT signature and expiration before processing" severity: critical patterns: - file: "**/*.java" code: "JwtParserBuilder.*build().parse.*" context: 3 remediation: "Use JwtDecoderFactory to validate signature and exp claim"

  这些规则会被编译成 AST 匹配器，比正则更可靠。比如SEC-001规则能准确识别Jwts.parser().setSigningKey(key).parseClaimsJws(token)，但不会误报new JwtParserBuilder()这种未完成调用。策略文件支持继承和覆盖，子公司可以基于总部策略加一条policies/subsidiary-a.yaml：“所有 SQL 查询必须使用 PreparedStatement”，而无需修改主程序。

• 开放反馈层（Open Feedback）：审查结果不是单向输出，而是可交互的闭环。ocr --interactive模式下，每条 issue 都带编号，你可以输入i1 accept接受，i2 reject --reason "this is intentional fallback"拒绝并留痕，i3 ask --question "why is this thread-safe?"直接生成追问 prompt 发给 LLM。所有操作记录在.ocr_feedback.json里，后续ocr --resume能接着上次中断的位置继续。这解决了 LLM 最大的痛点：它不知道你为什么拒绝某条建议。传统方案里，模型永远在猜“用户是不是没看到”，而 open-code-review 把反馈显式结构化，下次 review 时自动注入：“历史记录显示，用户三次拒绝‘建议用 Optional 替代 null check’，原因均为‘下游 SDK 不兼容’，本次跳过该类建议”。

2.3 为什么选择 Git 作为唯一上下文源？而非 IDE 或文件系统

这是整个设计里最反直觉、也最关键的决定。几乎所有同类工具都试图从 IDE 获取 AST 或从文件系统读取整个 project，但 open-code-review 坚持只信任 Git。原因有三：

第一，Git 是事实唯一源（Single Source of Truth）。IDE 的索引可能滞后（比如刚改完 pom.xml 但 Maven 没 reload），文件系统可能有未提交的脏文件（.DS_Store、node_modules），但git diff输出的内容是精确、可重现、可验证的。我们曾遇到一个诡异 case：某次 review 报告说“UserDao.java第 123 行缺少 null check”，但开发者坚称没改过这行。一查 Git log，发现是 CI 机器上残留了旧版本的UserDao.java，而 IDE 显示的是新版本——只有 Git diff 能证明“这次提交确实没碰这行”。

第二，Git 提供了天然的变更语义。git show --name-only HEAD告诉你改了哪些文件，git diff --no-prefix HEAD~1告诉你具体增删了什么，git log -n 1 --pretty=%B HEAD给出 commit message——这三者组合起来，就是 LLM 理解“为什么改这里”的黄金三角。比如 commit message 写着 “fix NPE in payment flow”，而 diff 里新增了if (payment != null) { ... }，LLM 就能推断出这是修复型变更，应重点检查 null safety；如果 message 是 “refactor order service”，而 diff 里大量方法拆分，那就要关注接口契约一致性。没有 Git，这些语义就丢失了。

第三，Git 保证了跨环境一致性。开发机、CI 服务器、审计沙箱，只要 clone 同一个 repo，运行ocr得到的结果必然一致。而依赖 IDE 的方案，在 Mac 上跑和 Windows 上跑结果可能不同（路径分隔符、换行符），依赖文件系统的方案，一旦npm install更新了node_modules，AST 就变了。我们做过压测：100 次ocr --diff在同一 commit 上运行，结果哈希值 100% 一致；而基于文件系统扫描的同类工具，波动率高达 17%。

3. 核心模块实现与关键技术细节

3.1 Git Diff 解析引擎：从文本 diff 到语义 AST 的转换

git diff输出的是纯文本，但 LLM 需要结构化上下文。open-code-review 的 diff parser 不是简单地按+/-分割行，而是构建三层语义模型：

• Layer 1：语法块识别（Syntax Block）
  用正则预处理原始 diff，识别出@@ -12,5 +12,7 @@这样的 hunk header，提取出原文件行号范围（12-17）、新文件行号范围（12-19）。关键技巧是：hunk header 里的行号是“逻辑行号”，不是“物理行号”。比如删除空行后，实际文件行号会偏移，但 hunk header 保持不变。parser 会维护一个 offset map，把 diff 行号映射回真实文件位置。

• Layer 2：语言感知切片（Language-Aware Slicing）
  根据文件扩展名加载对应语言的 grammar（内置 ANTLR4 语法树，支持 Java/Python/JS/Go/Terraform）。对每个 hunk，提取出受影响的 AST 节点。例如 Java diff 里新增一行return user.getName();，parser 不仅知道这是第 47 行，还知道它属于MethodDeclaration节点下的ReturnStatement，父节点是getUser()方法。这样 LLM 的 prompt 就能写成：“请审查以下 Java 方法的返回语句：public String getName() { return user.getName(); }”，而不是干巴巴的“第 47 行写了 return user.getName();”。

• Layer 3：跨文件引用分析（Cross-File Reference）
  这是最难的部分。当 diff 修改OrderService.java，而它调用了PaymentClient.java里的方法，parser 会自动抓取PaymentClient.java的当前版本（git show HEAD:src/main/java/com/company/PaymentClient.java），构建调用链。实测发现，32% 的严重问题（如 NPE、资源泄漏）都涉及跨文件逻辑，单纯看单文件 diff 会漏掉。我们的解决方案是：对每个被修改的方法，用javap -c反编译字节码，提取invokestatic指令的目标类和方法名，再匹配源码。虽然慢一点（增加 120ms 延迟），但准确率从 63% 提升到 98%。

提示：不要试图用grep或ast-grep替代这套引擎。我们试过，ast-grep --lang java --pattern '$X.getName()'在复杂泛型场景下会漏匹配，比如Optional<User>.map(u -> u.getName())就识别不了。而基于字节码的方案，不管源码怎么写，只要最终调用链存在，就一定能捕获。

3.2 LLM 交互协议：如何让大模型“看懂”代码审查任务

LLM 不是代码专家，它是语言模型。让它做好 code review，关键不是选多大的模型，而是设计正确的交互协议。open-code-review 采用四段式 prompt 结构：

1. Role & Context（角色与上下文）

   You are a senior Java engineer with 10+ years experience in high-frequency trading systems. You are reviewing a Git diff for a Spring Boot microservice. The diff shows changes between commit a1b2c3 and d4e5f6.

2. Input Format（输入格式约束）

   Input will be provided in this exact format: --- FILE: OrderService.java --- @@ -45,3 +45,5 @@ + public void processOrder(Order order) { + if (order == null) throw new IllegalArgumentException(); + // ... rest of method

3. Output Schema（输出结构强制）

   Output ONLY valid JSON array. Each issue MUST have: - "id": unique string (e.g., "JAVA-NULL-001") - "file": exact filename from diff header - "line": exact line number in NEW version (e.g., 46) - "severity": one of ["critical", "high", "medium", "low"] - "message": concise problem description (< 100 chars) - "recommendation": actionable fix (< 150 chars) - "code_snippet": 3-line context around the issue (original + new lines)

4. Validation Rules（校验规则）

   DO NOT output anything outside JSON array. DO NOT invent line numbers not in the diff. DO NOT suggest fixes that require changing files not in the diff.

这套协议解决了三个致命问题：一是防止模型幻觉（hallucination），比如建议“在UserService.java里加 null check”，而UserService.java根本没在 diff 里；二是确保输出可解析，避免{"issues": [...]}和[...]混用；三是强制聚焦，不让模型扯“Spring Boot 版本太老”这种无关话题。我们对比过，用这套协议，Qwen2-7B 的 JSON 输出合规率从 41% 提升到 99.2%，而 GPT-4 Turbo 从 87% 提升到 99.8%——说明协议设计比模型本身更重要。

3.3 安全敏感信息防护机制：密钥、token、密码的零泄露保障

“使用 LLM 时如何防止密钥泄露”是热搜词里最高频的问题。open-code-review 的答案很直接：在数据离开本地前，就把它 scrub（清洗）干净。它不依赖 LLM 的“别看密码”指令，而是用确定性规则提前过滤：

• Rule 1：正则预筛（Regex Pre-Filter）
  对 diff 内容运行 12 类正则，覆盖主流密钥格式：

  # AWS Access Key (?i)(aws|amazon)[-_ ]?access[_- ]?key[_- ]?(id)?\s*[:=]\s*["']?([A-Z0-9]{16,20})["']? # Slack Token (?i)slack[_- ]?token\s*[:=]\s*["']?(xox[bpa]|xoxr|xxoo)[a-zA-Z0-9-]{20,}["']? # Generic Password (?i)(password|passwd|pwd)\s*[:=]\s*["']?[^"\n\r]{8,}["']?

  匹配到的整行被替换为REDACTED_BY_OCR_<HASH>，hash 值存入.ocr_redactions.json供审计。

• Rule 2：AST 语义脱敏（AST Semantic Sanitization）
  正则会漏掉动态拼接的密钥，比如String key = "sk_" + env + "_test";。这时 AST 分析就起作用了：对所有字符串字面量（StringLiteral），计算其 Shannon entropy。熵值 > 4.5 的字符串（如"sk_live_abc123def456"）被标记为高熵字符串，无论是否匹配正则，一律脱敏。我们测试过，GitHub token、Stripe key、Firebase secret 的熵值都在 4.8-5.2 之间，而普通业务字符串（如"user_not_found"）熵值仅 2.1-2.9。

• Rule 3：上下文隔离（Context Isolation）
  即使密钥被意外传入 LLM，也要确保它不出现在输出里。我们在 prompt 末尾加了一条铁律：

  IMPORTANT: If input contains any redacted tokens (e.g., REDACTED_BY_OCR_abc123), DO NOT mention them, DO NOT infer their type, DO NOT suggest "remove this token". Just ignore them completely.

  实测表明，GPT-4 在看到REDACTED_BY_OCR_f8a2b1时，100% 不会提及其存在；而未经此约束的模型，有 37% 概率会说“检测到一个被遮蔽的密钥，请检查”。

注意：不要相信“LLM 不会记住 prompt 里的内容”这种说法。我们做过实验，把REDACTED_BY_OCR_f8a2b1放进 prompt，然后问“这个字符串是什么”，GPT-4 Turbo 有 12% 概率还原出f8a2b1。所以脱敏必须在数据进入 LLM 前完成，这是底线。

4. 实操全流程与参数配置详解

4.1 五分钟快速上手：从安装到首次 review

第一步，安装。支持三种方式，推荐按顺序尝试：

1. 一键安装（macOS/Linux）

   curl -fsSL https://get.open-code-review.dev | sh # 自动下载二进制、校验 SHA256、放入 /usr/local/bin/ocr

2. Ollama 本地模型（零依赖）

   # 先装 Ollama（官网下载 dmg 或 deb） ollama pull qwen2:7b ollama run qwen2:7b # 验证能跑

3. Docker（隔离环境）

   docker run -it --rm \ -v $(pwd):/workspace \ -w /workspace \ ghcr.io/open-code-review/cli:latest \ ocr --diff --model ollama/qwen2:7b

第二步，初始化配置。运行ocr init，它会：

• 创建~/.ocr/config.yaml，填入默认模型路径
• 检测 Git 仓库根目录，生成.ocrignore（类似.gitignore，但用于排除 review 文件）
• 下载默认策略包到~/.ocr/policies/

第三步，跑首次 review。进入你的 Git 仓库，执行：

# 查看最近一次 commit 的 diff 并 review ocr --diff HEAD~1 # 或 review 工作区未 commit 的变更 ocr --diff # 输出带颜色的终端报告（默认） # 加 --format=markdown 生成 README.md 风格报告 # 加 --format=jsonl 输出每行一个 JSON，方便 grep 或 jq 处理

你会看到类似这样的输出：

[CRITICAL] OrderService.java:46 - Null check missing before calling user.getName() Recommendation: Add 'if (user == null) throw new IllegalArgumentException("user cannot be null");' Code Snippet: public void processOrder(Order order) { → if (order == null) throw new IllegalArgumentException(); // ... rest of method

4.2 关键参数深度解析：每个 flag 的真实用途

ocr有 23 个参数，但日常用到的核心就 7 个。下面逐个拆解真实场景：

• --diff [commit]：指定 diff 范围。--diff（工作区）、--diff HEAD（暂存区）、--diff HEAD~1（上一个 commit）。注意：--diff main不是和 main 分支比较，而是和main这个 commit object 比较——必须用--diff origin/main才对。我们吃过亏，有次误用--diff develop，结果 review 的是 develop 分支的 HEAD，而不是当前分支和 develop 的差异。

• --model [name]：模型标识符。支持ollama/qwen2:7b、openai/gpt-4-turbo、deepseek/coder-v2。关键技巧：用ocr --list-models查看已知模型，它会扫描~/.ollama/models/和~/.ocr/models/。如果你把llama-3-8b.Q4_K_M.gguf放进~/.ocr/models/，就能用--model local/llama-3-8b调用。

• --policy [path]：策略文件路径。--policy security加载内置安全策略，--policy ./my-policy.yaml加载自定义策略。避坑：策略文件必须是 UTF-8 编码，BOM 字节会破坏 YAML 解析——Windows 记事本保存的文件常带 BOM，用 VS Code 保存时选 “Save without BOM”。

• --strict：严格模式。开启后，任何severity: critical或high的 issue 都会导致命令返回非零退出码（exit 1）。这是 CI 集成的关键——if ocr --strict; then echo "review passed"; else exit 1; fi。

• --timeout [sec]：LLM 请求超时。默认 120 秒。经验：Qwen2-7B 在 M2 MacBook 上平均响应 8.2 秒，GPT-4 Turbo 在 100Mbps 网络下平均 3.7 秒，但 DeepSeek-Coder-V2 有时卡在 110 秒（模型推理瓶颈），所以 CI 里建议设--timeout 180。

• --max-tokens [num]：限制 LLM 输出长度。默认 2048。为什么重要：有些模型（如早期 GLM）在输出 JSON 时会“续写”，超出预期长度后 JSON 不闭合，导致解析失败。设--max-tokens 1024能强制截断，配合 prompt 里的 “Output ONLY valid JSON array” 更可靠。

• --cache-dir [path]：缓存目录。默认~/.ocr/cache/。实操心得：把 cache 放到 SSD 上，速度提升 3.2 倍；如果磁盘空间紧张，可以ocr --cache-dir /dev/shm/ocr-cache用内存盘（Linux/macOS），但注意/dev/shm默认只有 64MB，需sudo mount -o remount,size=2g /dev/shm。

4.3 CI/CD 集成实战：在 GitHub Actions 里稳定运行

这是企业落地最关键的一步。以下是经过 12 个项目验证的 GitHub Actions 配置：

name: Code Review on: pull_request: types: [opened, synchronize, reopened] branches: [main, develop] jobs: review: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: fetch-depth: 0 # 必须！否则 git diff HEAD~1 会失败 - name: Install open-code-review run: | curl -fsSL https://get.open-code-review.dev | sh ocr --version # 验证安装 - name: Run code review id: ocr run: | # 设置超时和严格模式 if ! ocr --diff HEAD~1 --strict --timeout 180 --model ollama/qwen2:7b; then echo "OCR failed" >> $GITHUB_STEP_SUMMARY exit 1 fi - name: Post review comments if: always() uses: actions/github-script@v6 with: script: | const issues = require('./.ocr_output.json'); for (const issue of issues) { github.rest.pulls.createReviewComment({ owner: context.repo.owner, repo: context.repo.repo, pull_number: context.payload.pull_request.number, body: `**[open-code-review]** ${issue.severity.toUpperCase()}: ${issue.message}\n\`\`\`${issue.code_snippet}\`\`\`\n${issue.recommendation}`, path: issue.file, line: issue.line, side: 'RIGHT' }); }

关键细节说明：

• fetch-depth: 0是生死线。GitHub Actions 默认只 fetch 最新 commit，git diff HEAD~1会报错 “fatal: ambiguous argument 'HEAD~1'”。必须设为 0 或足够大的数（如 50）。

• --model ollama/qwen2:7b在 CI 里要提前拉取模型。加一步：

  - name: Pull Ollama model run: ollama pull qwen2:7b

• 输出 JSON 的路径由--output .ocr_output.json控制，上面配置里省略了，实际要用。

• createReviewCommentAPI 要求path必须是 diff 中出现的文件名，且line是新版本行号——这正是 open-code-review 的line字段保证的。

5. 常见问题排查与独家避坑指南

5.1 典型问题速查表

5.2 我踩过的五个深坑及解决方案

坑 1：Git diff 的 encoding 问题导致中文乱码
现象：Java 文件里// 用户信息校验变成// \u7528\u6237\u4fe1\u606f\u6821\u9a8c，LLM 完全看不懂。
原因：Git 默认用 UTF-8，但某些 Windows Git 客户端会用 GBK。
解法：在 repo 根目录加.gitattributes：

*.java text eol=lf charset=utf-8 *.py text eol=lf charset=utf-8

然后git add --renormalize .强制重编码。

坑 2：LLM 把log.info("user={}", user)误判为“敏感信息泄露”
现象：日志模板里的{}被当成占位符，LLM 认为会打印 user 对象，建议“用log.debug替代”。
原因：prompt 里没明确说“日志语句中的 {} 是 SLF4J 占位符，不是实际值”。
解法：在 policy 里加一条规则：

rules: - id: "LOG-PLACEHOLDER" name: "SLF4J placeholder" description: "Ignore {} in log statements as they are placeholders" severity: low patterns: - file: "**/*.java" code: "log\.(info|warn|error)\(\".*\{.*\}.*\""

坑 3：ocr --interactive卡在输入等待
现象：显示i1: [critical] ...后光标不动，Ctrl+C 也没反应。
原因：终端不支持 readline，比如在 tmux 里没启用set -g mouse on。
解法：加--no-interactive用批量模式；或在 tmux 里运行stty sane重置终端。

坑 4：Ollama 模型加载慢，首次 review 耗时 2 分钟
现象：ocr --model ollama/qwen2:7b第一次跑要 120 秒，后续正常。
原因：Ollama 首次加载模型到 GPU 显存，且 open-code-review 的 prompt template 编译也耗时。
解法：CI 里加预热步骤：

ollama run qwen2:7b "hi" >/dev/null 2>&1 ocr --model ollama/qwen2:7b --dry-run # dry-run 触发 prompt 编译

坑 5：审查结果里line字段总是偏移 1 行
现象：diff 显示+ return user.getName();在第 47 行，但报告说line: 48。
原因：git diff的行号从 1 开始计，但 open-code-review 的 parser 把 hunk header 的+45,5解析成“新文件从 45 行开始，共 5 行”，而+行在 hunk 内部的偏移是 2，所以 45+2=47——但某些 Git 版本（2.30+）的 hunk header 计算方式变了。
解法：升级 Git 到 2.39+；或手动校准：ocr --calibrate-diff运行校准脚本，它会生成.ocr_diff_offset文件。

5.3 性能调优实战：让 review 速度提升 3.7 倍

我们团队的 monorepo 有 1200 个 Java 文件，一次 full review 要 42 秒。优化后降到 11.3 秒，关键措施：

• Step 1：禁用非必要语言分析
  默认ocr会为所有文件类型跑 AST 解析，但.md、.yml文件根本不需要。在.ocrignore里加：

  **/*.md **/*.yml **/*.json

  速度提升 1.2 倍。

• Step 2：启用增量缓存
  ocr --cache-incremental会为每个 hunk 计算 SHA256，命中缓存就跳过 LLM 调用。缓存键包括：diff 内容 + model name + policy hash + prompt template hash。实测缓存命中率 68%，整体提速 1.8 倍。

• Step 3：模型量化降精度
  把qwen2:7b换成qwen2:7b-q4_k_m（4-bit 量化），推理速度从 8.2s → 3.1s，准确率损失仅 1.3%（用 500 个已知问题样本测试）。

• Step 4：并发控制
  ocr --concurrency 4启用 4 线程，但要注意：Ollama 默认单线程，需ollama serve后加--num-gpu 4；OpenAI API 则受限于 rate limit，--concurrency 2最稳。

最终配置：

ocr --diff HEAD~1 \ --model ollama/qwen2:7b-q4_k_m \ --cache-incremental \ --concurrency 4 \ --timeout 60

6. 进阶应用与定制化扩展

6.1 自定义策略开发：从规则编写到 AST 匹配

写策略不是写正则，而是写“代码意图”。以“禁止硬编码 HTTP 状态码”为例：

Step 1：定义问题域
不是“找return 200;”，而是“