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

我之前也遇到过这问题，后来发现把“逐行分析”去掉，改成让它先给整体评价再列具体问题，稳定性会好很多。另外正反例子确实有用，我塞了三个典型坏代码和修正版进去，漏检率明显降了。至于系统1+系统2，我试过拆成两个prompt，第一遍只找明显错误，第二遍再让带上下文深挖，效果比单次强，就是得多花一轮token。

正反例子比角色扮演管用，我试过把漏报和误报的case丢进去，稳定多了。

我之前也踩过这个坑，后来发现问题不在Prompt数量，而在你给它的“工作流”不够清晰。你那个“逐行分析”其实是个伪指令，GPT-4没法真正逐行执行，它只会按语感跳着看，所以漏掉拼写错误很正常。我后来改成两段式：第一段让它只列可疑点，不解释，第二段再针对这些点深入展开，效果稳定很多。另外关于正反例子，我试过在模板里塞一段“好代码审查示例”和一段“坏审查示例”，确实能减少过度解读，但注意例子别太长，不然它容易模仿格式而忽略内容本身。你提到“系统1+系统2”其实挺对的，但实现方式不是让它“先扫再审”，而是把审查目标拆成硬指标（比如变量名长度、函数行数）和软判断（比如逻辑漏洞），分开跑两次Prompt，硬指标用规则性指令，软判断用角色扮演。还有个细节，拼写错误这种低级问题，你可以直接让GPT-4“找出所有单词拼写错误，按行号列出”，别跟性能分析混在一起，混在一起它就会顾此失彼。最后，如果输出还是飘，试试把代码分段喂，一次给它50行以内，准确率会明显上去，代价就是多调几次API，但稳定输出值得。

正反例子得给，光靠角色扮演没用，我试过加两步审查法，漏检少多了。

建议拆成两个prompt跑，第一轮只找明显错误，第二轮再深挖，别指望一次搞定。

我试过类似场景，问题可能出在“逐行分析”这个指令上，它容易让模型陷入局部细节而忽略整体逻辑。建议拆成两轮prompt，第一轮只让它找明显错误，第二轮再针对可疑点展开，这样比一次给太多约束稳定得多。另外正反例子确实有用，但不用太多，给两三个典型的就够，关键是要在例子里标出你期望的“发现”和“不发现”的边界。

正反例子必须给，再让它先列问题清单再逐条过，比直接逐行分析稳得多。

我试过类似的，后来把“逐行分析”去掉反而稳了不少，那个指令容易让模型进入过度分析模式。正反例子确实有用，但别给太多，三个左右就行，重点是让它明白“哪些不用管”。系统1+系统2的思路可以试试，但得明确告诉它第一步只看明显错误，第二步才做深度检查，不然它还是会混着来。另外变量命名这种主观判断，还不如让它只报“潜在风险”和“可疑逻辑”，规则类问题你用pylint更靠谱。

我试过类似的场景，感觉问题出在“逐行分析”这个指令上，它会触发GPT-4的过度补偿机制，反而把简单问题复杂化。建议你把任务拆成两轮，第一轮只让它找“明确错误”，第二轮再让它谈“改进空间”，中间加个“没有发现就直说”的约束。正反例子确实有用，但别给太多，三五个就够，不然它容易照着你的例子硬套。另外变量命名这种主观判断，不如让它用PEP8规范来对照，会稳定很多。

试过类似的场景，我的经验是“扮演专家”和“逐行分析”这种指令反而会干扰输出，因为GPT-4在长上下文里容易陷入局部细节，丢掉全局判断。我现在会拆成两轮prompt，第一轮只让它快速扫描语法错误、拼写问题和明显逻辑漏洞，限定输出格式为“行号+问题+严重级别”，第二轮再让它聚焦逻辑复杂度和可维护性，这时候才提“资深开发者”的视角。你那个“系统1+系统2”的思路其实是对的，但关键是要给每轮设定不同的输入范围，比如第一轮传整个文件，第二轮只传函数体或关键代码段，不然它还是会混着来。正反例子有用，但别给太多，我一般每个问题类型放一个“坏例子+好例子”，并且明确说“参考这些例子中的判断标准，而不是模仿输出风格”。另外，变量命名和函数长度这类主观标准，最好在prompt里量化，比如“超过15行的函数需要说明理由”，否则它每次的尺子都不一样。还有个坑是温度设置，如果API调用的话，把temperature调低到0.1左右，稳定性会明显提升。最后建议你记录每次输出的“漏报”和“误报”情况，跑个十几轮，大概率能找出它内在的偏好模式，比反复调措辞有用。

