工程师的 Cursor 审查工作流：让 AI 先找重复问题再进人工 Review

01 痛点钩子

团队 Review 最容易被重复问题拖慢：命名不一致、边界条件没测、接口字段改了但调用方没跟上。人工审查应该集中在架构判断和业务风险，而不是一遍遍找低级遗漏。

02 结果预告

这篇会给你一套 Cursor 审查前置流程：先让 AI 读取变更摘要、列出风险清单、补充测试建议，再由工程师确认高风险项。目标不是替代 Review，而是让 Review 前的信息更完整。

03 工具简介

Cursor 适合做“上下文整理 + 风险枚举 + 测试补洞”。它能快速阅读多文件变更，但不应该直接决定是否合并；最终判断仍然要由熟悉系统的人完成。

04 实战演示

在提交 PR 或准备发给同事 Review 前，把当前变更说明和关键文件路径交给 Cursor，要求它按固定结构输出。

你是资深代码审查助手，请基于我提供的变更说明和文件列表，先做一次 Review 前风险扫描。

输入：
- change_summary: {{这次改动解决了什么问题}}
- changed_files: {{变更文件列表}}
- risk_context: {{业务风险、历史问题、相关模块约束}}
- test_command: {{本项目可运行的测试或构建命令}}

任务：
1) 用 5 句话以内总结这次改动的行为变化。
2) 找出可能影响用户行为、数据结构、权限、异步流程、错误处理的风险点。
3) 列出测试缺口，区分“必须补”和“可选补”。
4) 标记需要人工确认的问题，不要自行假设业务规则。
5) 给出 Review 前最终检查清单。

输出格式：
## 行为变化
- ...

## 高风险点
- 风险：
  证据：
  建议：

## 测试缺口
- 必须补：
- 可选补：

## 需要人工确认
- ...

## 合并前检查清单
- ...

要求：
- 不要泛泛而谈，每个风险必须指向具体文件、函数或数据流。
- 如果缺少上下文，明确写“需要人工确认”，不要编造。
- 不要建议大重构，只给与当前变更直接相关的建议。

示例输入

change_summary: 为文章列表增加 role 和 tag URL 筛选。
changed_files:
- app/articles/page.tsx
- components/articles-filter-client.tsx
- lib/articles.ts
risk_context: 站点使用静态导出，筛选逻辑在客户端运行。
test_command: npm run build

示例输出片段

## 高风险点
- 风险：URL 参数中的 role/tag 必须和文章 frontmatter 文本完全一致，否则筛选无结果。
  证据：筛选逻辑使用 collection.includes(value)。
  建议：保留“全部”入口，并在无结果状态提示用户切换筛选条件。

## 测试缺口
- 必须补：至少验证 /articles?role=产品%20/%20运营 能显示对应文章。
- 可选补：为 tag 和 role 同时存在的组合增加页面级 smoke check。

05 避坑提示

• 不要把 AI 输出直接当成 Review 结论，它只能帮你发现“可能的问题”。
• 不要让 AI 顺手重构无关代码，否则 Review 范围会变大。
• 对权限、计费、数据删除、批量更新类改动，必须要求人工复核。

合并前检查清单

• 行为变化是否能用 3-5 句话讲清楚。
• 是否有至少一个命令证明项目仍能构建或测试通过。
• AI 提出的高风险项是否逐条处理或明确接受风险。
• 变更是否只触达本次需求相关文件。
• Review 描述里是否写清楚“已知缺口”和“未覆盖测试”。

06 进阶拓展

下一步可以把这套 Prompt 固定到团队 PR 模板里：提交人先贴 AI 风险扫描结果，Reviewer 再重点看高风险点和人工确认项。

07 落地流程图

08 指标与验收

• PR 首轮 Review 前的缺失信息是否减少，例如变更摘要、测试说明和风险说明。
• Reviewer 平均等待时间是否下降，重复性评论是否减少。
• 高风险变更是否都有对应测试、回滚方式或人工确认记录。
• AI 风险扫描命中率每周复盘一次，错误建议进入团队 Prompt 修订记录。

09 来源与延伸阅读

• https://docs.github.com/en/copilot
• https://github.blog/ai-and-ml/
• https://dora.dev/research/

10 本文加工判断

本文把 AI 编程助手、代码托管平台和工程效能研究加工成一个 Review 前置流程。适合已有 PR 流程、测试习惯和代码 owner 的团队；不适合没有基础工程规范、也不适合让 AI 直接决定合并或跳过人工审查。

更新记录：2026-06-30 首次发布，补齐工程师/技术岗位入口。