使用本地LLM重读和审查代码（审查前 commit)

#为何在本地进行代码审查

把 diff 粘贴到 ChatGPT 中让它帮忙审查，确实很方便——直到某天，这份 diff 中包含了 API 密钥、竞争对手的业务逻辑，或受保密协议（NDA）约束的代码。使用本地 LLM 审查代码可以从根本上解决这个问题：模型在您的机器上运行，代码始终不会离开 11434 端口。

专有软件代码

自主研发算法、业务逻辑、架构秘技：任何内容都不会流向第三方进行日志记录或训练。

NDA 及保密条款

大量客户合同明确禁止将源代码发送至外部服务。在这种情况下，本地部署通常是唯一合规的选择。

无持续性费用

不按token计费。您可以随时重新阅读每个提交、每个分支，而无需关注计数器。

离线运行

在列车上、在与外部网络物理隔离的场所，或在限制严格的企业代理网络环境中：仍然可以进行代码审查。

#LLM 擅长发现什么（又会漏掉什么）

在接入任何组件之前，必须先调整好预期。本地代码模型擅长识别局部且能从 diff 中看出的错误，但对需要了解系统其余部分的任务表现较弱。

表现良好：局部代码缺陷

差一位错误、条件写反、变量未初始化、资源未关闭、遗漏错误处理。

表现不错：识别明显的安全漏洞

字符串拼接导致的 SQL 注入、硬编码的敏感信息、未经验证的路径、危险的反序列化、基础 XSS 漏洞。

擅长：可读性

命名混乱，函数过长，存在死代码，diff中可明显看到重复内容

较低：跨文件逻辑能力

它只能看到 diff。其他位置被破坏的 API 契约、全局不变量，以及在其他位置产生的副作用，都可能被它忽略。

较低：业务意图

它不知道代码本应实现什么功能。它指出的问题看似合理，却不一定正确。

风险：误报和幻觉

它可能虚构出不存在的漏洞，或提出会破坏原有行为的补丁。所有内容均需验证。

#先决条件

Ollama 已安装

守护进程默认监听 http://localhost:11434。如果尚未安装，请参阅 Ollama 安装指南。

一个 Git 仓库

代码审查依赖git diff，因此需要一个已纳入版本控制、且有待审查改动的项目。

代码模型

一个已下载到本地的代码专用模型（请参见下一节，根据您的 VRAM 选择模型）。

推荐使用 GPU

GPU 并非必需，但能让使用更顺畅：配备 12 GB 显存的 RTX 3060 足以运行 Q4 量化的 8–9B 模型。仅使用 CPU 也能运行，只是速度较慢。

# Le daemon répond ?
curl http://localhost:11434/api/tags

# Télécharger un modèle récent (exemple 9B)
ollama pull qwen3.5:9b

# Test rapide
ollama run qwen3.5:9b "Relis ce code : def add(a,b): return a-b"

#哪些本地模型适合审查代码

进行代码审查时，优先选择专门的代码模型，而不是通用模型：它更了解各编程语言的语法、惯用写法和常见陷阱。根据您的显存容量选择模型大小，并采用 Q4_K_M 量化（质量与内存占用之间的最佳折中）。以下标签属于 2026 年这一代模型，已在 Ollama 模型库中核实。

qwen3.5:9b — ~7 GB VRAM

2026 年的入门之选。速度快，上下文长度为 256k，可在 RTX 3060 12 GB 或入门级 M 系列 Mac 上运行。适合审查较小的代码差异（diff）。

devstral:24b — ~14 GB VRAM

适合大多数工作电脑的均衡之选。专长是编程和智能体代码编辑（Mistral AI，Apache 2.0），对细微 bug 的推理能力更强，可在配备 16 GB 显存的 RTX 4080 上运行。

qwen3-coder:30b — ~19 GB VRAM

面向代码的MoE模型（30B参数，3B激活），256k上下文，速度很快。跨函数推理质量明显更高。需要24GB显存的RTX 4090，或统一内存充足的Mac。

替代方案

gpt-oss:20b（OpenAI 开放权重模型，速度很快）和 glm-4.7-flash（采用 MIT 许可证的 MoE 模型，在智能体模式下表现稳健）都是不错的选择；如果您手头只有一个模型，mistral-small（24B，法语表现良好）可以作为通用模型应急。

#用一条命令手动进行代码审查

在实现自动化之前，先从按需手动审查开始。思路是：通过 Ollama 的 API 将尚未提交的改动 diff 发送给模型，再在终端中查看模型的反馈。这是接下来要设置的钩子的基础组件。

#!/usr/bin/env bash
# review.sh — relit les changements indexés (staged)
set -euo pipefail

DIFF=$(git diff --cached)
if [ -z "$DIFF" ]; then
  echo "Rien d'indexé à relire (git add d'abord)."
  exit 0
fi

PROMPT="Tu es un relecteur de code senior. Analyse ce diff Git et liste \
UNIQUEMENT les vrais problèmes (bugs, failles, cas limites). Format : \
- [gravité] fichier:ligne — problème puis correctif suggéré. \
Si le diff est correct, réponds 'RAS'. Diff :\n\n$DIFF"

jq -n --arg m "devstral:24b" --arg p "$PROMPT" \
  '{model:$m, prompt:$p, stream:false}' \
| curl -s http://localhost:11434/api/generate -d @- \
| jq -r '.response'

赋予脚本可执行权限（chmod +x review.sh），使用 git add 将变更加入暂存区，然后运行 ./review.sh。您会得到一份审查意见列表，可以自行选择忽略或采纳。此阶段没有任何阻断性检查——这是辅助代码审查，而不是把关机制。

