pr-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

PyTorch PR Review Skill

PyTorch PR审查技能

Review PyTorch pull requests focusing on what CI cannot check: code quality, test coverage adequacy, security vulnerabilities, and backward compatibility. Linting, formatting, type checking, and import ordering are handled by CI.

针对PyTorch拉取请求（PR）进行审查，重点关注CI无法检查的内容：代码质量、测试覆盖率是否充分、安全漏洞及向后兼容性。代码检查（Linting）、格式规范、类型检查和导入排序由CI负责处理。

Usage Modes

使用模式

No Argument

无参数模式

If the user invokes

/pr-review

with no arguments, do not perform a review. Instead, ask the user what they would like to review:

What would you like me to review?
A PR number or URL (e.g.,
/pr-review 12345
)
A local branch (e.g.,
/pr-review branch
)

如果用户调用

/pr-review

时未传入任何参数，请勿执行审查操作。请询问用户想要审查的内容：

请问您想要我审查什么内容？
PR编号或URL（例如：
/pr-review 12345
）
本地分支（例如：
/pr-review branch
）

Local CLI Mode

本地CLI模式

The user provides a PR number or URL:

/pr-review 12345
/pr-review https://github.com/pytorch/pytorch/pull/12345

For a detailed review with line-by-line specific comments:

/pr-review 12345 detailed

Use

gh

CLI to fetch PR data:

bash

undefined

用户提供PR编号或URL：

/pr-review 12345
/pr-review https://github.com/pytorch/pytorch/pull/12345

如需包含逐行具体评论的详细审查：

/pr-review 12345 detailed

使用

gh

CLI获取PR数据：

bash

undefined

Get PR details

获取PR详情

gh pr view <PR_NUMBER> --json title,body,author,baseRefName,headRefName,files,additions,deletions,commits

Get the diff

获取差异内容

gh pr diff <PR_NUMBER>

Get PR comments

获取PR评论

gh pr view <PR_NUMBER> --json comments,reviews

undefined

gh pr view <PR_NUMBER> --json comments,reviews

undefined

Local Branch Mode

本地分支模式

Review changes in the current branch that are not in

main

/pr-review branch
/pr-review branch detailed

Use git commands to get branch changes:

bash

undefined

审查当前分支中与

main

分支不同的变更：

/pr-review branch
/pr-review branch detailed

使用git命令获取分支变更：

bash

undefined

Get current branch name

获取当前分支名称

git branch --show-current

Get list of changed files compared to main

获取与main分支相比有变更的文件列表

git diff --name-only main...HEAD

Get full diff compared to main

获取与main分支的完整差异内容

git diff main...HEAD

Get commit log for the branch

获取分支的提交日志

git log main..HEAD --oneline

Get diff stats (files changed, insertions, deletions)

获取差异统计信息（变更文件、插入行数、删除行数）

git diff --stat main...HEAD


For local branch reviews:
- The "Summary" should describe what the branch changes accomplish based on commit messages and diff
- Use the current branch name in the review header instead of a PR number
- All other review criteria apply the same as PR reviews

git diff --stat main...HEAD


针对本地分支的审查：
- “摘要”部分需根据提交信息和差异内容描述该分支变更的目标
- 审查标题中使用当前分支名称替代PR编号
- 其他所有审查标准与PR审查一致

GitHub Actions Mode

GitHub Actions模式

When invoked via workflow, PR data is passed as context. The PR number or diff will be available in the prompt.

当通过工作流调用时，PR数据会作为上下文传入。PR编号或差异内容将在提示信息中提供。

Review Workflow

审查流程

Step 1: Fetch PR Information

步骤1：获取PR信息

For local mode, use

gh

commands to get:

PR metadata (title, description, author)
List of changed files
Full diff of changes
Existing comments/reviews
Fetch associated issue information when applicable

在本地模式下，使用

gh

命令获取：

PR元数据（标题、描述、作者）
变更文件列表
完整的变更差异内容
已有的评论/审查记录
适用时获取关联的问题信息

Step 2: Analyze Changes

步骤2：分析变更

Read through the diff systematically:

Identify the purpose of the change from title/description/issue
Group changes by type (new code, tests, config, docs)
Note the scope of changes (files affected, lines changed)

系统地阅读差异内容：

从标题/描述/关联问题中识别变更的目的
按类型对变更进行分组（新代码、测试、配置、文档）
记录变更的范围（受影响的文件、变更的行数）

Step 3: Deep Review

步骤3：深度审查

Perform thorough line-by-line analysis using the review checklist. See review-checklist.md for detailed criteria covering:

Code quality and design
Testing adequacy
Security considerations
Thread safety and concurrency (Python, C++, CPython C API, NoGIL)
Performance implications
Any behavior change not expected by author

使用审查清单进行逐行细致分析。详细标准请参考review-checklist.md，涵盖：

代码质量与设计
测试充分性
安全考量
线程安全与并发（Python、C++、CPython C API、NoGIL）
性能影响
任何作者未预期的行为变更

Step 4: Check Backward Compatibility

步骤4：检查向后兼容性

Evaluate BC implications. See bc-guidelines.md for:

What constitutes a BC-breaking change
Required deprecation patterns
Common BC pitfalls

评估向后兼容性（BC）影响。详细标准请参考bc-guidelines.md，涵盖：

哪些情况属于破坏向后兼容性的变更
要求的弃用模式
常见的向后兼容性陷阱

Step 5: Formulate Review

步骤5：整理审查结果

Structure your review with actionable feedback organized by category.

按类别组织可执行的反馈意见，构建审查报告。

Review Areas

审查领域

