Cursor 指令化 Code Review 技术分享

1. 目标与价值

在日常开发中，Code Review 常见痛点：

• 审查标准不一致，依赖个人经验
• review 结论偏主观，容易遗漏高风险点
• 提 PR 前缺少统一“自检”动作
• 反馈格式不统一，沟通成本高

指令化 Code Review 的目标是：
把“审查动作”变成一个可重复执行、可团队共享、可持续优化的工程流程。

---

2. 什么是 Cursor 指令化 Review

在 Cursor 里通过 .cursor/commands/*.md 定义命令（例如 @prepr-review），让 AI 按固定流程执行审查：

1. 拉取基线分支（如 origin/develop）
2. 对比 BASE...HEAD 的完整 diff
3. 按风险等级输出问题
4. 给出可执行回归清单
5. 明确“可提 PR / 不可提 PR”结论

核心思想：把“怎么审”从人脑经验，变成文档化规则。

---

3. 推荐命令结构

一个可落地的命令通常包含 6 个模块：

3.1 元信息

• description: 命令作用

3.2 参数解析

• 空参数默认行为（如 origin/develop）
• 可选参数（--quick、--strict、自定义 base）

3.3 执行步骤

• fetch、status、log、diff、质量检查（ts/lint/test）

3.4 风险判定标准

• 高/中/低风险定义
• 阻塞项判定规则

3.5 关联性判定

• 失败项是否与本次 diff 直接相关
• 防止“历史失败噪音”误判为阻塞

3.6 固定输出模板

• 阻塞问题
• 建议优化
• 已验证项
• 回归清单
• 最终结论

---

4. 一条命令的最佳实践

命令建议

• @prepr-review：提 PR 前审查主命令
• @prepr-review --quick：跳过测试，快速出审查结果
• @prepr-review --strict：严格模式，阻塞项更严格

使用建议

• 日常开发：先跑 --quick 快速发现问题
• 提 PR 前：跑标准版或 --strict
• CI 前：确保结论和回归清单已完成

---

5. 输出模板示例（建议团队统一）

## PR前审查报告

### 对比范围
- Base: origin/develop
- Head: feature/xxx
- 提交数: N
- 文件变更: N

### 阻塞问题（必须修复）
- [高风险] ...

### 建议优化（非阻塞）
- [中/低风险] ...

### 已验证项
- TypeScript: ✅/❌
- 测试: ✅/❌/未执行（原因）
- 测试关联性: ✅ 本次相关 / ⚠️ 疑似历史失败

### 回归测试清单（最小）
- [ ] 场景1
- [ ] 场景2
- [ ] 场景3

### 最终结论
- ✅ 可提PR
或
- ❌ 暂不建议提PR