预审（Pre-Review）

在发布 PR 之前 发现并修复问题 —— 而非之后。

使用一个高能力模型完成单次完整审查。无需编排开销，不依赖代理集群。快速、低成本、全面。

适用场景

• 在发布 PR 前审查代码变更
• 对现有代码进行审计，识别缺陷、安全风险或质量隐患
• 在指定文件或目录中定位并修复问题

不适用场景

• 运行编码代理生成新代码 → 请使用 coding-agent
• 检查 GitHub CI 状态 → 请使用 github
• 管理 fork 或变基分支 → 请使用 fork-manager

用法

/pr-review                    # 审查当前分支相对于 main/master 的变更
/pr-review src/api/ src/auth/ # 审计指定目录
/pr-review **/*.ts            # 审计匹配该模式的所有文件
/pr-review --audit            # 使用智能优先级策略审计整个代码库

两种模式：

执行步骤

步骤 1：识别模式与作用域

未提供任何参数时：

git diff main...HEAD --name-only 2>/dev/null || git diff master...HEAD --name-only

• 若存在变更 → 进入 Diff 模式
• 若无变更 → 提示用户并终止流程

提供了路径/模式，或使用了 --audit：

• 解析为实际文件（排除 node_modules、dist、build、vendor、.git、coverage 等目录）
• 若匹配文件数 > 50，提示用户缩小范围或确认继续
• 进入 Audit 模式

步骤 2：收集上下文

快速扫描项目规范（勿过度解读）：

# 检查项目约定
cat CLAUDE.md .claude/settings.json CONTRIBUTING.md 2>/dev/null | head -100
cat .eslintrc* .prettierrc* biome.json tsconfig.json 2>/dev/null | head -50
cat package.json 2>/dev/null | head -20  # 技术栈信息

获取 diff 内容或目标文件内容：

# Diff 模式
git diff main...HEAD  # 或 master

# Audit 模式
cat   # 读取目标文件

步骤 3：审查（单次遍历）

一次性分析全部代码，按以下优先级顺序覆盖各维度：

1. 正确性（最高优先级）

• 逻辑错误、边界情况、null/undefined 处理不当
• 越界访问、分页边界错误、数值精度问题
• async/await 使用错误、竞态条件、资源泄漏
• 数据一致性、幂等性缺失

2. 安全性

• 注入漏洞（SQL、XSS、命令注入、路径遍历）
• 认证/授权缺失、IDOR 风险、密钥暴露
• 未经校验的输入直接进入敏感操作
• 日志记录敏感数据、不安全的默认配置

3. 可靠性

• 异常处理缺失、静默失败、吞没异常
• 缺少超时机制、重试无退避策略
• 对用户可控数据执行无限制操作

4. 性能

• N+1 查询、冗余循环、内存膨胀
• 缺少分页、算法效率低下
• 在异步上下文中执行阻塞操作

5. 质量（最低优先级 — 若问题微不足道可跳过）

• 新增功能缺少测试
• 无效代码、重复逻辑
• 过时注释、命名不清晰
• 仅当违反项目规范时，才指出风格问题

步骤 4：打分与分类

对每个发现的问题，分配如下评分：

丢弃阈值：

• Diff 模式：低于 50 分的问题丢弃
• Audit 模式：低于 40 分的问题丢弃

每个问题须分类为：

• blocker — 涉及安全、数据损坏或崩溃风险
• important — 极可能为缺陷、性能退化、缺失校验等
• minor — 边界情况、可维护性、风格类问题

步骤 5：自动修复

对达到阈值的问题直接应用修复：

• Diff 模式：修复评分 >= 70 的问题
• Audit 模式：修复评分 >= 80 的问题

每次修复操作流程：读取文件 → 应用编辑 → 验证周边代码完整性。

禁止自动修复的情形：

• 需架构层面调整的问题
• 修复方式不明确、存在多种合理解法的问题
• 测试文件中的问题（仅报告）

修复完成后，若任意文件被修改：

git diff --stat  # 显示变更摘要

步骤 6：生成报告

报告格式：

## Pre-Review Complete

**Risk:** Low / Medium / High
**Verdict:** ✅ Clean | ⚠️ Issues found | 🔴 Blockers

### 🔴 Blockers (must fix)
1. **file:line** — Description
   - Impact: what goes wrong
   - Fix: applied ✅ | manual required (reason)

### ⚠️ Important (should fix)
1. **file:line** — Description (score: XX)
   - Fix: applied ✅ | suggestion

### 💡 Minor
1. **file:line** — Description

### Tests to Add
- description of test

### Files Modified: N
- path/to/file.ts

若未发现任何问题：## Pre-Review Complete — ✅ Clean. No issues found.

指导原则

务必做到：

• 直接修复问题，而非仅报告
• 严格遵循既有代码模式与风格
• 描述具体：精确到文件与行号，并给出明确修复方案
• 优先关注影响面，而非追求绝对全面

严禁行为：

• 在 Diff 模式下修复本次变更未涉及的既有问题
• 对风格问题过度争论，除非其违反项目规范
• 报告由 linter 或类型检查器即可捕获的问题（假设 CI 已覆盖）
• 实施架构调整或大规模重构
• 为明显无关紧要的问题消耗 token

应避免的误报

• Diff 模式下，当前变更未触及的既有代码
• 看似异常但实为有意为之的正确模式
• 类型检查器或 linter 可识别的问题
• 无项目规范支撑的主观风格偏好
• 资深工程师通常会忽略的一般性挑剔