87 lines
3.3 KiB
Markdown
87 lines
3.3 KiB
Markdown
---
|
||
name: "pr-reviewer"
|
||
description: "对变更/PR 做代码审查并给出可执行修改建议。用户要求代码评审、准备合并、或完成较大改动后自检时调用。"
|
||
---
|
||
|
||
# PR Reviewer（变更/PR 代码审查）
|
||
|
||
## 目标
|
||
|
||
- 快速识别高风险缺陷（正确性/安全/稳定性/兼容性）
|
||
- 以“可落地修改”为导向给出建议（位置、原因、影响、最小修复）
|
||
- 在不引入不必要依赖的前提下，尽量复用仓库现有模式与工具
|
||
|
||
## 何时使用
|
||
|
||
- 用户要求“评审这个 PR/diff/改动”
|
||
- 你完成了多文件或关键路径改动，准备合并前自检
|
||
- 修复 bug 或安全问题后，需要确认无回归
|
||
|
||
## 你需要获取的信息（尽量自己补齐）
|
||
|
||
优先使用现有上下文完成评审，不强制用户补全：
|
||
|
||
- 变更范围：diff/文件列表/目录
|
||
- 预期行为：功能目标、边界条件、失败语义
|
||
- 运行环境：语言版本、部署方式、配置来源、数据库/外部依赖
|
||
- 质量门槛：性能目标、SLA、兼容性、测试要求
|
||
|
||
## 审查方法（按优先级）
|
||
|
||
1. 先看变更入口与数据流：输入→处理→持久化/外部调用→输出
|
||
2. 先找会导致事故的点：鉴权、注入、并发、资源泄露、回滚困难
|
||
3. 再看可维护性：重复、耦合、命名、可读性、错误处理一致性
|
||
4. 最后看体验与一致性：日志、可观测性、风格、文档与配置
|
||
|
||
## 检查清单
|
||
|
||
### 正确性
|
||
|
||
- 边界条件：空值/缺省、极端长度、时区与编码、浮点与精度
|
||
- 错误路径：异常是否被吞、错误码与消息是否一致、重试/幂等性
|
||
- 并发：竞态、锁粒度、事务边界、重复提交
|
||
- 资源：连接/句柄/任务是否可控，是否有超时与取消
|
||
|
||
### 安全性
|
||
|
||
- 注入：SQL/命令/模板/路径穿越/正则 DoS
|
||
- 鉴权：敏感操作是否校验权限与主体一致性，是否存在越权路径
|
||
- 会话：token 处理是否安全（存储/传输/日志/错误信息）
|
||
- 密钥：不得输出或建议写入任何密钥/token/密码/私钥/PII
|
||
|
||
### 稳定性与性能
|
||
|
||
- 热路径复杂度、N+1、无界队列/循环、阻塞 I/O
|
||
- 缓存/分页/批处理是否合理，索引友好性
|
||
- 外部依赖：熔断/退避/限流/超时/重试策略是否一致
|
||
|
||
### 可维护性与一致性
|
||
|
||
- 是否复用项目既有抽象（配置、logger、错误处理、领域模型）
|
||
- 是否引入了不必要的新依赖；若必须引入，说明理由与替代方案
|
||
- API/DTO/Schema 是否向后兼容；破坏性变更是否标注与迁移路径
|
||
|
||
### 测试与验证
|
||
|
||
- 是否覆盖关键分支与失败路径
|
||
- 是否新增或更新了与变更一致的测试（单测/集成/端到端）
|
||
- 是否需要补充回归用例（最小复现）
|
||
|
||
## 输出格式（必须可执行）
|
||
|
||
按以下结构输出，中文为默认：
|
||
|
||
1. 结论摘要（风险：高/中/低，是否建议合并：是/否/有条件）
|
||
2. Blockers（必须修复）：每条包含
|
||
- 位置：文件 + 行号范围（若可获得）
|
||
- 问题：一句话描述
|
||
- 影响：会导致什么
|
||
- 修复：最小改动建议（必要时给补丁）
|
||
3. Suggestions（建议改进）：同上，但不阻塞
|
||
4. Tests（建议验证）：列出要跑/要补的测试与覆盖点
|
||
|
||
## 约束
|
||
|
||
- 不凭空假设依赖或环境已存在；不确定时先在仓库中确认
|
||
- 不输出或建议写入任何密钥/token
|