开源代码审查CLI工具：基于Git与LLM的结构化审查实践

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

“open-code-review”这个名字乍一听像某个 GitHub 上刚起步的玩具项目，但如果你真把它当成一个普通 CLI 工具去试，很快就会发现——它不是“又一个调用 LLM 的 wrapper”，而是一套围绕开发者真实工作流重新设计的代码审查基础设施。我从去年底开始在三个中型团队（前端+后端+嵌入式）里推动落地，不是用它替代 Code Review，而是把它塞进 PR 流程的缝隙里：Git 提交前自动扫描、CI 阶段做轻量级语义检查、甚至在本地git commit时弹出一行提示：“你改了 utils/date.js，LLM 建议补充时区校验，是否查看建议？”——这种颗粒度，才是 open-code-review 的核心价值。

它本质是把 LLM 从“问答机器人”拉回“工程协作者”的位置：不生成代码，只解释意图；不越权修改，只标注风险；不泛泛而谈“变量命名不规范”，而是指出“第 47 行res在 Promise 链中未被 catch，结合你刚改的 auth middleware，此处可能掩盖 token 过期错误”。关键词里反复出现的CLI、git、LLM、code review，不是并列关系，而是层级依赖：git 是触发器，CLI 是载体，LLM 是能力引擎，code review 是最终交付形态。那些热搜词里混杂的 codex cli、zcode cli、trae cli，其实都在验证同一件事——开发者不要“另一个 Chat UI”，而要“能嵌进终端、能读 Git 状态、能理解上下文边界”的审查伙伴。比如git diff --cached输出的 patch，open-code-review 会先做三件事：识别语言类型（不用猜，靠 shebang + 文件扩展 + AST 特征三重判定）、提取变更函数签名（不是正则匹配，而是用 tree-sitter 解析 AST 节点）、过滤掉测试/配置/锁文件（白名单机制，非简单后缀过滤）。这决定了它和多数“LLM + prompt”方案的根本差异：后者把 diff 当纯文本喂给模型，前者把它当结构化变更事件来处理。

适合谁用？不是 LLM 爱好者，而是每天要处理 5+ 个 PR 的 Tech Lead；不是想学 prompt engineering 的新手，而是被“这个 bug 明明写了单元测试却没覆盖到”折磨三年的 QA 工程师；也不是追求“AI 自动生成 PR 描述”的市场部同事，而是需要向客户证明“本次更新无新增安全漏洞”的合规负责人。它解决的不是“怎么让 AI 更聪明”，而是“怎么让聪明的 AI 不瞎说话”——比如所有 LLM 输出必须绑定 git commit hash，所有建议必须标注依据行号，所有敏感信息（密钥、token、内部 API 地址）在输入前就被正则+语义双层过滤。这才是 open-code-review 在一堆“LLM CLI”中活下来的关键：它默认不相信任何输入，也绝不信任任何输出，所有结论都可追溯、可复现、可审计。

2. 整体架构设计与核心思路拆解

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

很多人第一反应是：“做个浏览器插件多方便，还能高亮显示！”但我在线下和 12 个团队聊过，9 个明确拒绝 Web UI 方案。原因很现实：Code Review 发生在两个时刻——提交前（开发者自查）和合并前（团队评审）。前者要求零延迟、零上下文切换，后者要求可集成进现有流程（如 GitHub Actions）。Web UI 天然卡在这中间：提交前你不会特意开个网页，合并前你已经在 GitHub/GitLab 页面上操作，再跳转到另一个 UI 就是体验断层。

CLI 的优势在于它天然适配 Git 的 hook 机制。open-code-review 的核心设计是“以 Git 为中枢，以 CLI 为神经末梢”。它不自己管理仓库状态，而是通过git status、git diff、git log -n 10等标准命令实时获取上下文。这意味着：

