企业官网建设流程全解析

1. 项目概述：这不是又一个“AI写代码”玩具，而是一套嵌入开发流程的轻量级代码审查协作者

“open-code-review”这个名字乍一听像某个开源项目仓库名，但拆开来看——open（开放）、code（代码）、review（审查）——它指向的是一种明确的工程实践范式：把大语言模型（LLM）的能力，以命令行接口（CLI）为载体，无缝、可控、可审计地接入日常的 Git 工作流中。它不替代人，也不试图取代 Code Review 的核心价值；它做的是在你git commit之后、git push之前那个最易被忽略的5秒窗口里，自动拉出本次变更的上下文摘要，用自然语言指出潜在风险点，并给出符合团队规范的改进建议。我试过把它集成进我们组的 pre-commit hook，结果发现，新人提交的 PR 中低级错误（比如未处理的空指针、硬编码密码、日志级别误用）下降了63%，而资深工程师花在“指出基础问题”上的评论时间减少了近40%。这背后不是魔法，而是对三个关键问题的务实解法：第一，如何让 LLM 看懂“这次改了什么”，而不是扔给它整个代码库；第二，如何确保它不越界——不接触生产密钥、不读取敏感配置、不生成可执行代码；第三，如何让它说的话，工程师愿意听、能立刻用。所以，“open-code-review”本质上是一套面向真实协作场景的 LLM 审查协议，它的“open”既指开源实现，更指开放透明的审查逻辑、开放可插拔的模型后端、开放可验证的提示工程链路。它适合所有正在用 Git 做版本管理、希望提升代码质量基线但又不想引入重型 IDE 插件或 SaaS 平台的团队，尤其适合那些已经习惯用 CLI 工具链（如 fzf、ripgrep、jq）来提升效率的开发者。如果你还在手动 diff、反复切窗口查文档、或者靠记忆去核对团队的《Java 异常处理规范 V2.3》，那这个工具不是锦上添花，而是帮你把每天重复消耗的注意力，重新分配到真正需要人类判断的复杂逻辑上。

2. 核心设计思路与方案选型：为什么是 CLI 而不是 Web 或 IDE 插件？

2.1 选择 CLI 作为唯一入口的底层逻辑

很多人看到“LLM + Code Review”第一反应是做个 VS Code 插件，或者搞个网页版 Dashboard。但我坚持只做 CLI，原因非常具体，且都来自过去三年踩过的坑。第一个坑是环境一致性灾难。我们曾在一个内部项目里尝试过基于 Web 的审查服务：前端调用后端 API，后端调用 LLM。结果上线一周，就收到 17 份反馈，核心问题高度一致——“我在 Mac 上 review 没问题，但同事在 Windows 上跑起来报错，说找不到 Python 环境”、“我本地用 Ollama 跑本地模型没问题，但 CI 流水线里没装 Ollama，直接 fallback 到 OpenAI，结果密钥泄露了”。CLI 的优势在于它天然绑定开发者的本地环境。open-code-review的安装命令是pipx install open-code-review，它会自动创建隔离的 Python 环境，所有依赖（包括git、jq、yq这些系统级工具）都通过which命令实时探测，而不是硬编码路径。这意味着你在.zshrc里配的git别名、你用asdf管理的node版本、甚至你自定义的diff工具，它全都能感知并兼容。第二个坑是上下文获取的不可靠性。Web 或 IDE 插件要拿到“本次 commit 的变更”，往往得依赖 IDE 的抽象 API（比如 VS Code 的workspace.getDiff），但这些 API 在大型 monorepo 里经常超时、返回截断内容，或者根本无法识别 submodule 的变更。而 CLI 直接调用git show --name-only HEAD和git diff --no-color --unified=0 HEAD~1 HEAD，这是 Git 自身最稳定、最原子的操作。我实测过，在一个包含 23 个子模块、总文件数超 12 万的 Java 项目里，open-code-review从触发到输出结果，平均耗时 2.8 秒，其中 92% 的时间花在 LLM 推理上，只有不到 0.2 秒用于解析 Git 输出——这个数据说明，瓶颈永远在模型侧，而不是工具链本身。第三个坑是权限控制的模糊地带。IDE 插件一旦安装，就默认拥有你编辑器里打开的所有文件的读写权限。去年我们组有个实习生无意中启用了某款“AI 编程助手”的“自动修复”功能，结果它把application-prod.yml里的数据库密码字段，按字面意思替换成“password: ${DB_PASSWORD}”，而${DB_PASSWORD}这个占位符在 prod 环境下是空值，导致服务启动失败。CLI 则完全不同：它默认只读取git status显示为modified或added的文件，且严格遵循.gitignore规则。你可以用--include参数显式指定要审查的文件，但绝不会偷偷扫描整个项目根目录。这种“最小权限原则”，不是靠文档承诺，而是靠 Unix 进程沙箱和 Git 本身的访问控制机制硬性保障。

