Copilot代码评审提示词优化：解决只提格式问题

你在使用Microsoft Copilot进行代码审查时，是不是总被它反复强调缩进、空格、命名风格这类表层格式问题困扰？而真正的逻辑漏洞、边界条件、安全风险却被完全忽略。根本原因在于默认提示词缺乏明确的评审维度与优先级引导，导致模型自动选择最“保险”的输出路径——格式建议。

直接锁定核心缺陷，压制格式敏感

第一步，在提问开头用一句话锚定评审目标：“跳过所有格式类建议（如PEP 8、命名大小写、空行数量），仅识别可能导致运行时错误、数据丢失、权限越界或拒绝服务的实际缺陷。”

这条指令能有效抑制Copilot默认的格式优先倾向。原因在于其训练数据中PEP 8类提示占比极高，不做约束便会自动输出“看起来有用”的格式修正。

构建分级审查框架，强制排序输出

仅说“找实际缺陷”远远不够，必须给出清晰检查层级。建议在提示词中按严重性降序列出四个检查维度：

① 安全漏洞（SQL注入、硬编码密钥、未校验用户输入）
② 运行时崩溃（空指针解引用、数组越界、除零运算）
③ 业务逻辑错误（状态机跳转遗漏、金额计算精度丢失、并发竞态）
④ 可维护性风险（循环嵌套超4层、重复代码块＞15行、无注释的魔法值）

每条反馈必须附带对应层级编号。示例：“【②】第42行：list.pop()前未检查len(list) > 0”。这既让评审结果一目了然，也倒逼Copilot逐层排查，而非随意挑一个格式问题敷衍。

一个关键约束：若未发现①～③类问题，必须明确声明“未发现高危或中危缺陷”。禁止以“代码整洁”“符合规范”这类模糊结论收尾——那种措辞本质上是在掩盖“未找到实质性问题”的事实。

【硬性规则：未标注层级编号的反馈视为无效，需重新分析】

用真实反例堵住格式话术漏洞

Copilot的训练机制使其倾向于输出安全、常见、不易引发争议的反馈——格式建议恰好符合这一特征。因此需用针对性措施封堵其“格式话术后门”。

方法一：在提示词末尾追加一句：“若你给出类似‘建议将snake_case改为camelCase’或‘if语句后应加空行’的反馈，说明你忽略了指令，请立即停止并重审。”这相当于设置一道警戒线，一旦触碰必须回退重来。

方法二：粘贴一段格式完美但存在明显空指针风险的代码——例如Python中直接调用user.profile.avatar.url而未判空——要求Copilot仅针对该段落评审。当它被迫聚焦真实缺陷后，后续评审倾向会短暂转向更实质的问题。

注意：反例代码必须可真实运行。Copilot对虚构语法（如user?.profile?.avatar）识别不稳定，折腾不存在的写法只会适得其反。

归根结底，让Copilot产出有价值的代码评审，关键不在于问它“有没有问题”，而在于明确告诉它“哪些问题才算数”。你梳理提示词的方式，直接影响它梳理代码的方式。这是典型的“输入决定输出”，值得认真打磨。