很多团队已经会用 Cursor 写代码,但还不会用它做代码审查。
于是常见情况变成了:
- 改动已经生成了,才临时问一句“帮我 review 一下”
- 审查意见只有“可以优化”“建议补测试”这类空话
- 没有限定范围,工具把整个仓库都点评一遍
- 没有验收标准,最后还是得人肉重审
真正有用的做法不是“让 Cursor 替代审查”,而是让它在明确边界内,先替你做一轮结构化筛查。
如果你还在补基础用法,可以先看 Cursor 教程、Cursor 编辑器指南 和 Cursor Rules 模板。如果你关心性能与安全风险,也建议一起看 前端性能预算指南 和 AI Agent 安全与权限控制。
这篇解决什么问题
这篇文章主要解决 4 个常见问题:
- 怎么写一个真正能落地的 Cursor code review 提示词
- 审查时哪些维度必须覆盖,哪些维度容易漏
- 如何让审查结论和回归清单绑定,而不是停留在口头建议
- 怎样防止 AI 审查越界、误报、低价值输出
一句话结论:
代码审查提示词的核心不是“写得像不像咒语”,而是把范围、依赖、测试、性能、安全和回归标准定义清楚。
Cursor 做代码审查的机制边界
Cursor 适合做的是:
- 先看 diff 或指定文件,找出明显风险
- 按维度列出问题,而不是只给总体评价
- 生成补充测试建议、回归检查点和风险说明
Cursor 不适合直接承担的,是:
- 替代真实业务判断
- 替代运行时验证
- 在没有范围约束时审整个仓库
所以最稳的工作流是:
- 先限定审查范围
- 再限定审查维度
- 最后要求输出“问题 + 风险等级 + 建议修复 + 回归点”
如果你已经把任务拆解工作流跑顺,可以和 Cursor 任务拆解手册 配合使用。
审查维度总表
| 维度 | 重点问题 | 常见漏项 | 什么时候必须深查 |
|---|---|---|---|
| 范围 | 改动是否越界,是否影响非目标模块 | 顺手重构、顺手改命名 | 多文件改动、共享组件 |
| 依赖 | 调用方、配置、路由、状态是否同步更新 | 只改定义不改使用方 | 接口、组件 props、store |
| 测试 | 是否补了单元/集成/冒烟验证 | 只说“建议测试”但不给清单 | 表单、支付、权限、发布 |
| 性能 | 首屏、体积、重复请求、阻塞资源 | 新增库体积、无缓存、重复渲染 | Landing 页、内容页、SSR 页面 |
| 安全 | 输入校验、权限边界、敏感信息泄漏 | 日志泄漏、token 暴露、越权访问 | 登录、用户资料、支付、上传 |
这个表的作用不是把审查搞复杂,而是避免“只看语法,不看风险”。
可以直接复用的审查提示词模板
下面这版适合大多数 Web 项目:
请只审查以下改动范围:
- 文件:<列出文件>
- 目标:<一句话说明这次改动想解决什么>
- 不在范围内:<明确哪些模块不要展开>
请按以下维度输出审查结果:
1. 范围是否越界
2. 依赖与调用方是否漏改
3. 测试与回归项是否不足
4. 性能风险
5. 安全风险
输出要求:
- 只写有根据的问题,不要泛泛而谈
- 每条问题包含:严重级别、位置、原因、建议修复、回归检查点
- 如果没有发现问题,明确说明“未发现高置信问题”,并列出剩余验证风险
这版提示词的关键在于:
- 明确文件范围
- 明确目标
- 明确不要扩散的区域
- 明确输出格式
没有这些约束,工具就很容易变成“泛泛点评机”。
一个更适合前端页面改动的提示词模板
请审查这次页面改动,重点关注:
- 组件输入输出是否一致
- 页面结构是否影响搜索意图与首屏转化
- 是否引入额外性能负担(图片、脚本、渲染)
- 文案、表单、埋点、路由是否存在遗漏
请输出:
- 必修问题
- 可优化问题
- 回归清单(人工验证步骤)
这版更适合 Landing 页、活动页和 Builder 产出的页面审查,因为它把“页面结构”和“业务转化”也纳入了 review 范围。
可执行流程:把 Code Review 做成闭环
第一步:先给出最小上下文
最少要给 Cursor 4 类信息:
- 改动目标
- 影响文件
- 风险敏感点
- 输出格式
例如:
- 这次是登录错误提示修复,不允许扩大到整个鉴权模块
- 必查:用户提示文案、服务端错误透传、前端兜底、登录回归
第二步:让它只找“高置信问题”
如果不加这条限制,很多审查结果会充满“也许”“建议考虑”。
更好的要求是:
- 只输出能定位到文件或逻辑路径的问题
- 没把握的放进“待人工验证风险”
第三步:把问题转换成回归动作
有价值的代码审查,最终应该生成一份回归清单,例如:
| 场景 | 需要验证什么 | 为什么 |
|---|---|---|
| 用户名不存在 | 前端提示统一为用户可读信息 | 防止账户枚举与技术细节泄漏 |
| 密码错误 | 不暴露上游接口地址和状态码 | 保持安全边界 |
| 登录成功 | cookie / token / 登录态正常 | 防止修复副作用 |
| 网络失败 | 前端提示区分系统错误与凭证错误 | 防止误导用户 |
没有这一步,review 很容易停留在“看起来不错,但记不住要测什么”。
失败案例:提示词没限定范围,审查意见反而把团队带偏了
一个常见翻车场景是:
- 开发者改了一个登录弹窗
- 然后直接让 Cursor “review this codebase change”
- 工具开始点评命名风格、目录结构、历史遗留问题
- 真正关键的错误透传和用户提示问题,反而没有被优先指出
根因不是模型能力不够,而是提示词没有做范围控制。
复现条件
- 未指定文件范围
- 未指定这次改动目标
- 未指定优先级维度
结果
- 审查结果过宽
- 高风险问题被低价值建议淹没
- 人工还得二次过滤
修复方法
把提示词改成:
- 只看这几个文件
- 只围绕登录错误提示与鉴权回归
- 输出高置信问题 + 回归动作
回归用例
- 凭证错误是否统一提示
- 技术细节是否还会暴露
- 登录成功路径是否正常
- 未登录访问和过期登录态是否被误伤
Code Review 检查项清单
范围
- 这次改动是否只落在目标文件和必要依赖上
- 是否混入与当前任务无关的“顺手优化”
依赖
- 调用方、类型、接口、文案是否同步更新
- 是否存在只改一半的共享逻辑
测试
- 是否列出最小回归场景
- 是否需要新增自动化或至少人工冒烟验证
性能
- 是否引入额外脚本、依赖或重复请求
- 是否影响首屏、渲染或构建体积
安全
- 是否暴露错误细节、敏感信息、内部 URL
- 是否扩大权限范围或放松校验
什么时候该让 Cursor 审,什么时候不该
适合:
- 多文件改动后的第一轮结构化筛查
- 提交前补齐遗漏项
- 把 review 结果转成测试与回归清单
不适合:
- 完全无上下文地审整个项目
- 让它代替运行测试
- 让它代替业务 owner 做需求判断
如果你正在建立一条更稳的 AI 开发流程,可以继续看:
总结
高质量的 Cursor code review,不靠花哨提示词,而靠这 5 件事:
- 先限定范围
- 再限定审查维度
- 只接受高置信问题
- 每条问题都带修复建议
- 最后转换成回归清单
只要这 5 步做对,AI 审查就不再是“多一个意见来源”,而会变成一条可重复、可验证、可回滚的质量闸门。