#使用 Ollama 配置 pre-commit 钩子：分步说明

下一步：通过预提交钩子（pre-commit hook）在每次 Git 提交时自动触发此审查。有两种方法——使用原生 Git 钩子（零依赖）或使用 pre-commit 框架。本文重点介绍原生钩子，它更易于理解与审计。

1. 01
   1. 创建钩子文件

   Git钩子位于.git/hooks/目录中。创建.git/hooks/pre-commit（不带扩展名）。Git会在每次提交前自动执行该脚本；非零退出码将取消提交。
2. 02
   2. 编写审查脚本

   钩子获取已暂存的差异（diff），将其发送给 Ollama，并显示返回结果。请选择：仅提供信息（绝不阻止提交），或在模型输出表示严重程度的关键词时阻止提交。
3. 03
   3. 使钩子可执行

   chmod +x .git/hooks/pre-commit — 否则 Git 会忽略这个钩子，不给出任何提示。
4. 04
   4. 测试

   对一个故意包含 bug 的文件执行 git add，然后执行 git commit。提交钩子应在提交前显示模型的反馈。
5. 05
   5. 与团队共享（可选）

   .git/hooks/ 中的钩子不纳入版本控制。要共享这些钩子，请将 .githooks/ 文件夹纳入版本控制，并使用 git config core.hooksPath .githooks 将钩子路径指向该文件夹。

#!/usr/bin/env bash
# Revue LLM locale avant commit. Informatif par défaut.
set -euo pipefail

MODEL="devstral:24b"
DIFF=$(git diff --cached --diff-filter=ACM)
[ -z "$DIFF" ] && exit 0

PROMPT="Relecteur senior. Liste seulement les vrais bugs, failles ou cas \
limites de ce diff, format '- fichier:ligne — souci'. Termine par la ligne \
'VERDICT: OK' si rien de bloquant, sinon 'VERDICT: REVOIR'. Diff:\n\n$DIFF"

OUT=$(jq -n --arg m "$MODEL" --arg p "$PROMPT" \
  '{model:$m, prompt:$p, stream:false}' \
  | curl -s http://localhost:11434/api/generate -d @- \
  | jq -r '.response')

echo "────── Revue LLM locale ──────"
echo "$OUT"
echo "──────────────────────────────"

# Mode bloquant optionnel : décommentez pour refuser le commit
# if echo "$OUT" | grep -q 'VERDICT: REVOIR'; then
#   echo "Commit bloqué. Corrigez ou 'git commit --no-verify' pour forcer."
#   exit 1
# fi
exit 0

repos:
  - repo: local
    hooks:
      - id: revue-llm-locale
        name: Revue de code LLM locale (Ollama)
        entry: ./scripts/review.sh
        language: system
        stages: [pre-commit]
        pass_filenames: false

#优化评审提示词

使用 LLM 审查代码的质量主要取决于提示词。如果没有明确限定模型的审查范围，它就会用无用的代码风格意见淹没真正有价值的信息。以下三个原则能让输出切实可用。

缩小范围

明确要求忽略代码风格，只报告缺陷、安全漏洞和边界情况。否则，每份代码差异都会收到十条纯粹针对外观的评论。

强制指定格式

严格的格式（- 文件:行 — 问题）能让输出便于快速浏览，也便于解析，方便您日后进一步利用。

要求明确的判断

像 'VERDICT: OK/REVOIR' 这样的最后一行提供了一个简单的二元信号，便于在具有阻断作用的钩子中进行检查。

指定语言和上下文

请明确编程语言，并在有帮助时说明项目约定。模型会据此调整检查内容（例如 C 语言中的内存管理、JS 中的 Promise）。

#坦诚看待与人工审查相比的局限

我们需要明确，本地 LLM 代码审阅工具有哪些事情做不到，以免产生虚假的安全感——最糟糕的结果，就是以为已经有了保障，提交代码时反而不够谨慎。

只能看到 diff 中的代码变更

它不了解仓库中的其余代码。如果某项修改导致另一个文件中的调用方无法正常工作，它也不会察觉。集成测试仍然必不可少。

缺乏业务理解能力

它无法判断代码是否实现了工单要求的功能。它验证的是形式，而非意图。熟悉产品的人仍然不可替代。

误报与幻觉

它可能凭空编造一个漏洞，或给出错误的修复方案。采取行动之前，必须核实每一条意见——绝不要盲目修复。

不能替代代码静态检查工具或测试

代码检查工具（linter）、类型检查器和测试套件能够以确定性的方式捕获多类错误。LLM 是对这些工具的补充，不能替代它们。

取决于模型和提示词

一个7B参数的模型如果提示不佳，会遗漏一个32B参数模型在良好提示下能够识别的内容。输出质量无法保证，且不可复现到token级别。

#深入了解

如果您想进一步了解模型选择、IDE 集成或所需内存，本站的以下相关指南可以作为本指南的延伸阅读：

2026 年最适合编程的本地 LLM

Devstral、Qwen3-Coder 及其替代方案的详细对比，包含各模型的 VRAM 和运行速度。

在 VS Code 中免费本地使用 Copilot

不止于 CLI 中的代码审查：使用 Cline、Tabby 和 CodeGeeX 在 IDE 中进行聊天与代码重构。

选择量化方案（Q4、Q5、Q8、FP16）

了解为什么推荐 Q4_K_M，以及如何让一个 32B 模型放入 16 GB 显存的 GPU。