• 无需额外配置仓库地址或 token（Git 本身已含权限）
• 支持任意 Git 托管平台（GitHub/GitLab/Gitee/自建 Gitea）
• 可无缝接入 pre-commit hook（git commit触发）、pre-push hook（git push触发）、CI pipeline（git diff origin/main触发）

我实测过，在 M1 Mac 上，open-code-review diff --staged从读取 diff 到返回结构化建议平均耗时 1.8s（含 LLM 推理），而同等功能的 VS Code 插件因需启动 Node.js 进程+加载 UI 框架，首次响应常超 4s。更关键的是稳定性：CLI 进程随命令结束即释放内存，插件常驻进程易因 Electron 内存泄漏导致后续分析变慢。这不是技术优劣，而是场景选择——当你的目标是“让审查成为 Git 操作的自然延伸”，CLI 就是唯一合理载体。

2.2 LLM 如何嵌入而不失控？三层隔离设计

热搜词里高频出现的“防止密钥泄露”“prompt injection attack”，直指 LLM 在工程场景的最大软肋：不可控的输入输出。open-code-review 的解决方案不是靠更复杂的 prompt，而是物理隔离 + 语义过滤 + 输出约束三层防御：

第一层：输入沙箱（Input Sandbox）
所有传给 LLM 的代码片段，绝不是原始 diff。它经过三步净化：

1. 语法树剥离：用 tree-sitter 解析 AST，移除注释、空行、格式化字符，只保留可执行逻辑节点
2. 敏感词红黑名单：内置 327 条密钥模式（如sk-.*、AKIA[0-9A-Z]{16}、-----BEGIN RSA PRIVATE KEY-----），匹配即替换为<REDACTED>，且记录日志（含 commit hash 和文件路径）
3. 上下文裁剪：LLM 输入窗口有限，但代码逻辑有强局部性。系统自动识别变更函数的调用链（向上追溯 2 层，向下展开 1 层），只传入相关代码块，而非整个文件。例如改了一个 React 组件的useEffect，就只传入该组件定义+其直接依赖的 hooks，不传入无关的 CSS 文件或测试用例。

第二层：模型层协议（Model Layer Protocol）
不直接调用 OpenAI/Claude API，而是通过自研的llm-proxy中间件。它强制要求：

• 所有请求必须带X-Review-Context: { "repo": "org/proj", "commit": "abc123", "file": "src/api/auth.js" }header
• 模型输出必须是严格 JSON Schema（见后文），否则拒绝解析
• 超时阈值设为 8s，超时即 fallback 到规则引擎（如 ESLint 规则库）

第三层：输出验证器（Output Validator）
LLM 返回的 JSON 必须通过三项校验：

• 结构校验：符合预定义 schema（含file,line,severity,message,suggestion字段）
• 行号校验：line值必须在对应文件实际行数范围内（读取当前 HEAD 版本文件验证）
• 引用校验：suggestion中若含代码，必须能被 AST 解析器成功 parse，且与原代码 AST 结构兼容（避免生成语法错误代码）

这套设计让 LLM 退回到“高级规则引擎”的角色——它提供语义洞察，但不决定最终输出。我在金融客户现场部署时，审计方最认可的就是这点：所有 LLM 建议都附带可验证的上下文快照，且修改建议必须经人工确认才能应用。

2.3 Git 集成不是“支持”，而是“共生”

很多工具把 Git 当作数据源，open-code-review 把 Git 当作协作协议。它的命令设计完全镜像 Git 原生命令：

• open-code-review status→ 对应git status，显示哪些文件待审查（按 staged/untracked 分类）
• open-code-review diff [options]→ 对应git diff，但增加--semantic（语义级差异）和--security（安全敏感差异）模式
• open-code-review log -n 5→ 对应git log，但附加每条 commit 的 LLM 审查摘要（如“修复 JWT 校验绕过，建议增加 audience 检查”）

最关键的创新是open-code-review merge-base命令。它不简单调用git merge-base，而是：

