PR Review / 代码评审

结论

CC 把评审做成了产品矩阵：/review 是本地纯 prompt 命令（gh CLI 拉 PR + 通用评审清单）；/security-review 是带工具白名单的安全专审，明文要求「>80% 置信才报」；/code-review ultra（即 ultrareview）把仓库打包上传到 Claude Code on the web，跑一支 reviewer agent 舰队并对每个 finding 做独立复现验证；最上层是托管的 GitHub Code Review 服务——@claude review 评论触发、严重度三档（🔴 Important / 🟡 Nit / 🟣 Pre-existing）、check run 永远 neutral 不卡 merge、并留了 bughunter-severity 机器可读尾注供自建门禁。Codex 则是一条任务管线：ReviewTask 在 core 内作为独立 session task 类型，入口有三个（TUI /review、codex exec review --uncommitted|--base|--commit、app-server review/start），评审准则是一份可覆盖的 rubric 模板（「只报作者会修的 bug、不报 pre-existing」）；另有一套容易混淆的 guardian auto-review——那是给危险操作审批做的自动安全评估，不是代码评审。两家都把「降噪/置信度过滤」写进了 prompt 层而非后处理层。

研究问题

• CC 的本地评审、云端 ultrareview、托管 Code Review 三层各自的机制与边界？
• Codex review 在源码里是怎样一条管线？rubric 怎么控制 finding 质量？
• 置信度过滤各自怎么做？GitHub 集成的机制差异？

各 Agent 设计与实现

Claude Code

第一层：本地 /review [一手源码]。纯 prompt 命令：无参时 gh pr list，给定 PR 号则 gh pr view + gh pr diff，按固定清单（correctness/conventions/performance/tests/security）产出评审（src_2026-03-31/commands/review.ts 的 LOCAL_REVIEW_PROMPT）。源码注释强调「/ultrareview is the ONLY entry point to the remote bughunter path — /review stays purely local」（review.ts:44-46）。

第一层变体：/security-review [一手源码]。markdown 定义命令，frontmatter 限定 allowed-tools: Bash(git diff:*), ... Read, Glob, Grep, LS, Task，用 !命令内联注入 git status/diff/log；置信度过滤直接写进指令：「MINIMIZE FALSE POSITIVES: Only flag issues where you're >80% confident of actual exploitability」，并显式排除 DoS、落盘秘钥、限流类问题（commands/security-review.ts 的 SECURITY_REVIEW_MARKDOWN）。

第二层：ultrareview（/code-review ultra） [一手文档]。在 Claude Code on the web 的远程沙箱里「launches a fleet of reviewer agents」；相对本地 /review 的三个卖点：每个 finding 被独立复现验证（higher signal）、并行多 agent 覆盖面更广、不占本地资源（claude-code-docs/docs/ultrareview.md）。无参审「当前分支 vs 默认分支 + 未提交改动」（本地打 bundle 上传），传 PR 号则远端直接 clone PR；要求 Claude.ai 登录，Bedrock/Vertex/Foundry 与 ZDR 组织不可用；按 usage credits 计费、研究预览期有免费次数。源码侧有配额对话框与开关（commands/review/ultrareviewCommand.tsx、ultrareviewEnabled.ts、services/api/ultrareviewQuota.ts）[一手源码]。

第三层：托管 GitHub Code Review [一手文档]（claude-code-docs/docs/code-review.md）：

