open-code-review：基于 Git Diff 与 LLM Agent 的命令行代码审查范式-开发者社区

1. 这不是又一个代码审查工具，而是一次开发协作范式的重新定义

“open-code-review”这个名字乍看平平无奇，甚至有点拗口——它不像“GitHub Copilot”那样自带传播力，也不像“CodeWhisperer”那样直击“写代码”的动作。但如果你在最近三个月里翻过几份开源项目的 PR（Pull Request）评论区，或者在团队内部 Slack 频道里看到过“刚用 open-code-review 扫了一遍 diff，发现三处边界条件没覆盖”，那你大概率已经和它打过照面，只是还没认出它的名字。

它不是一个 SaaS 服务，不收订阅费，不绑定账号体系，不强制你登录；它也不是一个 IDE 插件，不会在你敲下return的瞬间弹出建议框。它是一个命令行原生、Git 原生、Diff 原生的轻量级审查代理，核心逻辑只做一件事：把一段git diff的文本输入，喂给本地或远程的 LLM，让它以资深工程师的身份，逐行阅读、质疑、追问、补全上下文，最后输出一份带明确依据、可追溯、可复现、可嵌入 CI 流程的审查意见。关键词里的 “open” 不是指开源协议（虽然它确实是 MIT 协议），而是指开放输入源、开放模型选择、开放审查规则、开放集成路径——它不预设你是用 DeepSeek-V2 还是 Qwen2.5-72B，不规定你必须用 JSON Schema 格式输出，也不要求你非得走 GitHub Actions 而不是 GitLab CI。

我第一次接触它，是在帮一家做边缘计算中间件的团队做代码审计时。他们用 Rust 写驱动层，C 写裸机适配，Python 写运维脚本，三套语言混在一个 monorepo 里。传统 Code Review 工具要么只支持 Python（如 SonarQube 的 Python 插件），要么对 Rust 的生命周期检查束手无策，更别说跨语言的接口契约一致性了。而open-code-review的 CLI 模式让我直接把git diff --no-prefix origin/main HEAD的输出喂进去，指定不同语言用不同模型配置（Rust 用本地 Qwen2.5-7B-Inst，Python 用飞书自建的 DeepSeek-R1 API），12 秒后就拿到一份带行号引用、带 CWE 编号标注、带修复建议的 Markdown 报告。最关键是——它不替你做决定，只放大你的判断力：它指出“第 47 行unwrap()在生产环境可能 panic”，但不会自动改成expect()；它标出“第 112 行 HTTP 状态码未校验”，但留给你决定是加if status.is_success()还是重构为 Result 类型。

适合谁？不是只想点个按钮就出报告的管理者，而是每天要读 20+ 个 PR、需要快速抓住要害的 Tech Lead；不是刚学 Git 的实习生，而是能写git log -p -n 3 --grep="refactor"精准定位变更范围的 Senior Dev；不是追求“AI 替我写代码”的人，而是相信“AI 应该替我多问一句‘这里为什么这么写？’”的务实派。它解决的从来不是“有没有人 review”，而是“review 是否真正穿透了变更意图”。

2. 它为什么必须是 CLI + Git Diff 原生？这背后有三重不可妥协的设计逻辑

2.1 CLI 不是妥协，而是对开发工作流的绝对尊重

很多人第一反应是：“CLI？现在都 2024 年了，还要敲命令？”——这恰恰是open-code-review最锋利的设计支点。我们来拆解一个真实 PR 场景：前端同学提交了一个 Vue 组件的修改，同时后端同学同步更新了对应的 API 接口文档（OpenAPI YAML）和 DTO 类。传统 Web UI 类 Code Review 工具会怎么做？它得先拉取整个 PR 的两个分支，解析出所有变更文件，再按文件类型分发给不同规则引擎，最后拼合成一份报告。这个过程隐含三个致命问题：