1. 获取当前分支与目标分支（如 main）的共同祖先 commit
2. 对比该祖先到当前 HEAD 的所有变更，生成增量审查报告
3. 自动识别“跨文件影响”：例如 A 文件新增了encrypt()函数，B 文件调用了它，系统会将这两处变更关联为同一逻辑单元，避免孤立审查

这解决了传统 Code Review 最大的痛点：单文件视角失真。我曾遇到一个案例：前端同学改了登录页的表单校验，后端同学同时改了密码强度策略，两者单独看都合规，但组合起来导致弱密码被前端放过、后端又拒绝，用户看到“未知错误”。open-code-review 的 merge-base 模式自动捕获这种跨文件耦合，报告中明确标注：“检测到 login-form.js 与 auth-service.py 存在密码策略协同变更，建议同步评审”。

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

3.1 安装与环境准备：为什么推荐二进制分发而非 pip/npm？

open-code-review 官方提供 macOS/Linux/Windows 的预编译二进制（.tar.gz/.zip），而非pip install open-code-review。这不是技术懒惰，而是基于三个硬性约束：

约束一：LLM 运行时依赖冲突
Python 生态中 LLM 相关包（transformers、llama-cpp-python）版本碎片化严重。某客户用 PyTorch 1.12，另一客户用 2.0，而llama-cpp-python的 wheel 包需精确匹配 CUDA 版本。若走 pip 安装，90% 的安装失败源于torch与llama-cpp的 ABI 不兼容。二进制分发将 Python 运行时、CUDA 库、LLM 引擎全部静态链接，彻底规避依赖地狱。

约束二：Git Hook 的可靠性要求
pre-commit hook 必须在任何 shell 环境下稳定运行（bash/zsh/fish/powershell）。pip 安装的脚本依赖python命令在 PATH 中，而企业环境中常存在多个 Python 版本（系统自带 2.7、开发用 3.9、数据分析用 3.11），python指向不确定。二进制文件无解释器依赖，./open-code-review即可执行。

约束三：安全审计合规
金融/政企客户要求所有二进制文件提供 SHA256 校验值和 SBOM（Software Bill of Materials）。pip 包的.whl文件无法提供确定性构建产物，而官方构建流水线对每个 release 生成sha256sum.txt和sbom.json，审计时可直接比对。

安装实操步骤：

# 下载对应平台二进制（以 macOS ARM64 为例） curl -L https://github.com/open-code-review/releases/download/v0.8.3/open-code-review-darwin-arm64.tar.gz | tar xz sudo mv open-code-review /usr/local/bin/ # 验证安装 open-code-review --version # 应输出 v0.8.3 # 初始化配置（首次运行自动创建 ~/.config/open-code-review/config.yaml） open-code-review init

提示：init命令会引导你设置 LLM 后端。它不存储 API Key，而是生成一个加密的llm-config.enc文件（密钥来自你的 macOS Keychain / Windows DPAPI / Linux Secret Service），确保密钥永不落盘明文。

3.2 配置文件深度解析：超越基础 API Key 的 7 个关键参数

~/.config/open-code-review/config.yaml看似简单，实则控制着审查质量的 80%。以下是必须调整的 7 个参数及其原理：

1.model_provider（必填）
支持openai,anthropic,ollama,local四种。选择逻辑：

• openai: 适合需要最强代码理解力的场景（如复杂算法重构），但成本高、延迟波动大
• anthropic: 对安全合规类提示（如“找出硬编码密钥”）响应更稳定，适合金融客户
• ollama: 本地运行codellama:13b，离线可用，但需 16GB GPU 显存
• local: 直连企业私有 LLM 服务（如 Dify 部署的 CodeLlama 微调版），完全可控

2.context_window（默认 4096）
不是越大越好。实测发现：当 context > 8192 时，LLM 对长代码的注意力会衰减，关键行号定位准确率下降 37%。建议按语言调整：

