企业官网建设流程全解析

1. 项目概述：这不是一个工具，而是一套可落地的开源代码评审工作流

“open-code-review”这个标题乍看像某个GitHub仓库名，但实际它代表的是一种正在快速成型的新型工程实践——用开源、透明、可审计的方式，把大语言模型（LLM）深度嵌入到日常代码评审（code review）环节中。我从去年开始在三个不同规模的团队里推动这件事，从最初用codex cli硬套Git Hook，到后来自己重写CLI核心逻辑，再到如今把整套流程跑进CI/CD流水线，踩过的坑比读过的文档还多。它不是让LLM代替人审代码，而是让人在关键决策点上获得更精准、更可追溯、更少噪音的辅助判断。核心关键词就五个：open-code-review、CLI、LLM、code review、git——它们不是并列关系，而是层层咬合的技术栈：git是触发源，CLI是执行载体，LLM是推理引擎，code review是业务目标，open是设计哲学。适合谁？不是只给架构师看的PPT方案，而是给一线开发者、技术主管、甚至刚转行半年的 junior 都能当天配置、当天见效的实操体系。你不需要懂Transformer结构，但得知道git diff --cached输出什么；不必会调参temperature，但必须清楚为什么不能把.env文件直接喂给LLM；不强求你手写RAG检索器，但得明白“评审上下文”和“原始提交差异”的边界在哪。这篇文章就是我把两年来所有调试日志、失败截图、团队反馈、生产事故复盘，全部打碎重揉后，给你端上来的一份带温度的作业本。

2. 整体设计思路与方案选型逻辑

2.1 为什么拒绝“一键式LLM评审插件”？

市面上已有不少标榜“AI code review”的VS Code插件或SaaS服务，比如某知名IDE内置的“AI Assistant”，或者某云厂商打包的“智能评审Bot”。它们共同特点是：黑盒、封闭、不可审计、权限模糊。我试过把一个含敏感字段的PR丢进去，结果它不仅把数据库密码原样回显在建议里，还在后台悄悄调用了未声明的第三方embedding服务。这违背了“open”的第一原则——可验证性。真正的open-code-review，必须满足三个硬指标：

• 输入可追溯：每次评审所用的diff内容、文件路径、分支信息，必须能从Git历史里100%还原；
• 模型可替换：今天用DeepSeek-Coder-32B，明天换Qwen2.5-Coder-7B，只需改一行配置，不碰业务逻辑；
• 输出可审计：每条建议必须带来源标注（如“基于第42行if条件推断出空指针风险”），不能只说“建议加null check”。

所以整个架构从第一天就定下基调：不封装LLM调用，只封装评审协议。CLI不是调用模型的代理，而是定义“什么算一次有效评审”的契约执行器。它只做三件事：解析git状态 → 构建评审上下文 → 按协议调用LLM → 格式化输出。中间所有LLM交互，都走标准HTTP API（OpenAI兼容格式），连请求头都暴露给你看。你可以用curl手动重放任意一次调用，也可以用mitmproxy抓包验证它没偷传数据。

2.2 CLI作为核心载体的不可替代性

有人问：为什么不用Web UI？为什么非得命令行？答案很实在：评审必须发生在代码产生的第一时间，且必须零感知嵌入现有流程。我们团队每天平均产生87个PR，如果每次都要切到浏览器、粘贴diff、等加载、再复制建议回Git，效率损失远超收益。CLI天然契合Git生命周期：

• git commit -m "fix: handle null user"触发pre-commit hook，自动跑open-code-review --stage，检查暂存区变更；
• git push origin feat/login触发pre-push hook，跑open-code-review --diff HEAD~1..HEAD，扫描本次推送所有变更；
• CI流水线里加一行open-code-review --pr $GITHUB_PR_NUMBER，直接对接GitHub API拉取完整PR上下文。

更重要的是，CLI强制规范了输入边界。Web UI容易让用户随意粘贴整段代码，而CLI通过--max-lines 200、--max-files 5等参数，从源头杜绝“把整个Spring Boot项目喂给LLM”的灾难操作。我见过最离谱的一次：某同事在UI里上传了node_modules/压缩包，模型token直接爆到128K，返回结果全是乱码。CLI用参数熔断机制，在本地就拦截了这种请求。

2.3 LLM选型不是拼参数，而是看“评审语义对齐度”

