1. 这不是又一个“AI Code Review”工具：open-code-review 的真实定位与设计哲学
我第一次在 GitHub 上看到 open-code-review 这个仓库时，下意识点开 README， expecting 又是一个“用 LLM 给 PR 加评论”的玩具项目——结果发现它连一行模型调用代码都没有。它不依赖 OpenAI、Claude 或 Gemini API，不打包任何大模型权重，甚至不强制要求联网。它跑在本地，只读取 git diff 输出，用纯 Rust 写的规则引擎做静态分析，再把结构化结果喂给本地运行的 LLM（比如 Ollama 上的 llama3:8b）做语义润色。这不是“LLM 驱动的 code review”，而是“LLM 协同的 code review”——人仍是决策主体，LLM 是高级协作者，而 open-code-review 是那个沉默但精准的调度员。
这个项目标题里藏着三个被严重误读的关键词：“open”不是指开源协议（虽然它确实是 MIT），而是指开放输入源、开放规则链、开放反馈路径；“code review”不是指替代人工评审，而是指重建评审过程的可观察性、可配置性与可复现性；“review”本身被拆解成四个原子动作：diff 解析 → 规则匹配 → 问题标注 → 语言生成。它不承诺“自动修复 bug”，但能确保每次 PR 提交后，你看到的每一条评论背后都有可追溯的 diff 行号、可验证的规则 ID、可替换的提示模板、可重放的本地 LLM 调用日志。
为什么这重要？因为当前市面上绝大多数“AI Code Review”工具都卡在同一个死循环里：用户上传代码 → 工具调用远程 API → 返回模糊建议 → 开发者无法判断建议是否基于当前分支真实变更 → 修改后再次提交 → 循环重复。而 open-code-review 把整个流程锚定在 git diff 这一不可篡改的事实层上。它强制你回答一个问题：“这条评论，是针对哪几行新增/修改代码提出的？它的触发条件是什么规则？如果我删掉这条规则，评论会消失吗？”——这种可证伪性，才是工程可信度的起点。
提示：如果你正在评估一个 AI 代码工具，先问它能否在不联网的情况下，仅凭
git diff main...feature-branch的输出，生成一份带行号引用、规则 ID 标注、且可离线重放的 review 报告。不能？那它本质上还是个黑盒聊天机器人，不是 code review 工具。
它解决的不是“怎么让 AI 看懂代码”，而是“怎么让人类看懂 AI 为什么这么说”。当你在 CI 流水线里看到一条来自 open-code-review 的评论：“src/utils/date.ts:42-45 — ⚠️ 潜在时区处理缺陷：未显式指定 timezone 参数（rule: TZ-003）”，你知道这背后不是模型幻觉，而是它匹配了你团队自定义的规则库中第 003 条：“所有调用new Date().toLocaleString()的地方必须传入{ timeZone: 'UTC' }”。而这条规则，就写在.open-code-review/rules.yaml里，和你的业务逻辑一样，受 Git 版本控制。
2. 不靠 API Key 驱动：open-code-review 的三层架构与数据流真相
open-code-review 的核心价值，藏在它拒绝“一键接入大模型”的设计选择里。它没有--model gpt-4o这样的 CLI 参数，也没有“选择服务商”的 Web 配置页。它的架构是明确分层的：Diff 层 → Rule 层 → LLM 层，每一层都可独立替换、调试、审计。这种解耦不是为了炫技，而是为了解决真实团队落地时的三个刚性约束：合规审计要求、网络策略限制、以及模型能力漂移带来的结果不一致。
2.1 Diff 层：从 git 输出到结构化变更描述
几乎所有“AI Code Review”工具都把git diff当作黑盒输入，直接喂给模型。open-code-review 则把它当作第一道解析器。它不使用git diff --no-color的原始文本，而是调用git diff --numstat --summary --find-renames=40获取结构化元数据，再结合git show <commit>:<file>提取变更前后的 AST 片段（通过 tree-sitter 解析）。这意味着它能精确识别：
- 哪些是纯格式调整（空格/换行变化），自动过滤；
- 哪些是函数签名变更（参数增删、类型变化），触发接口兼容性检查；
- 哪些是字符串字面量修改（如 SQL 查询中的 WHERE 条件），关联 SQL 注入规则；
- 哪些是配置文件键值对更新（如
config.json中timeout_ms从 5000 改为 3000），触发超时阈值告警。
实测中，我们团队曾用它对比两个分支：一个只改了 3 行日志级别，另一个重构了整个认证模块。传统工具对前者返回“无风险”，对后者返回 17 条泛泛而谈的“注意安全”。而 open-code-review 对前者输出：“logger.ts:123 — INFO 级别日志在 prod 环境被禁用（rule: LOG-001）”，对后者则列出 4 条具体规则命中：AUTH-002（JWT token 缺少 audience 声明）、AUTH-005（密码哈希算法未升级至 Argon2id）、PERF-007（同步阻塞 I/O 在 auth middleware 中调用）、SEC-009（CORS 配置未限制 origin 白名单）。差异源于它把 diff 解析成了“变更意图图谱”，而非“文本差异列表”。
2.2 Rule 层：YAML 规则即代码，且可版本化、可测试
规则不是硬编码在 Rust 二进制里的魔法字符串，而是存放在项目根目录.open-code-review/rules/下的 YAML 文件。每个规则文件包含四个必填字段：
# .open-code-review/rules/auth.yaml id: AUTH-002 name: "JWT Token 必须声明 audience" description: "缺失 audience 声明可能导致 token 被跨服务滥用" scope: ["src/auth/**", "packages/auth-core/**"] pattern: | # tree-sitter query for JavaScript/TypeScript (call_expression function: (member_expression object: (identifier) @provider property: (property_identifier) @method) arguments: (arguments (object)) @args) (#eq? @provider "jwt") (#eq? @method "sign") (#has-property? @args "audience") severity: high关键在于pattern字段：它不是正则表达式，而是 tree-sitter 的 S-expression 查询语法，能精准匹配 AST 节点关系。比如上面的规则，它实际在找：调用jwt.sign()时，其参数对象中是否包含audience键。这比grep -r "jwt\.sign(" .可靠一万倍——它不会被注释、字符串字面量或变量名干扰。
更关键的是，规则支持单元测试。你在.open-code-review/rules/test/下写测试用例：
# .open-code-review/rules/test/auth-002.test.yaml rule_id: AUTH-002 test_cases: - name: "正确声明 audience" code: | const token = jwt.sign({ user: 'alice' }, secret, { audience: 'api.example.com' }); should_match: false - name: "缺失 audience" code: | const token = jwt.sign({ user: 'bob' }, secret, { expiresIn: '1h' }); should_match: true运行open-code-review test就能验证所有规则是否按预期工作。我们团队每周 CI 流水线都会执行这套测试，确保新加入的规则不会误报历史代码，也不会漏报已知漏洞。这解决了“AI 工具越用越不准”的根本痛点：规则可验证，模型才可信。
2.3 LLM 层：本地模型调用的确定性封装
LLM 层不负责“理解代码”，只负责“润色反馈”。open-code-review 通过标准 HTTP 接口调用本地运行的 LLM 服务（Ollama、LM Studio、Text Generation WebUI），但它严格限定输入输出格式：
- 输入：固定 JSON 结构，包含
diff_context（变更前后代码片段）、rule_match（命中规则的 ID、名称、描述）、file_path、line_numbers； - 输出：必须返回
{"suggestion": "..."}，且 suggestion 字段长度不超过 200 字符； - 提示模板：存放在
.open-code-review/prompts/下，例如AUTH-002.j2：你是一名资深后端工程师，正在审查一段 JWT 签名代码。 【变更代码】 {{ diff_context }} 【规则说明】 {{ rule_match.description }} 【要求】 用中文生成一条简洁、可操作的建议，直接告诉开发者如何修改。不要解释原理，不要提及其他规则。
这种设计带来三个确定性保障：
- 结果可重放：同一份 diff + 同一规则 + 同一 prompt + 同一本地模型，必然产出相同 suggestion；
- 责任可分离：规则层决定“哪里有问题”，LLM 层只决定“怎么说得清楚”，模型能力下降只影响语言质量，不影响问题检出率；
- 成本可预测：所有 LLM 调用都在本地，无 token 计费，无网络延迟，CI 流水线耗时稳定在 8~12 秒（含模型 warmup）。
我们曾用 llama3:8b 和 gemma2:27b 对同一份 diff 生成 suggestion，前者输出：“请添加 audience 参数”，后者输出：“建议在 jwt.sign() 的第三个参数对象中显式设置 audience 字段，例如 { audience: 'your-api-domain.com' }，以防止 token 被恶意重放。”——后者更专业，但两者都准确指向了同一行代码。open-code-review 不追求“最聪明的模型”，只追求“最可控的协同”。
3. CLI 的真实战场：从codex cli到open-code-review的范式迁移
网络热词里反复出现的codex cli、zcode cli、trae cli，本质都是“把 IDE 插件能力 CLI 化”的尝试。它们共享一个底层假设：开发者需要一个能脱离编辑器、在终端里快速获得代码洞察的工具。但open-code-review的 CLI 设计，彻底颠覆了这个假设——它不提供“快速洞察”，而是提供“可审计的洞察流水线”。
3.1open-code-review diff：不是 diff 查看器，而是变更意图提取器
传统 CLI 如git diff输出是给人读的，open-code-review diff输出是给机器和人共同读的。它默认输出 JSON：
$ open-code-review diff main...feature-login { "files": [ { "path": "src/auth/service.ts", "changes": [ { "type": "function_added", "name": "validateSessionToken", "start_line": 45, "end_line": 62, "ast_node_type": "FunctionDeclaration" }, { "type": "string_modified", "old_value": "SELECT * FROM users WHERE id = ?", "new_value": "SELECT id, email, role FROM users WHERE id = ?", "line": 138 } ] } ], "summary": { "total_files": 3, "lines_added": 87, "lines_removed": 12, "functions_added": 2, "security_sensitive_changes": 4 } }这个输出直接喂给后续规则引擎，也支持--format markdown生成可读报告：
## 🔍 变更摘要（main → feature-login） | 文件 | 新增 | 删除 | 敏感变更 | |------|------|------|----------| | `src/auth/service.ts` | 42 行 | 8 行 | ✅ JWT 签名、SQL 字段白名单 | | `tests/auth.spec.ts` | 15 行 | 0 行 | ❌ | | `docs/API.md` | 30 行 | 4 行 | ❌ | ### 🚨 高风险变更 - `src/auth/service.ts:45-62` 新增 `validateSessionToken()` 函数，涉及 session token 验证逻辑 - `src/auth/service.ts:138` SQL 查询从 `SELECT *` 改为显式字段列表，符合最小权限原则关键区别在于：codex cli的diff命令只是美化git diff，而open-code-review diff是变更语义的首次结构化——它把“文本差异”翻译成“工程意图”，这是所有后续分析的基石。
3.2open-code-review review：一次调用，四重验证
这是核心命令，但它的执行流程远比codex cli review复杂：
$ open-code-review review --base main --head feature-login --output report.json它内部执行四步原子操作：
- Diff Extraction：调用
git diff --no-color --find-renames=40 main...feature-login，解析为结构化变更集； - Rule Matching：遍历
.open-code-review/rules/下所有 YAML 规则，对每个变更节点执行 tree-sitter 查询，生成match_result列表； - LLM Augmentation：对每个
match_result，构造 prompt 并调用本地 LLM API，获取suggestion； - Report Assembly：将
match_result + suggestion + diff_context组装为标准 SARIF 格式（Static Analysis Results Interchange Format），同时生成 Markdown 报告。
SARIF 输出可直接集成到 GitHub Code Scanning、SonarQube、或者 VS Code 的 Problems 面板。这意味着open-code-review不是独立工具，而是现有 DevSecOps 流水线的“智能适配器”。我们团队把它嵌入 GitHub Actions：
# .github/workflows/code-review.yml - name: Run open-code-review run: | open-code-review review \ --base ${{ github.event.pull_request.base.sha }} \ --head ${{ github.event.pull_request.head.sha }} \ --output sarif-report.sarif - name: Upload SARIF uses: github/codeql-action/upload-sarif@v2 with: sarif_file: sarif-report.sarifGitHub 自动在 PR 界面显示带行号链接的 review 评论，点击即可跳转到对应代码行。这比codex cli手动复制粘贴 suggestion 到评论框，可靠性和可追溯性高出两个数量级。
3.3open-code-review rule：规则即资产，管理即编程
codex cli的规则管理是黑盒配置，open-code-review把它变成开发工作流的一部分：
# 创建新规则模板 $ open-code-review rule create --id SEC-010 --name "禁止硬编码密钥" # 测试单个规则 $ open-code-review rule test --id SEC-010 --file src/config.ts # 列出所有启用的规则及其命中率 $ open-code-review rule list --stats ID NAME ENABLED HIT_COUNT LAST_HIT SEC-001 禁止 console.log 在 prod true 12 2024-06-15 SEC-005 JWT token 缺少 audience true 3 2024-06-18 SEC-010 禁止硬编码密钥 false 0 ---stats参数背后是.open-code-review/rule-stats.db（SQLite），记录每次 review 中各规则的匹配次数、文件分布、时间戳。你可以用 SQL 查询：“过去 30 天，SEC-005 规则在哪几个服务中高频触发？是否与某次 SDK 升级相关？”——这把代码规范从“主观提醒”变成了“客观数据”。
我们曾发现SEC-005在auth-service中触发率飙升，排查后发现是团队升级了jsonwebtoken库，新版本默认不校验audience。于是我们没改代码，而是更新了规则的scope字段，将其限制在auth-service目录，并在description中追加：“因 jsonwebtoken v9+ 默认行为变更，请确认业务是否需强制 audience 校验”。
4. 为什么它不叫agent-llm：open-code-review 对“Agent”概念的祛魅实践
网络热词里频繁出现的agent llm embedding，常被包装成“自主思考的 AI 助手”。但open-code-review的设计者公开表示：“我们刻意避免使用 ‘Agent’ 这个词，因为它暗示了自主决策权，而代码评审中，决策权必须且只能属于人类工程师。”
它用一套精巧的机制，把 LLM 从“决策者”降级为“表述优化器”，同时把真正的智能留在规则层：
4.1 “Embedding” 不是向量检索，而是规则索引映射
agent llm embedding通常指将代码切片向量化，再用相似度搜索召回历史问题。open-code-review的“embedding”是字面意义的：它把每条规则的id（如AUTH-002）作为唯一标识符，构建一个轻量级倒排索引，映射到该规则适用的文件路径模式（scope字段）和 AST 节点类型（pattern中的(call_expression)）。当解析到src/auth/service.ts的jwt.sign()调用时，它不计算余弦相似度，而是直接查表：“哪些规则的 scope 匹配此路径？其中哪些的 pattern 能匹配此 AST 节点？”——这是 O(1) 的哈希查找，不是 O(n) 的向量检索。
好处是：100% 确定性，零延迟，无需 GPU；坏处是：无法发现规则库未覆盖的新模式。但团队认为，代码规范的本质是“已知风险的确定性拦截”，而非“未知风险的概率性猜测”。未知风险交给人工深度审计，已知风险必须 100% 拦截。
4.2 “Agent” 行为被拆解为可审计的原子指令
所谓“LLM Agent”在代码评审场景，常表现为：1）读取 diff；2）推理潜在问题；3）生成建议；4）修正建议。open-code-review把这四步拆成独立可验证的环节：
| 步骤 | 执行者 | 输出 | 可验证性 |
|---|---|---|---|
| 1. 读取 diff | git+ Rust 解析器 | 结构化变更 JSON | git diff命令可重放 |
| 2. 推理问题 | tree-sitter 规则引擎 | match_result列表 | open-code-review rule test可验证 |
| 3. 生成建议 | 本地 LLM | suggestion字符串 | curl -X POST http://localhost:11434/api/chat可重放 |
| 4. 修正建议 | 人类工程师 | 代码修改 | Git commit hash 可追溯 |
没有一步是“黑盒 Agent”完成的。LLM 只参与第 3 步，且其输入（match_result）和输出（suggestion）都被完整记录。你可以打开report.json，看到：
{ "rule_id": "AUTH-002", "file": "src/auth/service.ts", "line": 47, "suggestion": "请在 jwt.sign() 的 options 参数中添加 audience 字段，例如 { audience: 'auth-api' }。", "llm_call_log": { "prompt_hash": "a1b2c3d4...", "model": "llama3:8b", "response_time_ms": 2341, "input_tokens": 156, "output_tokens": 42 } }这就是“Agent 祛魅”：去掉神秘主义外衣，暴露所有依赖、所有输入、所有输出。当某条 suggestion 出错时，你能精准定位是规则写错了（match_result错误），还是 prompt 写错了（llm_call_log显示模型被误导），还是模型本身能力不足（output_tokens过长但内容空洞）。
4.3 真实案例：一次“失败”的 LLM 调用如何推动规则进化
上周，我们收到一条奇怪的 suggestion：
src/utils/crypto.ts:88 — ⚠️ 密码哈希算法过时：请使用 bcrypt 替代 md5（rule: SEC-003）
但SEC-003规则原文是：“所有调用crypto.createHash('md5')的地方必须替换为bcrypt.hash()”。而实际代码是：
// src/utils/crypto.ts export function hashPassword(password: string): string { return crypto.createHash('sha256').update(password).digest('hex'); // line 88 }createHash('sha256')被误判为md5。排查发现，tree-sitter 查询写成了：
(call_expression function: (member_expression object: (identifier) @crypto property: (property_identifier) @method) arguments: (arguments (string) @algo)) (#eq? @crypto "crypto") (#eq? @method "createHash") (#match? @algo "md5|sha1|sha256") // 错误：应只匹配 "md5"LLM 的 suggestion 没错（sha256 确实比 md5 安全），但规则本意是拦截最危险的 md5。问题不在 LLM，而在规则的#match?逻辑太宽泛。我们立刻：
- 修复规则：
(#eq? @algo "md5")； - 添加测试用例：
sha256调用不应触发； - 更新
SEC-003的 description：“仅针对 MD5 哈希，SHA 系列不受此规则约束”。
整个过程 12 分钟完成，且所有变更受 Git 控制。如果这是个“黑盒 Agent”，我们只能抱怨“AI 又乱说了”，然后放弃工具。而open-code-review让错误成为规则进化的燃料。
5. 落地避坑指南：从零部署到生产就绪的七条血泪经验
我们团队花了三周时间，把open-code-review从 PoC 推进到全栈服务的默认 CI 检查项。以下是踩过的坑和提炼出的经验，比官方文档更真实：
5.1 坑一：git diff的默认编码导致 tree-sitter 解析失败
现象：在 Windows 机器上，open-code-review diff报错Failed to parse file: invalid utf-8 sequence。排查发现，git diff在 Windows 上默认用 GBK 编码输出中文路径和注释，而 tree-sitter 只接受 UTF-8。
解决方案：全局配置 Git 使用 UTF-8：
git config --global core.precomposeUnicode true git config --global i18n.commitEncoding utf-8 git config --global i18n.logOutputEncoding utf-8 # 关键一步：设置环境变量 export GIT_CONFIG_NOSYSTEM=1并在.open-code-review/config.yaml中强制指定：
git: encoding: utf-8注意：不要试图用 iconv 转换 diff 输出——tree-sitter 需要原始字节流来定位 AST 节点行号，编码转换会破坏行号映射。
5.2 坑二：LLM 的 context window 溢出导致 suggestion 截断
现象：对大型 diff（>500 行），LLM 返回的suggestion是"请在 jwt.sign() 的 options 参数中添加 audience 字段，例如 { audience: 'auth-api' }。"，但后面被截断，丢失了关键示例。
原因：Ollama 默认 context window 为 2048 tokens，而我们的 prompt 模板 + diff context 超过此限。LLM 不报错，而是静默截断。
解决方案：在.open-code-review/config.yaml中配置：
llm: model: llama3:8b timeout_ms: 12000 max_context_tokens: 4096 # 显式增大 # 同时启用 diff 剪裁 diff_truncation: max_lines_per_file: 100 max_total_lines: 500open-code-review会自动对超长 diff 进行语义剪裁：保留所有规则命中的代码块，删除无关的格式变更和注释。实测后，suggestion 完整率从 63% 提升至 100%。
5.3 坑三：规则 scope 的 glob 模式匹配失效
现象：规则scope: ["src/**/*.{ts,js}"]在 macOS 上生效，在 Linux CI 服务器上不生效。
原因：Rust 的globset库在不同平台对**的实现有细微差异，且 CI 环境的 shell（如 busybox ash）不支持某些 glob 语法。
解决方案：统一使用globcrate 的Pattern类型，并在 CI 中预编译规则：
# CI 脚本 open-code-review rule compile --output .open-code-review/compiled-rules.bin open-code-review review --rules-bin .open-code-review/compiled-rules.bincompile命令会将 YAML 规则转换为二进制索引，绕过运行时 glob 解析，速度提升 40%，且 100% 跨平台一致。
5.4 坑四：SARIF 报告在 GitHub 不显示行号链接
现象：SARIF 文件上传成功，但 GitHub 的 code scanning 界面只显示问题描述，不显示“View on GitHub”链接。
原因：SARIF 的physicalLocation.artifactLocation.uri字段必须是相对于仓库根目录的相对路径，且不能包含file://前缀。open-code-review默认输出绝对路径。
解决方案：在 CI 中添加路径标准化步骤：
# GitHub Actions - name: Fix SARIF paths run: | sed -i 's|"uri":"file:\/\/.*\/\(.*\)"|"uri":"\1"|g' sarif-report.sarif或更稳妥地，在.open-code-review/config.yaml中配置：
sarif: artifact_uri_base: ""5.5 坑五：本地 LLM 的 warmup 延迟拖慢 CI
现象：首次open-code-review review耗时 45 秒，后续降至 12 秒，CI 流水线不稳定。
原因：Ollama 加载模型到 GPU 需要时间，且默认不常驻内存。
解决方案：在 CI runner 启动时预热：
# runner startup script ollama run llama3:8b "hello" > /dev/null 2>&1 & sleep 5并在.open-code-review/config.yaml中启用连接池：
llm: connection_pool: max_idle_connections: 5 idle_timeout_ms: 300005.6 坑六：团队规则冲突导致 review 结果矛盾
现象：前端组添加了FRONT-001规则：“禁止在 React 组件中使用console.log”，后端组添加了BACK-001规则：“允许在 debug 模式下使用console.log”。两者 scope 重叠，导致同一行代码被标记为“高危”和“允许”。
解决方案：引入规则优先级和作用域继承：
# .open-code-review/rules/frontend.yaml priority: 100 scope: ["src/client/**"] rules: [...] --- # .open-code-review/rules/backend.yaml priority: 50 scope: ["src/server/**", "src/shared/**"] rules: [...]open-code-review按 priority 降序匹配，高优先级规则先执行。同时，src/shared/**目录下的文件，只有BACK-001生效（因为FRONT-001的 scope 不匹配），避免了冲突。
5.7 坑七：Markdown 报告中代码块渲染错乱
现象：open-code-review review --format markdown生成的报告，在 GitHub README 中显示为纯文本，而非语法高亮代码块。
原因：GitHub 的 Markdown 渲染器要求代码块必须有语言标识，如ts，而 `open-code-review` 默认输出。
解决方案：在.open-code-review/config.yaml中配置：
markdown: code_block_language: ts: "typescript" js: "javascript" py: "python" sql: "sql"它会根据文件扩展名自动注入语言标识，渲染效果立即提升。
6. 它不是终点，而是新协作范式的起点：open-code-review 的演进边界
open-code-review的 v1.0 版本已经足够稳定，支撑我们每日 200+ 次 PR 检查。但它真正的价值，不在于当前功能，而在于它所确立的协作范式：把代码评审从“人对人的沟通”，转变为“人-规则-模型”的三方契约。
在这个契约里，人定义什么是“好代码”（通过规则），规则保证一致性（通过 tree-sitter 和测试），模型提升表达力（通过本地 LLM）。三者缺一不可，但职责清晰。我们不再争论“这条建议对不对”，而是检查“这条建议是否基于正确的规则匹配”，以及“规则本身是否反映了团队最新共识”。
未来半年，我们计划在三个方向深化：
规则即服务（RaaS）：把
.open-code-review/rules/目录托管在私有 Git 仓库，各团队 fork 后定制自己的规则集。open-code-review支持--rules-repo https://git.internal/rules.git，自动拉取并验证签名，实现规则的集中治理与分布式执行。增量 review：当前每次 review 都处理全量 diff，未来将支持
--incremental模式，只分析上次 review 以来新增/修改的变更块，CI 耗时预计降低 60%。规则贡献市场：我们正在整理 37 条已验证的规则（涵盖 JWT、SQL、加密、React、TypeScript），计划开源为
open-code-review-rules-community仓库。每条规则附带：真实 PR 案例、tree-sitter 查询详解、测试用例、以及对应的 LLM prompt 模板。目标是让规则创作像 npm 包一样简单——open-code-review rule install @company/security。
最后分享一个细节：我们团队的open-code-review配置文件里，有一行被注释掉的配置：
# llm: # fallback_to_rule_description: true意思是：当 LLM 调用失败时，直接返回规则的description字段作为 suggestion。我们从未启用它，因为 LLM 本地运行极少失败。但这个开关的存在本身，就是open-code-review的灵魂——它不神话 AI，只把它当作一个可降级、可绕过、可替换的组件。当技术退潮，留下的不是幻觉，而是可执行的规则、可验证的流程、和可传承的工程判断。
这才是 open 的真正含义。
