gh-pr-review

你正在协助审查一个拉取请求。请提供全面、结构清晰的审查意见。

待审查的 PR： $ARGUMENTS

审查流程：

1. 使用 GitHub CLI 获取 PR 详情
2. 检查现有审查评论和状态检查
3. 如果检查失败，查看失败详情并提出修复建议
4. 分析已配置的 CI/CD 检查，并提醒是否缺少重要检查
5. 分析差异中的代码更改
6. 阅读修改过的文件，了解差异之外的上下文
7. 在写下每项结论前进行核实：
   • 检出分支并运行 PR 涉及的测试。报告实际输出，而不是预期结果。
   • 检查合并状态以及 CI 是否运行过。上次推送之前的绿色检查已过时。
   • 如果无法通过阅读确定某项结论，就编写一次性测试来验证，运行后再删除。
8. 找出遗漏的更改：
   • 逻辑遗漏：相关代码应该更新但没有更新
   • 文档遗漏：解释“原因”的代码注释（尤其是非显而易见的决策）、README 更新，以及需要更新的 API 文档
   • 测试遗漏：新功能应包含的测试用例
9. 提供结构化反馈，涵盖：
   • 代码质量：逻辑、可读性、可维护性
   • 安全性：潜在漏洞或安全隐患
   • 性能：效率与优化机会
   • 测试：测试覆盖率与质量
   • 文档：代码注释（重点关注关键逻辑的“原因”说明）、文档更新
   • 架构：设计决策与模式
   • 依赖项：新增依赖及其合理性
   • CI/CD 覆盖范围：此类更改应配置但尚未配置的检查
   • 完整性：遗漏的必要内容

每个方面都需提供：

• ✅ 做得好的地方
• ⚠️ 有待改进的地方
• 🔴 严重问题（如有）

所有结论都必须有依据。

仅描述代码的结论还不完整。每条结论都包含以下三部分：

1. 依据位置 — 每项结论都要标明 文件:行号，方便作者直接定位。
2. 证据 — 命令输出、测试结果或你运行的验证。绝不能把推断当作事实。如果有内容尚未验证，请明确标注，并说明如何验证。
3. 故障过程 — 用读者的视角再次说明同一缺陷。指出谁在操作、他们所在的界面、输入了什么、看到了什么，以及实际发生了什么。说明到损害发生处为止。

顺序和内容同样重要。开头先给出能证明问题的材料，通常是几行代码、一个测试或真实命令输出。之后再进行论证，不要先讲结论、后给证据。读者先看到证据，接下来会判断你的结论；先看到论证，则会花时间质疑你是否可信。

如果结论依赖某个领域概念，请先用三行或一个小表格解释该概念。若审查者不了解相关模型，就无法判断问题是否成立。

删除所有无法给出依据的结论。看似缺陷的猜测会浪费作者的时间，不如不提。

每条结论都要简短，并且彼此分开。

一条结论对应一条审查评论。不要把多个问题合并到一条评论中。只有分开提出，读者才能逐条接受或拒绝。

每条评论都按以下顺序组织：证据、后果、修复建议。

每条评论最多 3 段，正文最多 500 个词。代码块不计入字数限制，限制仅适用于周围的正文。只有在缩短会遗漏实质内容时才可超出限制，不能只是为了保留自己偏爱的观点。

如果某段话不会影响作者接下来的行动，就删掉。

最后给出总体建议： APPROVE、REQUEST CHANGES 或 COMMENT。 如果未提供 PR 编号/URL： 查找当前分支对应的 PR。如果当前处于 main 分支，则列出打开的 PR 并询问要审核哪一个。

使用以下 GitHub CLI 命令：

• gh pr view - 获取 PR 详情、审核意见和状态检查
• gh pr diff - 获取代码变更
• gh pr checks - 获取详细的检查状态和失败日志
• gh run view - 如果检查失败，获取工作流运行详情
• 检查 .github/workflows/，了解配置了哪些 CI/CD 检查