上下文割裂：Vue 组件里调用的fetch('/api/v2/user')和 OpenAPI 中定义的/api/v2/user是否参数一致？Web UI 工具看不到这两个文件在 diff 中的共变关系，只能孤立分析；
状态污染：为了分析 YAML 文件，它得加载 Swagger 解析器；分析 Vue 模板，得启动 JS 引擎；分析 DTO，得反射 Java 类。这些依赖极易冲突，尤其在 CI 环境中，一个npm install就可能让整个流程失败；
权限黑洞：Web UI 必须拥有仓库的读写权限才能获取 diff，而很多金融/政企客户连 GitHub App 的contents:read权限都要走月度安全评审。

open-code-review的 CLI 模式彻底绕开这些陷阱。它只接收git diff的纯文本输出——这是 Git 本身保证原子性、一致性、可重现性的最小语义单元。你执行：

git diff origin/main HEAD | open-code-review --model qwen2.5-7b-inst --rules ./rules/rust-security.yaml

这条命令里没有网络请求、没有文件系统访问、没有权限申请。它像grep或awk一样，是 Unix 哲学的忠实信徒：只做一件事，把它做到极致，并能被管道组合。你可以把它塞进pre-commit钩子，在git commit前自动扫描；可以放在make review里，作为每日构建的固定环节；甚至能用find . -name "*.rs" -exec git diff origin/main HEAD -- {} \; | open-code-review ...实现按目录粒度的定向审查。这种自由度，是任何 Web UI 永远无法提供的。

提示：不要试图用open-code-review替代git add -p。它的定位是“增强型 diff 阅读器”，不是“交互式暂存管理器”。我见过团队强行把它集成到 VS Code 的 Source Control 视图里，结果每次点击文件都要触发一次模型调用，CPU 占用飙到 98%——这是对工具边界的误判。

2.2 Git Diff 是唯一可信的变更事实源

为什么不用 AST（抽象语法树）？为什么不用 LSP（语言服务器协议）？为什么不用 GitHub API 的pulls/{id}/files？因为它们都不是“变更”的第一手证据。

AST 是编译器视角的代码结构，但它丢失了编辑意图。比如你把for i in 0..10 { ... }改成for i in 0..=10 { ... }，AST 可能显示为同一个RangeExpr节点，只是inclusive字段从false变true，但人类 reviewer 关心的是“为什么这里要包含 10？边界条件是否重叠？”——这个疑问只存在于 diff 的+行里。
LSP 提供实时语义，但它依赖编辑器状态。当 reviewer 在手机上打开 PR 链接时，LSP 根本不存在；当 CI 环境里没有安装对应语言服务器时，LSP 直接失效。
GitHub API 的 files endpoint 返回的是“变更后的文件内容”，而非“变更本身”。它无法告诉你config.yaml的第 3 行是从timeout: 30改成了timeout: 60，还是从timeout: 30删掉了整行再新增timeout: 60——后者可能意味着配置项被重置，前者只是调参，风险等级天壤之别。

open-code-review强制要求输入必须是git diff输出，正是因为它承载着无可替代的元信息：

@@ -12,5 +12,7 @@明确标识了变更在原文件中的精确位置和影响范围；
+和-符号天然编码了增删意图，模型可以据此推断“这里是新增防御逻辑”还是“这里是移除日志埋点”；
文件头diff --git a/src/lib.rs b/src/lib.rs提供了语言类型线索（.rs→ Rust），无需额外配置；
二进制文件会被git diff自动跳过，避免模型浪费算力分析图片或 PDF——这是对资源的本能敬畏。

我在某次金融项目审计中，发现一个关键支付路由模块的 diff 里，+行新增了一行let fee = amount * 0.025;，而-行删除了原有的fee = calculate_fee(&amount);调用。如果只看最终文件，你会以为只是内联计算；但看 diff，立刻意识到这是业务逻辑降级——原函数可能包含汇率换算、地区费率表查询等复杂逻辑，而新代码直接硬编码了 2.5%。这个洞察，只有 diff 能给出。

2.3 LLM Agent 不是噱头，而是审查能力的指数级放大器

热词里反复出现的 “LLM Agent”、“embedding”、“Codex CLI”，常被混为一谈。但open-code-review对 Agent 的定义极其克制：它不追求“自主规划”、“多步推理”、“工具调用”，而只聚焦于一个 Agent 能力——基于当前 diff 上下文，动态检索并注入相关知识片段。

