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

你说的“系统1+系统2”思路其实可行，我自己试过把任务拆成两轮：第一轮只让它列可疑点，第二轮再针对这些点给具体建议，比一股脑全让它查要稳不少。正反例子也得加，尤其给它看几个“你上次漏掉的错误”和“你上次误报的案例”，模型很快就能学会边界。不过别指望它完全稳定，代码审查这事本身就有主观性，我会把它当辅助工具，关键逻辑还是得自己过一眼。你那个逐行分析的指令可能是干扰项，换成“先概括整体结构再逐层深入”试试看？

试试拆成两轮：先让它只找bug，再单独查风格，别指望一个prompt全干。

我试过给反例有点用，但别太多，不然它光顾着模仿反例了。

你这情况我也踩过坑，问题不在约束多少，而是GPT-4对“代码审查”的理解太宽泛。建议把任务拆成两轮，第一轮只让它找语法和拼写错误，第二轮再给定具体规则（比如函数超过20行就提示），不然它会自己脑补标准。正反例子得给，但别超过3个，不然它容易学偏。系统1+系统2的思路可行，我试过让它在第一轮输出“可疑点清单”，第二轮再针对清单深挖，稳定性比一次过好很多。

这问题我也踩过坑，核心是别让GPT-4“自由发挥”。我试过把“逐行分析”改成“按优先级输出：致命错误、可读性问题、性能隐患”，外加一个真实bug的few-shot示例，稳定性立刻上来了。系统1+系统2思路可行，但别让它在一条prompt里分阶段，而是拆成两条独立请求，先让它快速列可疑点，再针对可疑点做深度追查。另外变量命名这种主观问题它判得很飘，我后来直接改成只让它查硬伤（比如未定义变量、逻辑矛盾），风格问题丢给linter。

建议拆成两级prompt，先让模型快速扫语法和命名，再针对可疑段落做深度分析，别一把梭。

试试few-shot给两个好坏例子，比光堆角色设定稳多了，我这么调完漏报少不少。

这问题我太有同感了，GPT-4做代码审查的波动性确实让人头大。我个人觉得你那个“逐行分析”的指令可能是个坑，它会让模型进入一种“必须找出点什么”的模式，反而把简单拼写错误这种低垂果实给忽略了。我现在的做法是拆成两轮，第一轮只给一段代码和一个笼统的问题“有没有明显错误”，让它先跑系统1；第二轮再拿第一轮的输出，加上“现在从性能、可维护性角度深挖”这种指令，逼它开系统2。另外正反例子特别管用，但别给太多，我试过给3个案例效果最好，给多了它反而会开始模仿案例里的风格而不是代码本身。还有个小技巧是让它“用一句话总结每个问题的严重性和修改成本”，这比单纯列问题要稳定得多，能逼它做优先级判断。你试过在prompt里限制它“只报告确定性超过80%的问题”吗？我这么干之后误报率低了不少。

我也踩过这个坑，专门给代码审查写Prompt反而容易翻车。后来试了下把任务拆成两轮，第一轮只让它列客观问题清单，第二轮才给修改建议，稳定性好很多。你提到的“系统1+系统2”思路其实可行，但别在一条Prompt里同时要求，GPT-4会自己找平衡点。另外建议别再堆角色设定了，给一个真实的有bug的代码片段当few-shot例子，比说一百遍“资深开发者”都管用。

我之前也踩过这个坑，加太多角色设定反而容易让模型自作聪明。后来我把任务拆成两段，第一段让它只列可疑点不解释，第二段再集中深度分析，输出稳定很多。

正反例子其实挺有用的，但我建议别给太多，三个左右就够，不然它容易照着例子模式硬套。你试试把“逐行分析”改成“按严重级别输出”，效果可能不一样。

对了，你检查的时候是不是把代码贴成一大坨了？分块喂给它，每块限制在50行左右，漏检率明显低一些。

我试过类似的场景，最后发现问题不在Prompt长短，而是输出格式太开放了。你试着让它先给一个“问题清单+严重级别”的固定结构，再针对每项给具体行号和修改建议，稳定性会提高不少。

