我怎么用 OCR 审 FFmpeg 的 PR

用 OCR 审 FFmpeg 的 PR，不需要改 OCR 源码——它是纯配置化的：CLI 只需要一个 Git 仓库 + 一个 diff，PR 的 checkout/fetch 交给 git 或 GitHub Action。下面给两条路径。

路径 A：本地 CLI 审 FFmpeg PR（最省事）

OCR 不认"PR"这个概念，它认 git ref。把 PR 头拉下来就能审： 1

git clone https://code.ffmpeg.org/FFmpeg/FFmpeg.git && cd FFmpeg

# 把 PR #123 的头和 merge-base 基准拉下来
git fetch origin pull/123/head:pr-123
git fetch origin master

ocr review --from origin/master --to pr-123

--from/--to 会自动算 merge-base(master, pr-123)..pr-123，只审这个 PR 引入的 diff。 2 想先不花 token 看看会审哪些文件：ocr review --from origin/master --to pr-123 --preview。 3

注意：上游 FFmpeg 实际是邮件列表工作流（ffmpeg-devel + git send-email），GitHub 上的 FFmpeg/FFmpeg 只是镜像，PR 基本不被合并。如果你审的是邮件列表 patch，同样适用——git am 把 patch 应用成 commit 后用 --commit 或 range 模式审即可。

路径 B：GitHub Action 自动审（适合自维护的 FFmpeg fork）

仓库里自带可复用 composite action（action.yml）和示例 workflow examples/github_actions/ocr-review.yml。在你 fork 的 FFmpeg 仓库里： 4

mkdir -p .forgejo/workflows
curl -o .forgejo/workflows/ocr-review.yml \
  https://raw.githubusercontent.com/alibaba/open-code-review/main/examples/github_actions/ocr-review.yml

然后配 secrets：OCR_LLM_URL、OCR_LLM_AUTH_TOKEN、OCR_LLM_MODEL（Anthropic 再设 OCR_LLM_USE_ANTHROPIC=true）。workflow 触发于 pull_request_target（fork PR 也能拿到 secrets，且只读 diff 不执行 PR 代码）和 /open-code-review 评论重跑；action 内部会 checkout base、git fetch pull/<N>/head、算 merge-base、跑 review、把发现以 inline review comment 回帖到 PR。 5 6

大型 PR 建议开 checkpoint_range: true + sticky_summary：每次 push 后只审 <上次 checkpoint>..<新 head> 的增量，而不是整个 PR 重审。 7

针对 FFmpeg 这种 C 大仓库的关键配置

1. 项目级评审规则

FFmpeg 有自己的编码规范（缩进风格、av_malloc/av_free 配对、AVERROR 错误码、ff_/av_ 前缀约定、DECLARE_ALIGNED、汇编优化等）。写进 <repo>/.opencodereview/rule.json 提交到 fork： 8

{
  "exclude": ["fate/**", "tests/ref/**", "doc/*.texi", "VERSION", "Changelog"],
  "rules": [
    {
      "path": "libavcodec/**/*.c",
      "rule": "Check av_malloc/av_free pairing, buffer overreads in bitstream parsing (GetBitContext bounds), AVERROR propagation, and that new decoders set correct capabilities flags."
    },
    {
      "path": "libavcodec/**/*_template.c",
      "rule": "This is a #include'd template file; review against the including compilation unit."
    },
    {
      "path": "**/*.{asm,S}",
      "rule": "Check x86 asm for correct clobber lists, stack alignment (16-byte), and cpuflags gating matching init code."
    },
    {
      "path": "libavutil/**/*.h",
      "rule": "Public headers: check version bump in version.h, API deprecation attributes, and doxygen @param completeness."
    }
  ]
}

exclude 把 FATE 测试数据和文档踢出去能省大量 token；规则按 glob 匹配文件路径，命中后注入该文件的评审 prompt。可用 ocr rules check libavcodec/h264.c 验证哪条规则生效。 9

2. 背景上下文

--background-file 注入需求背景到 plan + main prompt——对 FFmpeg 可以指向 doc/developer.texi 的精简版或 PR 描述： 10

ocr review --from origin/master --to pr-123 \
  --background-file ./ffmpeg-review-context.md

3. 成本与规模控制

FFmpeg 单文件动辄几千行，一个 PR 可能改几十个文件：

4. 结果回帖

本地 CLI 不自动回帖。要发到 GitHub PR 上，用 --format json --audience agent 拿结构化输出，自己走 GitHub API 或 gh CLI 回帖（action 已内置这套逻辑）。sarif 格式可直接喂给 GitHub Code Scanning。 13

总结：真正要"改造"的不是代码，而是 (1) 用 git fetch pull/N/head 把 PR 转成 git ref 区间，(2) 一份针对 C/汇编的 rule.json，(3) CI 场景直接复用仓库自带的 action.yml。如果想审的不是 GitHub PR 而是邮件列表 patch，同样 git am 落成本地 commit 再审即可。