github-pr-review

GitHub PR 评审

按严重程度优先级处理 Pull Request 评审评论、应用修复并回复讨论串。

当前 PR

!gh pr view --json number,title,state,milestone -q '"PR #\(.number): \(.title) (\(.state)) | Milestone: \(.milestone.title // "none")"' 2>/dev/null

核心工作流

1. 获取、筛选和分类评论

REPO=$(gh repo view --json nameWithOwner -q '.nameWithOwner')
PR=$(gh pr view --json number -q '.number')
LAST_PUSH=$(git log -1 --format=%cI HEAD)

# Inline review comments - filter out replies (keep only originals)
gh api repos/$REPO/pulls/$PR/comments?per_page=100 --jq '
  [.[] | select(.in_reply_to_id == null) |
   {id, path, user: .user.login, created_at, body: .body[0:200]}]
'

# PR-level reviews with non-empty body (CodeRabbit sections, Gemini, etc.)
gh api repos/$REPO/pulls/$PR/reviews?per_page=100 --jq '
  [.[] | select(.body | length > 0) |
   {id, user: .user.login, state, submitted_at, body: .body[0:500]}]
'

交叉核对附加到评审的评论：CodeRabbit 的评审正文会注明“Actionable comments posted: N”。如果通用的 pulls/$PR/comments 端点返回的该评审者新增原始评论少于 N 条，则部分评论只能通过评审专用端点获取。请获取这些评论，并按评论 ID 合并：

# $REVIEW_ID from the reviews fetch above; $EXPECTED from parsing "Actionable comments posted: N"
gh api repos/$REPO/pulls/$PR/reviews/$REVIEW_ID/comments?per_page=100 --jq '
  [.[] | select(.in_reply_to_id == null) |
   {id, path, user: .user.login, created_at, body: .body[0:200]}]
'

继续处理前，按 id 去重。仅通过评审专用端点找到的评论也是有效的行内评论，应采用相同方式处理（相同的分类方式、相同的 in_reply_to 回复机制）。

筛选新增评论与已查看评论：比较 $LAST_PUSH 与 created_at/submitted_at。上次推送后发布的评论属于新增评论。在摘要表中将更早的评论标记为“上一轮”。

解析 CodeRabbit 评审正文：初次获取的正文会被截断，无法用于分类。对于来自 CodeRabbit 的评审（user.login 以 coderabbitai 开头），请单独获取完整正文：

gh api repos/$REPO/pulls/$PR/reviews?per_page=100 --jq '
  [.[] | select(.user.login | startswith("coderabbitai")) |
   {id, submitted_at, body}]
'

CodeRabbit 会发布结构化的 <details> 区块，其中包含 diff 之外、重复和细枝末节的评论。每个区块都包含文件路径、行范围、严重程度，以及可选的预构建上下文“Prompt for AI Agents”。完整解析指南请参阅 references/coderabbit_parsing.md。

使用可用的 CodeRabbit AI 提示词：如果评论（或评审正文）包含“Prompt for AI Agents” <details> 区块，请用它了解问题和建议的处理方法。提出修复方案前，务必先阅读实际代码。如果评审正文包含“Prompt for all review comments with AI agents”区块，请先阅读该区块，了解跨评论的上下文，再处理单条评论。

按严重程度对所有评论分类，并按以下顺序处理：CRITICAL > HIGH > MEDIUM > LOW。

严重程度	指示标记	操作
CRITICAL	critical.svg、_🔒 Security_、_🚨 Critical_、_🔴 Critical_、“security”、“vulnerability”	必须修复
HIGH	high-priority.svg、_⚠️ Potential issue_、_🐛 Bug_、_⚡ Performance_、_🟠 Major_、“High Severity”	应当修复
MEDIUM	medium-priority.svg、_🛠️ Refactor suggestion_、_💡 Suggestion_、“Medium Severity”	建议处理
LOW	low-priority.svg、_🧹 Nitpick_、_🔧 Optional_、_🟡 Minor_、_🔵 Trivial_、_⚪ Info_、“style”、“nit”	可选处理

当评论同时包含类型标签和次级颜色徽标（例如 _💡 Suggestion_ | _🟠 Major_）时，以颜色徽标所表示的严重程度为准，覆盖基于类型的默认严重程度。

完整检测模式（Gemini 徽标、CodeRabbit 表情符号、Cursor 评论、关键词回退、相关评论启发式规则）请参阅 references/severity_guide.md。

2. 显示评审摘要表

开始处理前，以结构化方式概览所有评论：

| # | ID         | Severity | File:Line          | Type     | Status   | Summary            |
|---|------------|----------|--------------------|----------|----------|--------------------|
| 1 | 123456789  | CRITICAL | src/auth.py:45     | inline   | new      | SQL injection risk |
| 2 | 987654321  | HIGH     | src/db.py:346-350  | outside  | new      | Missing join cond  |
| 3 | 555555555  | HIGH     | src/chunk.py:188   | duplicate| previous | Stale metadata     |
| 4 | 444444444  | LOW      | tests/test_q.py:12 | nitpick  | previous | Naming convention  |

• 类型：inline（行内）、outside（diff 之外）、duplicate（重复）、minor（轻微）、nitpick（细枝末节，来自 CodeRabbit 区块）或 review（通用 PR 级评论）
• 状态：new（上次推送后发布）或 previous（来自更早轮次）
• 将相关评论分组（同一文件、同一根本原因、“also applies to”范围），并注明各组
• 去重：如果同一问题既出现在行内评论中，也出现在 CodeRabbit 评审正文区块中（例如重复评论），只保留一个条目，并注明两个来源

