1. 这不是又一个“AI代码审查”玩具，而是一套可嵌入开发流程的开源协作协议
你有没有遇到过这样的场景：团队里新同学提交了PR，你点开diff页面，盯着那27个文件、432行改动，手指悬在“Approve”按钮上方迟迟按不下去——不是不想审，是真没时间逐行看；不是不会审，是怕漏掉那个藏在utils/date.js第89行、把new Date().getTime()错写成Date.now().getTime()的隐性时区bug；更不是不重视，而是每次review都像在走钢丝：一边是上线 deadline 的倒计时红字，一边是生产环境凌晨三点的告警短信。这时候，有人甩给你一个叫open-code-review的CLI工具，说“它能用LLM帮你自动审代码”。你心里一咯噔：这玩意儿真敢往生产环境的CI流水线里塞？它知道我们项目里那个自研的@internal/permission-guard装饰器的校验逻辑必须绕过所有静态检查吗？它认得清src/pages/dashboard/v2和src/pages/dashboard/v3两个并存版本里API响应结构的微妙差异吗？它会不会把// TODO: refactor this legacy handler这种注释当成待办事项直接删掉？
别急着关网页。open-code-review的核心价值，从来就不是“让LLM代替人审代码”，而是把代码审查这件事，从单点、离散、依赖个人经验的“人肉动作”，变成可定义、可沉淀、可验证、可演进的“工程协议”。它本质上是一个轻量级的CLI框架，让你用纯文本（YAML/JSON）定义“什么算好代码”——比如“所有调用fetch的地方必须包裹try/catch”，“useState的初始值不能是null”，“eslint-disable注释必须附带Jira ID”。这些规则不是写死在某个模型权重里，而是明文存在你的.open-code-review/目录下，和package.json、.gitignore一样，受Git版本控制。LLM在这里的角色，是规则执行器的“智能协作者”：当它看到一段违反规则的代码，它不直接打叉，而是生成一条符合你团队语境的、带上下文引用的建议——比如“src/api/user.ts第42行：fetch调用未处理网络异常，建议参考CONTRIBUTING.md#api-error-handling添加重试逻辑”。这个过程全程离线可审计，所有提示词（prompt）、输入上下文、模型输出都记录在本地日志里。你不需要给任何第三方服务上传代码，也不需要在.env里填一堆API密钥——它默认只用本地运行的Ollama模型，或者你指定的、已配置好鉴权的私有LLM endpoint。关键词里的CLI、git、LLM，在这里不是技术堆砌的标签，而是三个咬合的齿轮：git提供变更的精确上下文（commit diff），CLI提供与开发者工作流无缝集成的入口（git commit钩子、npm run review），LLM提供理解语义和生成自然语言反馈的能力。它解决的不是“能不能审”，而是“怎么让审的过程可复现、可追溯、可被新人快速掌握”。
2. 为什么必须放弃“一键AI审代码”的幻想，转向协议化审查
市面上绝大多数打着“AI Code Review”旗号的工具，其底层逻辑存在一个致命的结构性缺陷：它们把LLM当作一个黑盒裁判，期望它基于海量公开代码训练出的“通用最佳实践”，来评判你手头这份特定业务代码的好坏。这就像让一个熟读《建筑学概论》的教授，去验收一座正在建造的核电站反应堆厂房——理论再扎实，也架不住图纸上那个为适配特种冷却剂管道而特意设计的非标法兰接口。open-code-review的设计哲学，恰恰是从这个陷阱里跳了出来。它的核心假设非常朴素：真正的代码质量，永远由具体业务场景、团队技术栈、历史包袱和当前阶段目标共同定义，不存在放之四海而皆准的“好代码”标准。这个认知，直接决定了它的架构选型。
首先，它彻底放弃了“中心化模型服务”的路径。你不会看到一个需要注册、登录、绑定信用卡的SaaS后台。它的CLI二进制文件下载即用，所有规则定义（.ocr-rules.yaml）、提示词模板（.ocr-prompts/）、甚至模型配置（.ocr-models.yaml）都存放在项目根目录下的.open-code-review/文件夹里。这意味着什么？意味着当你git clone一个新项目，cd进去，运行ocr review --commit HEAD~1，它就能立刻开始工作——因为所有“判断依据”都随代码一起流动。这解决了热词里反复出现的“密钥泄露”焦虑：没有API密钥需要配置，没有代码需要上传到外部服务器，所有敏感信息（如内部API密钥、数据库连接字符串）天然被Git的.gitignore和CLI的上下文裁剪逻辑隔离在外。我实测过，在一个包含process.env.DB_PASSWORD硬编码的测试分支上运行ocr review，它只会分析git diff中实际修改的、且未被.gitignore排除的源码文件，环境变量相关的风险根本不会进入LLM的视野。
其次，它把LLM降级为“规则解释器”而非“规则制定者”。传统方案里，LLM的输出是最终结论（“此PR有高危漏洞，拒绝合并”）。而在open-code-review里，LLM的输出只是对预设规则的一次“具象化演绎”。举个真实例子：我们团队有一条硬性规则——“所有GraphQL Resolver函数的返回类型必须显式声明为Promise<xxx>，禁止使用async隐式推导”。这条规则写在.ocr-rules.yaml里，格式如下：
rules: - id: "graphql-resolver-return-type" description: "GraphQL resolver must explicitly declare Promise return type" severity: "error" scope: "typescript" pattern: | export async function \w+\(.*\) \{.*\} suggestion: | Replace 'async function' with explicit Promise return type. Example: - BAD: export async function getUser() { ... } - GOOD: export function getUser(): Promise<User> { ... }当LLM看到export async function listProducts() { ... }时，它不会凭空发明一条新规则，而是严格遵循pattern匹配，然后根据suggestion模板生成一条带具体文件路径、行号和修正示例的反馈。这个过程完全可控，你可以随时修改suggestion模板，让它用团队内部约定的术语（比如把“GOOD”替换成“符合ARCHITECTURE_GUIDE.md#resolvers”）。这正是热词里“agent 和 LLM 和 AI模型 有什么区别”的答案：在这里，open-code-review本身就是一个轻量Agent，它负责调度（选择哪条规则触发）、上下文管理（提取diff、定位文件）、执行（调用LLM生成文本），而LLM只是它调用的一个“文本生成插件”。DeepSeek、Qwen、Llama这些大模型，在这里没有高低贵贱之分，只要它能跑通Ollama或支持OpenAI兼容API，它就是合格的“协作者”。这种解耦，让技术选型变得极其务实——你可以今天用本地4B的Qwen2，明天换成公司私有云上部署的70B DeepSeek-V2，只需改一行.ocr-models.yaml的配置，整个审查逻辑毫发无损。
提示：不要试图用
open-code-review去替代ESLint或Prettier。它的战场不在语法层面，而在语义和架构层面。把ESLint的no-unused-vars交给它干，就像用航天飞机送快递——大材小用且成本高昂。它的真正价值，是发现ESLint永远抓不到的问题：比如“这个新写的支付回调处理器，为什么没有接入我们统一的幂等性中间件？”、“这个前端组件的props接口，和后端Swagger文档里定义的DTO字段名不一致，是文档过期了还是代码写错了？”
3. 从零搭建：一个可立即投入生产的审查工作流
现在，让我们把概念落地。假设你刚接手一个维护了五年的React+Node.js电商项目，团队正被频繁的线上支付失败困扰，根源往往是前后端对接时的字段名拼写错误或类型不匹配。你想用open-code-review建立一道防线，确保每次涉及/api/payment/callback的改动，都强制校验其与Swagger文档的一致性。下面是我亲手搭建并已在三个项目中验证过的完整流程，每一步都附带踩过的坑和绕过方案。
3.1 环境准备：极简主义的CLI安装与基础配置
open-code-review的安装哲学是“最小侵入”。它不修改你的全局node_modules，也不要求你安装一堆Python依赖。官方推荐的方式是通过npm或yarn作为项目级dev dependency引入：
# 在项目根目录执行 npm install --save-dev open-code-review # 或者，如果你偏好全局CLI（仅限开发机） npm install -g open-code-review安装完成后，首次运行会引导你初始化配置：
npx ocr init # 或者全局安装后 ocr init这个命令会在项目根目录创建.open-code-review/文件夹，并生成三个核心文件：
.open-code-review/config.yaml：全局配置，定义默认模型、日志路径、忽略规则等。.open-code-review/rules/：存放所有审查规则的YAML文件夹，支持按模块拆分（如backend-rules.yaml,frontend-rules.yaml）。.open-code-review/prompts/：存放提示词模板，每个规则可以关联一个专属prompt。
关键避坑点：ocr init生成的默认配置，模型地址指向http://localhost:11434（Ollama默认端口）。如果你没装Ollama，或者想用其他模型，必须立刻修改config.yaml。我强烈建议新手先用Ollama，因为它开箱即用：
# macOS/Linux 安装Ollama curl -fsSL https://ollama.com/install.sh | sh # 拉取一个轻量模型（Qwen2:0.5b足够应付大部分JS/TS审查） ollama pull qwen2:0.5b修改config.yaml中的model.endpoint为http://localhost:11434/api/chat，model.name为qwen2:0.5b。这样，所有后续操作都无需网络，完全离线运行，彻底规避热词里“LLM代理地址”、“密钥泄露”等安全顾虑。
3.2 规则定义：用YAML写出你的团队“宪法”
这才是open-code-review的灵魂所在。我们以“支付回调一致性校验”为例，编写第一条业务规则。在.open-code-review/rules/payment-consistency.yaml中：
rules: - id: "payment-callback-swagger-sync" description: "Payment callback handler must match Swagger definition for /api/payment/callback" severity: "critical" scope: "javascript,typescript" # 使用正则精准匹配回调路由定义 pattern: | router\.post\(\s*['"]\/api\/payment\/callback['"]\s*,\s*(\w+) # 关联的提示词模板路径 prompt_template: "payment-swagger-check.j2" # 定义此规则生效的文件范围（避免扫描无关文件） file_patterns: - "src/routes/payment.js" - "src/routes/payment.ts" - "server/routes/payment.js" - "server/routes/payment.ts"注意file_patterns字段——这是性能优化的关键。open-code-review默认会扫描整个git diff的变更文件，但如果你的项目有node_modules或dist目录，它们也会被纳入分析，导致LLM负载激增。明确指定file_patterns，能让CLI在调用LLM前就过滤掉90%的无效文件。我曾在一个大型项目里忘记加这个，结果一次ocr review耗时从12秒飙升到3分钟，CPU风扇狂转。
接下来，创建提示词模板.open-code-review/prompts/payment-swagger-check.j2：
你是一名资深全栈工程师，正在审查一个电商项目的支付回调接口实现。 请严格比对以下两部分内容： 1. 【代码片段】：这是从{{ file_path }}第{{ line_number }}行提取的回调处理器定义： {{ code_snippet }} 2. 【Swagger定义】：这是来自项目根目录下`swagger.yaml`中`/api/payment/callback`路径的定义： {{ swagger_definition }} 请逐项检查： - 处理器函数接收的参数（req.body, req.query）是否与Swagger中`requestBody`和`parameters`定义的字段名、类型完全一致？ - 处理器函数返回的HTTP状态码（res.status(xxx)）是否与Swagger中`responses`定义的状态码匹配？ - 处理器函数返回的JSON结构（res.json({...})）是否与Swagger中`responses.200.schema`定义的DTO结构一致？ 如果发现任何不一致，请用中文清晰指出问题点、对应行号、以及符合Swagger定义的修正建议。如果完全一致，请输出"✅ 通过Swagger一致性校验"。这个模板的设计意图很明确：它不指望LLM自己去读swagger.yaml，而是把swagger.yaml的内容作为上下文的一部分，由CLI在调用LLM前动态注入。这就引出了下一个关键步骤——如何让CLI自动读取并注入swagger.yaml？答案是：利用CLI的--context参数和自定义脚本。
3.3 上下文注入：让LLM“看见”你的Swagger文档
open-code-reviewCLI支持--context <path>参数，可以将任意文件内容作为上下文注入到所有提示词中。但swagger.yaml通常很大，直接注入会导致token超限。我的解决方案是：写一个极简的Node.js脚本，只提取我们需要的部分：
// scripts/extract-swagger-payment.js const fs = require('fs'); const yaml = require('js-yaml'); // npm install js-yaml const swagger = yaml.load(fs.readFileSync('swagger.yaml', 'utf8')); const paymentPath = swagger.paths['/api/payment/callback']; console.log(JSON.stringify({ method: paymentPath.post.method, requestBody: paymentPath.post.requestBody, responses: paymentPath.post.responses }, null, 2));然后，在package.json的scripts里定义一个便捷命令：
{ "scripts": { "ocr:payment": "ocr review --rule payment-consistency --context scripts/extract-swagger-payment.js --format json" } }现在，运行npm run ocr:payment，CLI会先执行scripts/extract-swagger-payment.js，将其stdout（精简后的JSON）作为swagger_definition变量注入到payment-swagger-check.j2模板中。整个过程全自动，无需人工干预。这个模式可以无限扩展：你可以为数据库迁移脚本注入schema.sql，为前端组件注入Figma设计稿URL，为API客户端注入Postman Collection——LLM的“知识”边界，完全由你用脚本定义。
3.4 集成到Git工作流：让审查成为提交的必经之路
最后一步，让这套机制真正融入开发者的肌肉记忆。最常用的是Git Hooks。在.git/hooks/pre-commit文件中（需赋予可执行权限chmod +x .git/hooks/pre-commit）：
#!/bin/bash # 检查是否有相关文件改动 CHANGED_FILES=$(git diff --cached --name-only --diff-filter=ACMR | grep -E '\.(js|ts|jsx|tsx)$') if [ -n "$CHANGED_FILES" ]; then echo "🔍 正在运行 open-code-review 检查..." # 只对改动的文件运行审查 npx ocr review --files "$CHANGED_FILES" --format compact REVIEW_RESULT=$? if [ $REVIEW_RESULT -ne 0 ]; then echo "❌ open-code-review 发现问题，请修复后重试" exit 1 fi fi这个Hook的精妙之处在于--files "$CHANGED_FILES"。它只分析本次git add暂存区里的文件，而不是整个项目。这保证了审查速度，也避免了对未改动文件的误报。我曾经在团队里推行时，有同事抱怨“每次提交都要等几秒”，后来我把--files改成只针对src/和server/目录下的文件，审查时间从平均8秒降到1.2秒，抱怨声立刻消失了。
注意：
pre-commitHook只检查暂存区，无法捕获git commit --amend这种场景。更健壮的方案是结合CI/CD，在GitHub Actions或GitLab CI中添加一个reviewjob，使用ocr review --commit ${{ github.event.pull_request.head.sha }}来审查整个PR。这样，即使开发者绕过了本地Hook，CI也会拦截不合格的代码。
4. 深度解析：LLM在审查链路中的真实角色与能力边界
很多开发者第一次接触open-code-review时，最大的困惑是：“既然LLM这么强大，为什么还要费劲写那些YAML规则？直接让它‘看着办’不就行了？”这个问题触及了整个方案的根基。我们必须清醒地认识到：LLM不是万能的神谕，而是一个需要被精心喂养、严格约束、并置于人类监督之下的高级文本处理器。它在open-code-review审查链路中，扮演着三个明确且有限的角色，每一个都有其不可逾越的能力边界。
4.1 角色一：上下文感知的模式匹配增强器
传统正则表达式（regex）擅长匹配固定字符串模式，但在面对代码语义时力不从心。比如，要找出所有“可能造成内存泄漏的事件监听器添加”，regex很难区分window.addEventListener('resize', handler)（危险）和element.addEventListener('click', () => {})（安全，因为箭头函数无this绑定）。open-code-review的解决方案是：用YAML规则定义“可疑模式”的粗粒度锚点，再用LLM对锚点周围的上下文进行细粒度语义分析。继续上面的例子，我们可以先写一条规则：
rules: - id: "event-listener-leak-risk" pattern: "addEventListener\(" # 不指定具体参数，只定位调用位置当CLI扫描到addEventListener(时，它会提取该行及前后10行的代码，连同项目中CONTRIBUTING.md里关于“事件监听器清理规范”的章节，一起构建成LLM的输入上下文。LLM的任务就变成了一个二分类问题：“这段代码是否满足‘监听器必须在组件卸载时移除’的要求？”它的输出会被解析为true或false，进而决定是否触发后续的suggestion。这个过程，本质上是把LLM当成了一个“可编程的、带上下文的智能grep”。它的优势在于能理解this的绑定、闭包的作用域、React组件的生命周期钩子等复杂语义；它的劣势在于，如果上下文信息不足（比如CONTRIBUTING.md里没写清楚规范），它的判断就会失效。因此，规则的质量，永远取决于你提供的上下文质量和锚点的精准度，而不是LLM本身的“智商”。
4.2 角色二：自然语言反馈的生成引擎
这是LLM最无可替代的价值。静态分析工具（如ESLint）能告诉你“varis not allowed”，但open-code-review能生成：“src/utils/date.js第15行：使用var声明now变量，可能导致作用域污染。建议改为const now = new Date().getTime();，以符合团队CODE_STYLE_GUIDE.md#variable-declaration中‘优先使用const/let’的规定。” 这种反馈之所以有效，是因为它：
- 精准定位：包含绝对路径和行号，开发者双击即可跳转。
- 语境关联：引用了团队内部文档，建立了权威依据。
- 行动导向：提供了可直接复制粘贴的修正代码。
- 语气友好：避免了“ERROR”、“FATAL”等压迫性词汇，用“建议”、“符合”等协作性语言。
实现这一点的关键，在于.ocr-prompts/下的Jinja2模板。模板里{{ file_path }}、{{ line_number }}、{{ code_snippet }}这些变量，都是CLI在调用LLM前，从Git diff和AST解析中精确提取的。LLM所做的，只是把这些结构化数据，用符合人类阅读习惯的自然语言“翻译”出来。它不创造新知识，只是重组已有信息。这也是为什么open-code-review能完美兼容各种LLM——只要它能接受JSON输入并返回JSON或纯文本，它就能胜任这个“翻译员”的角色。我在测试中对比过Qwen2、Llama3和Claude-3-haiku，三者在生成反馈的准确性和流畅度上差异微乎其微，真正影响体验的，是模板的编写质量。
4.3 角色三：跨文件、跨语言的语义桥接者
现代应用很少是单语言的孤岛。一个典型的改动，可能同时涉及前端React组件的Props定义、后端Node.js的API路由、数据库的SQL Schema变更，以及Swagger文档的更新。传统工具只能在单一语言内工作。open-code-review的突破在于，它允许你在一条规则里，定义跨多个文件类型的检查逻辑，并由LLM完成最终的语义对齐。比如，我们定义一条规则，检查“前端组件的Props接口是否与后端API响应DTO一致”：
rules: - id: "frontend-backend-dto-sync" # 同时监听前端和后端文件的改动 file_patterns: - "src/components/PaymentForm.tsx" - "server/controllers/payment.ts" - "swagger.yaml" # 模式匹配只做触发，不做判断 pattern: ".*" prompt_template: "dto-sync-check.j2"对应的dto-sync-check.j2模板会要求LLM：
- 从
PaymentForm.tsx中提取interface PaymentFormProps的定义。 - 从
payment.ts中提取res.json({ ... })的返回对象结构。 - 从
swagger.yaml中提取#/components/schemas/PaymentResponse的定义。 - 三者进行字段名、类型、必填性的逐项比对，并指出差异。
这个任务，对人类来说是繁琐但确定的；对LLM来说，是它最擅长的“模式识别+文本比对”。它不需要理解支付业务逻辑，只需要忠实地执行“找字段、比类型、列差异”这个指令。而open-code-review的架构，恰好为它提供了执行这个指令所需的全部上下文。这正是热词里“agent 和 llm 和 ai模型 有什么区别”的终极答案：在这个系统里，open-code-review是Agent（决策、调度、整合），LLM是Tool（执行具体的文本处理任务），而git、filesystem、AST parser则是它调用的其他Tool。它们各司其职，共同构成一个可信赖的审查闭环。
实战心得：LLM的“幻觉”（hallucination）在审查场景中危害极大。我曾遇到一次，LLM在分析一个空数组
[]时，坚称它“包含了三个元素”。为杜绝此类风险，open-code-review强制要求所有LLM输出必须经过一个output_validator。这个validator是一个简单的正则或JSON Schema校验器，确保LLM的回复格式符合预期（例如，必须包含✅或❌开头，必须有line:字段）。任何不合规的输出，都会被CLI直接丢弃并报错，绝不会作为审查结果展示给开发者。这是保障审查结果可信度的最后一道防线。
5. 超越审查：构建属于你团队的可持续进化知识库
open-code-review的终极魅力，不在于它能帮你发现多少个bug，而在于它能把每一次代码审查，都转化为你团队独有的、可积累、可传承的知识资产。这听起来很玄，但它的实现路径却异常朴实：所有规则、所有提示词、所有审查日志，都以纯文本形式，和你的源代码一起，躺在Git仓库里。这意味着，代码审查不再是一次性的消耗性活动，而是一个持续的知识沉淀过程。
5.1 规则即文档：让最佳实践自动活在代码旁边
想象一下，新入职的工程师第一次看到src/utils/apiClient.ts，里面有一段复杂的错误重试逻辑。他想知道“为什么这里要重试3次而不是5次？”，“为什么超时设置为8000ms？”。传统方式，他得去翻Wiki、问前辈、或者在Slack里发消息。而在open-code-review体系里，答案就藏在.open-code-review/rules/api-retry-policy.yaml里：
rules: - id: "api-client-retry-policy" description: "API client must implement exponential backoff with max 3 retries and 8s timeout" # 这里不仅定义了规则，还解释了why rationale: | 根据2023年Q3线上故障复盘报告（INC-2023-087），超过70%的API超时故障源于瞬时网络抖动。 设置3次指数退避（1s, 2s, 4s）能在99.2%的抖动场景下恢复，同时避免对下游服务造成雪崩压力。 8s总超时是基于P99 API响应时间（6.2s）+ 1.8s缓冲得出的安全阈值。 pattern: "retry\(\d+\)" suggestion: | Use `retry(3)` with `timeout(8000)` as defined in `ARCHITECTURE_GUIDE.md#api-clients`.当这位新同事运行ocr review --file src/utils/apiClient.ts时，他不仅会看到一条关于重试次数的检查，还会在rationale字段里，读到背后真实的业务数据和决策依据。规则文件，就这样自然而然地成为了最鲜活、最贴近代码的“活文档”。它比Wiki更可靠，因为Wiki可能过期，而规则文件一旦过期，审查就会失败，立刻暴露问题；它比口头传授更公平，因为每个开发者看到的，都是同一份经过集体确认的共识。
5.2 日志即审计：每一次审查都是可追溯的决策快照
open-code-review默认会将每次审查的完整输入（diff、上下文、prompt）、LLM的原始输出、以及CLI的最终解析结果，记录在.open-code-review/logs/目录下，按日期和commit hash组织。这些日志不是垃圾，而是宝贵的审计线索。比如，某天线上出现了一个因Date.now()误用导致的时区bug，回溯发现，这个bug是在一个PR中引入的。我们打开当天的审查日志，就能看到：
- 当时的
git diff内容。 - CLI提取的、用于分析的代码片段（确认是否包含了出问题的那行）。
- LLM生成的原始反馈（确认它是否识别出了问题）。
- CLI的最终判断（是标记为
warning但被开发者忽略了，还是规则本身没覆盖到这个case？）。
这个完整的证据链，让事后复盘变得无比高效。它能清晰地区分：是规则缺失（需要补充新规则），是LLM误判（需要优化prompt），还是人为疏忽（需要加强流程）。我所在的团队，每月会抽取10个典型日志，组织一次“审查复盘会”，由不同成员轮流讲解日志里暴露的问题，并当场更新规则或prompt。这个过程，本身就是一次高效的团队技术对齐。
5.3 社区共建：从“我用”到“我们共建”的范式转移
open-code-review的开源本质，决定了它最大的潜力在于社区协同。目前，它的核心规则库（open-code-review/rules）已经包含了针对React、Vue、Node.js、Python Flask等主流技术栈的通用规则。但这些只是起点。真正的价值，诞生于你团队对这些规则的“fork”和“enhancement”。比如，我们团队在通用的“React Hooks依赖数组检查”规则基础上，增加了对useSWR和TanStack Query的特殊支持，因为我们的项目重度依赖这两个库。我们将这些增强版规则，以my-company-react-rules.yaml的形式提交到内部GitLab的rules-library仓库。其他项目组可以轻松地git submodule add或npm install @my-company/ocr-rules来复用。
更进一步，我们建立了一个内部的ocr-rule-marketplace网站（用Next.js搭的静态站），所有团队贡献的规则都以卡片形式展示，包含：
- 规则ID和描述。
- 适用的技术栈和场景。
- 贡献者和最后更新时间。
- 一个“一键安装”按钮，点击后自动生成
npx ocr rule install <id>命令。
这个市场，让知识共享从“被动推送”变成了“主动发现”。一个前端团队发现了一个能自动检测TypeScript泛型滥用的规则，后端团队看到后，立刻意识到它也能用于他们的NestJS DTO校验，于是贡献了一个适配版。这种跨职能的知识流动，是任何中心化SaaS工具都无法催生的。它印证了热词里“wikiskill:为llm skill编配经验层,实现持续进化”的理念——open-code-review不是在卖一个模型，而是在提供一个让团队技能持续进化的基础设施。
最后分享一个小技巧：在.open-code-review/config.yaml里，开启auto_update_rules: true选项。这样，每次运行ocr review时，CLI会自动检查rules-library仓库是否有新提交，并提示你是否要拉取更新。这个小小的自动化，让知识的保鲜期，从“月”缩短到了“小时”。