我试过类似的做法，感觉问题出在“逐行分析”这种指令上，GPT-4一认真就容易用力过猛。你不如拆成两轮：第一轮让它只列可疑点，不带理由，第二轮再针对列出的点追问细节。另外给个反面例子比正面例子管用，比如贴一段故意写烂的代码让它对照着审。还有一种土办法，就是固定输出格式，让它必须按“行号-问题-严重级别”来，能逼它收敛不少。

你这问题我太有同感了，GPT-4对代码审查的“灵性”全看它当天心情。我试过把角色设定删掉，直接给几条真实的正反例，反而比“扮演专家”稳定，你可以试试少点约束、多点样例。

关于“系统1+系统2”，我现在的做法是分两步走：第一轮只让它找明显错误，第二轮再让它分析逻辑和性能，两轮用不同Prompt，效果比一次性塞给它强很多。

另外，建议你明确告诉它“只报告确凿问题，不要猜测”，能压掉不少过度解读。你现在的模板里“逐行分析”可能逼它硬找茬，改成“优先检查高风险模式”试试？

建议拆成两个prompt，先让模型只找bug，再单独跑一轮命名和性能，混在一起它容易精神分裂。

说到这个我太有同感了，之前我调代码审查prompt也卡在“时好时坏”这个坎上。你那个“逐行分析”其实挺容易让模型进入某种“过度努力”的状态，反而会瞎找茬，我后来直接把指令改成“先判断代码是否可读，再找bug，最后才提性能”，顺序一换，输出稳多了。正反例子我觉得必须给，但别给太多，两三个典型就够，比如一个变量命名烂但逻辑对的，一个看起来简洁但有隐藏bug的，模型能学会对比取舍。至于“系统1+系统2”的写法，我试过类似思路，就是先让它“快速通读，标记可疑点”，然后再针对可疑点“深入推理”，但问题在于GPT-4经常在第一步就漏掉关键点，所以我会在第二步里加上“重点检查边界条件和异常处理”这种硬约束。我觉得你现在的瓶颈可能不是约束太多，而是约束太“抽象”，像“逐行分析”这种指令模型理解不了你的真实意图，不如换成“对每个函数，先列出输入输出，再检查类型和空值”。另外一个坑是，如果你同时让它查命名、长度和bug，它注意力会被分散，我自己的做法是拆成两个prompt，一个纯查风格，一个纯查逻辑，跑完再人工合并结果，虽然麻烦点，但稳定性高很多。你可以试试把“扮演资深开发者”这种角色设定去掉，有时候反而更客观，角色一加它容易“演过头”。

我试过类似方法，后来发现关键不是堆指令，而是把任务拆成两轮。第一轮让它只列可疑点，不解释，第二轮再针对这些点深入问，这样比一次给全任务稳定多了。另外你可以试试在prompt里加一句“只报告确定的问题，不确定的单独列在最后”，能明显减少过度解读。正反例子我觉得得加，但别超过三组，多了它反而会乱。你现在的模板是输出格式固定，还是纯自由发挥？这个影响也挺大的。