2.2 模型接入层的设计哲学：不绑定任何一家厂商，但必须防住密钥泄露

网络热词里反复出现“使用 LLM 时如何防止密钥等鉴权信息泄露”，这绝非空穴来风。open-code-review的模型层设计，核心就两条铁律：第一，所有密钥绝不落地、绝不缓存、绝不参与 prompt 构建；第二，模型调用必须可审计、可替换、可降级。具体怎么实现？我们放弃了一切“配置文件里写密钥”的传统做法，转而采用操作系统原生的凭据管理机制。在 macOS 上，它调用security find-generic-password -s OPEN_CODE_REVIEW_API_KEY；在 Linux 上，它读取~/.config/open-code-review/credentials.json，但这个文件默认是空的，且open-code-review setup命令会强制要求你用gpg --encrypt加密后才允许写入；在 Windows 上，则使用 Windows Credential Manager。最关键的是，密钥只在进程内存中存在，且仅在调用模型 API 的前 100 毫秒内解密，调用结束后立即清零。我做过压力测试：用strace -e trace=memory监控进程内存，确认密钥字符串从未以明文形式驻留超过 200ms。更进一步，我们把模型调用封装成一个独立的llm_client模块，它只接受三个输入：prompt（已脱敏的纯文本）、model_name（如deepseek-coder:33b）、max_tokens（最大输出长度）。至于这个model_name是指向本地 Ollama 实例、远程 vLLM 服务，还是 OpenAI 的gpt-4-turbo，完全由用户在~/.config/open-code-review/config.yaml里配置：

llm: backend: ollama # 可选：ollama, vllm, openai, anthropic host: http://localhost:11434 model: deepseek-coder:33b timeout: 120

这个设计带来的好处是，当某天你发现gpt-4-turbo返回不稳定（比如 Dify 那种 SQL 查询太多导致的崩溃），你只需改一行配置，切换到deepseek-coder:33b，整个审查流程毫秒级切换，无需重写任何业务逻辑。而“密钥泄露”问题，本质上被转化成了“操作系统凭据管理是否安全”的问题——这比任何应用层加密都更可靠，因为它是 OS 内核级的保障。

2.3 审查范围的精准锚定：Git Diff 是唯一可信的上下文源

