核心用法
structured-pr-review 提供双向 PR 审查模式：
模式一：主动评审（Giving Reviews）
- 自动获取 PR 详情与完整 diff
- 按五层框架遍历检查：Security（安全漏洞）、Correctness（逻辑正确性）、Conventions（团队规范）、IaC（基础设施即代码）、Testing（测试覆盖）
- 输出结构化裁决：
MUST FIX/SHOULD FIX/SUGGESTION三级严重度 - 内置评审原则：直接指出问题、提供具体修复建议、认可 PR 优点、不确定时降级处理
模式二：响应评审（Addressing Reviews）
- 拉取所有内联评论与评审级反馈
- 逐条修复或说明不修复理由
- 强制要求：回复每一条评论、更新 PR 描述、验证合并状态
显著优点
| 维度 | 优势 |
|------|------|
体系化 | 五层检查清单避免遗漏关键风险点 |
零依赖 | 仅使用 gh CLI，无需额外工具链 |
可定制 | 通过 conventions.md、iac-checklist.md 适配团队标准 |
闭环管理 | 评审响应流程强制确认每条评论，杜绝"幽灵评论" |
分级决策 | MUST/SHOULD/SUGGESTION 帮助团队聚焦阻塞性风险 |
潜在局限
1. 依赖 GitHub CLI：非 GitHub 平台（GitLab、Bitbucket）无法使用
2. 静态分析局限：无法替代动态测试或安全扫描工具（如 Snyk、Semgrep）
3. IaC 深度有限：虽提及 Terraform/CloudFormation，但复杂资源依赖分析需配合 terraform-skill
4. 语言中立性：未针对特定语言提供深度语法/语义分析
适合人群
- Tech Lead / Staff Engineer：建立团队代码审查标准与守门机制
- DevOps / Platform Engineer：基础设施变更的安全评审
- 开源维护者：批量处理外部贡献的规范化评审
- 安全合规团队：强制 Security 层作为合并门禁
常规风险
- 评审疲劳：五层检查可能导致过度评审，需结合团队规模调整深度
- 约定漂移：
conventions.md若未及时同步团队实际规范，可能产生冲突 - 自动化幻觉：分级裁决仍依赖执行者判断，高严重度问题建议人工复核
- 权限依赖：
ghCLI 需配置适当 GitHub Token 权限（pull_requests:write,contents:read）