举个具体例子。当模型看到 Rust diff 中出现Arc::new(Mutex::new(HashMap::new()))时，它不该只回答“这是线程安全哈希表”，而应主动触发检索：

检索项目根目录下的SECURITY.md，找到 “禁止在高频路径使用 Mutex，推荐 RwLock” 的条款；
检索git log -S "Arc<Mutex<HashMap>" --since="3 months ago"，发现过去三个月有 7 次同类模式被 rollback；
检索 HuggingFace 上rust-security-rulesembedding 数据库，匹配到 CWE-667（不恰当的同步）的典型模式。

这个过程不是靠模型“凭空想象”，而是由open-code-review的 Agent Runtime 控制：它把 diff 文本切片后生成 embedding 向量，去向量数据库查相似代码模式，再把匹配到的规则文档、历史 commit、CVE 报告摘要，作为 system prompt 的一部分注入下一轮 LLM 调用。这才是 “Agent” 的价值——它让 LLM 从“通用知识答题机”，变成“项目专属审查顾问”。

对比一下热词里的几个概念：

DeepSeek、Qwen、Claude是基础模型（Base Model），它们提供语言理解和生成能力，就像汽车的发动机；
Codex CLI、ZCode CLI是特定厂商封装的 CLI 工具，通常绑定自家模型和固定 prompt，灵活性低；
Embedding是把文本转成向量的技术，它是 Agent 实现知识检索的“眼睛”，但不是 Agent 本身；
Trae CLI、Deveco CLI属于 IDE 厂商的垂直工具链，深度耦合编辑器状态，难以脱离 GUI 运行。

open-code-review的 Agent 架构刻意保持“模型无关”：你可以用 Ollama 本地跑 Qwen，也可以用飞书 API 调 DeepSeek，甚至能用 Claude 的claude-3-haiku处理短 diff、用claude-3-opus处理长逻辑块——Agent Runtime 只负责调度，不绑定任何厂商。

3. 从零部署：一条命令启动，但真正落地需要理解这五个核心配置层

3.1 最简启动：验证你的环境是否 ready

别急着改配置文件。先用最暴力的方式确认基础链路通不通：

# 1. 安装（假设你已装好 Python 3.10+ 和 pip） pip install open-code-review # 2. 准备一个极简 diff（模拟单行修改） echo -e "diff --git a/test.py b/test.py\nindex abc123..def456 100644\n--- a/test.py\n+++ b/test.py\n@@ -1,3 +1,4 @@\n def hello():\n- return \"world\"\n+ return \"world!\"\n" > sample.diff # 3. 用内置小模型跑通（无需联网，纯 CPU） open-code-review --input sample.diff --model ollama/qwen2.5:0.5b --format markdown

如果输出类似：

## Review Summary - **Line 4**: Added exclamation mark to greeting string. Consider consistency with other string literals in project (e.g., `utils.py` line 22 uses `\"Hello\"` without punctuation).

恭喜，你的环境已通过第一关。注意这里用了ollama/qwen2.5:0.5b——这是 Ollama 仓库里最小的 Qwen2.5 模型，仅 1.2GB，能在 M1 Mac 上秒级响应。它不追求完美，只验证 pipeline 是否完整。

注意：不要在首次测试时尝试--model deepseek-coder:33b。33B 模型在消费级显卡上需要 24GB VRAM，且首次加载需 5 分钟以上。先用 0.5B 确认流程，再逐步升级。

3.2 模型层：不是越大越好，而是“够用即止”的精准选型

open-code-review支持四类模型接入方式，每种对应不同场景：

接入方式	典型模型	适用场景	延迟	成本
Ollama 本地	`qwen2.5:7b`,`deepseek-coder:6.7b`	离线环境、敏感代码、快速迭代	<2s (7B)	$0
HTTP API	DeepSeek-R1 (飞书), Claude-3-Haiku (Anthropic)	需要更强逻辑推理、支持长上下文	3-8s	¥0.02~¥0.15/次
HuggingFace TGI	`Qwen2.5-72B-Instruct`(自托管)	企业私有云、高吞吐审查	15-30s	GPU 电费
Lite 模式	`phi-3-mini`,`gemma-2b`	pre-commit 钩子、CI 快速初筛	<1s	$0