另外“逐行分析”这种指令其实容易触发过度解读，改成“优先检查逻辑错误和边界条件，命名和风格问题放最后”会更贴近真实审查习惯。正反例子我觉得不用给太多，给一个它上次漏掉的明显bug案例就够了，多了反而容易让它“照着范例找问题”而忽略整体。

系统1+系统2的思路可行，但直接写两轮Prompt调用可能比一个模板里塞两个阶段更可控，第一轮让它快速列可疑点，第二轮针对可疑点深入，我自己这么改后效果明显稳了。

我觉得问题可能出在“逐行分析”这个指令上，GPT-4一旦进入逐行模式就容易陷入局部视角，反而丢了全局判断。我自己试过类似情况，后来把prompt拆成两轮：第一轮只让它列“可疑点清单”并标注严重级别，第二轮才针对清单里的每项给具体修改建议，这样稳定性高了不少。正反例子确实有用，但不用给太多，我一般放一个典型的“命名混乱但逻辑正确”的片段和一个“看似简洁但有副作用”的片段，它就比较容易锚定你要的审查粒度。至于“系统1+系统2”，其实可以写成“先快速扫一遍，只报最可能影响正确性的问题；再花时间检查可读性和性能”，但关键是每轮都要明确限定输出格式，比如“用列表，每项必须包含行号和理由”。还有个坑是温度参数，代码审查这种场景我基本固定temperature=0.2，太高了它就开始创造性发挥，把正常代码脑补成反模式。另外你说的漏拼写错误，我怀疑是模型把注意力放在语义上，对词法层面的检查天然弱，所以我会补一句“特别注意变量名是否拼写一致，包括大小写和单复数”，效果立竿见影。你现在的模板是单次调用还是多次交互？如果是单次，建议改成先让它输出审查报告，你再追问具体某条的判断依据，这样能减少它为了迎合你而过度解读的倾向。

我之前也遇到过同样的问题，后来发现不是prompt越多越好，反而是给一两个具体的正反例比“扮演资深开发者”管用得多。你那个“逐行分析”太容易触发过度解读，不如改成“只标注确定有问题的点，并给出理由”，这样能明显减少幻觉。系统1+系统2的思路我觉得可行，但建议拆成两次调用：第一轮只查明显错误，第二轮再针对函数复杂度和逻辑漏洞，不然GPT-4容易在长上下文里自己乱掉。你试过在模板里加“如果没有问题就明确说无问题”这句吗？我加了之后稳定性提升不少。

我也踩过这个坑，后来发现“逐行分析”这种指令其实会触发模型过度补偿，反而容易漏掉全局问题。你试试把任务拆成两轮，第一轮只让它列可疑点，不解释理由，第二轮再针对这些点给具体建议，输出稳定很多。另外正反例子确实有用，但别给太多，三五个就够，不然模型会学着你的例子去“找茬”，而不是真正理解意图。

我觉得问题可能不在约束太多，而在于你给的“角色”和“任务”之间缺少一层具体的检查清单。GPT-4对“逐行分析”的理解很模糊，它容易在“找bug”和“找风格问题”之间来回横跳，所以输出才不稳定。我试过类似场景，后来把prompt拆成两段：第一段只让它列事实性问题（比如未定义变量、异常处理缺失），第二段再让它提优化建议，并且明确写“没把握的不要写”，效果会好很多。正反例子确实有用，但别放太多，放两个典型的就行——一个漏检案例，一个过度解读案例，让它模仿那个“度”。你提到的系统1+系统2思路我试过，但得靠外部控制，比如先跑一遍pylint或flake8把机械问题过滤掉，再让GPT-4专注逻辑和设计，不然它还是会混在一起。另外，温度参数记得调低点，或者固定成0，代码审查这种场景随机性就是毒药。我还有个疑问：你模板里有没有让它输出“置信度”或者“问题严重级别”？加了这层之后，我会更清楚哪些该信哪些该忽略。

