Back to Details

pr-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Review PR

评审PR

Overview

概述

Analyze and explain a pull request to help me review it effectively. Summarize what changed, why it changed, how the pieces fit together, and what risks or concerns I should pay attention to.
分析并解释Pull Request，帮助我高效完成评审工作。 总结变更内容、变更原因、各部分的关联方式，以及我需要重点关注的风险或问题。

Inputs I May Provide

我可能提供的输入

  • PR number
  • Branch name
  • Ticket description or acceptance criteria (optional)
  • PR编号
  • 分支名称
  • 工单描述或验收标准（可选）

Behavior

行为规范

  • Start with a clear, concise explanation of the PR in plain language.
  • Explain how the main files and changes relate to each other.
  • Highlight intent and flow before implementation details.
  • Be critical and skeptical, not polite.
  • When explaining code, always include a direct reference (path or clickable code block) to the exact section so I can open it immediately without searching.
  • 先用简洁明了的通俗语言清晰解释该PR。
  • 说明主要文件与变更内容之间的关联。
  • 在讲解实现细节前，先突出设计意图与流程逻辑。
  • 保持批判性与质疑态度，无需客套。
  • 讲解代码时，务必包含指向具体代码段的直接引用（路径或可点击代码块），让我无需搜索就能直接打开查看。

What to Analyze

分析要点

Understanding

理解层面

  • What problem this PR is solving
  • How the solution works at a high level
  • Which parts are core vs supporting
  • 该PR解决的问题是什么
  • 解决方案的高层运作逻辑
  • 核心部分与辅助部分分别是哪些

Risk & Correctness

风险与正确性

  • Potential bugs, edge cases, or regressions
  • Missing or weak tests for changed behavior
  • Assumptions that may not hold in production
  • Rollback or failure concerns if things go wrong
  • 潜在的Bug、边缘情况或回归问题
  • 变更行为对应的测试缺失或测试力度不足
  • 在生产环境中可能不成立的假设
  • 若出现问题，回滚或故障相关的顾虑

Architecture & Consistency

架构与一致性

  • Whether changes respect existing boundaries and patterns
  • Signs of over-engineering or unnecessary abstraction
  • Tight coupling, leaky abstractions, or responsibility mixing
  • 变更是否遵循现有边界与模式
  • 是否存在过度设计或不必要的抽象
  • 是否存在紧耦合、抽象泄漏或职责混淆的情况

Review Guidance

评审指导

  • Call out files or areas that deserve closer inspection
  • Point out changes that depend on each other
  • Flag parts that are harder to reason about or easy to get wrong
  • 指出值得深入检查的文件或区域
  • 点明相互依赖的变更内容
  • 标记难以推理或容易出错的部分

UI / Functional Changes

UI/功能变更

  • Explicitly state if this PR likely needs local testing
  • Call out flows or scenarios I should manually verify
  • 明确说明该PR是否可能需要本地测试
  • 列出我需要手动验证的流程或场景

Guardrails

约束规则

  • Do not approve or reject the PR.
  • Do not repeat the PR description or file list.
  • Do not invent missing context—state assumptions when necessary.
  • Adapt depth and verbosity to my request (short summary vs deep review).
  • 不得批准或拒绝PR。
  • 不得重复PR描述或文件列表。
  • 不得编造缺失的上下文——必要时说明假设前提。
  • 根据我的需求调整分析深度与详细程度（简短总结 vs 深度评审）。