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

试试分两步走，先让它标出可疑点，再逐条深挖，比一次性全审稳多了。

我试过类似思路，感觉问题不在约束多少，而是任务太杂了。变量命名、函数长度、潜在bug其实是三种不同的审查标准，混在一个Prompt里模型很容易顾此失彼。后来我拆成两轮：第一轮只让它标出可疑行，不给理由；第二轮再把可疑行喂回去让它逐条解释。这样漏报少很多，过度解读也压下来了。你那个系统1+系统2的想法方向是对的，但得用两次调用实现，别指望一个Prompt里写“先扫再深审”就能稳定。

我之前也折腾过一阵子用GPT-4做code review，确实会有这种时好时坏的感觉。你那个“系统1+系统2”的思路其实挺对的，我后来就是这么改的，先让它快速扫一遍列出可疑点，再针对每个点单独追问，让它给出具体理由和修改建议。这样比自己在一个prompt里塞一堆要求稳定多了，因为模型每次只专注一件事，不容易跑偏。

关于例子的问题，我觉得给正反例有用但别给太多，两三个就够了，重点是要把“什么算问题、什么不算”的边界说清楚。比如你可以在prompt里明确写“只报告会导致运行时错误或明显维护困难的命名问题，不要纠结风格偏好”，这样它就不会把正常代码硬说成性能问题了。另外“逐行分析”这个指令其实挺坑的，容易让它陷入细节，反而漏掉整体逻辑上的bug，不如让它先看函数级别再往下钻。

还有个我踩过的坑是temperature别调太高，做代码审查这种要稳定输出的场景，0.2左右比较合适。另外每次审查前最好把代码按功能块拆开喂给它，一次塞几百行它注意力会散。你那个拼写错误漏掉的情况，我怀疑是prompt里“资深开发者”这个角色设定让它默认你写的都是对的，反而不去挑低级错误了，可以试试去掉角色扮演，直接说“找出所有拼写和语法错误”。

分两步走确实稳，先让它标问题再逐条细审，比一股脑全丢给它好多了。

有没有更详细的教程推荐？

这个思路不错，收藏了。

先给正反例再让它审，比堆指令管用。我一般分两步：第一轮只挑明显bug，第二轮再深挖。

代码审查这活儿确实挺吃prompt结构的，我自己的经验是别把规则堆太满，先给个明确角色和输出格式，比如要求按“问题类型+行号+建议”来列。正反例子特别管用，尤其是贴两段你认可的审查结果当few-shot，稳定性会好很多。你提的“先扫再深审”我也试过，分成两步调用比塞一个prompt里靠谱，第一步只让它标可疑点，第二步再逐条展开，漏报和过度解读都能压下去。

我之前也踩过差不多的坑，后来发现核心问题不在指令多不多，而是任务边界太模糊了。你让它同时管命名、长度和bug，它其实是在一个pass里做三件事，注意力很容易被稀释掉。我现在会拆成两三个独立调用，比如先只做命名规范检查，再单独跑逻辑bug扫描，每轮只给一个明确目标，输出稳定性明显好很多。正反例子确实有用，但别塞太多，两三个典型就够，多了它反而会硬套模式。至于系统1加系统2那套，我试过先让它列可疑点再逐条深审，但前提是第一轮必须限制它只标记行号、不解释，不然它第一轮就开始长篇大论，第二轮反而没重点了。另外温度调低一点，代码审查这种场景不太需要发挥。

我之前也踩过这个坑，后来发现核心问题不在约束多少，而在于你把“审什么”和“怎么审”混在一个Prompt里了。GPT-4做代码审查时，如果让它同时兼顾命名、长度、bug、性能，注意力会被稀释，漏掉拼写错误太正常了。我现在是拆成两轮：第一轮只让它输出所有可能的异常点，不给任何评判标准，相当于“系统1”快速扫描；第二轮再针对每个异常点用单独Prompt深入分析，这时候它反而更稳。另外正反例确实有用，但别给太多，两三个典型的就够了，给多了它会强行往例子上套。你说的“系统1+系统2”写法其实可行，但别写在一个Prompt里，分两次调用效果更好。还有个小技巧，审查前先让它复述一遍你的审查规则，确认它理解了再开始，能减少不少过度解读。

代码审查这个场景我踩过差不多的坑，说点实际的。GPT-4做审查不稳，很多时候不是约束太多，而是约束太“泛”了——“资深开发者”“逐行分析”这种指令对它来说信息量几乎为零，它每次激活的审查视角都不一样，输出自然飘。我现在会把它拆成两步：第一步只让它输出问题清单，每条必须带行号和一句理由，不给建议；第二步再针对清单逐条让它给修复方案。这样能强制它先定位再判断，漏报会少很多。例子确实有用，但别给正反例各一堆，挑两三个你项目里真实的典型case，一个该报一个不该报，塞在system里当锚点就够了。“系统1+系统2”的写法我试过，本质就是两轮调用，别指望一次prompt里让它自己切换，模型做不到那么自觉。另外函数长度、命名这类偏主观的规则，最好你在prompt里给死阈值，比如超过30行才算长，不然它每次的尺度都不同。还有个容易被忽略的点：把diff而不是整个文件喂给它，上下文干净了，过度解读会明显下降。

代码审查这事我也折腾过一阵，后来发现把“逐行分析”去掉反而稳了，因为模型一旦被要求逐行就容易凑字数硬挑毛病。我的做法是拆成两步：先让它只输出最严重的三个问题，不带解释；确认没问题后再单独追问某一处的细节。给正反例确实有用，但例子别太多，两三个就够了，多了它反而会往例子上硬套。你说的系统1加系统2，其实就是先扫后审，这个思路靠谱，我自己也是这么跑的。

代码审查这活儿我试过，光靠角色扮演确实不稳。后来我改成两段式：第一轮只让它列问题清单别展开，第二轮再挑重点让它逐条给理由和修法，这样漏报少很多。正反例也关键，我塞了两三个“这种命名该报、这种别瞎报”的样本后，过度解读明显收敛。你那个系统1加系统2的思路其实就接近这个，先粗筛再深挖，别指望一次Prompt全搞定。

有没有更详细的教程推荐？

刚入门，这个对我帮助很大。

我试过类似的，后来发现把“逐行分析”去掉反而稳一些，那个指令容易让它钻牛角尖。给正反例确实有用，但别塞太多，两三个典型就够，多了它会过度模仿。你说的系统1+系统2思路我试过，先让它只输出问题清单不给解释，再单独跑一轮让它对每个问题给理由，稳定性明显好点。另外变量命名这种最好明确给规则，比如PEP8还是你们团队规范，不然它自己发挥就飘。