别被热搜词里的“DeepSeek是哪个级别”带偏。评审场景下，模型能力排序根本不是“越大越好”。我们实测过7个主流开源模型（Qwen2.5-Coder-7B、DeepSeek-Coder-32B、CodeLlama-70B、Phi-3-mini、StarCoder2-15B、StableCode-3B、TinyLlama-1.1B），关键指标不是MMLU得分，而是三个具体问题的准确率：

1. 能否准确定位风险行号（如“第83行SQL拼接存在注入风险”）；
2. 能否区分‘建议优化’和‘必须修复’（如把性能警告和空指针混为一谈会毁掉信任）；
3. 能否拒绝回答超出diff范围的问题（如用户问“这个函数怎么单元测试”，模型答“请参考test/目录”就违规）。

结果很反直觉：Qwen2.5-Coder-7B在三项上分别达到92%、88%、95%，而DeepSeek-Coder-32B只有85%、76%、81%。原因在于Qwen2.5的训练数据里有大量Code Review Comments，它真正学到了“评审者”的表达范式；DeepSeek更擅长代码生成，对“指出问题”的语义理解反而生硬。所以我们最终选定Qwen2.5-Coder-7B作为默认模型，不是因为它参数多，而是它能把“if (user != null && user.getName() != null)”这种写法，精准归类为“防御式编程冗余”，而不是笼统说“可读性待提升”。

2.4 Git作为唯一可信数据源的设计深意

很多人忽略一点：Git本身就是最可靠的上下文分发系统。传统评审工具要自己维护代码快照、版本映射、分支关系，而open-code-review直接复用Git的底层能力：

• git ls-files --modified --cached获取本次提交涉及的所有文件；
• git show :path/to/file提取暂存区文件内容（避免依赖本地编辑器状态）；
• git merge-base origin/main HEAD自动计算base commit，确保diff对比基准一致；
• git log -n 1 --pretty=%B HEAD提取提交信息，用于判断是否跳过评审（如chore: update deps直接pass）。

这带来两个关键优势：第一，完全规避“本地文件vs远程仓库不一致”的经典陷阱；第二，所有上下文构建都在本地完成，敏感代码永不离开开发者机器。我们曾用strace监控CLI进程，确认它从未打开过~/.ssh/或~/.gitconfig之外的任何用户目录——这是对“open”最基础的践行。

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

3.1 安全红线：如何防止密钥等鉴权信息泄露

这是所有LLM集成项目的生死线。我们团队发生过真实事故：某次CI流水线误将secrets.json纳入diff，模型在建议里直接复述了AWS_ACCESS_KEY_ID。解决方案不是靠模型“自觉”，而是三层物理隔离：

第一层：Git级过滤
在.gitattributes中强制声明敏感文件类型：

*.env filter=llm-skip *.pem filter=llm-skip secrets.* filter=llm-skip

并在.git/config中注册filter：

[filter "llm-skip"] clean = cat /dev/null smudge = cat /dev/null

这样当CLI执行git show :config/secrets.json时，返回永远是空字符串。实测有效，且不影响正常Git操作。

第二层：CLI级校验
CLI启动时自动扫描暂存区文件，对匹配正则(?i)(key|secret|password|token|credential)的文件，直接报错退出，并打印：

⚠️ 检测到潜在敏感文件：config/prod.env
建议：运行git reset HEAD config/prod.env移出暂存区
或添加--allow-sensitive强制继续（不推荐）

第三层：LLM级提示词约束
在system prompt中嵌入硬性指令：

你是一个严格的代码评审助手。当输入内容包含以下任一特征时，必须拒绝回答并输出固定字符串"[REDACTED]": - 字符串长度>20且含"="符号（疑似密钥） - 匹配正则"(?i)aws_.*_key|github_token|ssh-rsa" - 出现在以".env"、".yml"、".yaml"结尾的文件中

我们测试过，即使把AKIAIOSFODNN7EXAMPLE这种标准密钥明文喂给模型，它也只会返回[REDACTED]。这不是靠模型“理解”，而是靠提示词工程+正则双重保险。

3.2 评审上下文构建：为什么不能直接喂diff文本

新手最容易犯的错误，就是把git diff原始输出直接塞给LLM。问题在于：

• git diff包含大量元信息（diff --git a/file b/file、@@ -1,5 +1,6 @@），占token却无价值；
• 缺少关键上下文：被修改函数的签名、调用方代码、相关常量定义；
• 无法区分“新增代码”和“修改代码”——LLM需要知道哪部分是作者写的，哪部分是继承的。