如果评论超过 10 条，建议将评审摘要保存到 Claude 的记忆中，以便跨会话跟踪。摘要应包含：PR 编号、评论 ID、严重程度、状态（new/addressed/deferred/won't fix）和简要说明。这样有助于在后续推送后收到新评论时保持上下文连贯。

3. 处理每条评论

按严重程度顺序处理每条评论：

1. 显示上下文：评论 ID、严重程度、文件:行号、引用内容
2. 检查 AI 提示词：如果 CodeRabbit 为此评论提供了“Prompt for AI Agents”，请使用它来了解问题和建议的处理方法
3. 检查拟议的修复：如果 CodeRabbit 包含“Proposed fix”或“Suggested fix”代码块，请以此为起点（但要验证其正确性）
4. 阅读受影响的代码并提出修复方案（即使 AI 提示词或拟议修复已提供相关上下文，也始终要阅读实际代码）
5. 处理“also applies to”：如果评论提及其他行范围，请将所有位置都纳入修复
6. 在应用前向用户确认
7. 获得批准后应用修复
8. 确认已解决评论中的所有问题（一条评论包含多个问题的情况很常见）

4. 提交更改

使用 git-commit 技能的格式。功能性修复分别提交，美观性修复合并提交：

更改类型	策略
功能性（CRITICAL/HIGH）	每项修复单独提交
美观性（MEDIUM/LOW）	合并为一个 style: 提交

在提交说明中引用评论 ID。

5. 回复评论串

行内评论

重要：使用 --input - 和 JSON。-f in_reply_to=... 语法不起作用。

COMMIT=$(git rev-parse --short HEAD)
gh api repos/$REPO/pulls/$PR/comments \
  --input - <<< '{"body": "Fixed in '"$COMMIT"'. Brief explanation.", "in_reply_to": 123456789}'

非行内评论（CodeRabbit 审查正文）

嵌入在审查正文中的评论（位于差异之外、重复评论、细枝末节）没有行内评论串。GitHub API 不支持直接回复审查正文。请发布一条常规 PR 评论，引用具体问题：

gh pr comment $PR --body "Fixed in $COMMIT. Addresses outside-diff comment on file/path.py:346-350."

回复模板（不使用表情符号，简洁且专业）：

情况	模板
已修复	Fixed in [hash]. [brief description of fix]
不予修复	Won't fix: [reason]
按设计如此	By design: [explanation]
延后处理	Deferred to [issue/task]. Will address in future iteration.
已确认	Acknowledged. [brief note]

6. 运行测试并推送

运行项目测试套件。推送前必须确保所有测试通过。将所有修复一起推送，以尽量减少审查往返。

7. 提交审查（可选）

处理完所有评论后，正式提交审查：

• gh pr review $PR --approve --body "..." - 所有评论均已处理，PR 已准备就绪
• gh pr review $PR --request-changes --body "..." - 仍存在关键问题
• gh pr review $PR --comment --body "..." - 更新进度，暂不做决定

8. 确认里程碑

gh pr view $PR --json milestone -q '.milestone.title // "none"'

如果 PR 没有关联里程碑，请检查是否有未关闭的里程碑：

REPO=$(gh repo view --json nameWithOwner -q '.nameWithOwner')
gh api repos/$REPO/milestones --jq '[.[] | select(.state=="open")] | .[] | "\(.number): \(.title)"'

如果存在未关闭的里程碑，请告知用户并建议进行关联：

gh pr edit $PR --milestone "[milestone-title]"

请勿自动关联。这只是提醒。

避免审查往返

当机器人（Gemini、Codex 等）会在每次推送后进行审查时：

1. 合并修复：累积所有修复后一次推送
2. 草稿 PR：修复期间将 PR 转为草稿
3. 提交关键词：某些机器人会遵循 [skip ci] 或 [skip review]

重要规则

• 始终获取行内评论（pulls/$PR/comments）和评审正文（pulls/$PR/reviews）
• 始终将“Actionable comments posted: N”与找到的原始评论进行交叉核对；如果数量不一致，则获取 pulls/$PR/reviews/$REVIEW_ID/comments
• 始终解析 CodeRabbit 评审正文中的所有类型章节（diff 范围外、重复、次要、细枝末节）
• 始终在有可用内容时，将 CodeRabbit 的“Prompt for AI Agents”作为主要上下文
• 始终在开始处理前显示评审摘要表
• 始终在修改文件前征求确认
• 始终确认多问题评论中的所有问题均已修复，包括“also applies to”范围
• 始终在推送前运行测试
• 始终使用标准模板回复已解决的讨论串
• 始终在处理完所有评论后提交正式评审（gh pr review）
• 始终在最后检查里程碑，并在缺失时提醒
• 始终在评论超过 10 条时，建议将评审摘要保存到记忆中
• 绝不在提交信息或讨论串回复中使用表情符号
• 绝不在未获得用户明确许可时跳过 HIGH/CRITICAL 评论
• 绝不自动分配里程碑——只提出建议
• 功能修复 -> 分开提交（每项修复一个提交）
• 外观修复 -> 合并到一个 style: 提交中
• 重复评论 -> 将其视为高于其标签所示的优先级（该问题此前已经被标记过）
• 相关评论 -> 如果根本原因或文件上下文相同，则将其归组并一并修复

参考资料

• references/severity_guide.md - 严重性检测模式（Gemini 徽章、CodeRabbit 表情符号、Cursor 评论、关键词回退、相关评论启发式规则）
• references/coderabbit_parsing.md - CodeRabbit 评审正文结构、章节解析、“Prompt for AI Agents”的用法，以及重复评论和“also applies to”的处理方式