说实话你这个问题我太有共鸣了，GPT-4在代码审查上确实像个时灵时不灵的老员工。我试过跟你类似的模板，后来发现“逐行分析”这种指令反而会触发它的“过度努力”模式，把正常逻辑当成反模式来挑刺。我的做法是干脆把任务拆成两个独立调用，第一个Prompt只让它找“会导致运行错误或逻辑矛盾”的问题，第二个Prompt再让它看代码风格和性能，中间用固定的JSON格式输出，这样比一个复杂Prompt稳定得多。关于正反例子，我觉得给一个“绝对不该漏掉”的bug案例比给正面范例更有用，比如故意放一个变量名拼写不一致的代码进去，它记住这个模式后漏检率会明显下降。还有个细节，别在Prompt里写“资深开发者”，写“你有十年Python维护经验，重点检查可维护性”反而更精准，因为“资深”这种词太抽象，它不知道你要哪种资深。你说的“系统1+系统2”思路我试过，但实现方式不是靠Prompt说“先快速再深度”，而是靠temperature设置——第一遍用0.2做快速扫描，第二遍用0.7做深度分析，效果比在文字里写两阶段要实在得多。最后想问下，你那个“性能问题”的误报，是不是经常集中在循环和列表推导式上？如果是的话，可以在Prompt里加一句“仅当操作复杂度超过O(n²)时才提性能”，能砍掉大半假警报。

我之前也遇到过同样的问题，后来发现关键不是堆约束，而是把任务拆成两步走。你可以先让它只列“可疑点”和“具体行号”，别让它直接给结论，这样漏检率会低很多。至于系统1+系统2，我试过在prompt里写“先快速扫描明显错误，再针对复杂逻辑做深度分析”，但效果一般，GPT-4容易在第二步又回到过度解读的老路。我个人觉得给两三个正反例子特别管用，尤其是反例，比如“这段代码没性能问题，不要提”比单纯说“别过度解读”有效得多。另外变量命名这种主观项，建议你单独开一个prompt，跟bug检查分开，不然它总会混着回答。

试过把“逐行分析”改成“先列出最可疑的5个点，再解释原因”后，稳定了不少。你这情况我觉得不是约束太多，而是少了优先级排序，GPT-4一上来就想着全覆盖反而容易抓瞎。正反例子可以加，但别超过三组，多了它反而会学着模仿错误案例里的坏习惯。系统1加系统2的思路可行，不过建议明确告诉它第一阶段只查语法和命名，第二阶段才看逻辑和性能，不然它还是会混着来。

我试过类似的场景，感觉问题出在你让它“逐行分析”上——GPT-4一旦被要求全量覆盖，反而容易产生“平均用力”的错觉，该深挖的地方没深挖。与其给正反例子，不如把任务拆成两轮：第一轮用“只找明显错误和命名问题”这种限缩指令，第二轮再针对函数复杂度给一个阈值标准，比如“超过30行或嵌套超过3层才提”。另外，你可以试试在Prompt里加一句“如果某处没有把握，就明确说需要人工确认”，能显著减少它硬编造问题的次数。

试过把审查拆成两轮，第一轮只列客观问题不解释，第二轮针对筛选出的点让模型给理由和优先级，比一次性让它“全面分析”稳定很多。正反例子我加过几条，但感觉不如直接限定输出格式有效，比如让它按“严重程度+行号+原因”来写，能逼它更聚焦。你那个“逐行分析”可能确实太宽泛，模型容易自己加戏，试试让它先跑一遍静态检查规则，再手动指定几个关注维度。另外，拼写错误这种小事别指望GPT，交给linter更靠谱。

试试先给个检查清单再加个“只报确定问题”的兜底指令，能稳不少。系统1+2容易让它废话变多。

分两轮跑吧，第一轮限定只挑死错误，第二轮再让它聊设计，不然它老把风格问题当bug报。

试试先让它列问题清单再逐条给建议，分两轮走，输出会稳很多，单轮全包确实容易飘。

给它喂两个坏例子加一个好例子，比光写“逐行分析”管用，这玩意儿就得靠few-shot拽着。