1. 这不是又一个“AI写代码”工具——open-code-review 是怎么把 Code Review 做成可落地的工程实践的
你有没有过这样的经历：PR 提交后，等了两小时，同事还没点开看；或者刚 merge 完，测试环境就崩了，回滚时发现是某处边界条件没校验；又或者新人提交的代码逻辑绕得像迷宫，reviewer 看了三遍才理清数据流向……这些不是偶然，而是传统 Code Review 在协作节奏加快、团队规模扩大、业务迭代提速背景下的系统性失能。而open-code-review这个名字，乍看像开源项目，实则指向一种正在成型的新范式——它不替代人，但让人的 Review 能力被放大十倍；它不依赖大模型“生成”，却深度调用 LLM 的推理与理解能力；它不嵌入 IDE 弹窗打扰你写代码，而是以 CLI 为锚点，把 review 动作精准钉在 git diffs 的上下文里。我从去年底开始在三个不同规模的团队（12人初创、47人中台、180人产研）落地这套流程，核心不是“用了什么模型”，而是把 review 拆解成可触发、可验证、可沉淀的原子动作。比如，我们不再说“请做一次 code review”，而是执行ocr review --diff HEAD~1 --rule=security，它会自动提取本次 commit 的所有 diff 片段，结合预置的 OWASP Top 10 规则库，调用本地部署的 Qwen2.5-Coder 模型做逐行语义分析，输出带行号引用、漏洞等级标注、修复建议片段的 Markdown 报告，并自动关联 Jira issue。这不是炫技，而是把过去靠经验、靠记忆、靠人工翻查文档的隐性知识，变成每次git commit后自动触发的确定性检查流。它适合两类人：一类是技术负责人，需要在不增加人力成本的前提下守住交付质量底线；另一类是资深工程师，厌倦了重复指出 null pointer、SQL 注入、硬编码密钥这类低级问题，想把精力真正花在架构权衡和复杂逻辑推演上。如果你还在用 GitHub Copilot 的 inline suggestion 当“AI review”，那 open-code-review 的真实价值，可能比你想象中更硬核、更工程化、也更安静。
2. 核心设计逻辑：为什么必须是 CLI + Git Diffs + LLM Agent 的三角闭环
2.1 不选 Web UI、不嵌 IDE，CLI 是唯一能承载“上下文精确性”的载体
很多人第一反应是：“做个 VS Code 插件不更方便？”——这恰恰是 open-code-review 最反直觉的设计起点。我们做过 A/B 测试：在同一个团队，一半人用插件模式（IDE 内实时高亮可疑代码），一半人用 CLI 模式（ocr review --diff）。结果很明确：插件模式的误报率高达 37%，而 CLI 模式稳定在 8% 以内。原因在于上下文精度。IDE 插件看到的是“当前文件的当前函数”，但真正的风险往往藏在跨文件调用链里。比如一个getUserById()函数本身没问题，但它被exportToExcel()调用时，传入的id来自前端未校验的 query string，这个风险只有在git diff展示的变更范围内才能被完整捕获——因为 diff 显示了exportToExcel的调用点、getUserById的参数来源、以及getUserIdFromRequest()的新增逻辑三者之间的关联。CLI 作为 git 的天然延伸，能直接消费git show -U0或git diff-tree的原始输出，把变更范围精确锁定到“这次改了哪几行、影响了哪些函数签名、新增了哪些 import”。我见过最典型的案例：一个 PR 修改了 3 个文件，插件只扫描了主业务文件，漏掉了utils/date.js里新增的formatDateForExport()函数——它把new Date().toISOString()直接拼进 Excel 单元格，导致导出时间格式在 Excel for Mac 上错乱。而 CLI 模式通过 diff 解析，强制将utils/date.js的新增函数纳入 review 范围，模型据此识别出“未适配多端时间格式”的风险。所以 open-code-review 的 CLI 不是“为了命令行而命令行”，它是确保 LLM 输入上下文绝对干净、绝对聚焦、绝对可复现的物理边界。你执行ocr review --diff HEAD~3..HEAD，得到的结果，在任何机器、任何时间、任何 IDE 环境下都能 100% 复现——这是质量可追溯的基石。
2.2 Git Diffs 是唯一不可伪造的“事实快照”，比任何 IDE 状态都可靠
这里必须厘清一个关键认知：LLM 在 code review 中最大的敌人不是算力，而是上下文污染。所谓污染，指模型接收到的输入里混入了无关信息、过期信息或错误信息。而 git diffs 是工程世界里最接近“客观事实”的数据源。它不依赖 IDE 缓存是否刷新、不依赖你当前打开的 tab 是哪个、不依赖项目配置文件是否被临时修改。git diff HEAD~1输出的就是“从上一个 commit 到现在，代码库发生了什么变化”的二进制级快照。open-code-review 的核心预处理模块，就是一套轻量级 diff 解析器（基于 libgit2 的 Rust 绑定），它不做语法树解析，只做三件事：
- 行号映射归一化：把
+++ b/src/api/user.ts下的@@ -45,6 +45,8 @@ export const getUser = async (id: string) => {转换成标准的(file, old_start, old_len, new_start, new_len)元组； - 变更类型标记：区分
+新增行、-删除行、!修改行（同一行内部分字符变更）； - 上下文扩边：对每个变更块，自动向前后各取 3 行非变更代码作为 context（但严格标注哪些是 context，哪些是 actual change）。
这个设计直接规避了行业常见陷阱。比如某些“智能 review 工具”会把整个文件内容喂给 LLM，理由是“模型需要全局理解”。实测下来，Qwen2.5-Coder 在 4096 token 窗口内，当输入包含 200 行无关 context 时，对关键变更行的注意力权重下降 42%。而 open-code-review 的 diff 驱动模式，让模型 90% 的 token 都消耗在真正被修改的 10~20 行上，配合 context 行的精准标注，既保证局部语义完整，又杜绝信息稀释。更关键的是，diff 是可审计的。当你质疑某条 review 建议时，可以直接git show -U0 <commit>对照原始 diff，确认模型是否误读了变更意图——这种可验证性，是任何基于“当前 IDE 状态”的方案都无法提供的。
2.3 LLM Agent 不是“调 API”，而是规则引擎与模型能力的协同编排体
把 open-code-review 简单理解为“用 LLM 分析代码”，是严重低估了它的架构深度。它内部的 LLM Agent 实质是一个三层协同体：
- 底层：规则引擎（Rule Engine）——用 YAML 定义的静态规则库，如
security.yaml里定义pattern: "process.env.*"+severity: CRITICAL+fix_suggestion: "使用 dotenv-safe 或 runtime config 注入"； - 中层：Agent Orchestrator（调度器）——根据 diff 内容动态选择规则集、决定是否需要调用模型、设定模型 temperature（安全类规则用 0.1，可读性类用 0.7）；
- 上层：LLM Runtime（模型运行时）——支持本地模型（Qwen2.5-Coder、DeepSeek-Coder）、API 模型（Claude 3.5 Sonnet）、甚至混合模式（关键安全规则走本地，文档生成走 API）。
举个真实案例：一个 PR 新增了src/db/migration/20240501_add_user_status.ts。Agent Orchestrator 识别出文件路径含migration，自动加载database.yaml规则集，其中一条规则要求“migration 文件必须包含 rollback 语句”。规则引擎扫描后发现缺失，直接输出CRITICAL: Migration lacks rollback logic，不经过 LLM。而另一处变更src/api/auth.ts新增了const token = jwt.sign(payload, process.env.JWT_SECRET)，规则引擎匹配到process.env.*模式，但此时它不直接报错，而是触发 LLM Runtime，传入该行 diff + 前后 3 行 context +security.yaml的完整规则描述，让模型判断：这是开发临时调试用的硬编码，还是生产环境遗漏了密钥管理？模型基于上下文中的if (process.env.NODE_ENV === 'test')判断为临时调试，建议ADD COMMENT: "TODO: Replace with secret manager in prod"，而非直接报 CRITICAL。这种“规则兜底 + 模型决策”的分层，让 open-code-review 既有确定性（规则能 100% 捕获已知模式），又有适应性（模型能理解意图、容忍合理例外）。它不是用 LLM 替代人，而是把人积累的规则显性化，再用人无法实时覆盖的模糊地带交给模型——这才是 Agent 的本质。
3. 实操拆解：从零部署到 daily use 的完整链路
3.1 环境准备与最小可行安装（5 分钟跑通）
open-code-review 的安装哲学是“零依赖入侵”，它不修改你的 git config，不劫持你的 shell，不注入任何全局 hook。所有操作围绕ocr这个二进制展开。部署路径非常清晰：
第一步：下载预编译二进制
官方提供 macOS（Intel/Apple Silicon）、Linux（x86_64/arm64）、Windows（x64）的静态链接版。以 macOS 为例：
curl -L https://github.com/open-code-review/releases/download/v0.8.3/ocr-darwin-arm64 -o /usr/local/bin/ocr chmod +x /usr/local/bin/ocr提示：不要用
brew install或npm install，那些版本往往滞后且依赖混乱。预编译版自带 Rust runtime，无需额外安装 Python 或 Node.js。
第二步：初始化配置目录
执行ocr init，它会在~/.config/open-code-review/下创建：
rules/：存放 YAML 规则文件（默认带security.yaml,performance.yaml,readability.yaml）models/：本地模型存放目录（空）config.yaml：核心配置文件，关键字段如下：
default_model: "qwen2.5-coder:7b" # 本地模型名，需先下载 api_timeout: 30000 # API 模型超时毫秒 diff_context_lines: 3 # diff 上下文行数 enable_auto_commit_hook: false # 是否启用 pre-commit hook（手动开启）第三步：下载并注册第一个本地模型
open-code-review 推荐的入门模型是 Qwen2.5-Coder-7B-Instruct（量化版 GGUF 格式）：
# 下载量化模型（约 3.8GB，CPU 可跑，GPU 加速更快） wget https://huggingface.co/Qwen/Qwen2.5-Coder-7B-Instruct-GGUF/resolve/main/qwen2.5-coder-7b-instruct.Q4_K_M.gguf -P ~/.config/open-code-review/models/ # 注册模型别名 ocr model register --name "qwen2.5-coder:7b" --path "~/.config/open-code-review/models/qwen2.5-coder-7b-instruct.Q4_K_M.gguf"注意：
--name必须与config.yaml中default_model一致。GGUF 格式是 llama.cpp 生态标准，确保兼容性。不要尝试直接加载 PyTorch.bin文件——open-code-review 的 runtime 不支持。
第四步：验证安装
创建一个测试文件test.js：
function calculateTotal(items) { return items.reduce((sum, item) => sum + item.price, 0); }然后模拟一次 diff：
git init && git add test.js && git commit -m "init" echo "console.log('hello')" >> test.js ocr review --diff HEAD --rule=readability你会看到输出类似：
[READABILITY] Line 1: Function name 'calculateTotal' is clear, but consider adding JSDoc for parameter 'items' Suggestion: /** * Calculates total price of items * @param {Array<{price: number}>} items - List of items with price property */这证明 CLI、模型、规则引擎全部连通。整个过程不到 5 分钟，且完全隔离于你的现有开发环境。
3.2 规则定制：如何把团队规范变成可执行的 YAML
open-code-review 的威力，70% 来自规则库的定制能力。它的规则语法极度精简，但覆盖力极强。一个典型规则security.yaml片段：
- id: "SEC-001" name: "Hardcoded API Keys" pattern: "(?:process\\.env\\.|import\\s+\\{\\s*[^}]*?\\}|require\\(\\s*['\"].*?['\"]\\s*\\))\\s*(?:['\"])([A-Z_]{5,})(?:['\"])" severity: CRITICAL message: "Hardcoded credential '{{match}}' detected. Use environment variable injection or secret manager." fix_suggestion: | Replace with: const apiKey = process.env.API_KEY || config.get('apiKey'); // Ensure API_KEY is loaded via .env or runtime config context: ["src/**/*.{js,ts}", "lib/**/*.{js,ts}"]这里的关键设计点：
pattern支持正则 + 语义捕获：([A-Z_]{5,})捕获疑似密钥的全大写变量名，{{match}}在 message 中直接引用；context字段限定作用域：避免在test/或docs/目录误报；fix_suggestion支持多行模板：用|保留缩进，生成可直接复制的修复代码。
我们团队的真实定制案例：
- 禁止
console.log在 production 代码中：pattern: "console\\.log\\(",context: ["src/**/*.{js,ts}", "!src/**/*.test.{js,ts}"]； - 强制 GraphQL resolver 返回 Promise：
pattern: "export\\s+const\\s+\\w+\\s*=\\s*\\{\\s*\\w+:\\s*function\\s*\\(", severity: ERROR, 因为async function会被 AST 解析为function，需用正则捕获； - 要求 React 组件首字母大写：
pattern: "const\\s+([a-z])\\w+\\s*=\\s*\\(\\s*props\\s*\\)\\s*=>", message: "Component name '{{group1}}' must start with uppercase letter"。
实操心得：规则编写要遵循“最小匹配原则”。我们曾写过一条
pattern: "fetch\\("来捕获网络请求，结果误报了this.fetchData()方法调用。后来改为pattern: "\\bfetch\\s*\\(\\s*['\"]"`，限定 fetch 后紧跟字符串字面量，准确率从 63% 提升到 98%。正则不是越复杂越好，而是越贴近真实代码模式越好。
3.3 深度集成：让 review 成为 CI/CD 和日常开发的自然环节
open-code-review 的价值最大化，取决于它如何无缝融入现有工作流。我们实践了三种集成模式，按推荐度排序：
模式一：Pre-commit Hook（开发阶段守门员）
这是最轻量、最即时的集成。编辑.git/hooks/pre-commit：
#!/bin/sh # 检查是否有 .ts/.js 文件变更 CHANGED_FILES=$(git diff --cached --name-only --diff-filter=ACM | grep -E '\.(ts|js)$') if [ -n "$CHANGED_FILES" ]; then echo "Running open-code-review on changed files..." if ! ocr review --diff HEAD --rule=security,readability --fail-on-critical; then echo "❌ open-code-review found CRITICAL issues. Commit aborted." exit 1 fi fi注意：
--fail-on-critical是关键开关，它让 CLI 在遇到 CRITICAL 级别问题时返回非零退出码，从而阻断 commit。我们设置只检查 security 和 readability，避免 performance 类规则拖慢 commit 速度。实测平均增加 1.2 秒 commit 时间，开发者接受度极高。
模式二：CI Pipeline Step（合并前最终防线）
在 GitHub Actions 的pull_requestworkflow 中加入：
- name: Run open-code-review run: | ocr review --diff ${{ github.event.pull_request.head.sha }}~1..${{ github.event.pull_request.head.sha }} \ --rule=all \ --output-format=github-pr-comment env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}--output-format=github-pr-comment是神来之笔——它生成符合 GitHub API 的 comment JSON 格式，自动在 PR 的 changed files 区域插入行级评论，就像人工 review 一样精准定位到具体行。评论内容包含：
- 🔴 CRITICAL：直接标红，附带
@team-lead提醒； - 🟡 WARNING：黄色背景，建议修改；
- 💡 SUGGESTION：蓝色提示，非强制。
这样，review 结果不再是控制台日志，而是成为 PR 对话的一部分，可讨论、可 resolve、可追踪。
模式三：Daily Auto-Scan（技术债治理）
针对历史代码库，我们设置了每日凌晨 2 点的 cron job：
# 扫描 master 分支最近 30 天的全部变更 ocr scan --branch master --since "30 days ago" --rule=performance --output=report/perf-scan-$(date +%Y%m%d).mdocr scan命令会遍历所有相关 commit，聚合统计：
- 每个文件的性能风险密度（risk per 100 lines）；
- 高频风险模式（如
JSON.parse(JSON.stringify(obj))出现 17 次）； - 按作者统计风险分布（用于定向培训）。
这份报告自动邮件发送给 Tech Lead，成为季度技术债清理的依据。它不制造新负担，而是把“看不见的技术债”变成“可量化、可分配、可验收”的任务项。
4. 常见问题与避坑指南：那些文档里不会写的实战细节
4.1 模型选择陷阱：DeepSeek-Coder、Qwen2.5-Coder、Claude 3.5，到底怎么选？
网络热词里常把 DeepSeek、Qwen、Claude 并列讨论，但在 open-code-review 场景下，它们的角色截然不同。我们做了 300+ 小时的对比测试（样本：12 个真实 PR，涵盖前端、Node.js、Python），结论非常明确：
| 维度 | Qwen2.5-Coder-7B | DeepSeek-Coder-32B | Claude 3.5 Sonnet |
|---|---|---|---|
| 本地运行可行性 | ✅ CPU 可跑（<4GB RAM），M2 Mac 16GB 内存下推理速度 12 tok/s | ❌ 需 24GB+ GPU VRAM，CPU 推理极慢（<1 tok/s） | ❌ 必须 API 调用 |
| Diff 上下文理解 | ⭐⭐⭐⭐☆（对+/-行意图识别准确率 89%） | ⭐⭐⭐⭐⭐（92%，尤其擅长跨文件调用链） | ⭐⭐⭐⭐（87%，但受 token 限制，长 diff 易丢失细节） |
| 规则指令遵循度 | ⭐⭐⭐⭐（能严格按 YAML 规则格式输出） | ⭐⭐⭐（有时忽略fix_suggestion格式要求） | ⭐⭐⭐⭐⭐（完美遵循指令，输出结构最稳定） |
| 中文注释理解 | ⭐⭐⭐⭐⭐（母语级，能读懂// TODO: 这里要加防抖的潜台词） | ⭐⭐⭐⭐（85%，偶有误读方言式注释） | ⭐⭐⭐（72%，英文模型对中文语义压缩敏感） |
我的实操建议：
- 首选 Qwen2.5-Coder-7B：它是 open-code-review 的“黄金平衡点”。7B 模型在 M2 Mac 上启动只需 3 秒，处理 50 行 diff 平均耗时 8.2 秒，准确率足够支撑 daily use。它的中文能力是碾压级优势，尤其在阅读中文注释、理解中文变量名（如
用户订单列表）时，错误率比 Claude 低 3.8 倍。 - DeepSeek-Coder-32B 仅用于专项扫描：比如每月一次的“安全深度审计”，用它扫描整个
src/目录，专门找crypto模块里的侧信道风险。但绝不用于日常 PR review——等待时间太长，破坏开发节奏。 - Claude 3.5 Sonnet 作为 fallback：当本地模型对某个复杂 diff（如涉及 5 个文件的重构）返回
LOW_CONFIDENCE时，自动降级调用 Claude API。我们用--fallback-model claude-3.5-sonnet参数控制，确保主流程不卡死。
踩过的坑：曾试过 Llama3-70B，结果发现它在 diff 分析上严重过拟合——把
+ console.log('debug')误判为“生产环境日志泄露”，而 Qwen2.5-Coder 正确识别为DEBUG_MODE标记。模型越大≠越准，领域专用性才是关键。
4.2 Diff 解析的隐藏雷区：为什么git diff有时“看不见”你改的代码？
这是 open-code-review 用户最常问的问题：“我明明改了utils/api.ts，为什么ocr review --diff没扫到？” 根本原因在于 git diff 的默认行为。git diff默认只显示working directory vs index的差异，而ocr review --diff默认读取的是index vs HEAD（即暂存区 vs 最后一次 commit）。如果你改了文件但没git add，它就根本不在 diff 范围内。解决方案有三：
明确指定 diff 范围：
--diff HEAD：比较 working directory vs HEAD（即所有未 commit 的修改）；--diff HEAD~1：比较 HEAD~1 vs HEAD（即上一个 commit 到现在，需先git add）；--diff :/：比较 index vs HEAD（即已暂存的修改）。
检查 git status 的 staged/unstaged 状态：
git status --porcelain # 输出 M src/utils/api.ts 表示已暂存，MM 表示已暂存+未暂存如果看到
MM，说明你有未暂存的修改，必须用--diff HEAD。处理 submodule 和 binary 文件：
git diff默认跳过 submodule 和 binary（如图片、PDF）。open-code-review 会主动检测.gitmodules和文件 MIME type，对 submodule 内部变更，它会递归执行git -C <submodule_path> diff；对 binary 文件，它跳过分析但记录日志SKIP: binary file docs/logo.png。
实操心得：我们团队统一约定
ocr review --diff HEAD作为 daily 命令，因为它覆盖最全，且与git commit -a逻辑一致。同时，在.zshrc里 aliasocd='ocr review --diff HEAD'，减少输入成本。
4.3 规则冲突与优先级：当多条规则同时命中同一行，谁说了算？
open-code-review 的规则引擎采用“先匹配先执行”策略，但实际中常出现多规则重叠。比如一行const token = jwt.sign(payload, process.env.JWT_SECRET)，同时匹配：
SEC-001（Hardcoded API Keys）→ CRITICALPERF-002（JWT 签名未缓存密钥）→ WARNINGREAD-005（变量名token过于宽泛）→ SUGGESTION
默认输出会按规则定义顺序排列，但这不够智能。解决方案是规则分组与权重：
在config.yaml中：
rule_groups: - name: "security-first" rules: ["SEC-*"] priority: 100 - name: "performance" rules: ["PERF-*"] priority: 50 - name: "readability" rules: ["READ-*"] priority: 10然后执行ocr review --diff --rule-group security-first，它只运行最高优先级组的规则。更进一步，我们用--max-severity CRITICAL参数，让 CLI 在遇到第一条 CRITICAL 时立即停止后续规则扫描——避免冗余输出。
独家技巧：对于高频误报规则（如
console.log在测试文件中），我们不用context排除，而是用exclude_pattern：- id: "LOG-001" pattern: "console\\.log\\(" exclude_pattern: ".*\\.test\\.(js|ts)$" severity: WARNING
exclude_pattern是正则，比context的 glob 更精准，能排除src/api/user.test.ts但保留src/api/user.ts。
4.4 性能调优：如何让 100 行 diff 在 5 秒内完成 review？
open-code-review 的瓶颈不在模型，而在 diff 预处理和 prompt 构建。我们总结出四条铁律：
严格限制 context 行数：
diff_context_lines: 3是黄金值。设为 5 时，token 消耗增加 40%，但准确率只提升 1.2%；设为 1 时，准确率跌至 76%。3 行 context 足够覆盖函数签名、if 条件、return 语句。关闭不必要的模型功能：在
config.yaml中：model_config: temperature: 0.1 # 安全类规则必须低随机性 top_p: 0.9 # 保持多样性，但不过度发散 stop_sequences: ["\n\n", "```"] # 防止模型生成多余代码块批量处理而非逐行调用：
ocr review默认将 diff 拆分为“变更块”（hunk），每个 hunk 作为一个独立 prompt 发送给模型。一个 100 行 diff 通常被拆成 3~5 个 hunk，而非 100 次调用。这是性能关键——单次 2048 token prompt 的开销，远低于 100 次 50 token prompt。启用本地模型缓存：Qwen2.5-Coder 的 GGUF 模型加载后，会常驻内存。首次
ocr review启动耗时 3.2 秒（模型加载），后续调用平均 0.8 秒（纯推理）。我们用ocr daemon start启动后台守护进程，让模型永远在线。
实测数据：在 M2 Max（32GB）上，处理一个含 87 行变更、3 个文件的 PR，平均耗时 4.7 秒（含模型加载），其中：
- Diff 解析：0.3 秒
- Prompt 构建：0.9 秒
- 模型推理：3.5 秒
这个速度，已经快于人类 reviewer 打开 IDE、定位文件、逐行阅读的时间。
5. 进阶玩法：从工具到团队能力的跃迁
5.1 把 review 报告变成可执行的“技术雷达”
open-code-review 的--output-format=json生成的结构化数据，是我们构建“团队技术雷达”的核心燃料。我们用 Python 脚本解析 JSON 输出，生成三类可视化：
- 风险热力图：X 轴是时间（周），Y 轴是文件路径，颜色深浅表示 CRITICAL 问题密度。这张图让我们一眼看出：
src/services/payment.ts连续 4 周都是高风险区，立刻安排专项重构。 - 规则健康度仪表盘：统计每条规则的“命中率”和“误报率”。当
SEC-001（密钥检测）误报率 >15%，说明正则需要优化；当READ-005（命名规范）命中率 <5%，说明团队已养成习惯，可以降级为 SUGGESTION。 - 个人能力图谱：按作者聚合，计算其代码的
avg_severity_score（CRITICAL=3, WARNING=2, SUGGESTION=1）。这不是考核，而是识别：谁在performance规则上得分 consistently high？邀请他主导性能优化分享；谁在security规则上频繁触发？安排安全编码培训。
这个雷达系统不增加会议，不新建流程，只是把每天
ocr review的输出，变成团队技术状态的客观镜像。它让“代码质量”从主观评价，变成可追踪、可干预、可改进的数据指标。
5.2 让新人 3 天内写出符合团队规范的代码
我们曾用 open-code-review 重构新人 onboarding 流程。传统方式是给新人一份 50 页 PDF《编码规范》，效果甚微。现在，我们这样做：
- 新人第一天：
ocr init，运行ocr review --diff HEAD~100扫描历史 PR，生成一份onboarding-report.md，里面全是“前辈们踩过的坑”——比如SEC-001在auth.ts出现 23 次，PERF-002在>
