用Prompt调优GPT-4做代码审查，效果时好时坏，求大佬指点

这问题我太有同感了，GPT-4做代码审查的方差大得离谱，跟抽卡似的。你那个“扮演资深开发者”和“逐行分析”其实方向没错，但问题在于它会把“逐行”理解成每行都要挑点毛病出来，结果就变成了过度解读。我个人试下来，最管用的做法是把审查目标拆成两轮，第一轮给它看整体数据流和函数职责，让它只报“可能影响逻辑的异常”，第二轮再限定具体范围，比如“只查变量命名和函数长度，忽略性能”，这样能明显减少瞎指挥的情况。正反例子确实得加，但不用多，各给两三个就够了，关键是让它明白“漏报”比“误报”更不可接受，不然它为了保险就会疯狂刷存在感。你说的系统1+系统2思路挺对的，我现在的做法就是先让模型用一句话概括每个函数在干嘛，再让它针对概括里出现的矛盾点深挖，这比直接让它扫代码稳定很多。还有个歪招，你可以故意在代码里埋一两个小bug，然后Prompt里提一句“已知存在两个错误”，有时候能逼它更认真找。

我试过类似的做法，后来发现“逐行分析”这种指令反而会让模型陷入局部，漏掉整体逻辑问题。不如改成先让它总结函数职责，再找具体反例，效果稳定些。正反例子确实管用，但别给太多，一两个就够，不然它容易机械模仿。你那个“系统1+系统2”的思路挺有意思，我试过拆成两轮对话，先快速检查再深入，比一个Prompt里塞两种要求靠谱多了。

我最近也踩过类似的坑，加太多角色设定反而会让模型发挥失常。后来我改成两轮prompt，第一轮让它只列问题清单，第二轮针对清单逐项给修改建议，稳定性明显好多了。正反例子确实有用，但别超过三组，不然它会过度拟合你的示例格式。系统1+系统2的思路对代码审查挺合适，关键是第一轮要明确告诉它“只找硬伤，别管风格”，不然它老爱瞎操心。

我试过类似的场景，后来发现把“逐行分析”改成“先按优先级列出最可能出问题的模式”会稳很多，不然GPT-4容易陷入细节里瞎较劲。正反例子我个人觉得挺管用的，尤其放一个明显有bug的代码和一个干净的代码，比纯描述规则效果好。系统1+系统2的思路我也试过，但得明确告诉它第一遍只查致命错误，第二遍再看风格，不然它还是会混着来。你现在的Prompt里是不是没有限定“哪些检查项必须报，哪些可以忽略”？这个边界不画清楚，输出肯定飘。

我自己的经验是，别让它直接开干，先问它“这段代码里哪些变量名或控制流可能让新维护者困惑”，让它自己生成候选清单，再逐条确认，相当于把审查拆成两步。正反例确实有用，但别给太多，一正一反就够，多了它会开始猜你的意图。另外“扮演资深开发者”这种话效果不大，反而容易让它放飞自我，不如直接写“你是代码评审工具，输出格式为：严重问题/建议/忽略”。你试过把温度调低到0.1吗？代码审查这种任务，温度越低稳定性越明显，虽然偶尔会显得死板，但至少不会漏拼写错误。

我跟你正好相反，之前也是模板套一堆，后来砍到只剩“找出会导致

试试拆成两轮，第一轮只查语法和命名，第二轮再让它找逻辑问题，比一次全查稳得多。

给个正反例对比确实管用，我加了“这是坏代码，这是好代码”示例后，误报少了一大半。

这问题我踩过一样的坑，GPT-4对代码审查其实挺吃上下文的，你那个“逐行分析”反而容易让它陷入局部细节，漏掉全局问题。建议把模板拆成两轮，第一轮只让它列可疑点，第二轮再针对每个点给理由和严重等级，这样输出会稳很多。另外正反例子真的有用，尤其是你明确标注“这段代码有bug”和“这段没问题”的对比样本，模型能学会尺度，不然它自己就飘了。还有个土办法，给代码加个注释“只查逻辑错误，不讨论风格”，能明显减少过度解读。

