本地化 Git Diff 代码审查 CLI 工具 open-code-review

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

“open-code-review”这个名字乍一听像某个 GitHub 上刚创建的冷门仓库，但如果你最近在技术社区刷到过关于codex cli、zcode cli、trae cli、claude code cli这些关键词，或者反复看到有人问“为什么我的 LLM 代码审查结果总把.env文件内容直接输出？”、“git commit 后怎么自动触发本地大模型做 diff 分析？”，那你大概率已经站在了这个工具的实际使用场景门口——它不是概念玩具，而是一套面向真实开发流的、可嵌入 Git 生命周期的轻量级代码审查增强系统。

我从去年开始在三个不同规模的团队里推动类似方案落地：一个 5 人初创团队用它替代了 70% 的人工 PR 初筛；一个 30 人中台组把它集成进 pre-commit hook，把平均 CR 周期从 2.8 天压到 0.6 天；还有一个遗留系统维护组，靠它自动识别出 17 类 Java 旧版本反模式（比如new Date().toString()被误用为时间戳解析）。这些都不是 demo，而是每天跑在 Jenkins、GitLab CI 和本地终端里的真实流程。

核心就一句话：open-code-review 是一个命令行驱动的、不依赖云端 API 密钥的本地化代码审查代理，它把 LLM 的语义理解能力，精准锚定在 git diff 的变更上下文里，只看“这次改了什么”，不碰“整个项目长什么样”。它不替代 Code Reviewer，而是让 Reviewer 的注意力从“找空格错没”转向“这个业务逻辑是否覆盖了边界条件”。

你不需要懂 LLM 训练，也不用部署千卡集群。一台 16GB 内存的 MacBook 或 Windows 笔记本，装好 Git 和 Python 3.9+，5 分钟就能跑起来。它和你正在用的 VS Code、JetBrains IDE、Git Bash、甚至 Windows Terminal 完全兼容——因为它的入口就是一个ocr命令，后面接的是你每天都在敲的git diff、git show、git log -p的原生输出。

关键词里反复出现的 “LLM 密钥泄露”“prompt injection”“diff.mnemonicprefix=false” 其实都指向同一个痛点：现有 CLI 工具要么把整份代码扔给远程 API（风险明摆着），要么连 git 的基础 diff 格式都解析不对（导致模型看到一堆乱码）。而 open-code-review 的设计哲学很朴素：信任本地环境，尊重 Git 协议，最小化上下文注入。它不会读取你项目根目录下的config.yml，更不会扫描node_modules——它只处理你git diff HEAD~1输出的那几百行 patch，且默认启用语法感知的 diff 解析器（支持 42 种语言），把+if (x == null)和-if (x != null)这种语义等价但字面不同的变更，统一映射为“空值判断逻辑反转”。

适合谁？三类人立刻能用上：

• 前端/后端工程师：提交前ocr --stage自查，避免低级错误被同事当众指出；
• Tech Lead / 架构师：用ocr --batch --since=2.weeks.ago批量扫描历史提交，生成团队代码健康度周报；
• DevOps / 工具链开发者：把它当模块嵌入 CI 流程，配合--json-output输出结构化结果，喂给内部知识图谱或告警系统。

这不是又一个“用 LLM 包装 git blame”的噱头项目。它解决的是一个被长期忽视的缝隙问题：代码审查的本质不是“理解全部”，而是“聚焦变更”。而绝大多数 LLM 工具，恰恰在第一步就错了——它们试图让模型“读懂整个项目”，却忘了工程师真正需要反馈的，只是那 3 行新增的 if 判断里，有没有漏掉else分支。

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

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

这个问题我被问过至少 27 次，每次我都先反问对方：“你上一次完整走完一次 PR 流程，是在浏览器里点 Merge 按钮前，还是在终端敲完git push后？” 答案几乎全是后者。真正的代码审查动作，92% 发生在本地开发阶段——写完功能、跑通测试、git add、git commit、git push，这一串操作里，只有git commit是天然的检查点。Web UI 和 IDE 插件的问题在于：它们要么滞后（等你打开网页才触发），要么侵入（强制你切换窗口、打断编码流）。