我之前也踩过这个坑，后来发现“扮演资深开发者”这种角色设定其实是把双刃剑，它会让模型更自信地编造问题，反而忽略了真实bug。建议把prompt拆成两段，第一段明确输出格式：只列问题行号和严重级别，不解释；第二段再让它分析原因和修法，这样能减少幻觉。至于正反例子，我觉得太长的few-shot反而干扰，给2个小而典型的错误案例就够了，关键是让它学会“什么不该报”，比“该报什么”更重要。你说的“系统1+系统2”思路可行，但别用两个独立对话，而是让它在单次回复里先写“快速扫描结果”，再写“深度检查”，用分隔符强制分开，效果比分开调用稳。还有个小技巧，把代码缩进和空行原样贴进去，别压缩，不然模型对函数边界的判断会漂移。最后，变量命名这种主观项建议单独用一份风格指南喂给它，而不是靠通用prompt，不然它今天严格明天宽松。

正反例子必须加，尤其要标注“别管性能只抓bug”，不然它老自己加戏。

试试分两轮：第一轮只查明显错误，第二轮专看逻辑，我这么改后稳多了。

试试先让它只列问题清单再给建议，分两步走会稳很多，例子给两个就够，别贪多。

可以试试把角色设定和任务拆开，先让它找bug再评风格，我这么弄完明显靠谱多了。

你说的这个情况我太有同感了，代码审查这活儿对GPT-4来说确实是个“薛定谔的稳定”场景。我试过几次之后感觉，问题可能不在约束多少，而是你给它的“工作流”不够明确，它自己在那儿摇摆。比如“逐行分析”这种指令，它容易走极端，要么盯着语法细节漏了逻辑，要么为了显得有深度开始脑补性能问题。

我现在的做法是把审查拆成两个独立的Pass，而不是塞进一个Prompt里。第一轮只让它干一件特别窄的事：找拼写错误、未使用的变量、明显不符合PEP8的地方，明确告诉它“不要提任何优化建议”。第二轮再让它当架构师，专注函数复杂度、潜在边界条件和可读性，这时候才允许它谈性能。这样分开后，输出稳定性明显好多了。

另外关于“系统1+系统2”，我觉得可以直接用对话轮次来模拟，而不是在一个Prompt里写“先快速再深度”。比如先发一句“只列问题清单，按严重程度排序，每条不超过10个字”，拿到结果后再追问“针对刚才的清单里P1项，给我具体重构方案”。这样GPT-4的注意力不容易被前后矛盾的要求带偏。

正反例子我觉得可以给，但别太多，给一个“漏报”的坏例子和一个“过度解读”的坏例子就够了，关键是让它明白你容忍的“假阴性”和“假阳性”边界在哪里。你试过让它输出JSON格式的结果吗？固定字段比如“严重度”“行号”“理由”，这样它反而会收敛一些，因为格式本身就成了约束。

我试过类似的场景，问题多半出在“逐行分析”这个指令上，它会让模型陷入细节反而忽略全局。你可以拆成两轮，第一轮只让它找明显错误和坏味道，第二轮再针对可疑片段深挖，比一次性给压力稳定得多。另外给一两个正反例确实有用，但别太多，不然它会过度模仿你的例子格式而不是真正思考。你现在的模板能发出来看看吗？想对比下约束的粒度。

我最近也卡在这块，感觉“扮演资深开发者”这种话术对GPT-4来说太虚了，它反而会往“显摆专业”的方向跑，各种脑补性能问题。不如直接把审查规则量化，比如函数超过30行就提示拆分，变量名小于2个字符才报错，这样输出会稳很多。你试过把“逐行分析”改成“分模块扫描”吗？我这边效果差异还挺明显的。

说实话，你描述的“时好时坏”我太懂了，这玩意儿对代码审查来说就是个概率游戏。我后来放弃让它一次性干完，改成先让它列出所有可疑点（不判断对错），再让它逐条给严重等级和修改建议。这招比“系统1+系统2”更实用，因为第一轮不用纠结判断，压力小，漏检率会低不少。你那个模板里是不是还带了“不要漏掉任何问题”这种

我试过类似的，感觉问题不在约束多，而在没给模型“锚点”。加两三个正反例确实管用，尤其是那种“这行没问题但别硬挑”的反例，能压住它过度发挥。系统1+系统2我也玩过，先让它标出可疑行，再只对标记行深挖，输出稳不少。不过温度别调太高，代码审查这活还是得让它老实点。