我试过类似玩法，问题很可能出在任务拆分上。GPT-4对“逐行分析”这种指令太容易走极端，建议你把“查bug”和“查风格”拆成两次独立对话，一次只让它干一件事。正反例子确实管用，比单纯描述要求有效得多，但别超过三组，太多反而干扰它判断。至于系统1+系统2的思路，实际操作可以先用一个极简prompt让它快速列可疑点，再拿这个输出当第二轮输入要求展开，这样稳定性会好很多。

正反例子是真得加，尤其给几个“漏报”和“误报”的案例，模型会更快校准边界。你那个“逐行分析”可能反而让它太聚焦局部，建议拆成两轮，第一轮只问“有没有明显错误”，第二轮再给上下文问“潜在风险”。另外变量命名这类风格问题，不如直接丢给它你们团队的编码规范片段，比角色扮演管用。

我试过类似玩法，最后发现“逐行分析”这种指令其实是双刃剑，它会让模型进入一种“挑刺模式”，反而容易忽略全局逻辑。你提到的系统1+系统2思路我觉得方向对，但别用太玄的概念，直接拆成两个独立prompt调用：第一轮只让它列“可疑点清单”并给出置信度，第二轮再针对清单逐项深挖，这样输出方差会小很多。另外正反例其实比角色扮演管用，我塞了三个“典型坏味道”代码片段和对应正确审查结果后，稳定性提升明显，但注意例子别太多，不然模型会机械套用。还有个坑是GPT-4对“性能问题”特别敏感，动不动就说你O(n²)，你可以在模板里加一句“仅当数据量超过百万级时再讨论性能”，能减少很多误报。最后我习惯在prompt末尾加“如果没有发现问题，请明确说‘未发现明显异常’”，逼它做默认输出，避免为了显得有用而瞎编。你的模板里约束多可能不是主因，关键是让模型知道“什么不该做”比“该做什么”更有效。

说实话我也踩过这个坑，一开始给GPT-4塞了一堆角色设定和规则，结果它反而变得畏手畏脚，该抓的bug不抓，不该管的事瞎操心。你说的“系统1+系统2”思路我觉得靠谱，我现在就是拆成两个prompt跑：第一轮让它只做静态扫描，列可疑点，不解释；第二轮针对第一轮的结果做深度推演，比如数据流和边界条件。这样输出稳定多了，但代价是token消耗翻倍，得看你能不能接受。

另外正反例子确实比抽象指令管用，尤其是漏检拼写错误这种低级问题，直接给它看一个“错误拼写”的样本，比说一万遍“要仔细”都强。不过我也在纠结，是不是该给每个规则设个置信度阈值，比如某些检查项命中率低就自动降权，不然它老是把“可能性能问题”当成“一定有问题”来报。你现在的模板大概多少行？我怀疑是不是指令堆太长了，它反而抓不住重点，有时候我精简到20行以内效果反而更好。

我试过类似的场景，最后发现“扮演资深开发者”这种指令其实没啥用，GPT-4对角色扮演的敏感度远不如对任务拆解的敏感度。建议你把审查拆成两轮，第一轮只查语法和拼写，第二轮专门看逻辑和性能，每轮用不同的评分标准，这样比一条prompt硬扛要稳得多。另外你提到“逐行分析”，这个指令太模糊了，模型容易陷入过度细节，不如改成“先列出所有可疑点，再按严重程度排序”，输出结构会清晰很多。我也踩过“给正反例子”的坑，给太多反而会让模型模仿例子里的错误模式，不如只给一个极简的正面模板，然后靠温度参数调低来稳定输出。还有个土办法，就是让模型先输出“审查计划”再执行，相当于逼它走一遍系统1的快速扫描，再进系统2的深度检查，你可以试试看效果。

这问题我太有共鸣了，GPT-4对代码审查的“时好时坏”基本就是常态。你那个“逐行分析”的指令其实挺容易让它进入过度分析模式，反而漏掉大问题。我试过给两三个正反例放prompt里，比单纯强调角色有用得多，但例子一多输出又容易变啰嗦。系统1+系统2的思路我觉得可行，就是拆成两轮对话，第一轮让它快速列可疑点，第二轮再针对可疑点深入查，这样逻辑上更可控，你可以试试看效果。

