Local Diff Review（提交前本地评审）
核心原则
- 审查标准必须与
pr-review保持一致，不允许自定义弱化标准。 - 先审查再改代码：默认先输出问题清单，只有用户明确要求才改代码。
- 结论必须可执行：每个问题都要给出文件路径、行号、风险说明、修复建议。
审查标准来源（必须遵循）
- 代码质量标准：
./code-quality-standards.md - 常见问题清单：
./common-issues-checklist.md
说明：本 skill 的“评审准则”以
pr-review当前版本为准，以上链接即唯一标准来源。
使用场景
- 用户希望“先本地 review，再提 PR”。
- 用户给出“review 我当前改动/本地 diff/暂存区改动/分支差异”。
- 用户希望获得与 PR review 同等级别的风险分级反馈。
信息收集流程
先收集仓库状态：
git status --short
git branch --show-current
git remote -v
再根据用户意图选择 diff 范围（默认优先问清楚范围）：
# 1) 未暂存改动
git diff
# 2) 已暂存改动
git diff --staged
# 3) 工作区全部改动（含暂存+未暂存）
git diff HEAD
# 4) 当前分支相对基线分支（推荐用于“准备提 PR”）
git diff upstream/<base-branch>...HEAD
# 5) 指定提交
git show <commit>
审查步骤
- 阅读 diff，按文件分组梳理改动目的。
- 依次执行三维度审查（严格按上面 3 份标准文档）。
- 标注问题等级：
- 🔴 严重问题（必须修复）
- 🟡 建议改进（建议本次修）
- 🟢 可选优化（可后续处理）
- 汇总回归风险：i18n、类型安全、边界行为、兼容性、性能影响。
- 给出审查结论：可合并 / 需修改后再审。
输出格式（建议）
1) 变更概览
- 审查范围（哪一种 diff）
- 涉及文件数、核心模块
2) 问题清单
每个问题都包含：
- 文件路径 + 行号
- 风险等级（🔴/🟡/🟢）
- 问题描述（为什么是问题）
- 修复建议（给出可落地方案）
3) 总体结论
- 是否建议现在提 PR
- 提 PR 前建议补做的最小验证（如 lint / typecheck / 相关测试）
评审时的行为约束
- 不凭空猜测业务意图；证据不足时明确“需用户确认”。
- 不把“个人偏好”当成阻塞项。
- 不为不存在的调用路径添加过度防御性建议。
- 与用户沟通时优先中文、结论清晰、步骤可执行。
常用触发语句（示例）
- “请按 PR 标准 review 我本地当前改动。”
- “请 review 我的
git diff --staged，只给问题清单。” - “请按 FastGPT 规范审查我当前分支相对
upstream/v4.14.7-dev的改动。”