• 触发：PR 打开 / 每次 push / 手动 @claude review（订阅后续 push）与 @claude review once（一次性）；Team/Enterprise 研究预览。
• 机制：多个专项 agent 并行分析 diff + 周边代码，「a verification step checks candidates against actual code behavior to filter out false positives」，去重、按严重度排序后发 inline 评论。
• 严重度：🔴 Important / 🟡 Nit / 🟣 Pre-existing 三档；每条评论预挂 👍👎 供一键反馈，反馈用于调优 reviewer。
• 门禁哲学：check run「always completes with a neutral conclusion so it never blocks merging」；要自建门禁就解析 Details 尾部的机器可读注释：bughunter-severity: {"normal":2,"nit":1,"pre_existing":0}（文档给了 gh api ... --jq 的解析命令）。
• 定制：读仓库里的 CLAUDE.md 与 REVIEW.md 两个引导文件。
• 自建 CI 替代：用 anthropics/claude-code-action（见 headless 章）+ gh pr diff | claude -p --append-system-prompt "You are a security engineer..." 的管道模式（headless.md:224-230）。注意 @claude（Actions，可改代码/建 PR）与 Code Review（托管只评审服务）是两个产品：前者跑在你的 runner 上由 workflow 文件控制，后者跑在 Anthropic 基础设施上由 admin 设置页控制（code-review.md 开头与 github-actions.md 互链）。

反馈闭环与线程自动解决 [一手文档]：push 触发模式下，修复被标记的问题再 push，「the next run resolves the thread when the issue is fixed」；回复 inline 评论不会让 Claude 响应或更新 PR——动作语义只有「改代码 push」或「@claude review once 重审」（code-review.md Rate and reply 节）。这种「评论不可对话」的设计把评审产物固定为单向报告，避免 PR 线程变成聊天室。

Codex CLI

入口三件套，汇到同一条 ReviewTask 管线 [一手源码]：

1. TUI /review：slash 命令枚举里 Review（描述 "review my current changes and find issues"），支持内联参数（tui/src/slash_command.rs:30,88,154）。
2. CLI codex exec review：参数互斥的三种目标——--uncommitted（staged+unstaged+untracked）、--base BRANCH、--commit SHA [--title]，还可给自定义 prompt（exec/src/cli.rs:265-298）。协议层对应 ReviewTarget::{UncommittedChanges, BaseBranch, Commit}（protocol/src/protocol.rs:3005-3012）。
3. app-server review/start：给 IDE/SDK 用的同款入口（app-server-protocol/src/protocol/common.rs:812-815）。

执行模型：ReviewTask 是独立的 TaskKind::Review session task，经 run_codex_thread_one_shot 以子线程一次性跑完，评审过程以 EnteredReviewMode/ExitedReviewMode(ReviewOutputEvent) 事件进出（core/src/tasks/review.rs:33-60；protocol.rs:1290-1293）；输出经 format_review_findings_block 渲染成 findings 块（core/src/review_format.rs）[一手源码]。

质量控制在 rubric 模板（prompts/templates/review/rubric.md）[一手源码]，要点：bug 必须「discrete and actionable」、「introduced in the commit (pre-existing bugs should not be flagged)」、「one must identify the other parts of the code that are provably affected」（不许凭空猜测影响面）；评论要求 ≤1 段、代码片段 ≤3 行、语气 matter-of-fact、禁止 "Great job..." 式恭维；finding 数量准则是「输出所有作者知道后一定会修的，宁缺毋滥」。模板明示可被 developer/user message 的更具体 guideline 覆盖——定制机制与 CC 的 REVIEW.md 同构但在 prompt 拼装层。