• JavaScript/TypeScript: 6144（因 JSX/TS 类型声明膨胀）
• Python: 4096（AST 简洁）
• Rust: 8192（宏展开后代码量激增）

3.review_granularity（默认function）
控制审查粒度：

• line: 每行独立分析（适合安全扫描，但误报率高）
• function: 默认，分析整个函数体（平衡精度与效率）
• file: 全文件分析（仅用于首次导入旧项目）

4.severity_threshold（默认medium）
定义什么级别问题才报告：

• critical: 仅报告可能导致崩溃/数据泄露的问题（如 SQL 注入、硬编码密钥）
• high: 增加性能反模式（如循环内 DB 查询）
• medium: 默认，包含可维护性问题（如重复代码、过长函数）
• low: 文档缺失、TODO 注释等

5.ignore_patterns（默认空）
不是简单的.gitignore复制。它支持正则和语义规则：

ignore_patterns: - ".*\\.test\\.js$" # 正则：忽略测试文件 - "src/generated/" # 路径前缀：忽略代码生成目录 - "node_modules/**" # glob：忽略依赖 - "if (process.env.NODE_ENV === 'development') {" # 代码片段：忽略开发专用逻辑

6.custom_rules（默认空）
允许注入企业特有规则。例如某银行要求“所有数据库连接字符串必须通过 Vault 获取”，可添加：

custom_rules: - id: "vault-db-conn" description: "数据库连接字符串必须从 Vault 获取" pattern: "const dbConn = '.*'" suggestion: "使用 vaultClient.get('db-connection-string') 替代硬编码"

7.git_hooks（默认启用 pre-commit）
精细控制 hook 行为：

git_hooks: pre_commit: enabled: true skip_on_merge: true # 合并时跳过，避免 CI 冲突 timeout: 15 # 超时时间（秒） pre_push: enabled: false # 默认关闭，避免推送延迟

注意：修改 config 后需运行open-code-review config reload生效，而非重启终端。

3.3 审查模式详解：diff、log、merge-base 的实战差异

open-code-review提供三种核心审查模式，适用场景截然不同：

diff模式：精准狙击变更点
这是日常使用频率最高的模式。关键参数：

• --staged: 审查暂存区（git add后的内容），适合提交前自查
• --cached: 同--staged，Git 术语别名
• --all: 审查工作区所有变更（未git add的文件），适合快速扫描
• --semantic: 启用 AST 级差异分析（比文本 diff 多识别 42% 的逻辑变更）

实操案例：

# 提交前检查暂存区，只关注中高危问题 open-code-review diff --staged --severity high,critical # 审查最近一次提交的变更，并生成 Markdown 报告 open-code-review diff HEAD~1 --format markdown > review-report.md

log模式：历史问题归因
不是简单展示 commit message，而是对每个 commit 做 LLM 审查摘要。关键能力：

• 自动识别 commit 类型：feat,fix,refactor,chore
• 关联 Jira/GitHub Issue ID（从 message 中提取#PROJ-123）
• 标注技术债引入点（如 “此 commit 新增了 3 处 TODO，建议 2 周内清理”）

# 查看最近 5 次提交的审查摘要 open-code-review log -n 5 # 导出为 JSON 供 CI 解析 open-code-review log -n 10 --format json > commits-review.json

merge-base模式：跨分支协同审查
这是解决“合并冲突”的终极武器。它不比较两个分支的全量差异，而是：

1. 计算current-branch...main的 merge base commit
2. 提取从该 base 到 current-branch 的所有变更
3. 智能聚类：将修改同一业务域的文件归为一组（如auth/目录下所有文件）

# 审查当前分支相对于 main 的增量变更 open-code-review merge-base main # 指定目标分支（如 release/2.1） open-code-review merge-base release/2.1 --format html > merge-review.html

