使用 alibaba/open-code-review 的 `ocr` CLI 对 Git 变更进行 AI 驱动的代码审查。当用户要求审查代码、审查拉取请求、审查暂存/未暂存的更改、审查提交或比较分支以发现代码质量问题时使用。生成行级别的审查评论，并可在请求时自动应用修复。配合适当的审查规则，可以检测各种类型的问题，包括错误、安全漏洞、性能问题和代码质量问题。
Open Code Review
一个用于调用 open-code-review (ocr) 的技能——这是一个开源的 AI 代码审查 CLI，可以读取 Git diff 并生成结构化的行级审查评论。
前置条件检查
在开始审查之前，请验证环境：
# 1. 检查 CLI 是否已安装
which ocr || echo "NOT INSTALLED"
# 2. 验证 LLM 连接
ocr llm test
如果 ocr 未安装，请先安装：
npm install -g @alibaba-group/open-code-review
如果 ocr llm test 失败，用户必须配置 LLM。请使用以下选项之一指导用户：
选项 A — 环境变量（优先级最高，推荐用于 CI）：
export OCR_LLM_URL=https://api.anthropic.com/v1/messages
export OCR_LLM_TOKEN=<api-key>
export OCR_LLM_MODEL=claude-opus-4-6
export OCR_USE_ANTHROPIC=true
选项 B — 持久化配置：
ocr config set llm.url https://api.anthropic.com/v1/messages
ocr config set llm.auth_token <api-key>
ocr config set llm.model claude-opus-4-6
ocr config set llm.use_anthropic true
在此处停止并询问用户提供凭据——切勿发明或硬编码 API 密钥。
工作流程
步骤 1：收集业务上下文
分析审查目标（提交、分支或更改）以提取简洁的业务上下文。通过 --background 传递此上下文以提高审查质量。
步骤 2：运行代码审查
使用适当的标志运行 OCR 命令。始终在可用时通过 --background 传递业务上下文：
ocr review --audience agent --background "business context here" [user-args]
参数处理：
- 背景上下文（推荐）：使用
--background "context"或-b "context"提供业务上下文以获得更好的审查质量 - 默认（无用户参数）：审查暂存、未暂存和未跟踪的更改（工作区模式）
- 特定提交：使用
--commit或-c审查单个提交与其父提交的差异 - 分支比较：使用
--from <ref>和--to <ref>审查两个引用之间的差异 - 超时：默认超时为每个文件 10 分钟；使用
--timeout <minutes>调整 - 并发：默认并发数为 8 个文件工作线程；如果遇到速率限制，使用
--concurrency <n>减少 - 预览模式：使用
--preview或-p预览将要审查的文件，而不运行 LLM - 安装：如果找不到
ocr命令，通过运行npm i -g @alibaba-group/open-code-review安装
常用调用模式：
| 用户说 | 要运行的命令 |
|---|---|
| "review my changes" / "review the working copy" | ocr review --audience agent -b "context" |
| "review this PR" / "review feature branch" | ocr review --audience agent -b "context" --from main --to <branch> |
| "review commit abc123" | ocr review --audience agent -b "context" --commit abc123 |
| "what would be reviewed?" (dry-run) | ocr review --preview |
输出模式：
- 始终使用
--audience agent以抑制进度 UI 并仅输出最终摘要
步骤 3：分类并报告
对于审查输出中的每条评论，按优先级分类并向用户报告所有问题：
- 高：明显的错误、安全问题、明显错误或具有精确修复建议的合理建议
- 中：合理的关注点但依赖于上下文、风格/性能建议或需要手动实现的修复
- 低：可能是误报、缺乏足够上下文、吹毛求疵或无意义的建议
按优先级级别分组报告所有评论。
步骤 4：修复
在应用修复之前，检查用户是否请求了自动修复：
- 如果用户明确要求“review and fix”或类似内容，则继续自动修复
- 如果用户只要求“review”而没有修复意图，则在应用任何更改前请求许可
修复问题和建议时：
- 专注于高优先级和中优先级的项目
- 在安全且定义明确的情况下直接对代码应用修复
- 对于需要手动干预的复杂修复，清楚描述需要做什么
- 在提交之前始终与用户确认修复
输出格式
每条评论包含：
path：文件路径content：审查评论文本start_line/end_line：行范围（两者均为 0 表示定位失败）suggestion_code：可选的修复建议existing_code：可选的原始代码片段thinking：可选的 LLM 推理过程
按优先级过滤评论后，使用以下模板呈现结果：
## 代码审查结果
**审查的文件数**：N
**发现的问题**：X 个高优先级 / Y 个中优先级
### 高优先级
- **`path/to/file.java:42`** — 简要描述
> 建议：如何修复
### 中优先级
- **`path/to/file.ts:88`** — 简要描述
> 建议：如何修复（如果适用）
如果过滤后未发现任何问题，只需说明：“审查完成——在 N 个文件中未发现问题。”
优先级分类：
- 高：明显的错误、安全问题、明显错误或具有精确修复建议的合理建议
- 中：合理的关注点但依赖于上下文、风格/性能建议或需要手动实现的修复
- 低：静默丢弃（可能是误报、缺乏上下文、吹毛求疵或无意义的建议）
处理定位错误的评论：
当 start_line 和 end_line 均为 0 时，评论未能定位到文件中的确切位置。在这种情况下：
- 阅读评论内容以理解问题
- 检查评论中提到的目标文件
- 根据评论的上下文识别相关的代码段
- 将修复或建议应用到正确的位置
自定义审查规则
如果用户想要项目特定的规则，OCR 按以下优先级顺序解析：
--rule <path>标志（最高）<repo>/.opencodereview/rule.json~/.opencodereview/rule.json- 内置系统默认值（最低）
默认情况下，第一个匹配的用户规则会替换内置的系统规则。当匹配的系统规则和用户规则都应包含时，在规则条目上设置 merge_system_rule: true。
规则文件格式：
{
"rules": [
{
"path": "**/*.java",
"rule": "所有新方法必须验证必需参数是否为 null",
"merge_system_rule": true
},
{
"path": "**/*mapper*.xml",
"rule": "检查 SQL 是否存在注入风险和缺少闭合标签"
}
]
}
要在审查前预览哪个规则适用于文件：
ocr rules check src/main/java/com/example/Foo.java
注意事项
- 必须首先配置 LLM — 如果无法访问 LLM，
ocr review会大声失败。在首次审查前始终运行ocr llm test。 - 工作目录很重要 —
ocr review对当前目录的 Git 仓库进行操作。使用--repo /path/to/repo从其他位置运行。 - 工作区模式下会审查未跟踪的文件 — 直接运行
ocr review会包括暂存、未暂存和未跟踪的更改。如果需要更窄的范围，请选择性暂存。 - 大型 diff 可能达到令牌限制 — 非常大的 diff 文件可能会被截断。默认的
MAX_TOKENS为每个请求 58888。 - 计划阶段在 50 行触发 — 超过 50 行更改的 diff 会在主审查之前运行额外的风险分析阶段。这会增加延迟但提高质量。
- 不要传递
--audience human— 它会流式传输进度 UI，污染输出。始终使用--audience agent。 - 评论语言遵循配置 — 将
language配置设置为English或Chinese（默认：Chinese）以控制审查评论的语言。
验证
审查完成后，通过检查以下内容验证成功：
- 命令以退出码 0 结束
- 生成了评论（或出现“No comments generated”消息）
- 警告（如果有）显示在 stderr 中
如果发生错误，请检查 stderr 警告以了解哪些文件失败及其原因。