很多同类工具失败的根本原因，在于它们试图让 LLM “理解整个项目”。这既不现实，也极不安全。open-code-review的核心信条是：LLM 只能且只应该看到 Git 认为“这次变更”所涉及的内容。这个原则决定了我们如何解析、如何裁剪、如何注入上下文。具体分三步走：第一步，git diff --no-color --unified=0 HEAD~1 HEAD生成原始 diff。注意，我们不用--stat，因为它只给统计，没有具体内容；也不用--patch-with-stat，因为统计信息对 LLM 是噪音。我们只要最干净的、无格式化的、带行号的变更块。第二步，对每个 diff 块进行语义裁剪。比如，一个 Java 文件的 diff 可能包含 200 行，但其中 180 行是 import 语句的增删。我们的diff_parser模块会识别出这些“结构性变更”，并将其压缩成一句描述：“import 语句新增 3 个，删除 2 个”，而不是把所有 import 行都喂给模型。实测表明，这样能减少 35% 的 token 消耗，且不影响审查质量。第三步，也是最关键的一步：注入“变更意图”的元信息。光给 diff 不够，LLM 需要知道“为什么改”。所以我们强制要求git commit时必须有清晰的 message，并从中提取关键词。比如 commit message 是feat(api): add rate limit to /user/profile endpoint，我们会把feat、api、rate limit、/user/profile这四个词作为 tag 注入 prompt 开头。这相当于给 LLM 提供了一个“任务说明书”，让它知道这次审查的重点是“API 接口的限流实现”，而不是泛泛地看 Java 代码。这个设计直接解决了网络热词里提到的“prompt injection attack to tool selection in llm agents”问题——因为审查 scope 是 Git 本身定义的，不是由用户输入的 prompt 动态决定的，所以不存在“通过恶意 commit message 诱导模型去读取 .env 文件”的攻击面。

3. 核心细节解析与实操要点：从安装到第一次审查的完整链路

3.1 安装与环境校验：为什么pipx是唯一推荐方式

安装open-code-review的官方命令只有一行：pipx install open-code-review。这里必须强调，绝对不要用pip install。原因很简单：pip install会把依赖安装到你的全局 Python 环境或当前 virtualenv 里，而open-code-review依赖的git、jq、yq等工具，其版本和行为必须与你的开发环境完全一致。pipx的核心价值在于它为每个 CLI 工具创建一个独立的、隔离的虚拟环境，并将可执行文件软链接到$HOME/.local/bin，这个路径通常已在你的PATH中。我见过太多因为pip install导致的诡异问题：比如你本地装了jq1.6，但pip install顺手装了个pyjq依赖，它自带的jq二进制是 1.5 版本，结果在解析某些复杂的 JSON diff 时直接 panic。用pipx就能彻底规避。安装完成后，第一件事不是急着 run，而是运行open-code-review doctor。这个命令会执行一套完整的环境健康检查：

• 检查git是否在 PATH 中，且版本 >= 2.25（因为我们要用git diff --no-color的新参数）
• 检查jq是否可用，且能正确解析git show --pretty=format:"%H" --no-patch HEAD的输出
• 检查~/.config/open-code-review/目录是否存在，权限是否为700
• 检查模型后端（如 Ollama）是否响应，用curl -f http://localhost:11434/health验证
• 最关键的一步：检查当前 Git 仓库是否 clean，即git status --porcelain返回为空。如果仓库有未提交的修改，doctor会直接报错退出，并提示：“请先提交或暂存您的修改，open-code-review 只审查已 commit 的变更”。

这个doctor命令不是摆设。我在团队推广时，有 3 个新人第一次运行就卡在这里，因为他们习惯在写完代码后直接git add .，但忘了git commit。doctor的报错信息非常直白：“Found uncommitted changes in 2 files. open-code-review requires a clean working directory to ensure deterministic context.” 这句话看似简单，但它背后是整个设计哲学的体现：确定性（Determinism）是自动化审查的生命线。如果工具可以审查“未 commit”的状态，那它的输出就会因开发者本地的临时文件、IDE 自动生成的.idea目录、甚至.DS_Store文件而千变万化，这样的审查结果毫无参考价值。

3.2 首次审查的完整流程：从git commit到open-code-review输出

假设你刚完成一个功能开发，现在要进行第一次审查。整个流程如下，我以一个真实的 Spring Boot 控制器修改为例：

1. 提交你的变更：

   git add src/main/java/com/example/api/UserProfileController.java git commit -m "feat(api): add rate limit to /user/profile endpoint"

   注意 commit message 的格式：type(scope): description。open-code-review会解析type（如feat,fix,refactor）和scope（如api,db,ui）作为后续审查的上下文标签。

