Back to Details

review-pr

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
Note: If you have 
mcporter
installed locally, you should use 
mcporter
to invoke the MCP tool instead of directly calling the MCP tool. The 
mcporter
CLI provides a more convenient interface and better error handling.
注意：如果你本地已安装
mcporter
，应使用
mcporter
调用MCP工具，而非直接调用MCP工具。
mcporter
CLI提供了更便捷的界面和更完善的错误处理。

Review PR via Gitee MCP

借助Gitee MCP审查PR

Perform a thorough code review on a Pull Request in a Gitee repository.
对Gitee仓库中的拉取请求（PR）进行全面的代码审查。

Prerequisites

前置条件

  • Gitee MCP Server configured (tools: 
    get_pull_detail
    , 
    get_diff_files
    , 
    list_pull_comments
    , 
    comment_pull
    )
  • User must provide: repository owner, repository name, PR number (or say "review the latest PR")
  • Optional: If the current directory is the local clone of the PR's repository, you can leverage local git commands and file access to get more context.
  • 已配置Gitee MCP Server（工具：
    get_pull_detail
    、
    get_diff_files
    、
    list_pull_comments
    、
    comment_pull
    ）
  • 用户必须提供：仓库所有者、仓库名称、PR编号（或说明“审查最新的PR”）
  • 可选：如果当前目录是该PR对应仓库的本地克隆版本，你可以借助本地git命令和文件访问权限获取更多上下文信息。

Steps

步骤

Step 1: Fetch PR Details

步骤1：获取PR详情

Use 
get_pull_detail
to retrieve PR information, checking:
  • Whether the title and description clearly explain the purpose of the changes
  • Whether the source and target branches are correct
  • PR state (if already closed/merged, stop the review)
  • Whether it is a Draft — if so, notify the user
使用
get_pull_detail
获取PR信息，检查以下内容：
  • 标题和描述是否清晰说明变更的目的
  • 源分支和目标分支是否正确
  • PR状态（如果已关闭/合并，则停止审查）
  • 是否为草稿状态——如果是，通知用户

Step 2: Fetch Diff Files

步骤2：获取差异文件

Use 
get_diff_files
to get the list of changed files, analyzing:
  • Number and scope of changed files
  • Whether any sensitive files are involved (config files, secrets, permission-related code)
For each core changed file, use 
get_file_content
to read its content for context.
If running in the local repository directory, leverage local git commands and file access to gain additional context for the review (e.g., viewing related commits, related files, file history).
使用
get_diff_files
获取变更文件列表，分析：
  • 变更文件的数量和范围
  • 是否涉及敏感文件（配置文件、密钥、权限相关代码）
对于每个核心变更文件，使用
get_file_content
读取其内容以获取上下文。
如果在本地仓库目录中运行，可借助本地git命令和文件访问权限为审查获取额外上下文（例如，查看相关提交、关联文件、文件历史）。

Step 3: Check Existing Comments

步骤3：检查现有评论

Use 
list_pull_comments
to retrieve existing comments and avoid raising issues that have already been discussed.
使用
list_pull_comments
获取已有的评论，避免提出已讨论过的问题。

Step 4: Code Review

步骤4：代码审查

Review the code across these dimensions:
Correctness
  • Is the logic correct? Are edge cases handled?
  • Are there obvious bugs or null pointer risks?
  • Is error handling adequate?
Security
  • Are there SQL injection, XSS, command injection, or other security risks?
  • Is sensitive information hardcoded?
  • Are permission checks in place?
Maintainability
  • Are names clear and semantic?
  • Does each function/method have a single responsibility?
  • Are complex logic blocks documented with comments?
Performance
  • Are there unnecessary nested loops or N+1 queries?
  • Are large file operations mindful of memory usage?
Consistency
  • Does the code follow the existing project style?
  • Is it consistent with related modules?
从以下维度审查代码：
正确性
  • 逻辑是否正确？是否处理了边缘情况？
  • 是否存在明显的bug或空指针风险？
  • 错误处理是否充分？
安全性
  • 是否存在SQL注入、XSS、命令注入或其他安全风险？
  • 是否硬编码了敏感信息？
  • 是否有适当的权限检查？
可维护性
  • 命名是否清晰且具有语义化？
  • 每个函数/方法是否单一职责？
  • 复杂逻辑块是否配有注释说明？
性能
  • 是否存在不必要的嵌套循环或N+1查询？
  • 大文件操作是否考虑了内存使用情况？
一致性
  • 代码是否遵循现有项目的风格规范？
  • 是否与相关模块保持一致？

Step 5: Classify Issues

步骤5：问题分类

Classify findings by severity:
  • 🔴 Blocker: Affects correctness or has a security risk — must be fixed
  • 🟡 Suggestion: Code quality issue — recommended but not mandatory
  • 🟢 Optional: Nice-to-have improvement
按严重程度对发现的问题进行分类：
  • 🔴 阻塞问题：影响正确性或存在安全风险——必须修复
  • 🟡 建议优化：代码质量问题——推荐修复但非强制
  • 🟢 可选改进：锦上添花的优化点

Step 6: Post Review Comment

步骤6：发布审查评论

Use 
comment_pull
to post the review to the PR. Use this format:
undefined
使用
comment_pull
将审查结果发布到PR中。请使用以下格式：
undefined

Code Review

Code Review

Summary: [One sentence describing the purpose of the PR and overall quality assessment]
Summary: [One sentence describing the purpose of the PR and overall quality assessment]

🔴 Blockers

🔴 Blockers

  1. [filename:line] [Issue description]
    • Problem: [Specific explanation]
    • Suggestion: [How to fix it]
  1. [filename:line] [Issue description]
    • Problem: [Specific explanation]
    • Suggestion: [How to fix it]

🟡 Suggestions

🟡 Suggestions

  1. [filename] [Issue description]
    • Suggestion: [Direction for improvement]
  1. [filename] [Issue description]
    • Suggestion: [Direction for improvement]

🟢 Optional

🟢 Optional

  1. [Improvement suggestion]
  1. [Improvement suggestion]

Conclusion

Conclusion

[Overall assessment — LGTM or key changes needed]
🤖 Generated by AI + Gitee MCP

If no issues are found, comment:
[Overall assessment — LGTM or key changes needed]
🤖 Generated by AI + Gitee MCP

如果未发现问题，评论内容如下：

Code Review

Code Review

LGTM! No significant issues found. Code quality looks good.
🤖 Generated by AI + Gitee MCP
undefined
LGTM! No significant issues found. Code quality looks good.
🤖 Generated by AI + Gitee MCP
undefined

Notes

注意事项

  • Focus only on new/modified code in the PR, not pre-existing code
  • Avoid nitpicking — do not raise issues that a linter would automatically catch
  • Comments should be specific and actionable — provide suggestions, not just observations
  • For uncertain issues, say "recommend verifying" rather than asserting it is definitely a bug
  • 仅关注PR中的新增/修改代码，不要涉及已有代码
  • 避免吹毛求疵——不要提出linter可自动检测的问题
  • 评论应具体且可执行——提供改进建议，而非仅指出问题
  • 对于不确定的问题，应说“建议验证”而非断言其肯定是bug