open-code-review diff Provider 详解Workspace、Commit、Range 三种模式完整指南【免费下载链接】open-code-reviewFast, efficient, battle-tested at Alibabas scale. Hybrid architecture code review tool: deterministic pipelines LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI Anthropic compatible.项目地址: https://gitcode.com/GitHub_Trending/op/open-code-reviewOpenCodeReviewopen-code-review是一款阿里巴巴开源的 AI 代码评审 CLI 工具其核心是确定性流水线 LLM Agent的混合架构。它通过 diff Provider 从 Git 仓库中精准提取变更再交给 LLM 生成行级精确的评审评论。diff Provider 提供了Workspace工作区、Commit单提交、Range区间三种模式分别对应 commit 前自查、复查历史提交和分支对比三大场景。掌握这三种模式的差异是高效使用 OCR 的第一步。diff Provider 是什么diff Provider 是 OCR 的取数层源码位于 internal/diff/git.go它定义了三种模式常量const ( ModeWorkspace Mode iota // 当前工作区staged unstaged untracked ModeCommit // 单个 commit 相对其父提交 ModeRange // merge-base(from,to)..to )它的工作职责很清晰组装 git diff调用git diff/git show等命令统一附加--find-renames、-U33 行上下文等参数保证 diff 格式稳定可解析过滤噪声文件内置.git/、node_modules/、target/等硬编码黑名单并解析项目 .gitignore与 git 一致的最后匹配生效语义冻结输入端点ResolveInput 会把本次运行的 base/head 解析成不可变 SHA供断点续审--resume时严格校验评审对象没变。CLI 层的模式判定逻辑在 internal/tool/filereader.go传了--commit就是 Commit 模式--from和--to同时传就是 Range 模式都不传则回落到 Workspace 模式。三种模式参数互斥混用会直接报错。三种模式逐一拆解1. Workspace 模式默认commit 前自查ocr review不传任何模式参数时OCR 默认进入 Workspace 模式评审当前仓库中所有未提交变更。它是两条 git 命令的组合实现见 workspaceTrackedDiff变更来源获取方式staged unstaged 已跟踪变更git diff HEAD若无 HEAD 则回退git diff --staged支持尚无提交的新仓库untracked 新文件git ls-files --others --exclude-standard从磁盘读取并整体作为新增文件适用场景写代码过程中随时自查、git commit前最后一道质检。如果想只评审一部分变更可以先选择性git add暂存。一个细节Workspace 模式下 Agent 读取文件内容走的是磁盘见 FileReader.Read而 Commit/Range 模式走git show ref:path读取历史版本——这样 Agent 看到的上下文与 diff 所描述的代码版本永远一致不会出现diff 是旧代码、上下文是新代码的错位。2. Commit 模式精准复查单个提交ocr review --commit abc123 ocr review -c abc123Commit 模式评审git show abc123产生的 diff即该提交引入的变更。这里有一个容易踩坑的点merge commit 的处理。普通的git show对合并提交会输出 combined diffdiff --cc格式解析器无法处理该提交会静默产出 0 条评审。因此 OCR 显式附加--diff-mergesfirst-parent让合并提交相对第一个父提交生成标准 unified diff见 internal/diff/git.go。适用场景CI 流水线中对每一次 push 的提交做门禁、复盘某次事故提交改了什么。3. Range 模式分支对比只看你引入的ocr review --from main --to feature-branchRange 模式是功能分支合并评审的主力。关键在于它不是简单的main..feature-branch而是先计算merge-base(main, feature-branch)再对比merge-base..feature-branch见 computeMergeBase。为什么要多这一步假设分支切出后main上又合入了别人的 20 个提交直接main..feature对比会把这 20 个无关变更也算进来而 merge-base 模式只呈现你的分支真正引入的 diff评审噪音大幅降低。适用场景MR/PR 合入前评审、CI 中自动评审功能分支。三种模式速查表WorkspaceCommitRange触发命令ocr review默认ocr review -c shaocr review --from A --to B评审对象未提交变更含 untracked单个提交的变更分支自 merge-base 起的引入变更merge commit不涉及相对第一父提交评审不涉及文件读取来源磁盘工作树git show commit:pathgit show to:path支持--resume断点续审❌✅✅典型场景提交前自查提交门禁、复盘MR/PR 评审提示Range 与 Commit 模式的评审会话支持断点续审。运行被中断后用ocr session list找到会话 ID再执行ocr review --from main --to dev --resume session-id已完成的文件检查点会被复用。恢复逻辑非常严格——只有本次运行对象与父运行完全一致同样的提交端点、规则集、provider/model时才会复用 checkpoint避免半新半旧的评审结果。一次评审的完整流程无论哪种模式拿到 diff 之后都会走同一条确定性流水线文件筛选按扩展名白名单、路径规则、token 预算过滤ocr review --preview可先预览选中哪些文件智能分组语义相关的文件如中英文properties文件打包为一个评审单元规则匹配每个文件按四层规则链custom → project → global → system匹配内建规则文档覆盖 NPE、线程安全、XSS、SQL 注入等问题类型规则源码见 internal/config/rules/rule_docs/Agent 评审每组分发一个子 agent 并发执行默认 8 路并发Agent 可调用读文件、代码搜索等工具获取上下文定位与反思独立模块校正评论行号定位、过滤低质评论最终输出带行号范围和修复建议的结构化评论。常见实战组合日常开发ocr review提交前自查配合--effort high加大投入档位大分支合入ocr review --from main --to feature --format json --audience agent把结果交给 CI 或上游 Agent 消费带上下文评审加上--background 给登录接口加限流或--background-file ./docs/requirements.md把需求背景注入 prompt这是提升评审质量最有效的手段之一全文件审计没有有意义的 diff 时改用ocr scan直接扫描完整文件无需 Git 历史。延伸阅读CLI 参数完整参考pages/src/content/docs/zh/cli-reference.mddiff Provider 核心实现internal/diff/git.go、internal/diff/parser.go文件读取模式实现internal/tool/filereader.go项目主文档README.md选对模式评审就有边界Workspace 守好提交前最后一关Commit 把住每一次入库Range 让 MR 评审只聚焦你写的代码。【免费下载链接】open-code-reviewFast, efficient, battle-tested at Alibabas scale. Hybrid architecture code review tool: deterministic pipelines LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI Anthropic compatible.项目地址: https://gitcode.com/GitHub_Trending/op/open-code-review创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
open-code-review diff Provider 详解：Workspace、Commit、Range 三种模式完整指南
open-code-review diff Provider 详解Workspace、Commit、Range 三种模式完整指南【免费下载链接】open-code-reviewFast, efficient, battle-tested at Alibabas scale. Hybrid architecture code review tool: deterministic pipelines LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI Anthropic compatible.项目地址: https://gitcode.com/GitHub_Trending/op/open-code-reviewOpenCodeReviewopen-code-review是一款阿里巴巴开源的 AI 代码评审 CLI 工具其核心是确定性流水线 LLM Agent的混合架构。它通过 diff Provider 从 Git 仓库中精准提取变更再交给 LLM 生成行级精确的评审评论。diff Provider 提供了Workspace工作区、Commit单提交、Range区间三种模式分别对应 commit 前自查、复查历史提交和分支对比三大场景。掌握这三种模式的差异是高效使用 OCR 的第一步。diff Provider 是什么diff Provider 是 OCR 的取数层源码位于 internal/diff/git.go它定义了三种模式常量const ( ModeWorkspace Mode iota // 当前工作区staged unstaged untracked ModeCommit // 单个 commit 相对其父提交 ModeRange // merge-base(from,to)..to )它的工作职责很清晰组装 git diff调用git diff/git show等命令统一附加--find-renames、-U33 行上下文等参数保证 diff 格式稳定可解析过滤噪声文件内置.git/、node_modules/、target/等硬编码黑名单并解析项目 .gitignore与 git 一致的最后匹配生效语义冻结输入端点ResolveInput 会把本次运行的 base/head 解析成不可变 SHA供断点续审--resume时严格校验评审对象没变。CLI 层的模式判定逻辑在 internal/tool/filereader.go传了--commit就是 Commit 模式--from和--to同时传就是 Range 模式都不传则回落到 Workspace 模式。三种模式参数互斥混用会直接报错。三种模式逐一拆解1. Workspace 模式默认commit 前自查ocr review不传任何模式参数时OCR 默认进入 Workspace 模式评审当前仓库中所有未提交变更。它是两条 git 命令的组合实现见 workspaceTrackedDiff变更来源获取方式staged unstaged 已跟踪变更git diff HEAD若无 HEAD 则回退git diff --staged支持尚无提交的新仓库untracked 新文件git ls-files --others --exclude-standard从磁盘读取并整体作为新增文件适用场景写代码过程中随时自查、git commit前最后一道质检。如果想只评审一部分变更可以先选择性git add暂存。一个细节Workspace 模式下 Agent 读取文件内容走的是磁盘见 FileReader.Read而 Commit/Range 模式走git show ref:path读取历史版本——这样 Agent 看到的上下文与 diff 所描述的代码版本永远一致不会出现diff 是旧代码、上下文是新代码的错位。2. Commit 模式精准复查单个提交ocr review --commit abc123 ocr review -c abc123Commit 模式评审git show abc123产生的 diff即该提交引入的变更。这里有一个容易踩坑的点merge commit 的处理。普通的git show对合并提交会输出 combined diffdiff --cc格式解析器无法处理该提交会静默产出 0 条评审。因此 OCR 显式附加--diff-mergesfirst-parent让合并提交相对第一个父提交生成标准 unified diff见 internal/diff/git.go。适用场景CI 流水线中对每一次 push 的提交做门禁、复盘某次事故提交改了什么。3. Range 模式分支对比只看你引入的ocr review --from main --to feature-branchRange 模式是功能分支合并评审的主力。关键在于它不是简单的main..feature-branch而是先计算merge-base(main, feature-branch)再对比merge-base..feature-branch见 computeMergeBase。为什么要多这一步假设分支切出后main上又合入了别人的 20 个提交直接main..feature对比会把这 20 个无关变更也算进来而 merge-base 模式只呈现你的分支真正引入的 diff评审噪音大幅降低。适用场景MR/PR 合入前评审、CI 中自动评审功能分支。三种模式速查表WorkspaceCommitRange触发命令ocr review默认ocr review -c shaocr review --from A --to B评审对象未提交变更含 untracked单个提交的变更分支自 merge-base 起的引入变更merge commit不涉及相对第一父提交评审不涉及文件读取来源磁盘工作树git show commit:pathgit show to:path支持--resume断点续审❌✅✅典型场景提交前自查提交门禁、复盘MR/PR 评审提示Range 与 Commit 模式的评审会话支持断点续审。运行被中断后用ocr session list找到会话 ID再执行ocr review --from main --to dev --resume session-id已完成的文件检查点会被复用。恢复逻辑非常严格——只有本次运行对象与父运行完全一致同样的提交端点、规则集、provider/model时才会复用 checkpoint避免半新半旧的评审结果。一次评审的完整流程无论哪种模式拿到 diff 之后都会走同一条确定性流水线文件筛选按扩展名白名单、路径规则、token 预算过滤ocr review --preview可先预览选中哪些文件智能分组语义相关的文件如中英文properties文件打包为一个评审单元规则匹配每个文件按四层规则链custom → project → global → system匹配内建规则文档覆盖 NPE、线程安全、XSS、SQL 注入等问题类型规则源码见 internal/config/rules/rule_docs/Agent 评审每组分发一个子 agent 并发执行默认 8 路并发Agent 可调用读文件、代码搜索等工具获取上下文定位与反思独立模块校正评论行号定位、过滤低质评论最终输出带行号范围和修复建议的结构化评论。常见实战组合日常开发ocr review提交前自查配合--effort high加大投入档位大分支合入ocr review --from main --to feature --format json --audience agent把结果交给 CI 或上游 Agent 消费带上下文评审加上--background 给登录接口加限流或--background-file ./docs/requirements.md把需求背景注入 prompt这是提升评审质量最有效的手段之一全文件审计没有有意义的 diff 时改用ocr scan直接扫描完整文件无需 Git 历史。延伸阅读CLI 参数完整参考pages/src/content/docs/zh/cli-reference.mddiff Provider 核心实现internal/diff/git.go、internal/diff/parser.go文件读取模式实现internal/tool/filereader.go项目主文档README.md选对模式评审就有边界Workspace 守好提交前最后一关Commit 把住每一次入库Range 让 MR 评审只聚焦你写的代码。【免费下载链接】open-code-reviewFast, efficient, battle-tested at Alibabas scale. Hybrid architecture code review tool: deterministic pipelines LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI Anthropic compatible.项目地址: https://gitcode.com/GitHub_Trending/op/open-code-review创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