关键原则：按 diff 复杂度分级调用模型。我们团队的实践配置如下：

# .open-code-review.yaml models: # 简单变更（<10 行，单文件） simple: provider: ollama model: qwen2.5:0.5b timeout: 3000 # 3秒超时 # 中等变更（10-100 行，跨 2-3 文件） medium: provider: http model: https://feishu-api.example.com/v1/chat/completions api_key: ${FEISHU_API_KEY} timeout: 8000 # 复杂变更（>100 行，含算法/安全关键逻辑） complex: provider: tgi model: http://tgi-server:8080 timeout: 30000

然后在 CLI 中指定策略：

# 自动根据 diff 行数选择模型 git diff origin/main HEAD | open-code-review --strategy auto # 强制用复杂模型（用于审计关键 PR） git diff origin/main HEAD | open-code-review --strategy complex --rules ./rules/security.yaml

实测数据：对一个 42 行的 Python diff（含 pandas 数据处理逻辑），qwen2.5:0.5b平均耗时 1.8s，准确率 68%（漏检 2 处潜在空指针）；deepseek-r1耗时 6.2s，准确率 94%；qwen2.5-72b耗时 24s，准确率 97%，但性价比暴跌。真正的工程智慧，是承认 94% 的准确率已足够支撑 80% 的日常审查场景。

3.3 规则层：用 YAML 写“审查宪法”，而不是写 if-else

open-code-review的规则文件不是传统静态分析的 regex 规则库，而是面向 LLM 的提示工程（Prompt Engineering）说明书。一个典型的security.yaml长这样：

# rules/security.yaml name: "Security Hardening" description: "Detect common security anti-patterns in diffs" # 这些是注入到 system prompt 的全局约束 system_prompt: | You are a senior security engineer reviewing code changes. Focus ONLY on security implications: injection, auth bypass, crypto misuse, hard-coded secrets. NEVER comment on style, naming, or non-security logic. # 每条 rule 是一个 context-aware 的 prompt 片段 rules: - id: "hardcoded-secret" description: "Detect hardcoded credentials in new code" trigger: "line contains 'password=' or 'api_key=' or 'secret:'" prompt: | This line appears to contain a hardcoded credential. Check if it's: - A test fixture (e.g., in tests/ directory) → OK - A production config → MUST be moved to environment variables - A placeholder for demo → MUST be annotated with TODO(security) Cite exact line number and file path. - id: "sql-injection" description: "Detect potential SQL injection vectors" trigger: "line matches 'f\"SELECT.*{.*}\"' or 'format(\"SELECT.*%s\")'" prompt: | String interpolation in SQL queries is dangerous. Recommend: - Use parameterized queries (e.g., sqlite3 placeholders) - If ORM is used, ensure query builder is applied - If raw SQL is unavoidable, validate input with allowlist

关键点在于trigger字段：它不是正则匹配，而是语义感知的 diff 行过滤器。open-code-review会先用轻量级 parser 提取 diff 中的+行，再对每行执行trigger判断，只把匹配的行喂给 LLM。这样既减少 token 消耗，又提升审查精度。

我踩过的坑：曾把trigger写成line contains "eval("，结果模型对所有含evaluate的变量名都报警。后来改成line matches "eval\$[^)]*\$"（精确匹配 eval() 调用），误报率从 37% 降到 2%。

3.4 集成层：不是“接入飞书”，而是“让飞书成为你的审查终端”

热词里频繁出现的 “codex cli 接入飞书”，本质是误解。open-code-review从不主动“接入”任何 IM 工具，而是通过标准 webhook 协议，让飞书（或钉钉、企业微信）成为它的输出终端。

实现步骤极简：

在飞书创建一个 Bot，获取 Webhook URL；
配置open-code-review的 output 插件：