容易混淆的 guardian auto-review [一手源码]：core/src/guardian/review.rs 是「automatic review for approval prompts」（feature flag 注释，features/src/lib.rs:194）——用一个 guardian reviewer 子会话自动评估危险命令审批（输出 GuardianRiskLevel/决策，带拒绝后熔断与 /approve 重试，tui/src/auto_review_denials.rs）。这是审批安全评估，不是 PR 评审；app-server 通知名 item/autoApprovalReview/*（common.rs:1541-1542）。

评审输出的结构：协议层有专门的 ReviewOutputEvent（ExitedReviewModeEvent.review_output，protocol/src/protocol.rs:1776-1777），评审子会话以 SubAgentSource::Review 标记（protocol.rs:2547,2670），exec 侧用 render_review_output_text 渲染——即 findings 是结构化数据先于文本，harness 可在事件层直接拿 [一手源码]。中断的评审也有专门模板（prompts/templates/review/exit_interrupted.xml）。

GitHub 集成：本仓库内未见托管 PR 评审服务的代码；ChatGPT 网页端的 Codex code review 属云产品（无本地源码，[推断]/UNCONFIRMED）。CI 自建路线是 openai/codex-action + codex exec review --base origin/main（action 用法见 headless 章）。

差异矩阵

最小复现

# CC：本地 PR 评审（交互内）
claude
> /review 1234
> /security-review

# CC：CI 管道式安全评审（/review 类 skill 在 -p 下不可用，用描述替代）
gh pr diff 1234 | claude --bare -p \
  --append-system-prompt "You are a security engineer. Review for vulnerabilities." \
  --output-format json | jq -r '.result'

# Codex：三种 target 的评审（互斥，cli.rs:265-298）
codex exec review --uncommitted
codex exec review --base origin/main
codex exec review --commit abc1234 --title "fix: auth race"
# 自定义准则（prompt 与三种 target flag 互斥）
codex exec review "只关注并发与资源泄漏"

# CC 托管服务：在 PR 评论里
# @claude review        ← 评审并订阅后续 push
# @claude review once   ← 一次性评审，不订阅

# 自建门禁：解析 check run 的机器可读尾注
gh api repos/OWNER/REPO/check-runs/CHECK_RUN_ID \
  --jq '.output.text | split("bughunter-severity: ")[1] | split(" -->")[0] | fromjson'
# {"normal": 2, "nit": 1, "pre_existing": 0}

Harness 接入建议（Yoda 实践）

• Yoda 的 task 完成节点可以挂一个「评审站」：Codex 侧直接 codex exec review --base <defaultBranch> --json 跑在 task worktree 里（worktree 章），结构化消费 findings；CC 侧没有 headless 的 /review（skill 在 -p 不可用），用 git diff <base>... | claude --bare -p "<评审指令>" --json-schema <findings schema> 自建同构输出。
• findings 的 IR 建议直接抄 CC 托管服务的三档严重度（important/nit/pre_existing）——Codex rubric 的「不报 pre-existing」可映射为过滤第三档，两家输出能归一。
• 降噪不要在 harness 层做 LLM 二次过滤，先用两家已内置的 prompt 层门槛（CC 的 80% 置信、Codex rubric）；Yoda 只需做跨 run 去重（按 file:line + 指纹）。
• 不要把 Codex guardian auto-review 当评审能力接——它服务于审批安全，开启后会影响 Yoda 的审批流（拒绝熔断、/approve 重试语义）。

失效条件

• ultrareview 是研究预览：「pricing and availability may change」，命令已从 /ultrareview 迁到 /code-review ultra（旧名保留别名）——再次改名/收费变化需更新
• CC 托管 Code Review 限 Team/Enterprise、排除 ZDR；准入面变化（如开放个人版）影响选型建议
• bughunter-severity 尾注是非正式机器接口（HTML 注释解析），格式可能不打招呼变更
• Codex ReviewArgs/ReviewTarget 参数面（b89ce9a）与 rubric 模板内容随版本演进；guardian 系仍在 feature flag 后
• Codex 云端 review 的存在性本章标 UNCONFIRMED，取得一手证据后需改写

参考资料

• CC 源码（重构）：src_2026-03-31/commands/review.ts、commands/security-review.ts、commands/review/ultrareviewCommand.tsx、services/api/ultrareviewQuota.ts
• CC 文档：claude-code-docs/docs/code-review.md、ultrareview.md、headless.md:218-230、github-actions.md
• Codex 源码：codex-rs/exec/src/cli.rs:265-298、core/src/tasks/review.rs、prompts/templates/review/rubric.md、tui/src/slash_command.rs、core/src/guardian/review.rs、app-server-protocol/src/protocol/common.rs:812（@ b89ce9a）
• 交叉章节：chapters/workflow/headless-ci.md（claude-code-action / codex-action）、chapters/workflow/worktrees.md（评审跑在隔离 worktree）