用 Cursor 做代码审查：实用指南
代码审查是软件开发中杠杆效应最高的活动之一，但也很耗时间。Cursor 的 AI 功能可以帮你更快地完成审查，发现你可能遗漏的问题。这篇指南涵盖从单个 PR 到团队级流程的实用技巧。
为什么要用 Cursor 做代码审查
传统代码审查涉及阅读 diff、检查逻辑、验证风格、在脑中模拟执行。Cursor 通过以下方式增强这个过程：
- 用通俗语言解释不熟悉的代码
- 识别潜在的 bug 和边界情况
- 检查与现有模式的一致性
- 提出你可能想不到的改进建议
Cursor 的代码审查功能不能替代人的判断。它是让审查更 thorough、更高效的工具。行动前务必验证 AI 的建议。
审查前的准备
开始审查前，先配置好 Cursor 以获得最佳效果。
1. 切换到目标分支
检出你要审查的分支：
git fetch origin
git checkout feature-branch-name
Cursor 在能索引整个代码库（包括待审查的改动）时效果最好。
2. 先看 Diff
在让 AI 介入前，自己先扫一遍 diff 了解范围：
git diff main...feature-branch-name
这给你上下文，让你在 Cursor 里能提出更好的问题。
3. 索引代码库
确保 Cursor 已索引最新改动：
- 打开命令面板（
Ctrl/Cmd + Shift + P） - 搜索 Cursor: Reindex Codebase
- 等待索引完成
如果 PR 很大，考虑分块审查。Cursor 的上下文窗口很大但不是无限的。一次聚焦 2-3 个文件比把整个 diff 丢进聊天效果更好。
用 Cursor Chat 审查 PR
聊天面板是代码审查的主要工具。以下是经过验证的技巧。
要高层摘要
先从宏观入手，理解意图：
@file.ts 这个 PR 改了什么，为什么？
或者针对整个分支：
总结一下这个分支相比 main 的改动。它解决了什么问题？
这帮你理解作者的意图，再深入细节。
审查特定函数或类
选中代码，提出针对性问题：
审查这个函数：
1. 潜在的空指针异常
2. 差一错误
3. 缺少错误处理
4. 性能问题
提示词要具体。"审查这段代码"太模糊。"检查这个函数的竞态条件"给了 Cursor 明确方向，产出更有用。
检查安全问题
审查这个认证 handler 的安全问题：
- SQL 注入漏洞
- 输入验证不当
- 硬编码密钥
- 不安全的依赖
Cursor 能标记常见的安全模式，但不可能抓到所有问题。把它当作第一轮筛查，不是最终安全审计。
验证业务逻辑
这个实现是否符合 @spec.md 里的需求？
检查：
- 遗漏的边界情况
- 计算错误
- 缺少的验证
用 Cursor 找 Bug
Cursor 特别擅长发现手动审查中容易遗漏的 bug。
常见 Bug 模式检查清单
让 Cursor 查找特定类别的 bug：
| Bug 类别 | 提示词 |
|---|---|
| 空/undefined 处理 | "找出变量可能为 null 或 undefined 的地方" |
| Async/await 问题 | "检查缺少 await、未处理的 promise rejection、竞态条件" |
| 资源泄漏 | "找出潜在的内存泄漏、未关闭的文件句柄、缺少清理" |
| 类型不匹配 | "检查 TypeScript 可能遗漏的类型不一致" |
| 逻辑错误 | "验证这个函数的条件逻辑。所有情况都处理了吗？" |
示例：审查数据处理函数
// 待审查的代码
function processUserData(users: User[]) {
const results = [];
for (let i = 0; i <= users.length; i++) {
const user = users[i];
if (user.isActive) {
results.push({
name: user.name.toUpperCase(),
email: user.email
});
}
}
return results;
}
给 Cursor 的提示：
审查这个函数的 bug：
Cursor 可能会标记：
- 差一错误：
i <= users.length应该是i < users.length - 潜在空引用：如果
name为 null，user.name.toUpperCase()会报错 results缺少类型：应该是const results: ProcessedUser[] = []
Cursor 能可靠地抓到明显的 bug，但可能遗漏需要深度领域知识的微妙问题。AI 审查的同时务必运行测试套件并做你自己的分析。
代码风格一致性检查
在代码库中保持风格一致很繁琐但很重要。Cursor 可以帮忙。
对照现有模式检查
这个新组件是否遵循 @ExistingComponent.tsx 中的相同模式？
检查：
- 命名规范
- 错误处理方式
- 状态管理模式
- Prop 类型风格
执行项目规范
如果你的项目有风格指南或 .cursorrules 文件，引用它：
根据 @.cursorrules 审查这段代码。标记任何违规。
格式化和 Lint
Cursor 可以建议格式修复，但自动化工具更可靠：
# 先运行你的 linter
npm run lint
npm run format:check
用 Cursor 处理语义风格问题（架构、模式），用 linter 处理语法风格问题（空格、引号、分号）。
提出精准问题
审查质量取决于问题质量。以下是有效的提问模式。
"可能出什么错"模式
这段代码在生产环境可能有哪 3 种失败方式？
这迫使 Cursor 思考边界情况和失败模式。
"像给新人解释"模式
像给刚加入团队的初级开发者解释这个算法。
如果 Cursor 的解释让人困惑，那代码可能需要更好的注释或重构。
"对比方案"模式
作者用 for 循环实现这个。这里用 map/filter 会不会更好？为什么？
这帮你评估所选方案是否最优。
"缺少测试"模式
这个函数缺少哪些测试用例？
Cursor 经常能建议作者没覆盖到的边界情况。
团队的 AI 辅助审查 Workflow
把 Cursor 整合进团队审查流程需要一些协调。
Workflow 1：预审筛查
人工审查前，作者先用 Cursor 检查：
- 作者在 Cursor 里打开自己的 PR 分支
- 运行一套标准的审查提示词
- 修复 AI 标记的明显问题
- 提交 PR，附上备注："Cursor 审查已完成，问题 X 和 Y 已修复"
这减少了人工审查中的噪音，早早抓住低垂的果实。
Workflow 2：审查者助手
人工审查者把 Cursor 当作第二双眼睛：
- 审查者检出 PR 分支
- 手动阅读 diff
- 用 Cursor 深入复杂部分
- 在审查评论中结合 AI 发现和人肉判断
Workflow 3：合并后审计
对于关键代码路径，合并后用 Cursor 复查：
- PR 合并后检出
main - 让 Cursor 在完整系统的上下文中审查合并后的代码
- 标记隔离的 PR 审查可能遗漏的集成问题
为团队建立一套共享的审查提示词。保存在仓库的 REVIEW_PROMPTS.md 文件里，让所有审查者问一致的问题。
审查提示词模板
创建一个可复用的团队模板：
## Cursor 代码审查清单
### 每个修改的文件：
1. "总结这个文件做什么，以及它怎么改的"
2. "找出潜在的 bug 或边界情况"
3. "检查错误处理是否完整"
4. "验证与现有代码模式的一致性"
### 整个 PR：
1. "这个改动会引入任何破坏性变更吗？"
2. "新功能有缺少的测试吗？"
3. "这会影响性能吗？"
4. "有安全方面的影响吗？"
局限性与陷阱
Cursor 是强大的审查助手，但也有局限。
Cursor 擅长什么
- 发现明显的 bug（空引用、差一、缺少 await）
- 用更简单的话解释复杂代码
- 检查与现有模式的一致性
- 建议缺少的测试用例
Cursor 不擅长什么
- 需要领域知识的微妙业务逻辑错误
- 依赖未来路线图的架构决策
- 需要性能分析数据的性能问题
- 依赖部署上下文的安全漏洞
常见陷阱
- 过度依赖：不要因为 Cursor 没标记问题就批准 PR
- 误报：Cursor 有时会把正确的代码标记为有问题
- 上下文缺失：Cursor 不了解你的生产环境、负载模式或业务约束
- 幻觉问题：偶尔 Cursor 会编造不存在的问题
永远不要因为用了 Cursor 就跳过人工审查。AI 是助手，不是替代品。把它的建议当作调查线索，不是最终结论。
总结
正确使用 Cursor 能让代码审查更快、更 thorough。关键实践：
- 先手动扫 diff 了解范围
- 问具体、有针对性的问题，而不是模糊的"审查一下"
- 用 Cursor 找 bug、检查模式、解释代码
- 把 AI 发现与人工判断和自动化测试结合
- 建立团队 workflow，让所有人一致地使用 Cursor
目标不是完全自动化代码审查。而是在更短时间内发现更多问题，让人工审查者能专注于 AI 无法评估的架构和设计决策。