pr-review

核心用法

pr-review 是一款面向开发者的代码预审查工具，设计目标是在 PR 发布前快速发现并修复问题，而非事后补救。采用单遍审查模式——使用单一 capable 模型完成分析，无多 Agent 编排开销，兼顾速度与深度。

两种工作模式：

• Diff 模式（默认）：对比当前分支与 main/master，仅审查变更文件，自动修复阈值 ≥70 分
• Audit 模式（指定路径或 --audit）：审查指定文件/目录或全库，自动修复阈值 ≥80 分

执行流程： 检测模式 → 收集上下文（CLAUDE.md、ESLint 配置、package.json 等）→ 单遍审查 → 评分分类 → 自动修复 → 生成报告

显著优点

1. 成本效益：单模型单遍审查，相比 Agent Swarm 方案显著降低 token 消耗与等待时间
2. 自动修复：高分问题直接修改代码，而非仅报告，减少人工介入
3. 优先级清晰：按正确性 → 安全 → 可靠性 → 性能 → 质量五级优先级审查，确保关键问题不被淹没
4. 模式智能：Diff 模式避免修复历史遗留问题，Audit 模式支持全库扫描与智能优先级排序
5. 报告结构化：Blocker / Important / Minor 三级分类，附带风险评级与修复状态

潜在缺点与局限性

1. 修复门槛限制：Diff 模式仅自动修复 ≥70 分、Audit 模式 ≥80 分，中等严重问题可能滞留
2. 架构级问题不处理：明确排除需要架构变更的问题，复杂重构需人工决策
3. 测试文件不修复：测试代码中的问题仅报告不修改
4. 风格审查保守：仅当违反项目指南时才处理风格问题，可能漏过一致性瑕疵
5. 单模型上限：相比多模型交叉验证，极端复杂场景可能遗漏边缘 case
6. 依赖 Git 环境：需本地 git 可执行文件，纯云端/容器环境需预配置

适合人群

• 高频提 PR 的开发者：需要在提交前快速自检，减少 CI 失败与 review 往返
• Tech Lead / 代码审查者：作为人工审查前的预筛工具，聚焦高价值问题
• 安全/质量审计场景：Audit 模式适合定期全库扫描，发现潜伏 bug 与漏洞
• 追求效率的小团队：不愿为代码审查搭建复杂 Agent 系统，但需要比 linter 更深的语义分析

常规风险

1. 自动修复副作用：直接修改代码可能引入新 bug，尤其在复杂逻辑或边界条件下
2. 评分主观性：50-69 分区间依赖模型判断，可能存在误判或漏判
3. 上下文依赖：若 CLAUDE.md、CONTRIBUTING.md 等指南缺失，审查质量可能下降
4. 非确定性输出：大模型生成内容存在波动，相同代码多次审查结果可能略有差异
5. 敏感数据暴露：审查过程中读取代码文件，需确保无硬编码密钥（尽管工具本身会检测此类问题）

核心用法

pr-review 是一款专为代码审查场景设计的AI增强技能，通过Claude Code内置工具（Bash、Read、Edit、Write等）实现PR预审功能。支持两种工作模式：

• Diff模式：无参数调用时，自动检测当前分支与main/master的差异文件，对变更内容进行审查，修复阈值≥70分
• Audit模式：通过指定路径、通配符或--audit参数，对指定文件或全代码库进行深度审查，修复阈值≥80分

使用流程简洁直观：检测模式与范围→收集项目上下文（读取CLAUDE.md、ESLint配置等技术栈信息）→单遍综合审查→按优先级评分分类→自动应用高置信度修复→生成结构化报告。评分体系采用90-100（关键漏洞必修复）、70-89（实际问题建议修复）、50-69（代码异味仅报告）、<50（丢弃）的四档分级。

显著优点

效率优先的设计理念是该技能的核心竞争力。区别于多Agent协作的复杂编排，采用"单遍审查+单 capable model"架构，消除了 orchestration 开销，实现快速、低成本且全面的代码审查。

智能优先级排序确保关键问题不被淹没。审查覆盖正确性（逻辑错误、竞态条件）、安全性（注入漏洞、越权风险）、可靠性（错误处理缺失）、性能（N+1查询、内存泄漏）、质量（测试覆盖）五大维度，按业务影响严格排序。

精准自动修复机制减少人工干预。仅对高置信度问题（Diff模式≥70分、Audit模式≥80分）直接应用修复，同时明确排除架构性变更、多方案模糊场景、测试文件修改等高风险自动操作。

零可执行代码架构带来极致安全性。纯Markdown文档型设计（T-MD分类），98.2%内容为说明文档，所有bash示例仅作教学用途，实际执行完全依赖Claude Code标准工具链。

潜在缺点与局限性

语言与生态覆盖有限。文档示例以TypeScript/Node.js为主（*.ts、node_modules排除模式、package.json读取），对Java/Kotlin、Go、Rust、Python等其他语言生态的支持程度需用户自行验证。

自动修复的边界约束。明确不处理架构性变更、测试文件、多方案模糊场景，意味着复杂重构仍需人工介入。70/80分的阈值设计在保守与安全之间取得平衡，但也可能导致部分潜在问题遗漏。

依赖Claude Code环境。作为Claude Code专用技能，无法独立运行或迁移至其他AI编码平台，工具链绑定形成生态壁垒。

项目上下文理解深度。快速扫描模式（head -100、head -50）对大型项目规范的理解可能流于表面，复杂业务规则的合规判断依赖模型先验知识。

适合的目标群体

• 全栈开发者：需要快速预审功能分支，在提交PR前捕获回归问题
• Tech Lead/架构师：进行代码库定期审计，建立质量门禁
• 开源维护者：批量审查贡献者PR，标准化入库代码质量
• 安全工程师：自动化安全左移，在开发阶段识别注入、越权等漏洞
• 中小团队：缺乏专职QA资源，需高性价比的代码质量保障方案

使用风险

版本控制风险：自动修复会直接修改工作区文件，建议在干净分支使用，修复后通过git diff --stat确认变更范围，避免未预期修改混入提交。

误修复风险：尽管设置了高置信度阈值，复杂业务逻辑的场景判断仍可能存在误判。关键业务代码建议逐行审查自动修复结果，并补充回归测试。

模型能力边界：单遍审查模式对超长上下文（>50文件触发警告）的处理能力受限，超大规模变更建议拆分审查或采用--audit全库模式而非Diff模式。

工具链依赖风险：依赖git二进制可用性及Claude Code工具稳定性，特殊Git工作流（如monorepo子模块、LFS大文件）可能存在兼容性问题。