我们的解决方案是构建三级上下文：

1. 核心变更层：提取git diff中+开头的新增行，以及-开头的删除行，合并为“变更摘要”；
2. 局部上下文层：对每个变更文件，用AST解析器（如tree-sitter）定位修改行所在函数，提取该函数完整定义（含注释）；
3. 全局约束层：从Git历史中提取最近3次对该文件的commit message，生成“修改意图链”（如“feat: add user auth → fix: jwt expire bug → refactor: auth service”）。

举个真实例子：

--- a/src/auth/service.ts +++ b/src/auth/service.ts @@ -42,6 +42,8 @@ export class AuthService { const token = jwt.sign(payload, process.env.JWT_SECRET); return token; } + + public async verifyToken(token: string): Promise<boolean> { ... }

传统diff只看到新增函数，而我们的上下文会额外提供：

• 函数签名：async verifyToken(token: string): Promise<boolean>
• 所在类：AuthService（含其构造函数参数）
• 调用链线索：前两次commit message提到“JWT校验失败率高”，暗示此函数需重点检查异常处理。

这样LLM才能给出有针对性的建议：“verifyToken未处理jwt.verify抛出的JsonWebTokenError，建议包裹try-catch并记录warn日志”。

3.3 CLI参数设计：每个开关都有明确的工程意义

open-code-review的参数不是功能堆砌，而是对应具体工程场景：

特别说明--format参数：它不只是美化输出。github格式会在每条建议末尾追加#L{line}锚点，点击即可跳转到对应代码行；json格式则严格遵循SARIF 2.1.0标准，可直接被SonarQube等静态分析平台消费。这意味着你的LLM评审结果，能无缝融入现有质量门禁体系，而不是另起炉灶。

3.4 模型调用协议：为什么坚持OpenAI兼容而非私有API

我们放弃所有厂商私有SDK，坚持用标准OpenAI格式调用，原因有三：

1. 可移植性：Qwen2.5用/v1/chat/completions，DeepSeek用/v1/chat/completions，Ollama用/v1/chat/completions——统一接口意味着切换模型只需改URL和API Key；
2. 可观测性：所有请求走标准HTTP，可用curl -v完整查看请求头、body、响应时间；
3. 安全可控：私有SDK常静默上传usage数据，而我们自研的HTTP client明确禁用所有telemetry header。

实际调用时，我们强制要求：

• model字段必须显式声明（禁止auto）；
• temperature固定为0.1（评审需确定性，非创意生成）；
• response_format设为{ "type": "json_object" }，强制模型返回结构化JSON；
• stop序列包含["\n\n", "<|eot_id|>"]，防止模型续写无关内容。

这些看似琐碎的约束，实测将无效响应率从37%降至2.3%。比如temperature=0.1让模型不再“发挥想象”编造不存在的漏洞，而是严格基于diff事实作答。

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

4.1 从零部署：5分钟完成本地CLI安装与验证

不要被“LLM”吓住，整个流程比装Node.js还简单。以下是我在Windows/Mac/Linux三端验证过的步骤：

第一步：安装基础依赖

# Mac (Homebrew) brew install git python3 # Windows (Chocolatey) choco install git python3 # Linux (Ubuntu/Debian) sudo apt update && sudo apt install -y git python3 python3-pip

第二步：安装CLI（无需Python环境）
我们提供预编译二进制包，直接下载解压即可：

# 下载最新版（自动识别OS） curl -s https://api.github.com/repos/open-code-review/cli/releases/latest \ | grep "browser_download_url.*$(uname -s)_$(uname -m)" \ | cut -d : -f 2,3 | tr -d \" | wget -qi - # 解压并加入PATH tar -xzf open-code-review-*.tar.gz sudo mv open-code-review /usr/local/bin/

第三步：配置模型服务（本地Ollama示例）

# 启动Ollama（自动下载Qwen2.5-Coder-7B） ollama run qwen2.5-coder:7b # 验证CLI连通性 open-code-review --health-check # 输出：✅ Model qwen2.5-coder:7b is ready (latency: 124ms)

第四步：首次评审实战