CLI 的优势不是“看起来酷”，而是时序精准、环境可控、链路透明。

• 时序精准：pre-commithook 可以在git commit执行前拦截，post-checkout可以在git checkout feature/x后自动加载该分支的审查规则。这种粒度是任何图形界面无法提供的。
• 环境可控：你在终端里执行ocr --model=llama3:8b-q4_k_m --context=50，参数含义一目了然；而 IDE 插件里点几下设置，背后可能调用了 3 层封装的 SDK，连 temperature 都不知道被谁覆盖了。
• 链路透明：ocr --debug输出的每一步，都是真实 shell 命令和标准输入输出。当你发现某次审查漏判了 SQL 注入风险，可以直接复制ocr --verbose输出的 prompt 内容，粘贴到本地 Ollama 或 LM Studio 里复现，不用猜“插件到底传了什么给模型”。

我们做过对比实验：同一段 React 组件变更，在 VS Code 插件里耗时 4.2 秒（含插件启动、上下文序列化、网络请求、响应解析），而在终端执行ocr --file src/components/Button.tsx平均仅需 1.7 秒（纯本地推理，无网络开销）。更重要的是，插件在 WSL2 环境下会因路径映射失败导致文件读取为空，而 CLI 在任何 shell 下行为一致。

所以 open-code-review 的定位很明确：它不是要取代 IDE，而是成为 IDE 的底层能力提供者。就像eslint和prettier一样，你可以选择在 VS Code 里装插件调用它，也可以选择在终端里直接用——但核心引擎永远在 CLI 层。

2.2 为什么坚持“本地 LLM + Git Diff”双核心？而非调用 OpenAI/Claude API？

热搜词里高频出现的 “LLM 密钥泄露”“prompt injection attack” 不是危言耸听。去年我们团队就发生过真实事件：某位工程师在调试一个 codex cli 工具时，误将包含 AWS_ACCESS_KEY_ID 的.env.local文件纳入git add，工具自动上传整份文件内容到远程 API，密钥 12 分钟后出现在公开数据集镜像站。这不是个例——GitHub 上超过 1400 个公开仓库的 issue 里，都有类似描述：“review tool 把 secrets.json 当作代码片段发给了 LLM”。

open-code-review 的解决方案极其简单粗暴：默认不联网，不碰文件系统，只消费 git 的标准输出。
它的输入源只有三种：

1. git diff的 patch 文本（经语法感知解析器清洗后）；
2. git show <commit>的单次提交变更；
3. 用户手动指定的代码片段（ocr --code "if (x) { return y; }"）。

所有输入在进入 LLM 前，都会经过三道过滤：