另外我怀疑你模板里“变量命名”和“性能问题”这种关键词放在一起，会让它在两者之间摇摆不定。我自己是把“潜在bug”单独拎出来做一轮专项审查，其他风格问题再单独一轮，分开来稳定很多。

试试把“逐行分析”改成“先列问题清单再给修改建议”，加个few-shot示例稳定很多。

试试拆成两轮：先让它只找bug，再单独查风格，目标单一输出会稳很多。

正反例子必须给，尤其放个它漏掉的拼写错误当few-shot，比光堆角色指令管用。

试试分两轮，第一轮只让找bug，第二轮专门查风格，别混一起，稳定不少。

我试过给几个坏例子当few-shot，比纯指令管用，要不你加个“漏报比误报更严重”试试？

我试过类似的，问题出在“逐行分析”这个指令太容易被GPT-4理解成“每条都要评论”，反而分散了注意力。现在我的做法是先丢给它一段坏代码样本，明确说“只找这类问题”，然后再给目标代码，效果稳很多。

至于系统1+系统2，你可以拆成两个prompt分两次调用，第一次让它用一句话总结每个函数的功能，第二次再针对总结里可疑的地方深挖。我试过在一个prompt里塞两个阶段，它经常做着做着就混了。

还有个偏方，把“请扮演”删掉，改成“你是Python linter，输出格式为警告级别：问题描述”，它反而更听话。你试试是不是输出格式太自由导致的波动。

试过把审查拆成两轮，第一轮只让模型列“可疑点清单”不给建议，第二轮再让它针对清单逐条展开。这样比一次性要求“逐行分析”稳定不少，漏检率明显降了。另外正反例子真得给，我之前塞了三个改前改后对比，它判断“过度解读”的毛病好了很多。你那个“系统1+系统2”的思路我觉得可行，但得注意别让两轮prompt互相污染上下文，中间加个分隔符隔开效果会好点。

这问题我太有同感了，GPT-4对代码审查的“手感”确实飘忽。你那个“逐行分析”的指令可能反而害了它，模型容易为了满足要求而强行找茬。我试过给一正一反两个示例代码，比单纯说“要严格”管用得多，它更能抓住你期望的尺度。至于“系统1+系统2”的思路，可以拆成两个独立Prompt跑两遍，第一遍让它只报明显错误，第二遍再让它从架构层面挑刺，最后人工合并结果，稳定性比一次性强求高不少。

这问题我太有同感了，GPT-4对代码审查的敏感度确实跟抽风似的。我觉得你那个“逐行分析”的指令可能反而害了它，模型容易为了完成任务强行找茬，漏掉真正关键的逻辑问题。建议你试试把任务拆成两轮，第一轮只让它报“明显错误”和“可疑点”，第二轮再让它针对可疑点展开，这样比一次性塞给它一堆要求稳得多。另外正反例子很有用，尤其是你贴一个故意写烂的代码和一个优质代码，让它先对比再审，输出质量能上去一截。

这问题我太有同感了，代码审查这种任务其实特别吃上下文一致性，你加太多角色扮演反而会让模型分心。我建议把“逐行分析”拆成两个独立prompt轮流跑，第一轮只查明显错误，第二轮再让模型集中找逻辑问题，效果会比一个复杂模板稳定很多。

另外你提到的正反例子非常关键，我试过在prompt里塞两三个“该报不报”和“过度报告”的对比片段，输出质量立刻上了一个台阶。不过别放太多，五六个以内吧，不然它容易学着扩大化。

还有个土办法，我一般会限定输出格式，比如要求每条评论带“严重程度+行号+理由”，这样就算它偶尔抽风，你也能快速过滤掉无效信息。至于系统1系统2的写法，我感觉不如直接跑两遍，把第一遍的结果丢进第二遍让它复核，比硬塞在一条prompt里好使。