注意：如果你本地安装了 mcporter，应使用 mcporter 来调用 MCP 工具，而不是直接调用 MCP 工具。mcporter CLI 提供了更便捷的接口和更好的错误处理能力。

通过 Gitee MCP 审查 Pull Request

对 Gitee 仓库中的一个 Pull Request 进行全面的代码审查。

前置条件

• 已配置 Gitee MCP 服务（工具：get_pull_detail、get_diff_files、list_pull_comments、comment_pull）
• 用户需提供：仓库所有者、仓库名称、PR 编号（或说明“审查最新的 PR”）
• 可选：如果当前目录是该 PR 所属仓库的本地克隆，可以利用本地 Git 命令和文件访问来获取更多上下文信息

操作步骤

步骤 1：获取 PR 详情

使用 get_pull_detail 获取 PR 信息，检查以下内容：

• 标题和描述是否清晰说明了变更目的
• 源分支和目标分支是否正确
• PR 状态（若已关闭或合并，则停止审查）
• 是否为草稿（Draft）——若是，需通知用户

步骤 2：获取差异文件列表

使用 get_diff_files 获取被修改的文件列表，并分析：

• 修改文件的数量与范围
• 是否涉及敏感文件（如配置文件、密钥、权限相关代码）

针对每个核心修改文件，使用 get_file_content 读取其内容以获取上下文。

如果在本地仓库目录中运行，可借助本地 Git 命令和文件访问，进一步获取审查上下文（例如查看相关提交、关联文件、文件历史等）。

步骤 3：检查已有评论

使用 list_pull_comments 获取已有评论，避免重复提出已讨论过的问题。

步骤 4：代码审查

从以下维度对代码进行审查：

正确性

• 逻辑是否正确？边界情况是否已处理？
• 是否存在明显缺陷或空指针风险？
• 错误处理是否充分？

安全性

• 是否存在 SQL 注入、XSS、命令注入等安全风险？
• 是否硬编码敏感信息？
• 是否有权限校验机制？

可维护性

• 变量名和函数名是否清晰且具有语义？
• 每个函数/方法是否职责单一？
• 复杂逻辑块是否有注释说明？

性能

• 是否存在不必要的嵌套循环或 N+1 查询？
• 大文件操作是否考虑内存使用？

一致性

• 代码是否符合项目现有风格？
• 是否与相关模块保持一致？

步骤 5：问题分类

根据严重程度对发现的问题进行分类：

• 🔴 阻断项：影响正确性或存在安全风险 —— 必须修复
• 🟡 建议项：代码质量问题 —— 推荐但非强制
• 🟢 可选项：优化建议 —— 有益但非必要

步骤 6：提交审查评论

使用 comment_pull 将审查结果发布到 PR 中，采用以下格式：

## Code Review

**Summary**: [一句话概括 PR 的目的及整体质量评估]

### 🔴 阻断项
1. **[文件名:行号]** [问题描述]
   - 问题：[具体说明]
   - 建议：[修复方案]

### 🟡 建议
1. **[文件名]** [问题描述]
   - 建议：[改进方向]

### 🟢 可选项
1. [改进建议]

### 结论
[总体评估 —— LGTM 或需关键修改]

🤖 由 AI + Gitee MCP 生成

若未发现任何问题，应提交如下评论：

## Code Review

LGTM！未发现显著问题，代码质量良好。

🤖 由 AI + Gitee MCP 生成

注意事项

• 仅关注 PR 中新增或修改的代码，不审查已有代码
• 避免过度挑剔 —— 不要提出连代码检查工具（linter）都会自动捕获的问题
• 评论应具体且可操作 —— 提供建议而非仅陈述观察
• 对不确定的问题，应表述为“建议验证”，而非断言其为 bug