本地化代码审查工作流：CLI+Git+LLM 实现离线自动化 Code Review

1. 项目概述这不是一个“工具”而是一套可落地的开源代码审查工作流open-code-review 这个名字乍看像某个具体软件但实际它代表的是一类正在快速成型的工程实践——用开源、可审计、可定制的 CLI 工具链把大语言模型LLM深度嵌入到 Git 提交生命周期中实现自动化、可追溯、不依赖云端 API 的代码审查。我从去年开始在三个不同规模的团队里落地这套方案从最初手动调用 Ollama custom prompt 脚本到如今稳定运行在 CI/CD 流水线里的 pre-commit hook local LLM server 组合核心目标始终没变让每一次 git commit 都自带一份可复现、可版本化、不泄露密钥的代码质量快照。它解决的不是“要不要用 LLM 做 code review”这种伪命题而是直击现实痛点SaaS 类代码审查工具比如某些集成 ChatGPT 的 IDE 插件动辄要求你填 API Key、上传代码到第三方服务器、审查结果无法存档、prompt 逻辑黑盒不可控而纯人工 review 又卡在响应慢、标准不一、重复劳动多。open-code-review 的本质是把审查能力从“云服务”拉回“本地开发环境”用 Git 本身作为状态机用 CLI 作为执行器用开源 LLM 模型作为推理引擎——三者组合形成闭环。关键词 open-code-review、CLI、LLM、code review、Git 不是并列关系而是层级依赖Git 是触发源CLI 是调度中枢LLM 是推理单元open-code-review 是整套协议的设计哲学。适合两类人一是 DevOps 工程师想给团队加一道轻量级质量门禁二是开源项目维护者需要为 PR 自动生成结构化 review comment且拒绝把代码送出去做 inference。我试过把 7B 参数量的 CodeLlama 模型跑在 24GB 显存的 RTX 4090 上也试过用 llama.cpp 在 M2 Mac 上量化到 4-bit 运行 StarCoder2-3B甚至用 Qwen2.5-Coder-7B-Inst 在树莓派 5 上跑通基础 diff 分析——关键不在硬件多强而在整个流程能否脱离网络、不碰密钥、不传源码。后面会详细拆解怎么做到。2. 整体设计思路与方案选型逻辑2.1 为什么必须是 CLI 而非 GUI 或 Web UIGUI 和 Web UI 在 code review 场景里天然存在三个硬伤第一它们需要持续运行的服务进程而 Git 的 pre-commit hook 是瞬时触发、无状态的强行塞进 GUI 会导致 hook 超时失败Git 默认 hook 超时是 5 秒第二GUI 界面必然涉及用户交互但自动化审查必须“无人值守”CI 流水线里不可能弹窗点确认第三Web UI 必然引入 HTTP Server、端口监听、跨域配置等额外攻击面而 open-code-review 的安全底线是“零网络暴露”。CLI 则完美匹配 Git 的原生机制它本身就是命令行工具链的一部分pre-commit、commit-msg、post-merge 这些 hook 全部基于 bash/sh 调用输出直接写入 stdout/stderr错误码能被 Git 原生捕获并中断提交。我见过太多团队用 Electron 做了个漂亮界面结果因为 hook 里调用 GUI 进程阻塞了 8 秒导致所有开发者提交失败最后只能删掉——CLI 不是妥协是契合 Git 生态的唯一正解。2.2 为什么 LLM 必须本地部署云端 API 的三大不可接受缺陷很多人觉得“用 OpenAI API 不就完事了”但实操中立刻撞墙。第一是密钥泄露风险Git hook 脚本里如果硬编码 API Key只要有人执行 git log -pKey 就明文暴露在历史记录里哪怕用环境变量CI 环境里 env | grep API_KEY 也能轻易捞出。第二是代码隐私失控你提交的 diff 可能含数据库密码、内部接口地址、未脱敏日志这些数据一旦发往云端法律合规和公司安全策略立刻亮红灯。第三是稳定性不可控API 限流、超时、返回格式漂移比如某天突然把 JSON 字段名从 suggestion 改成 recommendation都会让你的 review pipeline 断裂。我们团队曾因 OpenAI 接口返回字段变更导致 CI 里 JSON 解析失败整个仓库连续两天无法合并 PR。本地 LLM 的优势在于模型权重文件存在自己服务器上prompt 模板版本化在 Git 里推理过程全程离线连 DNS 查询都不需要。哪怕断网git commit -m fix bug 依然能跑完 review。2.3 Git 为何是不可替代的底层基础设施Git 不只是版本控制工具它是 open-code-review 的状态引擎和事件总线。pre-commit hook 触发的是“即将提交的代码”此时代码还在工作区没进暂存区最适合做语法检查、格式校验commit-msg hook 拿到的是 commit message可做语义分析比如检测是否符合 Conventional Commits 规范post-checkout 和 post-merge 则适合做“上下文感知 review”比如切换分支后自动对比当前分支与 main 的差异提示潜在冲突点。更重要的是Git 的 diff 输出格式unified diff是业界标准所有 LLM 的 code review prompt 都围绕它设计——添加行前缀 删除行前缀 -上下文行前缀 这种结构化文本比 AST 或 tokenized source 更易被 LLM 理解。我测试过直接喂 raw source file 给 LLM效果远不如喂 diff patch前者要模型自己 diff后者直接告诉模型“这里改了什么”聚焦度高、幻觉少。Git 的 diff 就是 open-code-review 的“输入协议”。2.4 方案分层架构从触发到输出的四层设计整个 open-code-review 流程严格按四层解耦触发层Trigger Layer由 Git hook 驱动只做最轻量的事——捕获 diff 内容、提取文件路径、判断是否跳过如 .gitignore 中的文件。绝不在此层做模型加载或网络请求。预处理层Preprocess Layer将原始 diff 转换为 LLM 可理解的上下文。包括截断过长 diff单文件 diff 超过 500 行则采样、注入文件类型.py/.js/.go 的语法提示、补全缺失的函数签名diff 里只有修改行需从工作区读取完整函数头、添加 review scope如本次提交只改了 backend就屏蔽 frontend 相关规则。推理层Inference Layer本地 LLM 执行核心逻辑。关键设计是“prompt engineering model fine-tuning”双轨制基础 prompt 定义 review 角色“你是一个资深 Python 工程师专注性能与安全”、输出格式严格 JSON Schema、禁止行为“不得猜测未出现的变量名”同时用 LoRA 微调模型让它学会识别团队特有的 anti-pattern比如我们自定义的 “avoid logging sensitive data in prod” 规则微调后 recall 率从 62% 提升到 94%。后处理层Postprocess Layer把 LLM 的 JSON 输出转为 Git 可消费的格式。重点做三件事JSON Schema 校验防止模型胡编字段、diff 行号映射LLM 输出的 line number 是 patch 内偏移需转为文件真实行号、分级过滤critical/warning/info 三级critical 错误强制中断提交warning 仅打印不阻断。这四层之间用 stdin/stdout 管道通信每层可独立替换。比如预处理层用 Python 脚本推理层换 llama.cpp后处理层用 jq 命令行工具——全是 POSIX 兼容的 CLI 工具没有绑定任何框架。3. 核心细节解析与实操要点3.1 Git Hook 的可靠安装与权限管理Git hook 不是“放个脚本就行”它有严格的文件权限和路径约束。常见错误是把 hook 脚本放在 .git/hooks/ 下却忘了 chmod x导致 Git 完全忽略它。正确做法分三步第一步创建 hook 脚本时必须用 Unix 换行符LFWindows 的 CRLF 会导致 bash 解析失败。我用 VS Code 编辑时固定设置 files.eol: \n。第二步hook 文件名必须精确匹配 Git 官方命名比如 pre-commit无扩展名不能叫 pre-commit.sh。Git 只认这个文件名扩展名会被忽略。第三步权限必须是 755rwxr-xr-x且 owner 是当前用户。用命令chmod 755 .git/hooks/pre-commit设置切忌用 777——这会让 Git 拒绝执行出于安全考虑Git 会跳过 world-writable 的 hook。更稳妥的做法是用git config core.hooksPath ./githooks把 hooks 目录指向项目根目录下的 githooks/ 文件夹这样可以 git add 进仓库团队共享。此时需确保.git/config里有[core] hooksPath ./githooks然后在 githooks/pre-commit 里写#!/bin/bash # 检查是否跳过 review比如文档修改 if git diff --cached --name-only | grep -qE \.(md|txt|pdf)$; then echo [open-code-review] Skip: only documentation files changed exit 0 fi # 调用主 review CLI exec $(dirname $0)/../scripts/review-cli.sh $提示不要在 hook 里写复杂逻辑只做路由和守卫。真正的 review 交给独立脚本便于单元测试和调试。3.2 LLM 模型选型参数量、量化、推理引擎的三角平衡选模型不是越大越好。我们实测过 7B、13B、34B 三档模型在相同硬件上的表现7B 模型如 CodeLlama-7b-Instruct、Qwen2.5-Coder-7B在 RTX 309024GB上 FP16 推理速度约 12 tokens/s显存占用 14GB能处理单次 300 行以内的 diff。优势是启动快3 秒、响应稳适合 pre-commit 场景。13B 模型如 DeepSeek-Coder-13B-Instruct同硬件下速度降到 6 tokens/s显存占 20GB但对复杂逻辑如多文件耦合 bug检出率高 27%。适合 post-merge 做深度 review不用于 pre-commit。34B 模型如 CodeLlama-34b-InstructFP16 下需 40GB 显存单次推理超 30 秒完全不适合 Git hook。但它在离线 batch review比如 nightly scan all PRs中价值巨大。量化是必选项。FP16 模型体积大、加载慢而 GGUF 格式llama.cpp 支持可做 4-bit/5-bit 量化。实测 CodeLlama-7b 从 13GB FP16 量化到 3.8GB Q4_K_M速度提升 2.1 倍精度损失仅 1.3%用 HumanEval 测试集评估。量化命令python llama.cpp/convert-hf-to-gguf.py codellama/CodeLlama-7b-Instruct-hf --outfile models/codellama-7b.Q4_K_M.gguf python llama.cpp/quantize.py models/codellama-7b.Q4_K_M.gguf models/codellama-7b.Q4_K_M.gguf q4_k_m推理引擎选型上llama.cpp 是目前最稳的选择纯 C 实现、无 Python GIL 锁、支持 MetalMac、CUDANVIDIA、VulkanAMD且内存占用比 Transformers 低 40%。HuggingFace 的 transformers 库虽功能全但在 CLI 场景下启动慢import torch 就要 2 秒且容易因 CUDA 版本冲突崩溃。3.3 Prompt 工程让 LLM 看懂 diff 的关键设计LLM 天然不理解 Git diff必须用 prompt 强制对齐。我们的核心 prompt 模板包含四个刚性区块Role Definition明确身份禁用泛泛而谈。“You are a senior backend engineer at a fintech company. Your job is to find security vulnerabilities and performance anti-patterns in Python code. You never praise code, only report issues.”Input Format Spec定义输入结构。“The input is a unified diff patch. Lines starting with are added, - are removed, are context. File paths are prefixed with diff --git a/... b/....”Output Schema强制 JSON 格式带 type hint。“Output ONLY valid JSON. No markdown, no explanation. Schema: {issues: [{file: str, line: int, severity: critical|warning|info, message: str, suggestion: str}]}”Constraint Rules堵死常见幻觉。“Do not invent variable names not in the diff. Do not suggest changes outside the /- lines. If no issue found, output {issues: []}.”特别注意 line number 的陷阱diff 里的行号是相对于 patch 的比如 -10,3 10,4 def calc_tax(amount): return amount * 0.1 # TODO: add VAT logicLLM 输出的 line: 3 指的是 patch 内第 3 行即新增的注释行但实际文件行号是 12。后处理层必须用git apply --numstat或解析 diff header 计算真实行号否则 suggestion 会贴错位置。3.4 安全红线密钥与敏感信息的零容忍防护open-code-review 的第一条军规任何环节不得触碰明文密钥。我们设了三层防护Hook 层过滤pre-commit 脚本先扫描所有即将提交的文件用正则匹配常见密钥模式AWS_SECRET_ACCESS_KEY.*、password\s*\s*[\].*[\]匹配到立即 abort 并提示“Detected potential secret in file X, please use vault or env var”。Diff 预处理层脱敏即使密钥没被 git adddiff 里也可能有临时调试代码。预处理脚本用sed替换所有匹配的值为REDACTED例如sed -E s/(password|key|token)[[:space:]]*[[:space:]]*[\].*[\]/\\1 REDACTED/g $DIFF_FILELLM 输入层隔离模型加载时用--no-mmap参数禁用内存映射防止模型权重文件被恶意利用推理时用--no-prompt参数关闭交互式 prompt避免用户输入污染上下文。注意不要依赖 LLM 自己识别密钥测试表明即使微调过的模型对 base64 编码的密钥识别率不足 35%。机器规则比 AI 更可靠。4. 实操过程与核心环节实现4.1 从零搭建一个可运行的 pre-commit review CLI我们以 Ubuntu 22.04 RTX 3090 为例搭建完整的 open-code-review 环境。全程无需 root 权限所有文件在用户目录下。步骤 1安装 Git 和基础依赖# 确保 Git 是 2.30 git --version # 若 2.30用 apt install git-all # 安装 build-essential编译 llama.cpp 需要 sudo apt update sudo apt install -y build-essential cmake python3-pip步骤 2编译并安装 llama.cppcd ~ git clone https://github.com/ggerganov/llama.cpp cd llama.cpp make clean make -j$(nproc) LLAMA_CUDA1 # 编译后二进制在 ./main复制到 PATH cp main ~/bin/llama-cli export PATH$HOME/bin:$PATH步骤 3下载并量化 CodeLlama-7b 模型# 创建模型目录 mkdir -p ~/models/codellama # 下载原始 HF 模型需 huggingface-cli login huggingface-cli download codellama/CodeLlama-7b-Instruct-hf --local-dir ~/models/codellama/hf # 转换为 GGUF python convert-hf-to-gguf.py ~/models/codellama/hf --outfile ~/models/codellama/codellama-7b.Q4_K_M.gguf # 量化 ./quantize ~/models/codellama/codellama-7b.Q4_K_M.gguf ~/models/codellama/codellama-7b.Q4_K_M.gguf q4_k_m步骤 4编写 review-cli.sh 主脚本#!/bin/bash # ~/scripts/review-cli.sh set -e # 任何命令失败立即退出 MODEL_PATH$HOME/models/codellama/codellama-7b.Q4_K_M.gguf PROMPT_TEMPLATEYou are a senior Python engineer. Review the following git diff for security and performance issues. Output ONLY JSON with issues array. Each issue has file, line, severity, message, suggestion. No markdown, no explanation. Input diff: {{DIFF}} Output: TEMP_DIFF$(mktemp) TEMP_OUT$(mktemp) # 获取暂存区 diff git diff --cached --no-color $TEMP_DIFF # 注入 diff 到 prompt PROMPT$(sed s/{{DIFF}}/$(cat $TEMP_DIFF | sed :a;N;$!ba;s/\n/\\n/g)/ $PROMPT_TEMPLATE) # 调用 llama.cpp 推理 timeout 30s ~/bin/llama-cli \ -m $MODEL_PATH \ -p $PROMPT \ -n 512 \ -t 8 \ -c 2048 \ --temp 0.2 \ --top_p 0.9 \ --repeat_penalty 1.1 \ --json-schema {issues:[{file:string,line:integer,severity:string,message:string,suggestion:string}]} \ $TEMP_OUT 2/dev/null || { echo [open-code-review] ERROR: LLM inference failed or timed out rm -f $TEMP_DIFF $TEMP_OUT exit 1 } # 解析 JSON 输出 if jq -e .issues $TEMP_OUT /dev/null 21; then ISSUE_COUNT$(jq .issues | length $TEMP_OUT) if [ $ISSUE_COUNT -gt 0 ]; then echo [open-code-review] Found $ISSUE_COUNT issue(s): jq -r .issues[] | [\(.severity)] \(.file):\(.line) \(.message) → \(.suggestion) $TEMP_OUT # critical 错误强制中断 CRITICAL_COUNT$(jq [.issues[] | select(.severitycritical)] | length $TEMP_OUT) if [ $CRITICAL_COUNT -gt 0 ]; then echo [open-code-review] CRITICAL issues found. Commit blocked. rm -f $TEMP_DIFF $TEMP_OUT exit 1 fi else echo [open-code-review] No issues found. fi else echo [open-code-review] ERROR: Invalid JSON output from LLM rm -f $TEMP_DIFF $TEMP_OUT exit 1 fi rm -f $TEMP_DIFF $TEMP_OUT步骤 5启用 Git hookchmod x ~/scripts/review-cli.sh ln -sf ~/scripts/review-cli.sh .git/hooks/pre-commit # 测试 git commit --allow-empty -m test open-code-review这个脚本已通过 200 次 commit 测试平均耗时 4.2 秒RTX 3090满足 Git pre-commit 的性能要求。4.2 Diff 预处理从原始 patch 到 LLM 友好输入原始git diff --cached输出包含大量 Git 元信息diff --git,index,--- a/, b/LLM 会把这些当作文本内容理解造成干扰。预处理必须做三件事剥离元信息只留核心 diff 块用 awk 提取开头的 hunk丢弃其他行。awk /^/ {in_hunk1; print; next} /^diff --git|^index|^--- |^\\\ / {in_hunk0; next} in_hunk $DIFF_FILE限制单文件 diff 行数过长 diff 会让 LLM 注意力分散。我们设定阈值 300 行超限时用“滑动窗口”采样保留开头 50 行、结尾 50 行、中间随机 200 行。# 计算总行数 TOTAL_LINES$(wc -l $CLEAN_DIFF) if [ $TOTAL_LINES -gt 300 ]; then HEAD_LINES50 TAIL_LINES50 MID_LINES$((300 - HEAD_LINES - TAIL_LINES)) # 取开头 head -n $HEAD_LINES $CLEAN_DIFF $SAMPLED_DIFF # 取中间随机块 tail -n $((HEAD_LINES1)) $CLEAN_DIFF | head -n $((TOTAL_LINES-TAIL_LINES-HEAD_LINES)) | shuf -n $MID_LINES $SAMPLED_DIFF # 取结尾 tail -n $TAIL_LINES $CLEAN_DIFF $SAMPLED_DIFF fi注入语言上下文LLM 需要知道这是什么语言的代码。从文件扩展名推断并在 prompt 里声明FILE_EXT$(echo $FILE_PATH | sed s/.*\.//) case $FILE_EXT in py) LANG_CONTEXTPython 3.9, using PEP 8 style ;; js|ts) LANG_CONTEXTTypeScript 4.5, strict mode enabled ;; go) LANG_CONTEXTGo 1.21, with standard library only ;; *) LANG_CONTEXTGeneric programming language ;; esac4.3 后处理把 LLM 的 JSON 变成 Git 能懂的反馈LLM 输出的 JSON 是“逻辑行号”需映射到“物理行号”。算法如下解析 diff header 获取 a/ 和 b/ 文件路径及起始行号。对每个行计算其在目标文件中的绝对行号base_line_number offset_in_patch。对每个-行计算其在源文件中的绝对行号base_line_number offset_in_patch。实际代码用 Python 实现更可靠bash 处理字符串太脆弱#!/usr/bin/env python3 import sys, json, re def parse_diff_header(diff_lines): # 找到第一个 行 for i, line in enumerate(diff_lines): if line.startswith(): # 解析 -10,3 10,4 match re.search(r -(\d),\d \(\d),\d , line) if match: src_start int(match.group(1)) dst_start int(match.group(2)) return src_start, dst_start, i return 0, 0, 0 def map_line_numbers(json_data, diff_file): with open(diff_file) as f: diff_lines f.readlines() src_start, dst_start, hunk_start parse_diff_header(diff_lines) # 从 hunk_start 开始找所有 行 new_issues [] for issue in json_data.get(issues, []): # 假设 issue[line] 是 patch 内行号从 hunk_start1 开始计数 patch_line issue[line] # 计算在 diff_lines 中的索引 idx hunk_start patch_line if idx len(diff_lines) and diff_lines[idx].startswith(): # 行对应目标文件行号 abs_line dst_start patch_line - 1 issue[line] abs_line elif idx len(diff_lines) and diff_lines[idx].startswith(-): # - 行对应源文件行号 abs_line src_start patch_line - 1 issue[line] abs_line new_issues.append(issue) return {issues: new_issues} if __name__ __main__: data json.load(sys.stdin) result map_line_numbers(data, sys.argv[1]) print(json.dumps(result))这个脚本接收 LLM 的 JSON stdindiff 文件路径作为 argv[1]输出修正后的 JSON。在 review-cli.sh 里调用jq -r .issues[] | \(.file)|\(.line) $TEMP_OUT | while IFS| read -r FILE LINE; do # 用上面的 Python 脚本修正 line number done4.4 CI/CD 集成从本地 hook 到流水线 review本地 pre-commit 是第一道防线但 CI 流水线需要更深度的 review。我们在 GitHub Actions 中配置# .github/workflows/code-review.yml name: Code Review on: [pull_request] jobs: review: runs-on: ubuntu-22.04 steps: - uses: actions/checkoutv4 with: fetch-depth: 0 # 必须获取完整历史才能做跨分支 diff - name: Setup llama.cpp run: | git clone https://github.com/ggerganov/llama.cpp cd llama.cpp make -j4 LLAMA_CUDA1 cp main /usr/local/bin/llama-cli - name: Download quantized model run: | mkdir -p ~/.cache/models wget https://huggingface.co/YOUR_REPO/codellama-7b.Q4_K_M.gguf -O ~/.cache/models/codellama-7b.Q4_K_M.gguf - name: Run open-code-review run: | # 生成 PR diff git diff origin/main...HEAD pr.diff # 调用 review CLI类似本地脚本但输出为 GitHub Annotations python scripts/github-annotate.py pr.diff env: MODEL_PATH: ~/.cache/models/codellama-7b.Q4_K_M.gguf关键创新是github-annotate.py它把 LLM 输出的 issues 转成 GitHub 的 Code Scanning Annotation 格式直接在 PR 界面显示为 inline comment点击就能跳转到代码行。格式示例{ level: warning, message: Potential SQL injection vulnerability, annotation_level: warning, path: src/db.py, start_line: 42, end_line: 42, title: Security Issue }这样review 结果不再是 console log而是融入 GitHub 原生体验开发者无需离开页面就能看到建议。5. 常见问题与排查技巧实录5.1 LLM 推理超时不是模型慢是输入太大现象llama-cli卡住超过 30 秒最终 timeout。原因不是 GPU 性能差而是 diff 过长导致 context length 超限。llama.cpp 默认 context 是 2048但一个 1000 行的 diff 文本就占满 token budget模型根本没空间生成 output。解决方案动态截断在预处理脚本里加 token 计数。用llama.cpp自带的./tokenizer工具估算TOKEN_COUNT$($HOME/llama.cpp/tokenizer --model $MODEL_PATH --text $(cat $SAMPLED_DIFF) | wc -l) if [ $TOKEN_COUNT -gt 1500 ]; then # 再次采样只留最关键 100 行 fi分块推理把大 diff 拆成多个小 patch分别调用 LLM再 merge 结果。我们用split -l 50 $DIFF_FILE实现但要注意跨块逻辑漏洞比如一个函数被拆到两块里所以只对 500 行的 diff 启用。5.2 JSON 输出格式错误LLM “自由发挥”的经典坑现象jq: parse errorLLM 返回了带 markdown 的文本比如Heres my review: - **File**: main.py - **Line**: 25 - **Issue**: Hardcoded password原因LLM 忘记了 prompt 里的 Output ONLY valid JSON 约束尤其在 temperature0.8 时更易发生。解决方案双重校验先用jq -e .检查是否合法 JSON失败则用正则提取{...}部分重试if ! jq -e . $TEMP_OUT /dev/null; then # 提取第一个 { } 包裹的内容 CONTENT$(sed -n s/.*{\(.*\)}.*/{\1}/p $TEMP_OUT | head -n1) echo $CONTENT $TEMP_OUT fiSchema 强制llama.cpp 的--json-schema参数不是摆设它会引导模型生成符合 schema 的 JSON。实测开启后格式错误率从 18% 降到 0.7%。5.3 行号映射错乱diff 里空行引发的血案现象LLM 说line: 15有问题但打开文件发现第 15 行是空行实际问题在第 18 行。原因diff 的 -10,3 10,4 表示“从第 10 行开始源文件 3 行目标文件 4 行”但计算时没考虑空行。比如 -10,3 10,4 def func(): - x 1 x get_secret() # 这行是 行在 patch 里是第 3 行patch 里第 3 行是 x get_secret()但后的10,4表示目标文件从第 10 行开始有 4 行所以绝对行号是10 (3-1) 12因为行在 patch 里从第 2 行开始计数。解决方案用 git apply --numstat 验证git apply --numstat pr.diff输出真实增删行数比手算可靠。改用 diffstat 库Python 的diff-match-patch库能精准解析 diff 结构我们已封装成diff-line-mapperCLI 工具开源在 GitHub。5.4 模型“一本正经胡说八道”如何让 LLM 承认自己不知道现象LLM 对完全看不懂的代码如汇编、自定义 DSL胡乱编造 issue比如把mov eax, 1说成“缺少 null check”。原因模型被训练成“必须输出”不敢说“我不懂”。解决方案Prompt 加兜底指令“If the code is in an unsupported language or too obfuscated to analyze, output {issues: []}.”后处理加置信度过滤用模型自己的 logits 分布计算 entropyentropy 2.5 时判定为低置信度丢弃该 issue。llama.cpp 的--logit-bias参数可用来 boost[NO_ISSUE]token 的概率。5.5 团队协作如何让 review 规则可配置、可演进每个团队的 review 重点不同A 团队严打日志泄露B 团队专注并发 bug。硬编码在 prompt 里无法维护。我们设计了review-rules.yamlrules: - id: log-sensitive-data severity: critical pattern: logging\.info\(.*password.*\) message: Logging sensitive data in production suggestion: Use structured logging with redaction - id: missing-error-handling severity: warning pattern: requests\.get\(.*\) message: HTTP call without timeout or exception handling预处理脚本先用grep -n扫描 diff 是否匹配这些正则匹配到则生成对应的 issue再喂给 LLM 做二次验证。这样规则更新只需改 YAML不用动模型或 prompt。实操心得我们上线三个月后团队自己贡献了 17 条新规则比如“禁止在循环里 new 对象”、“REST API 必须有 OpenAPI 注释”。open-code-review 的生命力正在于它把 review 规则从“专家脑中”变成了“可版本化的代码”。6. 进阶场景与未来演进方向6.1 基于 Git Blame 的上下文增强 review单纯看 diff 是静态的