What · 是什么
规则不够用？MCP 接入外部工具、自定义规则文件、--rule 临时规则、委托模式喂给任意 Agent
内置规则不够用时提供四条扩展路径：MCP 接入、自定义规则文件、--rule ad-hoc 规则、委托模式
MCP 接入：config.json 的 mcp_servers.<name> 配置外部工具，支持 stdio（本地进程）与 remote（远程服务）两种模式，让审查过程调用外部工具能力
自定义规则文件：内置覆盖 10+ 语言，专项场景（特定框架/合规要求）可补写专属规则文件
--rule ad-hoc 规则：单次命令临时注入规则，不改动任何配置文件
委托模式：把审查规则喂给任意 Agent 的 skill（如 skills/open-code-review/），让外部 Agent 以 OCR 规则为 skill 执行审查
规则值可引用 .md/.txt 文件：复杂审查指令可写在独立文档中，规则文件仅引用其路径，便于维护长指令
Why · 为什么
原理 · Principle
单一内置规则无法覆盖所有团队规范与框架特性，扩展性是工具长期可用的前提
MCP 生态让审查能联动外部工具（如安全扫描器、数据库 schema 检查），审查从『读代码』升级为『查事实』
复杂指令内联在 JSON 规则里难以维护，引用外部 .md/.txt 把指令与配置分离，可读性与可维护性双提升
How · 怎么做
接入 MCP 工具：在 config.json 的 mcp_servers 下新增 <name>，配置 stdio（本地命令启动）或 remote（远程端点）类型，审查中即可调用该工具
编写专项规则：按内置规则文件格式新建自定义规则文件，覆盖内置 10+ 语言之外的场景（如特定框架规范），再在配置中启用
临时注入：运行审查时追加 --rule '规则内容'，一次性生效，适合现场临时检查
委托扩展：把审查规则以 skill 形式（skills/open-code-review/）喂给任意 Agent，外部 Agent 加载 skill 后按规则审查
复杂指令外置：把长审查指令写入 .md/.txt 文件，规则值引用文件路径，审查时读取文件内容作为指令
案例 · Cases
| 代表性案例 |
|---|
| 框架专项审查：自定义规则覆盖公司内部框架约定，内置规则不认识的模式也能被审查 |
| 安全联动：MCP 接入依赖扫描器，审查时自动交叉验证依赖版本与已知漏洞 |
| 多 Agent 协作：委托模式 + skill 文件让 Claude Code 等宿主 Agent 用同一套 OCR 规则审查 |
| 复杂合规指令：审查标准写成 .md 文档（数十条细则），规则文件只引用路径，评审修改只动文档 |
反模式 · Anti-patterns
- 把长指令直接内联进 rule.json 的字符串值，JSON 转义与换行处理困难，且评审修改频繁改配置
- MCP 工具地址配置为不可信远程端点，审查数据可能外泄，remote 模式需确认信任边界
- --rule 临时规则被误以为是持久的，下次审查不生效时误判为 bug
- 自定义规则与内置规则命名冲突或作用域重叠，规则互相覆盖导致行为不可预测，改动前先用 ocr rules check 验证
正反实例论证 · Evidence
正例 · Pro
MCP 接入外部工具联动审查
# config.json"mcp_servers": {"dep-scan": {"type": "stdio", "command": "dep-scanner", "args": ["--json"]}}# 审查中调用 dep-scan 交叉验证依赖版本审查从『读代码』升级为『查事实』：依赖漏洞、schema 一致性等外部事实可实时核对。
反例 · Con
MCP 配置不可信 remote 端点
"mcp_servers": {"tool": {"type": "remote", "url": "http://unknown-host:8080"}}审查数据可能被发送到不可信远程端点，源码外泄风险；remote 模式必须先确认信任边界。
正例 · Pro
规则值引用 .md 文件承载复杂指令
# rule.json 中规则值引用文档路径"rules": [{"name": "compliance", "value": "rules/compliance.md"}]# 数十条细则写在 compliance.md 中长指令与配置分离，评审修改只动文档不改 JSON，可读性与可维护性双提升。
反例 · Con
长指令内联进 rule.json 字符串
"rules": [{"value": "禁止1、禁止2、禁止3…（数十条细则内联）"}]JSON 转义与换行处理困难，评审每次改动都触碰配置文件，容易引入语法错误。
正例 · Pro
--rule ad-hoc 补充专项检查
ocr review --rule '禁止在事务中执行耗时查询'内置 10+ 语言规则之外的专项约束随时补充，一次性生效，适合现场临时检查。
反例 · Con
自定义规则与内置规则命名冲突
# 自定义规则与内置规则同名且作用域重叠ocr review规则互相覆盖导致行为不可预测，改动前应先用 ocr rules check 验证命中与覆盖关系。