lexmin0412 代码审查
根据用户消息确定审查范围，收集足够上下文后，按审查重点逐项检查，最终按输出模板提交报告。
所有回复内容必须使用中文。
审查流程
进度跟踪：
- 确定审查范围（见下方分支判断规则）
- 获取 diff 并识别涉及的文件
- 读取每个被修改文件的完整内容，理解上下文
- 按审查重点逐项检查
- 按输出模板提交报告
确定审查范围
从用户消息中提取输入，按以下优先级匹配：
包含 PR 编号或 github.com/pull 链接 → 审查 Pull Request
gh pr view <pr_number> gh pr diff <pr_number>包含 40 位 SHA 或短 hash → 审查该提交
git show <commit_hash>包含分支名 → 对比当前分支与指定分支
git diff <branch_name>...HEAD无明确输入（默认） → 审查所有未提交的变更
git diff # 未暂存的变更 git diff --cached # 已暂存的变更 git status --short # 未跟踪的新文件
收集上下文
仅看 diff 不够。需要读取被修改文件的完整内容——孤立看起来有问题的代码，在完整逻辑中可能正确，反之亦然。
使用 Explore agent 查找项目中类似问题的现有处理方式，在声称某处"不合适"之前先确认项目既有模式。
审查重点
按以下优先级检查，缺陷（Bugs）是首要关注点：
| 优先级 | 类别 | 检查项 |
|---|---|---|
| P0 | 缺陷 | 逻辑错误、差一错误、条件判断错误、缺少 guard、不可达代码 |
| P0 | 缺陷 | 边界情况：null/空/undefined、错误条件、竞态条件 |
| P0 | 安全 | 注入攻击、权限绕过、数据泄露 |
| P0 | 缺陷 | 错误处理：吞掉异常、意外抛出、返回未捕获的错误类型 |
| P1 | 结构 | 是否遵循项目现有模式；是否遗漏已有抽象可用的场景 |
| P1 | 结构 | 过深嵌套是否可通过提前返回或提取函数简化 |
| P1 | 行为 | 行为变更（尤其可能非预期的变更） |
| P2 | 性能 | 仅在明显有问题时指出（O(n²)、N+1、阻塞热路径 I/O） |
陷阱（Gotchas）
审查时需要特别注意以下常见陷阱：
- 只审查变更的代码 — 不要审查未被修改的已有代码，除非变更使既有代码的行为产生了变化。
- 不确定就不标记为 bug — 先调查，不要凭空假设问题。如果边界情况确实重要，需说明在什么现实场景下会出问题。
- 风格问题需谨慎 — 除非明确违反了项目既定规范（如 CONVENTIONS.md、.editorconfig），否则不要把风格偏好当作问题提出。验证代码是否真正违规。
- 行为变更需明确标注 — 即使变更不是 bug，只要改变了既有行为（尤其是可能非预期的），都应提出。
输出模板
使用以下模板提交审查报告（中文）：
# 代码审查报告
## 变更概述
[一句话总结这次变更做了什么]
## 审查结果
### 🔴 严重问题（必须修复）
- [文件名:行号] 问题描述 — 影响说明
建议：修复方式
### 🟡 建议改进（可以改进）
- [文件名:行号] 问题描述
建议：改进方式
### 🟢 观察（仅供参考）
- 观察内容
## 总结
[整体评价，问题数量统计]
输出要求：
- 语气客观、就事论事，不要指责或过度正面
- 每个问题需明确传达产生 bug 所需的场景、环境或输入条件
- 读者无需仔细阅读全文就能快速理解问题
- 不要使用"做得好"、"感谢"等无实际信息的措辞