• 路径白名单过滤：默认只允许src/、app/、lib/目录下的变更，.env*、*.key、secrets.*等扩展名被硬性排除；
• 内容敏感词过滤：正则匹配password\s*[:=]\s*["']\w+["']、api_key.*[a-zA-Z0-9]{32,}等模式，匹配项直接替换为<REDACTED>；
• 上下文长度截断：每个 diff hunk 严格限制在 200 token 内，超出部分按 AST 节点优先级裁剪（保留函数签名、条件判断、SQL 字符串，裁掉注释和空行）。

这带来一个关键收益：你永远不需要配置 API KEY。它支持 Ollama、LM Studio、llama.cpp、甚至本地运行的 vLLM 实例，但所有模型调用都发生在本机。我们实测过，在 M2 Max 上用phi-3:3.8b模型审查 50 行 TypeScript diff，端到端延迟 830ms，功耗增加不到 5%。而调用一次 GPT-4 Turbo API，光网络往返就 1.2 秒起，加上 token 计费和隐私风险，性价比极低。

当然，我们也预留了--remote-api开关，供有合规审计需求的团队对接内部 LLM 网关。但那个开关默认关闭，且开启后会强制要求用户确认“已阅读《敏感数据处理协议》第 3.2 条”，这是硬性安全红线。

2.3 为什么深度绑定 Git？而不是做成通用代码分析器？

看看热搜词里反复出现的git -c diff.mnemonicprefix=false、git commit --amend、git config gitee key——这些不是随机组合，而是真实开发者每天面对的碎片化操作。open-code-review 的 Git 绑定不是“为了集成而集成”，而是把代码审查动作，还原到工程师最自然的工作节奏里。

举个典型场景：你修复了一个支付超时 bug，写了 3 行代码，git add payment.js，然后习惯性敲git commit -m "fix: timeout in payment gateway"。这时，如果 pre-commit hook 里配置了ocr --stage，它会自动：

1. 获取暂存区（staging area）里payment.js的 diff；
2. 提取变更涉及的函数名（processPayment）、调用链（-> validateCard -> callGateway）；
3. 构建 prompt：“请检查以下变更是否可能导致支付网关调用超时。重点关注：① 是否添加了新的网络请求？② 是否修改了 timeout 参数？③ 是否移除了重试逻辑？”；
4. 调用本地模型，返回结构化 JSON：{"risk_level": "medium", "issues": [{"line": 42, "reason": "移除了 retry(3) 调用，建议补充降级策略"}]}；
5. 如果risk_level为 high 或 medium，中断 commit，输出建议并附带--no-verify绕过选项。

这个流程之所以成立，是因为它完全复用了 Git 的原语：staging area、commit message convention、diff format。你不需要学新命令，git commit还是那个git commit，只是背后多了层智能校验。相比之下，通用代码分析器（如 SonarQube）需要你配置项目根路径、语言类型、质量配置文件，还要定期扫描全量代码——它解决的是“项目整体健康度”，而 open-code-review 解决的是“这次提交安不安全”。

我们甚至利用了 Git 的 plumbing 命令做深度优化。比如git diff-tree -r --no-commit-id --name-only -z HEAD这种零分隔符输出，比git status --porcelain更可靠（后者在某些 Git 版本里对中文路径处理异常）。open-code-review 内置的 Git 探测器会自动识别你用的是 Git、GitHub CLI 还是 GitKraken，并适配其 diff 输出格式——这才是真正的“无缝集成”。

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

3.1 安装与环境准备：避开 90% 的新手坑

安装本身很简单：pip install open-code-review。但实际落地时，83% 的首次失败案例都卡在环境准备环节。我整理了最常见的 5 类问题及对应解法，这些都是踩坑后加到文档里的硬核经验。

第一类：Python 环境冲突。
很多团队用 conda 管理数据科学环境，而 open-code-review 依赖transformers和tokenizers，这两个库在 conda-forge 和 PyPI 的二进制包 ABI 不兼容。现象是ImportError: cannot import name 'AutoTokenizer' from 'transformers'。

解决方案：绝对不要用 conda install open-code-review。正确做法是：

# 创建干净的 venv python -m venv ~/ocr-env source ~/ocr-env/bin/activate # macOS/Linux # 或 ~/ocr-env/Scripts/activate.bat # Windows pip install --upgrade pip setuptools wheel pip install open-code-review

第二类：Git 配置缺失导致 diff 解析失败。
open-code-review 默认调用git diff，但如果用户没配置core.autocrlf（Windows）或core.eol（macOS），diff 输出会出现^M符号或换行混乱，模型会把\r\n当作非法字符。

解决方案：运行git config --global core.autocrlf true（Windows）或git config --global core.eol lf（macOS/Linux）。这不是可选项，是必须项。我们在安装脚本里加入了自动检测，如果发现配置异常，会提示并给出一键修复命令。

第三类：模型下载路径权限问题。
Ollama 默认把模型存在~/.ollama/models，但某些企业笔记本启用了 BitLocker 或 McAfee，会阻止非管理员进程写入该目录。现象是ocr --model llama3:8b卡在 “pulling model...” 10 分钟不动。

解决方案：用OLLAMA_MODELS环境变量重定向路径：

export OLLAMA_MODELS="/path/to/writable/models" ocr --model llama3:8b --context=100

我们推荐放在项目根目录下的.ocr-models/，这样每个项目用独立模型，互不干扰。

第四类：CUDA 驱动版本不匹配。
想用 GPU 加速？别急。llama.cpp的 CUDA 后端要求驱动 >= 525.66.12，而很多公司 IT 部门锁死在 470.x。现象是CUDA error: no kernel image is available for execution on the device。

解决方案：优先用 CPU 模式验证功能。ocr --model phi-3:3.8b-q4_k_m --device cpu在 M1 Mac 上实测 1.2 秒/diff，足够日常使用。GPU 加速是锦上添花，不是雪中送炭。

第五类：Windows 终端编码问题。
PowerShell 默认 UTF-16，而 open-code-review 的 prompt 模板是 UTF-8。现象是中文提示词变成乱码，模型输出 “” 字符。

解决方案：在 PowerShell 里执行chcp 65001切换到 UTF-8，或直接用 Windows Terminal（默认 UTF-8）。我们已在代码里加入自动编码探测，但手动设置更可靠。

这些不是边缘 case，而是真实发生过的高频问题。open-code-review 的安装脚本（ocr-setup）现在会自动执行这 5 步检测，并生成一份setup-report.txt，告诉你哪步通过、哪步失败、如何修复。它不假设你是个资深运维，而是把你当成第一次接触 Git 的实习生来设计体验。

3.2 模型选型与参数调优：不是越大越好

热搜词里充斥着 “deepseek 是属于哪个”“llm 基础”“temperature 如何作用”——说明很多人还在模型认知的混沌期。open-code-review 的模型策略很务实：不追求 SOTA，只追求“够用、稳定、快”。我们内部测试过 23 个开源模型，最终只推荐 4 个，理由如下：

模型名称	参数量	量化格式	CPU 推理速度（tokens/s）	代码理解得分（HumanEval）	推荐场景
phi-3:3.8b-q4_k_m	3.8B	Q4_K_M	127	42.3%	日常 PR 审查，M1/M2 笔记本首选
llama3:8b-q4_k_m	8B	Q4_K_M	68	51.7%	中大型项目，需要更强逻辑推理
codellama:7b-q4_k_m	7B	Q4_K_M	73	48.9%	专注 Python/JS，对语法错误检出率高
tinyllama:1.1b-q4_k_m	1.1B	Q4_K_M	215	33.1%	超快速草稿审查，CI 流水线预检

注意：所有速度数据基于 M2 Pro 16GB 统一测试，tokens/s指模型生成 100 个 token 的平均吞吐。不要盲目追求高分——HumanEval 51.7% 的llama3:8b在审查 Java Spring Boot 事务传播时，反而不如 42.3% 的phi-3稳定，因为后者对@Transactional(propagation = Propagation.REQUIRED)这种固定模式识别更准。

关键参数只有三个，必须理解其物理意义：

• --context：指模型能看到的“上下文窗口大小”，单位是 token。不是越大越好！实测发现，当--context=200时，模型对单个 diff hunk 的专注度最高；--context=500会导致注意力分散，漏判if (user != null && user.isActive())中的空指针风险。我们默认设为 150，这是大量 patch 测试后的黄金值。
• --temperature：控制输出随机性。代码审查需要确定性，所以默认0.1（不是 0，因为完全 deterministic 会丧失少量必要灵活性）。如果你发现模型总重复说“建议添加日志”，可微调到0.3。
• --max-new-tokens：限制模型生成长度。默认128，足够输出 3-5 条具体建议。设太大（如 512）会导致模型编造不存在的风险，比如给一个纯 CSS 修改建议“检查 XSS 过滤”。

一个真实案例：某电商团队用llama3:8b审查订单状态机变更，--max-new-tokens=512时模型输出：“风险：未处理库存回滚。建议：在order.cancel()中添加inventory.rollback()调用。”——但代码里根本没有order.cancel()方法。改成128后，输出变为：“风险：状态流转缺少PENDING -> CANCELLED路径。建议：检查OrderStateTransitionService的transition()方法。” 这才是有效反馈。

3.3 Git 集成深度解析：从 pre-commit 到 CI/CD

open-code-review 的 Git 集成不是简单包装git diff，而是深入到 Git 的四个关键生命周期钩子（hook），每个钩子解决不同颗粒度的问题。下面逐个拆解，附真实配置示例。

pre-commit hook：守住最后一道防线
这是最常用、也最重要的集成点。它在git commit执行前触发，审查即将提交的变更。配置方法：

# 在项目根目录执行 echo '#!/bin/sh\nexec ocr --stage --fail-on-medium-risk' > .git/hooks/pre-commit chmod +x .git/hooks/pre-commit

关键参数--fail-on-medium-risk表示：只要检测到 medium 或 high 风险，就中断 commit，强制开发者修正。我们建议生产环境必开此开关。

注意：--stage指审查暂存区（staged）内容，不是工作区（working directory）。这是精准性的保证——你git add了什么，它就审什么，不会误伤未提交的草稿。

post-checkout hook：新分支即刻适应
当你git checkout feature/login时，这个 hook 会自动加载该分支专属的审查规则。比如feature/login分支可能启用更严格的密码策略检查，而main分支则侧重性能告警。配置：

# .git/hooks/post-checkout #!/bin/sh branch=$(git rev-parse --abbrev-ref HEAD) if [ "$branch" = "feature/login" ]; then ocr --load-rules ./rules/login-rules.yaml fi

规则文件login-rules.yaml可定义：

checks: - id: password-complexity enabled: true severity: high pattern: "password.*=.*['\"].*['\"]"

prepare-commit-msg hook：智能生成 commit message
结合git commit的-m参数，自动生成符合 Conventional Commits 规范的消息。例如你修改了 API 路由，模型会建议：
feat(api): add /v1/users/{id}/profile endpoint with rate limiting
配置：

echo '#!/bin/sh\nocr --generate-commit-msg "$1"' > .git/hooks/prepare-commit-msg chmod +x .git/hooks/prepare-commit-msg

CI/CD 集成：GitLab CI 示例
在.gitlab-ci.yml中：

code-review: stage: test image: python:3.9-slim before_script: - pip install open-code-review - ocr --download-model phi-3:3.8b-q4_k_m script: - git fetch origin $CI_COMMIT_BEFORE_SHA - git diff $CI_COMMIT_BEFORE_SHA $CI_COMMIT_SHA > /tmp/diff.patch - ocr --patch /tmp/diff.patch --json-output > review-report.json artifacts: - review-report.json

这里的关键是git diff $CI_COMMIT_BEFORE_SHA $CI_COMMIT_SHA——它精确获取本次 MR 的变更，避免 CI 环境里git diff HEAD~1拿到错误的基线。

所有这些 hook 的共同原则是：不修改 Git 行为，只增强它。你git commit还是git commit，git push还是git push，open-code-review 只是安静地坐在旁边，提供实时反馈。

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

4.1 从零开始：5 分钟完成首次审查

我们以一个真实的 Vue 3 组件修复为例，演示完整流程。假设你修复了一个登录表单的邮箱验证 bug，代码变更如下：

diff --git a/src/components/LoginForm.vue b/src/components/LoginForm.vue index abc1234..def5678 100644 --- a/src/components/LoginForm.vue +++ b/src/components/LoginForm.vue @@ -23,7 +23,7 @@ export default { }, methods: { async login() { - if (!this.email || !this.password) return; + if (!this.email || !this.password || !this.isValidEmail(this.email)) return; try { await this.$api.login({ email: this.email, password: this.password }); } catch (error) {

步骤 1：确保 Git 状态干净

git status # 应显示 modified: src/components/LoginForm.vue git add src/components/LoginForm.vue

步骤 2：运行审查命令

ocr --stage --model phi-3:3.8b-q4_k_m --context=150

输出：

🔍 Analyzing staged changes... ✅ Detected language: Vue (TypeScript) ✅ Parsed 1 hunk (3 lines added, 1 line modified) 🧠 Running local LLM inference... ⚠️ Medium risk detected: Line 26: Added email validation but no user feedback. Suggestion: Add error message display when isValidEmail returns false. 💡 Low risk suggestion: Line 26: Consider using built-in HTML5 email validation (<input type="email">) as first layer. 📝 Summary: 1 medium, 1 low risk. No high risks found.

步骤 3：理解输出逻辑
这个结果不是随机生成的。背后发生了什么？

• --stage让工具从 Git 暂存区读取LoginForm.vue的 diff；
• 语法解析器识别出这是 Vue 单文件组件，提取<script setup>区域的 JS 逻辑；
• 模型 prompt 被构造为：

  You are a senior frontend engineer reviewing a Vue 3 component change. Focus ONLY on the following diff: [paste diff here] Identify security, correctness, and UX risks. Be specific: mention line numbers, suggest concrete fixes. Output in plain English, no markdown.

• phi-3:3.8b模型在 150 token 上下文内，准确捕捉到isValidEmail()调用新增，但 UI 层无反馈机制这一 UX 缺陷。

步骤 4：修正并重新审查
你按建议在模板里加了<div v-if="!isValidEmail(email)">请输入有效邮箱</div>，再次git add，运行ocr --stage，输出变为：

✅ No risks detected. Ready to commit!

这就是一个完整的闭环。整个过程耗时约 90 秒，比人工快速扫一眼还快，但覆盖了人容易忽略的 UX 边界。

4.2 批量审查：扫描历史提交找出技术债

单次审查价值有限，真正的威力在于批量扫描。ocr --batch命令专为此设计。我们曾用它在一个 5 年老项目里，3 分钟内找到 237 处潜在问题。

场景：审计过去两周的所有提交

ocr --batch --since="2 weeks ago" --model llama3:8b-q4_k_m --output=audit-report.md

它会：

1. 执行git log --pretty=format:"%H %s" --since="2 weeks ago"获取提交哈希；
2. 对每个提交，运行git show --format="" --name-only <hash>获取变更文件；
3. 对每个文件，提取git show <hash>:<file>的内容，构建最小上下文；
4. 调用模型审查，聚合结果。

输出audit-report.md包含：

• 按风险等级统计的饼图（文本版）；
• 高频问题 Top 5：
  1. Hardcoded API URLs (142 occurrences)
  2. Missing error boundaries in React components (67)
  3. Insecure deserialization in Java controllers (23)
• 每个问题附带示例提交链接（git show <hash>命令）和修复建议。

关键技巧：用--filter精准定位
不想扫全量？用--filter：

# 只审查 Java 文件的 security 相关变更 ocr --batch --since="1 month ago" --filter="*.java" --tag="security" # 只审查合并到 main 分支的 PR ocr --batch --merge-base=origin/main --model codellama:7b-q4_k_m

--tag功能基于 commit message 的 emoji 标签（如🔒 security fix），这是团队约定的低成本标记方式。

4.3 自定义规则引擎：超越 LLM 的确定性检查

LLM 擅长模糊推理，但有些规则必须 100% 确定。open-code-review 内置了规则引擎，支持 YAML 配置，与 LLM 审查并行运行。

示例：禁止在生产环境使用 console.log
创建rules/no-console.yaml：

id: no-console-log name: "禁止 console.log" description: "生产代码中不得使用 console.log" severity: high language: javascript pattern: "\\bconsole\\.log\\b" replacement: "use logger.info() instead"

启用：

ocr --stage --rules ./rules/no-console.yaml

引擎会：

• 用 AST 解析器（而非正则）精准匹配console.log()调用；
• 忽略注释和字符串内的console.log（如"debug: console.log(x)"）；
• 输出：Line 45: console.log('debug') —— use logger.info() instead。

为什么不用 ESLint？
ESLint 是通用 JS 检查器，而 open-code-review 的规则引擎：

• 可与 LLM 结果融合输出（同一报告里既有规则告警，也有模型建议）；
• 支持跨语言规则（同一 YAML 文件可定义 JS/Java/Python 规则）；
• 可动态加载（--rules参数支持 HTTP URL，方便团队中心化管理）。

我们团队的common-rules.yaml存在内部 Git 仓库，所有项目通过ocr --rules https://internal.git/rules/common.yaml引用，确保规范统一。

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

5.1 模型输出不稳定？先查这 3 个地方

LLM 输出“不稳定”是高频抱怨，但 90% 的情况与模型无关，而是输入或环境问题。以下是我们的排查清单：

问题 1：diff 格式被 Git 配置污染
现象：模型输出乱码，或反复说“无法解析代码”。
原因：git config --global diff.noprefix true会移除a/b/前缀，导致语法解析器无法识别文件类型。

✅ 解决：git config --global diff.noprefix false，或用ocr --force-language=typescript强制指定语言。

问题 2：上下文被截断导致逻辑断裂
现象：模型说“缺少 else 分支”，但 diff 里明明有else { ... }。
原因：--context=100太小，模型只看到if (x) {这半句，没看到后续。

✅ 解决：用ocr --verbose查看实际输入的 prompt，确认if和else是否在同一 context 内。增大--context至 200，或改用--hunk-mode（按 diff hunk 切分，而非 token）。

问题 3：模型缓存失效引发幻觉
现象：同一 diff，第一次审查说“安全”，第二次说“高危”。
原因：llama.cpp的 KV cache 未正确 reset，导致历史生成影响当前输出。

✅ 解决：添加--no-cache参数强制禁用 cache，或升级到llama.cpp>=v0.2.58（已修复此 bug）。

5.2 性能瓶颈在哪？CPU/GPU/IO 三维度诊断

审查慢？别急着换更大模型。先运行诊断命令：

ocr --diagnose --model phi-3:3.8b-q4_k_m

输出示例：

📊 Diagnostics Report: • CPU Load: 82% (normal) • Disk I/O: 12 MB/s reading models (normal) • GPU Utilization: 0% (GPU not detected) • Tokenizer Speed: 4200 tokens/sec (excellent) • Model Inference: 68 tokens/sec (expected for 3.8B on CPU) • Prompt Construction: 120ms (slight delay — check .gitattributes)

关键指标解读：

• Tokenizer Speed < 2000 tokens/sec：说明磁盘慢或模型文件损坏，重装模型；
• Model Inference < 30 tokens/sec：CPU 频率被限制，检查powercfg（Windows）或pmset（macOS）；
• Prompt Construction > 100ms：.gitattributes里有过多linguist-generated=true规则，禁用即可。

我们遇到过最离谱的案例：某团队在.gitattributes里为 200+ 文件类型设置了diff=cpp，导致git diff解析耗时 3.2 秒。ocr --diagnose一眼定位，删掉冗余规则后，审查速度从 8.7 秒降到 1.3 秒。

5.3 安全红线：如何确保绝不泄露任何敏感信息

这是 open-code-review 的生命线。我们设计了四层防护，全部开源可审计：

第一层：输入沙箱
所有git diff输出在进入模型前，经过DiffSanitizer类处理：

• 移除所有^M、\0等控制字符；
• 替换password=.*、secret_key:.*等模式为<REDACTED>；
• 对 base64 编码字符串（如data:image/png;base64,...）进行长度截断，只保留前 50 字符。

第二层：模型隔离
ocr进程启动时，自动调用os.setuid()降权（Linux/macOS），或CreateRestrictedToken()（Windows），确保即使模型被 prompt injection 攻击，也无法访问/etc/passwd或C:\Windows\System32。

第三层：输出净化
模型返回的 JSON 或文本，经过OutputScrubber：

• 移除所有http://https://链接（防止模型返回恶意 URL）；
• 过滤ssh-rsa AAAA...等密钥特征字符串；
• 对eval(Function(等危险 JS API 调用，添加⚠️ DANGEROUS前缀。

第四层：审计日志
启用--audit-log后，所有审查请求（不含