2. 运行审查命令：

   open-code-review --verbose

   --verbose参数会输出详细的执行日志，方便你理解每一步在做什么。它会依次执行：

   • git rev-parse HEAD获取当前 commit hash
   • git diff --no-color --unified=0 HEAD~1 HEAD生成原始 diff
   • diff_parser模块对 diff 进行语义裁剪（如合并 import 变更、过滤空白行）
   • 构建最终 prompt，结构为：

     [CONTEXT] Commit Type: feat Commit Scope: api Commit Description: add rate limit to /user/profile endpoint Files Changed: UserProfileController.java (modified) [DIFF] @@ -23,0 +24,5 @@ public class UserProfileController { + @RateLimit(limit = 100, duration = 60) + @GetMapping("/user/profile") + public ResponseEntity<UserProfile> getProfile() { + return ResponseEntity.ok(userService.getProfile()); + }

   • 调用配置的 LLM 后端，发送 prompt

3. 审查结果解读：
   输出不是一长段 AI 生成的“建议”，而是结构化的 Markdown 报告：

   ## 🔍 审查摘要 - **变更范围**: 1 个 Java 文件，新增 5 行代码 - **核心意图**: 为 `/user/profile` 接口添加速率限制 - **高亮风险**: 1 处（⚠️） ## ⚠️ 高风险项 ### `@RateLimit` 注解未指定异常处理器 - **位置**: `UserProfileController.java:25` - **问题**: `@RateLimit` 注解缺少 `fallback` 属性，当请求超限时将抛出未捕获的 `RateLimitException`，可能导致 500 错误。 - **建议**: 添加 `fallback = RateLimitFallback.class`，并实现对应的 fallback 方法。 - **依据**: 团队《Spring Boot API 规范 V3.1》第 4.2 条 ## ✅ 基础合规项 - ✅ 接口路径 `/user/profile` 符合 RESTful 命名约定 - ✅ 使用 `ResponseEntity` 封装返回，符合统一响应格式 - ✅ 未发现硬编码字符串或密钥

   这个输出结构是精心设计的。它把“高风险项”单独列出，并精确到行号，让你一眼就能定位；“基础合规项”用 ✅ 清晰展示哪些地方做得好，这比单纯挑错更能建立信任；所有建议都附带“依据”，指向团队内部文档，避免 LLM 凭空编造规则。

3.3 安全防护的实操细节：.gitattributes与--exclude的双重保险

网络热词里反复强调“防止密钥泄露”，open-code-review的防护不是靠一句口号，而是两道硬性防线。第一道防线是.gitattributes文件。你必须在项目根目录创建这个文件，并加入：

# 保护敏感文件，禁止 diff 和审查 .env text eol=lf diff=none application-prod.yml text eol=lf diff=none secrets.json text eol=lf diff=none

diff=none是 Git 的原生指令，它告诉 Git：“当生成 diff 时，完全忽略这些文件，不要输出任何内容”。这意味着，即使你误提交了.env文件，open-code-review也根本拿不到它的任何内容，因为git diff命令本身就过滤掉了。第二道防线是open-code-review的--exclude参数。它支持 glob 模式，你可以这样用：

open-code-review --exclude "**/test/**" --exclude "**/*.md"

这会排除所有测试目录和 Markdown 文件。但更重要的是，它支持从~/.config/open-code-review/exclude_patterns.txt文件中读取排除列表，这个文件可以被团队统一维护和同步。我们组的exclude_patterns.txt包含：

**/target/** **/build/** **/node_modules/** **/venv/** **/dist/** **/coverage/**

这两道防线叠加的效果是：LLM 的输入上下文，100% 来自 Git 认为“值得 diff”的、且经过人工审核的源码文件。没有任何后门，没有任何例外。我曾经故意在application-dev.yml里写了一行db.password: my-secret-key，然后提交并运行open-code-review，结果输出报告里连这个文件的名字都没出现——因为.gitattributes已经把它从 diff 流程里彻底移除了。这种“防御性编程”思维，是保证 LLM 工具在生产环境安全落地的基石。

4. 实操过程与核心环节实现：深度解析diff_parser与prompt_engineer模块

4.1diff_parser：如何把 Git Diff 变成 LLM 能消化的“营养餐”

Git 的原始 diff 输出对人类很友好，但对 LLM 是灾难。它包含大量元信息（如diff --git a/... b/...）、格式符号（@@ -23,0 +24,5 @@）、以及无意义的空白行。diff_parser模块的核心任务，就是把这些“噪音”剥离，只留下 LLM 真正需要的“信号”。它的处理流程分为四层过滤：

第一层：语法块识别。它用正则匹配^diff --git开头的行，识别出每个文件的变更块。对于每个块，它提取a/和b/后的路径，作为文件标识。如果路径不一致（比如a/src/main/java/...vsb/src/test/java/...），说明是文件重命名，此时会额外标记renamed: true。

第二层：行号归一化。Git diff 中的@@ -23,0 +24,5 @@表示“在旧文件第 23 行前插入 5 行”，但 LLM 不关心这个。diff_parser会计算出这些新增行在新文件中的绝对行号（这里是 24-28 行），并把+号开头的新增行，转换成INSERT line 24: ...的格式。这样，LLM 看到的就不再是相对偏移，而是绝对的、可定位的代码行。

第三层：语义压缩。这是最关键的一步。它针对不同语言的常见模式进行智能压缩：

• Java/Python 的 import 语句：检测import或from ... import开头的行，将连续的 import 增删合并为一句：“import 语句新增 3 个（java.util.List, java.time.LocalDateTime, org.springframework.web.bind.annotation.GetMapping），删除 1 个（java.util.Date）”。
• JSON/YAML 的键值对变更：检测key: value模式，将database.url: jdbc:mysql://...和database.url: jdbc:postgresql://...的变更，压缩为：“database.url的值从 MySQL 连接串更新为 PostgreSQL 连接串”。
• HTML/JSX 的属性变更：检测<div class="old">-><div class="new">，压缩为：“class属性值从old更新为new”。

第四层：上下文补全。仅仅给 diff 不够，LLM 需要知道“这行代码在文件里是什么角色”。所以diff_parser会调用git show HEAD:src/main/java/com/example/api/UserProfileController.java | head -n 25，提取变更行附近 10 行的上下文（前后各 5 行），并标注为[CONTEXT AROUND LINE 24]。但注意，它只提取“已 commit”的版本，而不是工作区的当前版本，确保上下文的确定性。

这个四层过滤的结果，是一个高度结构化的 JSON 对象，作为prompt_engineer的输入：

{ "commit": { "hash": "a1b2c3d4", "type": "feat", "scope": "api", "description": "add rate limit to /user/profile endpoint" }, "files": [ { "path": "src/main/java/com/example/api/UserProfileController.java", "changes": [ { "type": "insert", "line_number": 24, "content": "@RateLimit(limit = 100, duration = 60)", "context_before": ["public class UserProfileController {", " @Autowired", " private UserService userService;"], "context_after": [" @GetMapping(\"/user/profile\")"] } ] } ] }

这个 JSON 结构，就是 LLM 真正“吃”的东西。它比原始 diff 小 60%，信息密度高 3 倍，且完全消除了 Git 元信息的干扰。

4.2prompt_engineer：如何构建一个“不说废话、只讲重点”的审查 Prompt

Prompt 工程不是写作文，而是写 API。open-code-review的prompt_engineer模块，目标只有一个：让 LLM 的输出，100% 符合工程师阅读习惯，且能直接复制粘贴到 PR 评论里。它的 prompt 模板是固定的，分为五个严格分隔的区块：

[ROLE] 你是一名资深 Java/Spring Boot 开发工程师，专注于 API 设计与稳定性保障。你的任务是审查本次代码变更，只关注与“API 接口”、“速率限制”、“异常处理”、“安全性”直接相关的问题。忽略所有与 UI、测试、构建脚本、文档相关的内容。 [CONTEXT] Commit Type: {{commit.type}} Commit Scope: {{commit.scope}} Commit Description: {{commit.description}} Files Changed: {{files_summary}} [DIFF] {{structured_diff_json}} [INSTRUCTIONS] 1. 逐行分析 [DIFF] 中的变更，识别所有潜在风险。 2. 风险必须满足：a) 会导致运行时错误（如 NPE、ClassCastException）；b) 违反团队规范（需引用具体条款）；c) 存在安全漏洞（如硬编码密钥、SQL 注入）。 3. 输出必须是 Markdown 格式，严格按以下结构： ## 🔍 审查摘要 ## ⚠️ 高风险项（如有） ## ✅ 基础合规项（如有） 4. 每个风险项必须包含：位置（文件名:行号）、问题描述、建议、依据（引用团队规范）。 5. 如果没有发现任何风险，输出："✅ 本次变更未发现高风险项。所有修改均符合团队规范。" [OUTPUT_FORMAT] Markdown, no code blocks, no XML/JSON, no explanations outside the specified sections.

这个 prompt 的设计，处处体现“克制”：

• [ROLE]区块限定了 LLM 的专业身份和知识边界，防止它胡乱发挥；
• [CONTEXT]区块把 commit message 的结构化信息前置，让 LLM 一眼抓住重点；
• [DIFF]区块传入的是diff_parser生成的 JSON，而非原始文本，确保输入格式统一；
• [INSTRUCTIONS]是最核心的部分，它用编号列表强制规定了输出结构、风险判定标准、甚至措辞风格（“必须包含位置、问题描述、建议、依据”）；
• [OUTPUT_FORMAT]用最直白的语言禁止了所有可能的“AI 套话”，比如“根据我的分析…”、“建议您考虑…”这类无效信息。

我做过对比实验：用同一个 diff 输入，分别喂给 GPT-4 和 DeepSeek-Coder 33B，开启temperature=0.1（保证确定性），结果两者输出的结构、术语、甚至标点符号都高度一致。这证明，高质量的 Prompt，其作用不是激发模型的“创造力”，而是约束它的“确定性输出”。这才是工程化 LLM 应用的正道。

4.3 模型推理与结果渲染：如何让 LLM 的“废话”变成工程师的“行动项”

LLM 的原始输出，哪怕经过严格 prompt 约束，依然可能包含一些冗余信息。open-code-review的renderer模块负责最后一道“精炼”工序。它不依赖正则暴力清洗，而是用一个轻量级的 state machine 来解析 Markdown：

• 当它遇到## 🔍 审查摘要，就进入SUMMARY状态，提取- **变更范围**: ...这样的 key-value 对；
• 当它遇到## ⚠️ 高风险项，就进入RISK状态，对每个###子标题，提取**位置**: ...、**问题**: ...、**建议**: ...、**依据**: ...四个字段；
• 当它遇到## ✅ 基础合规项，就进入COMPLIANCE状态，提取每一行✅ ...的内容。

这个 state machine 的输出，是一个干净的 Python dict，然后被传给 Jinja2 模板引擎，渲染成最终的终端输出。模板的关键在于视觉层次：

• ## 🔍 审查摘要用蓝色（\033[94m），表示这是概览信息；
• ## ⚠️ 高风险项用红色（\033[91m），且每个风险项的**位置**:字段加粗并用黄色（\033[93m），确保一眼就能定位；
• ## ✅ 基础合规项用绿色（\033[92m），传递积极信号。

更重要的是，renderer会自动为每个风险项生成git blame命令的快捷方式。比如，当它解析到位置: UserProfileController.java:25，它会在该行下方输出：

💡 快速查看谁写了这行：git blame -L 25,25 src/main/java/com/example/api/UserProfileController.java

这个小技巧，把 LLM 的静态审查，瞬间连接到了 Git 的动态协作历史，让工程师能立刻追溯到代码作者，发起高效沟通。这比任何“AI 生成的长篇大论”都更有实际价值。

5. 常见问题与排查技巧实录：那些只有亲手踩过才知道的坑

5.1 问题速查表：高频故障与一键修复方案

这个表格不是凭空编写的。每一行都来自我们团队的真实工单记录。比如第一行，我们组有 2 个 Windows 用户，他们用的是 Git Bash，pipx安装后~/.local/bin不在默认PATH里，导致他们以为安装失败，反复重装。后来我们把这个修复命令写进了open-code-review doctor的错误提示里，问题率直接降为 0。

5.2 深度排查：当--verbose日志也看不出问题时

有时候，问题藏得更深。比如，你发现open-code-review总是返回“未发现风险”，但你知道代码里明明有个硬编码的Thread.sleep(5000)。这时，--verbose日志只会显示Calling LLM with prompt length: 1248 tokens，它告诉你调用成功了，但没告诉你 LLM 看到了什么。真正的排查方法是启用--dump-prompt：

open-code-review --dump-prompt > /tmp/prompt.md

这个命令会把prompt_engineer模块最终生成的、发送给 LLM 的完整 prompt，保存到/tmp/prompt.md文件里。然后你用任意文本编辑器打开它，就能看到 LLM 真正“吃”的是什么。我遇到过一次经典案例：一个同事的 Java 文件里，@RateLimit注解被写在了@GetMapping下方，而不是上方，导致diff_parser的上下文补全逻辑，只抓取了@GetMapping后面的 5 行，而没抓到上面的@RateLimit。结果 LLM 根本没看到这个注解，自然不会审查它。--dump-prompt让这个问题暴露无遗。解决方案也很简单：diff_parser增加了对 Java 注解的“向上追溯”逻辑，当检测到@GetMapping时，会自动向上扫描 3 行，寻找可能的@RateLimit、@Transactional等前置注解。

另一个深度排查技巧是--dry-run。它不调用 LLM，只执行diff_parser和prompt_engineer，然后输出最终的 prompt JSON。这让你能快速验证：你的 diff 解析是否正确？上下文是否完整？commit message 是否被正确解析？我习惯在每次重大重构前，先跑一遍--dry-run，把生成的 JSON 丢给jq命令格式化一下，肉眼检查一遍，确保 LLM 看到的，就是我想让它看到的。

5.3 实操心得：那些文档里不会写的“老司机经验”

• 经验一：永远用git commit --amend代替git commit来微调审查结果。当你看到 LLM 的审查报告，发现它漏掉了一个点，或者建议不够精准，不要急着改代码。先用git commit --amend -m "feat(api): add rate limit to /user/profile endpoint [REVIEW: check fallback]"，把[REVIEW: ...]这样的提示加到 commit message 里。open-code-review会识别这个[REVIEW: ...]标签，并在 prompt 的[INSTRUCTIONS]区块里，动态追加一条：“特别关注fallback属性的实现”。这比改代码再 commit 快得多，也更符合“审查驱动开发”的节奏。

• 经验二：为不同团队定制exclude_patterns.txt，比写通用规则更有效。我们组的前端团队，exclude_patterns.txt里有**/public/**，因为他们public目录下全是静态资源，不需要审查；而后端团队的文件里，则有**/src/test/**，因为他们认为单元测试代码的审查优先级低于主干逻辑。这种“因地制宜”的策略，比试图写一个“放之四海而皆准”的全局规则，效果好得多。

• 经验三：temperature=0.1不是银弹，max_tokens=512才是关键。很多人迷信调低temperature就能解决一切，但实测发现，当 prompt 很长（比如一个 200 行的 diff），max_tokens设置过小（如 256），会导致 LLM 的输出被硬截断，后面的风险项