实操心得：merge-base模式在大型单体应用中效果显著。我们曾用它发现一个隐藏问题：user-service的数据库迁移脚本（SQL 文件）与api-gateway的路由配置（YAML 文件）存在版本错配，两者在各自分支中均无异常，但合并后导致 5% 的用户请求 500 错误。传统 diff 工具无法关联这两种文件类型，而merge-base通过语义标签（@domain: auth）自动聚类，提前 3 天预警。

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

4.1 从零开始：为新项目配置 open-code-review

假设你接手一个 Vue 3 + TypeScript 的电商项目，需要快速启用审查。以下是完整流程（含避坑点）：

步骤 1：初始化项目配置

# 进入项目根目录 cd ~/projects/ecommerce-frontend # 生成初始配置 open-code-review init # 编辑配置文件（重点修改以下项） nano ~/.config/open-code-review/config.yaml

关键修改：

model_provider: ollama ollama_model: codellama:13b # 本地运行，免 API Key context_window: 6144 review_granularity: function severity_threshold: medium ignore_patterns: - "dist/" - "node_modules/" - ".*\\.d\\.ts$" - "cypress/" git_hooks: pre_commit: enabled: true timeout: 20

步骤 2：安装 pre-commit hook

# 生成 hook 脚本 open-code-review hook install --pre-commit # 验证 hook 是否生效 cat .git/hooks/pre-commit # 应看到类似内容： #!/bin/sh open-code-review diff --staged --severity high,critical || exit 1

注意：某些 IDE（如 WebStorm）的 Git 集成会绕过.git/hooks/pre-commit，需在 IDE 设置中禁用“Use IDE Git integration”或启用“External Git”。

步骤 3：首次全量扫描（建立基线）

# 扫描所有文件（耗时较长，建议下班前运行） open-code-review diff --all --format json > baseline-review.json # 提取高危问题（critical/high） jq '.issues[] | select(.severity == "critical" or .severity == "high")' baseline-review.json | jq -r '.file + ":" + (.line|tostring) + " - " + .message'

典型输出：

src/utils/encryption.ts:47 - 使用 insecure crypto.createCipher，建议升级到 crypto.createCipheriv src/services/payment.ts:123 - 硬编码支付网关 URL，应从环境变量读取

步骤 4：修复并验证

# 修复后，用 diff 模式验证 git add src/utils/encryption.ts src/services/payment.ts open-code-review diff --staged # 应返回 "No issues found" 或仅剩 low 级别问题

步骤 5：集成 CI（GitHub Actions 示例）
在.github/workflows/code-review.yml中添加：

name: Code Review on: [pull_request] jobs: review: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 with: fetch-depth: 0 # 必须获取完整历史，用于 merge-base - name: Install open-code-review run: | curl -L https://github.com/open-code-review/releases/download/v0.8.3/open-code-review-linux-amd64.tar.gz | tar xz sudo mv open-code-review /usr/local/bin/ - name: Run code review run: | open-code-review merge-base ${{ github.base_ref }} --format json > review.json # 提取 critical 问题并失败构建 if jq -e '.issues[] | select(.severity == "critical")' review.json > /dev/null; then echo "Critical issues found!" exit 1 fi

4.2 审查报告解读：如何区分“真问题”与“LLM 幻觉”

LLM 生成的建议并非 100% 准确，关键在于建立人工校验 checklist。以下是我在 200+ 次审查中总结的 5 类典型幻觉及应对法：

幻觉类型 1：行号漂移（Line Number Drift）
现象：LLM 建议修改第 85 行，但实际文件只有 82 行。
原因：输入时做了 AST 剪裁，LLM 基于剪裁后代码计行，但输出时映射回原始文件失败。
验证法：运行open-code-review diff --staged --debug，查看 debug 日志中的input_ast_lines和output_original_line字段是否匹配。