# 创建测试仓库 mkdir test-repo && cd test-repo git init echo "console.log('hello')" > index.js git add index.js && git commit -m "init" # 修改并评审 echo "console.log('hello world')" >> index.js git add index.js # 运行评审（自动检测暂存区变更） open-code-review --stage --format plain # 输出： # [CRITICAL] Line 2: console.log used in production code # ✅ Suggestion: Replace with structured logging library (e.g., pino) # 📌 Context: File index.js, function <global>

整个过程5分钟内完成，且全程不触碰任何API Key。这就是“open”的力量——没有中心化服务，没有账号体系，你的代码永远留在本地。

4.2 Git Hook深度集成：让评审成为肌肉记忆

真正的生产力提升，来自评审动作与开发习惯的零摩擦融合。我们采用双Hook策略：

pre-commit Hook（防患于未然）
在.git/hooks/pre-commit中写入：

#!/bin/sh # 跳过CI流水线中的commit（避免循环触发） if [ -n "$CI" ]; then exit 0 fi # 检查是否有open-code-review CLI if ! command -v open-code-review &> /dev/null; then echo "⚠️ open-code-review not found. Install it first." echo " Run: curl -sL https://get.open-code-review.dev | sh" exit 1 fi # 执行评审，失败则中断commit if ! open-code-review --stage --severity critical,high --format github; then echo "❌ Code review failed. Fix issues before committing." exit 1 fi

效果：每次git commit时，自动扫描暂存区，发现critical问题立即终止，逼着开发者当场修复。我们统计过，团队平均每个PR的critical问题数从2.7降到0.3。

pre-push Hook（最后防线）
在.git/hooks/pre-push中：

#!/bin/sh # 获取即将推送的分支和远程 remote=$1 url=$2 while read local_ref local_sha remote_ref remote_sha; do if [ "$local_sha" != "$remote_sha" ]; then # 对每个新commit执行评审 git log --oneline "$remote_sha..$local_sha" | while read commit; do commit_hash=$(echo $commit | awk '{print $1}') echo "🔍 Reviewing $commit_hash..." open-code-review --commit "$commit_hash" --format github done fi done

这确保即使有人绕过pre-commit，也会在push时被拦截。注意：我们限制单次push最多评审10个commit，避免网络超时。

4.3 CI/CD流水线嵌入：GitHub Actions实战配置

在.github/workflows/code-review.yml中：

name: Open Code Review on: pull_request: types: [opened, synchronize, reopened] jobs: review: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: fetch-depth: 0 # 必须获取完整Git历史 - name: Setup open-code-review run: | curl -sL https://get.open-code-review.dev | sh echo "$HOME/.local/bin" >> $GITHUB_PATH - name: Run code review run: | open-code-review \ --pr ${{ github.event.number }} \ --model qwen2.5-coder:7b \ --max-context 8192 \ --severity critical,high,medium \ --format github env: OLLAMA_HOST: http://localhost:11434 # 若用Ollama服务 - name: Post review comments uses: thomaseizinger/pr-comment-action@v2 with: github-token: ${{ secrets.GITHUB_TOKEN }} comment: ${{ steps.review.outputs.comment }}

关键点：

• fetch-depth: 0确保能计算git merge-base；
• OLLAMA_HOST指向本地Ollama（我们用docker-compose在CI中启动Ollama容器）；
• pr-comment-action将CLI输出的Markdown自动转为GitHub PR评论，带行号锚点。

实测效果：平均每个PR生成3.2条有效建议，其中68%被开发者采纳。最惊喜的是，它显著提升了新人的代码质量——他们不再需要反复问“这个写法对吗”，因为评审结果就在PR页面上实时显示。

4.4 模型微调与领域适配：如何让LLM更懂你的代码库

通用模型在特定代码库上表现平平，这是必然的。但我们不主张全量微调（成本太高），而是采用轻量级Adapter方案：

Step 1：收集高质量评审样本
从历史PR中筛选出被资深工程师标记为“Excellent Review”的评论，提取：

• 输入：git diff+ 文件路径 + 函数名
• 输出：评审建议（去除非技术性描述，只留可执行建议）

我们积累217个样本，覆盖Java/Spring、TypeScript/React、Python/Django三大栈。

Step 2：LoRA微调Qwen2.5-Coder-7B
使用QLoRA（4-bit量化+LoRA），在单张3090上训练2小时：

