Cursor代码评审提示词编写指南

在AI代码评审过程中，提示词的质量至关重要。许多开发者在Cursor等AI编辑器中进行代码审查时，效果差异巨大，关键在于提示词的编写技巧。有人用起来像请了个资深专家坐镇，火眼金睛；有人却感觉AI也就那样，给的建议不疼不痒，甚至还会脑补一堆不存在的“问题”。这中间的差距，很多时候就取决于你输入的提示词。提示词的质量，直接决定了AI反馈是干货还是废话。写得模糊，AI自然就泛泛而谈；写得太宽泛，它又可能完全忽略掉边界条件和安全漏洞这些硬伤。

明确AI代码评审目标与上下文

先得明确目标。别一上来就写“请评审这段代码”，这太模糊了。在提示词的开头，用一句话精准锁定本次评审的核心。例如：“请重点检查这段HTTP路由处理逻辑是否存在未校验的用户输入导致的路径遍历风险”。目标越具体，AI的准头就越好，不容易跑偏去关注那些无关紧要的细节。

然后，你得把完整、可运行的代码块贴进去。千万不要只给个函数头，或者把依赖声明给截断了。如果涉及多个文件，务必用注释标明文件路径，比如 // auth/middleware.go。不这么做，AI可能会因为弄错作用域而给出错误的建议。

最后，还得补充必要的上下文。当前用的框架版本是什么（比如Gin v1.9.1）？部署环境有什么限制（比如运行在Docker容器内且没有SELinux）？有哪些已知的约束条件（比如“该服务禁止使用第三方日志库”）？这些背景信息缺了，AI推荐的可能就是一套用不上的解决方案。

指定评审维度并限制AI自由发挥

评审维度该怎么给？一个很管用的方法是用短句罗列，每项独占一行，用破折号开头，一目了然：
– 检查所有从query、form、path提取的参数是否经过白名单校验
– 确认error返回前是否已记录trace ID
– 验证数据库查询是否使用参数化语句，禁止字符串拼接SQL

更关键的一步，是限制AI的自由发挥。不少开发都遇到过这种情况：AI看着你的代码，突然脑补出一个不在你上下文里的业务规则，然后建议你重构整个模块。这完全是画蛇添足。所以，必须在提示词里明确加上这句话：“【不许推测未出现的业务规则，不许建议重构整个模块，只基于所给代码指出可验证的问题】”。有了这条禁令，AI才会老老实实地基于你给的代码找问题，而不是一个劲儿地“过度设计”。

控制输出格式提升评审效率

这一步千万别省。在提示词末尾，强制约定AI的输出结构。比如：“请按以下顺序输出：① 问题行号；② 原始代码片段（最多3行）；③ 风险类型（如‘XSS’‘竞态’‘空指针’）；④ 修复建议（给出可直接粘贴的代码补丁，含import变更）”。

如果不做这个约束，AI的默认输出往往会把描述性文字和建议混在一起，让你很难快速定位和解决问题。Cursor的AI有时候会把“建议增加单元测试”这种无效信息和真实的漏洞并列输出，让开发者分不清轻重缓急。

最后，加上一句：“发现0个问题时，只回复‘ 未发现高危或中危问题’，不要解释原因。”这能有效防止AI为了凑字数，编造一些可有可无的低价值提醒，让评审报告干净利落。