幻觉类型 2：上下文误判（Context Misattribution）
现象：在user.controller.ts中建议“检查 JWT token”，但该文件根本不处理认证。
原因：LLM 将import { verifyToken } from '../auth/jwt'误判为当前文件逻辑。
验证法：检查建议中的suggestion是否引用了当前文件未定义的变量/函数。若引用外部模块，需人工确认调用链。

幻觉类型 3：过度泛化（Overgeneralization）
现象：对一个简单的for (let i=0; i<arr.length; i++)循环，建议“改用for...of以提升性能”。
原因：LLM 训练数据中大量强调for...of更优，但忽略了arr.length在 JS 中是 O(1) 操作，且for...of有额外迭代器开销。
验证法：对性能类建议，必须用console.time()实测。我们的基准测试显示：对 < 1000 元素数组，传统 for 循环快 12%。

幻觉类型 4：安全误报（Security False Positive）
现象：标记const url = 'https://api.example.com' + endpoint为“潜在 XSS”，因endpoint未校验。
原因：LLM 未识别endpoint是受控枚举值（如['users', 'products']），而非用户输入。
验证法：检查变量声明处是否有as const或 TypeScript 枚举定义。若有，则为误报。

幻觉类型 5：建议不可行（Unactionable Suggestion）
现象：建议“将函数拆分为 3 个微服务”，但项目是单体架构且无服务网格。
原因：LLM 从训练数据中习得“微服务更好”，但未考虑当前技术栈约束。
验证法：所有架构类建议必须附带迁移路径（如“需先引入 API Gateway，再逐步拆分”），否则视为无效。

实操心得：我们团队约定——任何 LLM 建议必须满足“三可原则”：可验证（有代码/文档依据）、可执行（不需重构整个系统）、可回滚（修改后不影响现有功能）。不满足任一条件，直接忽略。

4.3 高级技巧：用 custom rules 构建企业知识库

custom_rules不是简单的正则匹配，而是将企业最佳实践编码为可执行规则。以下是三个生产环境真实案例：

案例 1：强制 API 响应格式统一
某公司规定所有 REST API 必须返回{ code: 0, data: {}, message: "" }结构。传统 ESLint 无法检查运行时逻辑，而 custom rule 可：

custom_rules: - id: "api-response-format" description: "API 响应必须符合 {code, data, message} 格式" pattern: "return \\{.*\\}" # 使用 AST 模式，精准匹配 return 语句 ast_pattern: "ReturnStatement > ObjectExpression" suggestion: | return { code: 0, data: result, message: 'success' }

案例 2：禁止特定 npm 包
因moment.js已 EOL，要求全面替换为date-fns。规则需识别所有导入和调用：

custom_rules: - id: "no-moment-js" description: "禁止使用 moment.js，改用 date-fns" pattern: "import.*moment" suggestion: "import { format, parseISO } from 'date-fns'" - id: "no-moment-call" description: "禁止调用 moment() 函数" pattern: "moment\\(" suggestion: "使用 date-fns 的 parseISO() 或 new Date()"

案例 3：合规性检查（GDPR）
用户数据处理必须有明确 consent flag：

custom_rules: - id: "gdpr-consent-check" description: "处理用户数据前必须检查 consent flag" pattern: "user.email|user.phone" # 结合上下文：检查前 5 行是否有 consent 相关变量 context_before: 5 suggestion: | if (!user.consent?.marketing) { throw new Error('Marketing consent not granted'); }

注意：custom rules 的pattern支持两种模式：

• 字符串模式：纯文本匹配（适合简单关键字）
• AST 模式：通过ast_pattern字段指定 tree-sitter 查询（如"CallExpression[callee.name='fetch']"），精度更高但需学习 AST 语法。

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

5.1 安装与权限问题：为什么open-code-review命令找不到？

这是新手最高频问题，90% 源于 PATH 配置。排查步骤：

Step 1：确认二进制文件存在且可执行