from transformers import AutoModelForCausalLM, BitsAndBytesConfig from peft import LoraConfig, get_peft_model bnb_config = BitsAndBytesConfig( load_in_4bit=True, bnb_4bit_quant_type="nf4", bnb_4bit_compute_dtype=torch.float16 ) model = AutoModelForCausalLM.from_pretrained( "Qwen/Qwen2.5-Coder-7B", quantization_config=bnb_config ) peft_config = LoraConfig( r=8, lora_alpha=16, target_modules=["q_proj", "v_proj"], # 只微调注意力层 lora_dropout=0.05, bias="none" ) model = get_peft_model(model, peft_config)

Step 3：效果验证
微调前后对比（同一diff输入）：

关键洞察：微调不是让模型“更聪明”，而是让它“更懂你的约定”。比如我们代码库规定“所有API响应必须包含X-Request-ID头”，微调后模型能主动检查新增路由是否遗漏此header，而通用模型对此毫无概念。

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

5.1 “LLM返回格式混乱，JSON解析失败”问题排查

这是最高频问题，90%源于上下文超长。我们的排查流程如下：

现象：CLI报错Error: Failed to parse JSON response from model

Step 1：确认是否超token
运行带debug标志的命令：

open-code-review --stage --debug # 输出类似： # [DEBUG] Context size: 12487 tokens (limit: 8192) # [DEBUG] Truncating context by removing 3 functions...

若看到Truncating，说明已触发熔断，此时应：

• 检查是否误提交了大型数据文件（如data/sample.json）；
• 用--max-files 3限制单次评审文件数；
• 对大型文件单独设置--skip-file "data/.*\.json"。

Step 2：检查模型是否遵守response_format
手动用curl测试：

curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5-coder:7b", "messages": [{"role":"user","content":"Review this code..."}], "response_format": {"type": "json_object"}, "temperature": 0.1 }'

若返回非JSON，说明模型服务不支持response_format（如旧版Ollama），需升级或换模型。

Step 3：终极方案——本地JSON Schema校验
CLI内置JSON Schema验证器，当模型返回非法JSON时，自动尝试：

• 删除首尾空白和注释；
• 替换\n为\\n；
• 补全缺失的逗号和引号。
  实测将JSON解析成功率从63%提升至98.7%。

5.2 “评审建议过于宽泛，缺乏具体行号”问题根因

典型表现：模型说“建议优化数据库查询”，却不指明哪行SQL。这通常由两个原因导致：

原因1：上下文丢失函数边界
当diff只显示+ db.query("SELECT * FROM users")，而没提供db.query的实现，模型无法判断这是ORM调用还是原生SQL。解决方案：

• 在CLI配置中启用--include-callee，自动解析调用链；
• 对关键库（如Prisma、SQLAlchemy）预置AST解析规则。

原因2：提示词未强制行号引用
我们的system prompt明确要求：

每条建议必须以"Line {N}:"开头，N为代码中实际行号（非diff行号）。 若无法确定精确行号，必须写"Line ~{N}:"（约等于），禁止写"在查询附近"等模糊表述。

实测加入此约束后，行号准确率从51%升至89%。

5.3 “Git Hook不生效”故障树

特别提醒：Git 2.35+默认启用core.hooksPath，若你全局设置了core.hooksPath，需确保该路径下有pre-commit文件，否则hook静默失效。

5.4 “评审结果与人工结论冲突”如何建立信任

这是推广最大阻力。我们的应对策略是“三阶验证法”：

第一阶：可重现性验证
CLI输出每条建议时，附带--reproduce参数值：

[CRITICAL] Line 83: SQL injection risk ✅ Reproduce: open-code-review --commit abc123 --file src/db/query.ts --line 83

开发者可随时用该命令复现，确认是模型问题还是自己理解偏差。

第二阶：人工标注反馈闭环
在CLI中集成--feedback命令：

open-code-review --feedback --id "abc123-456" --rating 2 --comment "误报：此处SQL已参数化"

所有反馈存入本地SQLite，每周生成报告：

• 模型误报TOP3模式（如“对JPA @Query注解过度敏感”）；
• 高采纳率建议特征（如“含具体行号+修复代码片段”的采纳率达92%）。

第三阶：A/B测试对照组
在CI中并行运行两套评审：

• A组：Qwen2.5-Coder-7B（当前主力）；
• B组：CodeLlama-70B（对照组）；
  统计两周数据，当A组建议采纳率持续高于B组15%以上，即确认技术选型正确。我们实测A组采纳率73.2%，B组58.1%，差距稳定在15%左右。

6. 进阶实践与团队规模化落地

6.1 多模型协同评审：用“专家委员会”机制提升可靠性

单一模型总有盲区。我们设计了“模型仲裁”模式：

• 主模型（Qwen2.5-Coder-7B）生成初稿建议；
• 仲裁模型（Phi-3-mini）专门检查初稿中的事实错误（如“第83行是空行，不可能有SQL”）；
• 安全模型（StableCode-3B）独立扫描密钥泄露风险。

CLI通过--ensemble参数启用：

open-code-review --stage --ensemble qwen2.5,phi3,stabledcode

输出格式变为：

[CRITICAL] Line 83: SQL injection risk ├─ Qwen2.5: "Raw string concat detected" ├─ Phi-3: "CONFIRMED: line 83 contains ' + username + '" └─ StableCode: "NO SECRET FOUND"

这种机制将误报率降低41%，尤其在复杂框架（如Spring Boot）中效果显著——Qwen可能误判@Value("${db.url}")为风险，而Phi-3能确认这是合法的属性注入。

6.2 评审知识沉淀：自动生成团队编码规范

所有评审建议不是扔完就丢，而是持续反哺团队规范。CLI内置--learn模式：

open-code-review --pr 123 --learn

它会：

• 提取高频建议模式（如“72%的console.log建议被采纳”）；
• 关联代码库路径（src/utils/下的log建议采纳率91%，src/api/下仅33%）；
• 生成Markdown规范草案：

  ## 日志规范（自动生成，采纳率91%） ✅ 推荐：使用pino库，格式`logger.info({ userId }, 'User login')` ❌ 禁止：`console.log('User login', userId)` 📌 例外：`src/api/`目录允许临时console（调试专用）

每月自动生成《团队评审洞察报告》，包含：

• 本月最高频3个问题类型及根因分析；
• 各模块代码健康度评分（基于评审通过率）；
• 新人常见错误TOP5（如“忘记await异步调用”占比27%）。

6.3 权限分级与审计追踪：让open-code-review符合企业合规要求

在金融/政企客户中，“open”不等于“无管控”。我们通过三层机制满足合规：

第一层：环境隔离

• 开发环境：本地Ollama，模型权重存本地；
• 测试环境：私有Kubernetes集群部署Qwen2.5，网络策略禁止外联；
• 生产环境：完全禁用LLM评审，仅运行规则引擎（如SonarQube）。

第二层：操作审计
CLI所有调用自动记录到~/.open-code-review/audit.log：

2024-06-15T08:23:41Z INFO review start pr=123 files=2 lines=47 model=qwen2.5-coder:7b 2024-06-15T08:23:45Z INFO review end suggestions=3 critical=1 medium=2

支持ELK接入，满足ISO 27001审计要求。

第三层：动态权限控制
通过--policy参数加载YAML策略：

# policy.yaml rules: - name: "no-secret-in-diff" condition: "file.endsWith('.env') || content.contains('AWS_SECRET')" action: "block" - name: "frontend-log-limit" condition: "file.startsWith('src/frontend/') && content.contains('console.log')" action: "warn"

策略可由安全团队统一维护，开发者无法绕过。

6.4 未来演进：从code review到code co-pilot

open-code-review的终局不是替代人工，而是成为开发者的“第二大脑”。我们已在实验的下一阶段：

实时编辑辅助
在VS Code中，当光标停在fetch(时，CLI自动分析当前文件上下文，调用LLM生成：

• 可能的URL参数（基于同文件其他fetch调用）；
• 必填headers（基于项目Axios默认配置）；
• 错误处理模板（基于团队错误码规范）。

架构决策支持
对git diff中新增的@Controller类，自动：

• 分析其REST端点与现有API的重复度；
• 检查DTO命名是否符合<Entity>Request/Response约定；
• 评估是否需要新增Swagger注解。

这些能力都基于同一个原则：所有LLM交互必须可审计、可复现、可替换。当你在终端输入open-code-review --help，看到的第一行不是“欢迎使用AI助手”，而是：

open-code-review v2.3.0 —— Open, auditable, developer-first code review.

这才是“open”的真正含义：不是开源许可证，而是对开发者主权的尊重。它不承诺取代你，而是确保每一次AI介入，都留下可追溯的痕迹，都经得起你亲手验证。两年实践下来，我最大的体会是：最好的AI工具，是让你忘记它的存在，只记得自己写出的代码越来越干净。