Area	Focus	Reference
Code Quality	Abstractions, patterns, complexity	review-checklist.md
API Design	New patterns, flag-based access, broader implications	review-checklist.md
Testing	Coverage, patterns, edge cases	review-checklist.md
Security	Injection, credentials, input handling	review-checklist.md
Performance	Regressions, device handling, memory	review-checklist.md
Thread Safety	Data races, GIL assumptions, NoGIL, CPython C API	review-checklist.md
BC	Breaking changes, deprecation	bc-guidelines.md

领域	关注重点	参考文档
代码质量	抽象设计、模式、复杂度	review-checklist.md
API设计	新模式、基于标志的访问、广泛影响	review-checklist.md
测试	覆盖率、模式、边缘情况	review-checklist.md
安全性	注入风险、凭证处理、输入校验	review-checklist.md
性能	性能退化、设备处理、内存使用	review-checklist.md
线程安全	数据竞争、GIL假设、NoGIL、CPython C API	review-checklist.md
向后兼容性（BC）	破坏性变更、弃用策略	bc-guidelines.md

Output Format

输出格式

Structure your review as follows:

markdown

undefined

按以下结构整理审查结果：

markdown

undefined

PR Review: #<number>

PR审查：#<编号>

Branch Review: <branch-name> (vs main)

分支审查：<分支名称>（对比main分支）

Summary

摘要

Brief overall assessment of the changes (1-2 sentences).

对变更的整体简要评估（1-2句话）。

Code Quality

代码质量

[Issues and suggestions, or "No concerns" if none]

[存在的问题与建议，若无则填写“无相关问题”]

API Design

API设计

[Flag new patterns, internal-access flags, or broader implications if any. Otherwise omit this section.]

[标记新模式、内部访问标志或广泛影响（如有）。若无相关内容可省略此部分。]

Testing

测试

Tests exist for new functionality
Edge cases covered
Tests follow PyTorch patterns (TestCase, assertEqual) [Additional testing feedback]

新功能有对应的测试
覆盖了边缘情况
测试遵循PyTorch模式（TestCase、assertEqual） [额外的测试反馈]

Security

安全性

[Issues if any, or "No security concerns identified"]

[存在的问题（如有），若无则填写“未发现安全问题”]

Thread Safety

线程安全

[Threading concerns if any, or "No thread safety concerns"]

[存在的线程安全问题（如有），若无则填写“无线程安全问题”]

Backward Compatibility

向后兼容性

[BC concerns if any, or "No BC-breaking changes"]

[存在的向后兼容性问题（如有），若无则填写“无破坏向后兼容性的变更”]

Performance

性能

[Performance concerns if any, or "No performance concerns"]

[存在的性能问题（如有），若无则填写“无性能问题”]

Recommendation

建议

Approve / Request Changes / Needs Discussion

[Brief justification for recommendation]

undefined

批准 / 要求修改 / 需要讨论**

[建议的简要理由]

undefined

Specific Comments (Detailed Review Only)

具体评论（仅详细审查包含）

Only include this section if the user requests a "detailed" or "in depth" review.

Do not repeat observations already made in other sections. This section is for additional file-specific feedback that doesn't fit into the categorized sections above.

When requested, add file-specific feedback with line references:

markdown

undefined

仅当用户要求“detailed”（详细）或“in depth”（深入）审查时才包含此部分。

请勿重复已在其他部分提及的内容。 此部分用于补充不适合放入上述分类部分的、针对特定文件的反馈。

当用户要求时，添加带行号引用的文件特定反馈：

markdown

undefined

Specific Comments

具体评论

```
src/module.py:42
```
- Consider extracting this logic into a named function for clarity
```
test/test_feature.py:100-105
```
- Missing test for error case when input is None
```
torch/nn/modules/linear.py:78
```
- This allocation could be moved outside the loop

undefined

```
src/module.py:42
```
- 建议将此逻辑提取为命名函数以提升可读性
```
test/test_feature.py:100-105
```
- 缺失输入为None时的错误场景测试
```
torch/nn/modules/linear.py:78
```
- 此内存分配操作可移至循环外部

undefined

Key Principles

核心原则

No repetition - Each observation appears in exactly one section. Never repeat the same issue, concern, or suggestion across multiple sections. If an issue spans categories (e.g., a security issue that also affects performance), place it in the most relevant section only.
Focus on what CI cannot check - Don't comment on formatting, linting, or type errors
Be specific - Reference file paths and line numbers
Be actionable - Provide concrete suggestions, not vague concerns
Be proportionate - Minor issues shouldn't block, but note them
Assume competence - The author knows PyTorch; explain only non-obvious context

不重复 - 每个观察结果仅出现在一个部分。同一问题、关注点或建议切勿在多个部分重复提及。如果一个问题涉及多个分类（例如，同时影响性能的安全问题），仅将其放入最相关的分类部分。
聚焦CI无法检查的内容 - 请勿对格式、代码检查或类型错误发表评论
具体明确 - 引用文件路径和行号
可执行 - 提供具体的建议，而非模糊的担忧
适度合理 - 小问题不应阻碍审查通过，但需记录下来
假定能力 - 作者熟悉PyTorch，仅解释非显而易见的背景信息

Files to Reference

参考文件

When reviewing, consult these project files for context:

```
CLAUDE.md
```
- Coding style philosophy and testing patterns
```
CONTRIBUTING.md
```
- PR requirements and review process
```
torch/testing/_internal/common_utils.py
```
- Test patterns and utilities
```
torch/testing/_internal/opinfo/core.py
```
- OpInfo test framework

审查时，可参考以下项目文件获取上下文信息：

```
CLAUDE.md
```
- 编码风格理念和测试模式
```
CONTRIBUTING.md
```
- PR要求和审查流程
```
torch/testing/_internal/common_utils.py
```
- 测试模式和工具
```
torch/testing/_internal/opinfo/core.py
```
- OpInfo测试框架