# .open-code-review.yaml output: - type: webhook url: https://www.feishu.cn/... # 你的飞书 Bot webhook format: feishu_card # 预设的飞书卡片模板

在 CI 脚本中触发：

# .gitlab-ci.yml review: stage: review script: - git diff origin/main HEAD > /tmp/diff.patch - open-code-review --input /tmp/diff.patch --output webhook

飞书收到的不是冷冰冰的 JSON，而是一张带图标、折叠详情、一键跳转的卡片：

标题：[PR#42] Fix user profile update race condition
主体：⚠️ Security Alert: Line 87 in api/handler.go uses unsafe strconv.Atoi()
折叠区：Full review report → [View on GitLab]
操作按钮：✅ Approve,💬 Comment,🔄 Rerun

这才是真正的“接入”——不侵入飞书 SDK，不依赖飞书客户端版本，不绑定飞书账号体系。你换钉钉，只需改format: dingtalk_card；换 Slack，改format: slack_block。集成的自由，源于对标准协议的坚守。

3.5 环境层：用 .env 文件管理密钥，用 Docker Compose 隔离模型服务

生产环境部署的核心矛盾是：模型服务需要 GPU，审查 CLI 需要轻量，两者必须隔离。我们的标准方案是 Docker Compose：

# docker-compose.yml services: # 模型服务（GPU 节点） tgi: image: ghcr.io/huggingface/text-generation-inference:2.0.2 runtime: nvidia environment: - MODEL_ID=Qwen/Qwen2.5-72B-Instruct - CUDA_VISIBLE_DEVICES=0 ports: - "8080:80" # 审查服务（CPU 节点） reviewer: build: . environment: - TGI_URL=http://tgi:8080 - FEISHU_WEBHOOK=https://... volumes: - ./rules:/app/rules - ./repos:/app/repos

CLI 容器里只装 Python 和open-code-review，通过http://tgi:8080调用模型服务。这样做的好处：

模型更新只需重启tgi容器，不影响审查流程；
审查 CLI 可以水平扩展（起 10 个容器并行处理 PR）；
.env文件只存TGI_URL和FEISHU_WEBHOOK，密钥不进 Git。

实操心得：永远不要在open-code-review的配置文件里写明文 API Key。用 Docker 的--env-file加载.env，并在.gitignore中屏蔽它。我曾因一次git commit -a泄露了 Anthropic Key，导致账单暴涨——教训是：密钥管理不是配置问题，是流程红线。

4. 实战复盘：一次真实金融项目审查的全流程记录与决策推演

4.1 场景还原：支付路由模块的紧急 hotfix

客户是一家持牌支付机构，其核心路由模块（Go 语言）需紧急修复一个跨境交易汇率计算偏差。原始 PR 描述极其简单：“Fix USD/EUR rate calculation in /payment/route.go”。但 diff 内容让我脊背发凉：

diff --git a/payment/route.go b/payment/route.go index a1b2c3d..e4f5g6h 100644 --- a/payment/route.go +++ b/payment/route.go @@ -120,7 +120,7 @@ func calculateRate(from, to string, amount float64) float64 { case "USD", "EUR": // Use ECB daily rate - rate := getECBRate(from, to) + rate := getECBRate(from, to) * 1.002 default: rate := getFixerRate(from, to)

表面看只是乘了个 1.002 的系数，但getECBRate函数在ecb_client.go里定义为：

func getECBRate(from, to string) float64 { // Cache result for 1 hour if cached, ok := cache.Get(from + "_" + to); ok { return cached.(float64) } // Fetch from ECB API (rate-limited to 1000 req/day) rate := fetchFromECB(from, to) cache.Set(from+"_"+to, rate, 1*time.Hour) return rate }

问题来了：这个* 1.002是临时补偿，还是永久调整？如果是永久调整，ECB 缓存的原始值是否还有效？如果只是临时，为什么不在注释里说明生效时间？

4.2 审查执行：五层穿透式提问

我执行了分层审查命令：

# 第一层：快速扫描（0.5B 模型，1s） git diff origin/main HEAD | open-code-review --strategy simple --rules ./rules/finance.yaml # 第二层：深度追问（DeepSeek-R1，7s） git diff origin/main HEAD | open-code-review --strategy medium --rules ./rules/finance.yaml --prompt "Explain the business rationale for this 0.2% adjustment. Is it regulatory-mandated? Temporary? Documented in Jira?" # 第三层：历史比对（本地检索） git log -S "* 1.002" --since="6 months ago" --oneline # 第四层：合规校验（调用内部风控 API） curl -X POST http://risk-api/v1/validate-rate-adjustment \ -H "Content-Type: application/json" \ -d '{"from":"USD","to":"EUR","multiplier":1.002,"pr_id":42}'

各层输出汇总：

Layer 1：标记Line 123: Hardcoded multiplier 1.002. Consider config-driven approach.（基础事实）
Layer 2：返回This adjustment appears to compensate for recent SWIFT fee increase (see Jira PAY-789). However, the multiplier is applied unconditionally, while SWIFT fees only apply to cross-border transfers. Suggest adding condition: if isCrossBorder() { rate *= 1.002 }.（业务逻辑）
Layer 3：发现PAY-789确实存在，但状态是 “In Progress”，且最新评论写着 “Pending central bank approval, ETA 2024-06-30”（历史佐证）
Layer 4：风控 API 返回{ "valid": false, "reason": "multiplier not approved for production use" }（合规拦截）

4.3 决策闭环：从报告到落地的三步转化

审查报告不是终点，而是决策起点。我们按以下流程闭环：

即时阻断：在 GitLab CI 中，当open-code-review的 exit code 为2（严重问题）时，自动 fail 构建，并在 MR 页面插入评论：
⚠️ Review failed: Rate multiplier 1.002 violates risk policy (PAY-789 not approved).
✅ Fix: Remove multiplier, add feature flagswif_fee_compensation
📝 Reference: Jira PAY-789

知识沉淀：将本次审查的prompt和rule提交到rules/finance.yaml，新增一条：

- id: "unapproved-rate-multiplier" trigger: "line matches '\\* [0-9.]+'" prompt: | This line applies a rate multiplier. Verify: - It references an approved Jira ticket (format PAY-XXX) - The ticket status is 'Approved' - The multiplier is gated by a feature flag

流程加固：在pre-commit钩子里加入：

# .pre-commit-config.yaml - repo: local hooks: - id: open-code-review-finance name: Finance rule check entry: bash -c 'git diff --cached | open-code-review --strategy simple --rules ./rules/finance.yaml || echo "Finance rule violation!" >&2; exit 1' language: system

这样，开发者在本地git commit时就会被拦截，问题不出开发机。

这套流程让我们在 48 小时内，把一个可能引发监管处罚的代码变更，转化成了可审计、可追溯、可复用的知识资产。Code Review 的终极价值，不是阻止错误，而是让正确成为习惯。

5. 常见问题与排查技巧实录：那些文档里不会写的血泪经验

5.1 模型“胡说八道”？先检查你的 diff 切片策略

现象：模型对git diff输出中的一行+ fmt.Println("user created")，回复This logs PII data. Remove immediately.（PII 是个人身份信息，user created显然不是）。

原因：open-code-review默认将 diff 按文件切片，但fmt.Println这行所在的文件main.go可能包含大量用户数据操作代码。模型看到文件名main.go+ 日志语句，就脑补出 PII 场景。

解决方案：启用--context-lines 3参数，强制模型只看到变更行及其前后 3 行：

git diff origin/main HEAD | open-code-review --context-lines 3

这样模型看到的是：

+ userID := generateID() + fmt.Println("user created") // ← 这行 + sendWelcomeEmail(userID)

上下文表明这是 ID 生成后的欢迎邮件发送，与 PII 无关。

实操心得：永远不要相信模型对“孤立行”的判断。--context-lines是你的第一道防线，建议默认设为 3，复杂逻辑设为 5。

5.2 审查报告“千篇一律”？你的 prompt 缺少否定约束

现象：所有审查意见都长这样：“Consider using a more descriptive variable name.”，“Add unit test for this function.”——泛泛而谈，毫无针对性。

根源：你的system_prompt里缺少否定性约束（Negative Prompt）。LLM 倾向于给出安全但无用的建议，除非你明确禁止。

修正方案：在规则文件的system_prompt末尾加上：

system_prompt: | ...（原有内容） DO NOT give generic advice like "add tests" or "improve naming". ONLY comment when you can cite: - A specific line number and file path - A concrete risk (e.g., "panic on nil pointer", "SQL injection vector") - A direct reference to project docs (e.g., "violates SECURITY.md section 3.2")

效果立竿见影：模型输出从 “Add error handling” 变成 “Line 45 in db/query.go: db.QueryRow() error is ignored. May cause panic on empty result set. See ERROR_HANDLING_GUIDE.md.”

5.3 CI 中审查超时？不是模型慢，是 diff 太大

现象：GitLab CI 报错open-code-review: timeout after 30s，但本地运行只要 5s。

真相：CI 环境中git diff origin/main HEAD默认比较的是整个仓库，而本地你可能只git diff HEAD~1。一个含 200 个文件的 PR，diff 输出可能达 5MB，远超模型 token 限制。

根治方法：用--diff-filter精确控制范围：

# 只审查修改的 Go 文件（排除 .md, .yml） git diff --diff-filter=AM origin/main HEAD -- '*.go' | open-code-review ... # 或用 git show 获取单次 commit 的 diff git show --no-prefix $CI_COMMIT_SHA | open-code-review ...

我们团队的 CI 模板固定为：

review: script: - git diff --diff-filter=AM origin/main HEAD -- $(git diff --name-only origin/main HEAD | grep '\.go$\|\.rs$\|\.py$') > /tmp/review.diff - open-code-review --input /tmp/review.diff

5.4 飞书卡片不显示？检查你的 webhook payload schema

现象：飞书 Bot 收到请求，但卡片空白，日志显示invalid card content。

排查路径：

用curl -X POST http://your-webhook -d '{"msg_type":"text","content":{"text":"test"}}'测试基础连通性；
查看open-code-review的--debug输出，确认它生成的 payload；
对比飞书文档的 Card Schema ，关键字段必须存在：
- msg_type必须是interactive
- card对象必须有elements数组和config对象
- elements中每个 item 必须有tag字段（如"tag": "div"）

我们的修复方案：在output.webhook.format中指定feishu_card_v2，它会自动注入飞书 v2 卡片所需的全部字段，而非依赖旧版 schema。

5.5 模型“拒绝回答”？你触发了它的安全护栏

现象：对含os.RemoveAll("/tmp")的 diff，模型回复I cannot assist with that request.

这不是 bug，是 LLM 内置的安全机制。所有主流模型（包括 Qwen、DeepSeek）都对文件系统操作、网络请求、进程控制等敏感指令做硬性拦截。

破解思路：不绕过护栏，而是重构 prompt。把问题从 “如何删除” 转为 “如何安全删除”：

- id: "dangerous-removeall" trigger: "line matches 'os\\.RemoveAll\\(.*\\)'" prompt: | This calls os.RemoveAll() which can delete arbitrary paths. Check if: - The path is hardcoded (e.g., "/tmp") → HIGH RISK, replace with tempdir - The path is user-input → CRITICAL RISK, add strict allowlist validation - The path is derived from trusted config → MEDIUM RISK, add audit log Cite exact line and suggest safe alternative (e.g., os.Clean() + allowlist).

模型看到 “suggest safe alternative”，就会绕过拒绝逻辑，给出Use filepath.Clean(path) and validate against /tmp/ prefix这样的建设性意见。

最后分享一个小技巧：在.open-code-review.yaml里加一行debug: true，所有模型输入输出都会打印到 stderr。这不是为了 debug，而是为了反向训练你的 prompt——当你看到模型在哪一行“卡壳”，就知道 prompt 的哪部分需要重写。我 70% 的规则优化，都来自盯着 debug 日志里那几行失败的 token。