ls -la /usr/local/bin/open-code-review # 正常输出应包含 'x'（可执行位），如 `-rwxr-xr-x` # 若无 'x'，运行：sudo chmod +x /usr/local/bin/open-code-review

Step 2：检查 PATH 是否包含/usr/local/bin

echo $PATH | tr ':' '\n' | grep "/usr/local/bin" # 若无输出，说明 PATH 未包含该路径

Step 3：永久修复 PATH（按 Shell 类型）

• Bash/Zsh：编辑~/.bashrc或~/.zshrc，添加：

  export PATH="/usr/local/bin:$PATH"

• Fish：编辑~/.config/fish/config.fish，添加：

  set -gx PATH /usr/local/bin $PATH

• Windows PowerShell：运行：

  $env:Path += ";C:\Program Files\open-code-review"

Step 4：验证终端会话

# 重新加载配置 source ~/.zshrc # 或 ~/.bashrc # 检查命令是否识别 which open-code-review # 应输出 /usr/local/bin/open-code-review

提示：某些企业环境禁用sudo，此时可将二进制放在~/bin/并添加到 PATH，效果相同。

5.2 LLM 连接失败：timeout 或 401 错误的根因分析

Timeout（超时）
现象：open-code-review diff卡住 30 秒后报错Request timeout。
根因：

• 网络问题：公司防火墙拦截了 LLM API 域名（如api.openai.com）
• 模型负载：免费 tier 的 Anthropic API 常排队，响应超 15s
• 本地 Ollama 未启动：ollama serve进程未运行

排查命令：

# 测试网络连通性 curl -I https://api.openai.com # 应返回 401（未授权），而非 timeout # 检查本地 Ollama ollama list # 应显示已拉取的模型 # 查看 open-code-review 日志（含详细错误） open-code-review diff --staged --debug 2>&1 | grep -i "error\|timeout"

401 Unauthorized
现象：明确报错HTTP 401: Invalid API key。
根因：

• API Key 过期（OpenAI 密钥 90 天轮换）
• Key 权限不足（如只开通了 Chat Completions，未开通 Code Completion）
• 配置文件中 Key 被意外截断（复制时多了一个空格）

验证法：

# 手动测试 API（以 OpenAI 为例） curl https://api.openai.com/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer YOUR_KEY_HERE" \ -d '{ "model": "gpt-4", "messages": [{"role": "user", "content": "test"}], "temperature": 0.7 }'

若返回{"error":{"message":"Incorrect API key provided."}}，则 Key 无效。

5.3 Git Hook 不生效：为什么git commit没触发审查？

常见原因与解决方案：

深度调试法：
在.git/hooks/pre-commit开头添加调试日志：

#!/bin/sh echo "$(date): Pre-commit hook started" >> /tmp/hook-debug.log echo "PATH=$PATH" >> /tmp/hook-debug.log echo "which open-code-review: $(which open-code-review)" >> /tmp/hook-debug.log # 原有命令...

提交后检查/tmp/hook-debug.log，即可定位环境差异。

5.4 审查结果不一致：为什么两次diff输出不同？

这是 LLM 的固有特性，但 open-code-review 提供了确定性保障：

原因 1：Temperature 参数波动
默认temperature: 0.3，虽降低随机性，但仍有微小差异。解决方案：在 config 中设为0.0（完全确定性）。

原因 2：输入上下文动态变化
git diff输出受工作区状态影响。例如：

• 第一次git add file.js后运行diff --staged
• 第二次在file.js中新增一行未git add，再运行diff --staged
  → 两次输入不同，输出自然不同。

原因 3：LLM 模型版本更新
Ollama 的codellama:13b标签可能指向不同 commit。解决方案：锁定具体版本：

ollama_model: "codellama:13b-20240301" # 指定日期 tag

终极确定性方案：
启用--deterministic标志（需 v0.8.2+）：

open-code-review diff --staged --deterministic

它会：

• 强制temperature: 0.0
• 对输入 diff 进行 SHA