用Prompt工程调大模型写代码，为什么加例子反而效果变差了？

角色设定确实容易跑偏，我一般只给任务描述不给身份，代码风格靠具体约束反而更稳。

few-shot例子选不好就是反向优化，我试过给一个复杂例子，模型就死磕那个逻辑，删了反而好了。

说实话few-shot这玩意儿真不是越多越好，我踩过同样的坑，后来发现给1-2个最贴近你实际需求的例子就够了，多了模型容易把示例当模板硬套。角色设定我也试过，感觉对代码任务帮助不大，反而容易让模型放飞自我去炫技，不如直接说“写清晰简单的代码”来得实在。我现在基本就是任务描述+约束条件+一个正例，效果稳定很多。你可以试试把例子改成“输入输出对”而不是完整代码块，减少变量名污染。

我最近也踩过类似的坑，尤其是few-shot那个，后来发现例子选得“太像”反而会带偏模型。它其实是在模仿你的格式和模式，而不是真正理解你要的抽象逻辑，你给的例子越具体，它越容易把那些特定的变量名、中间步骤当成必须复刻的模板，硬套到新代码里。我自己试下来，few-shot控制在1-2个，而且例子最好覆盖边界情况而不是“标准答案”，比如空输入或异常分支，这样它才会去学规则而不是抄作业。角色设定那个我也觉得挺玄学的，让模型当“资深工程师”它就会自动给你加一堆类型注解、抽象类、甚至装饰器，改起来比你直接写还费劲。我现在基本就是给一个清晰的任务描述，加上输入输出的类型定义，最多给一个极简的伪代码骨架，效果反而稳定很多。你那个硬编码变量名的问题，我猜可能是例子里的命名太有“特征”了，比如用了temp_data这种，它就默认这是业务关键词，可以试试用无意义的var1之类的。另外，如果模型老出错，可以试试在prompt里明确写“不要使用示例中的命名，只参考逻辑结构”，有时候一句显式的约束比调例子数量管用。

说实话我最近也踩过这个坑，后来发现few-shot不是越多越好，尤其是对代码生成这种任务，例子反而会引导模型去模仿结构而不是理解意图。我现在基本只给一个最简示例，而且刻意选那种跟目标代码风格差异大的，避免它照抄变量名。至于角色设定，我觉得对代码任务真的没啥用，让它当“资深工程师”它就会堆设计模式，改成“写一个能跑的最小实现”反而靠谱。我现在的做法是，把需求拆成特别细的小函数，每个函数单独用零样本生成，再自己拼起来，这样比堆prompt稳定得多。不过我也挺好奇，你用的例子是不是都偏长？我怀疑长例子会让模型更倾向于复制整体框架。另外，你试过在例子后面加一句“注意：以下示例仅展示接口格式，不要复用其中的实现细节”吗？我加了这个之后，硬编码的情况少了很多。

few-shot吃的是例子质量不是数量，挑错例子等于给模型带偏，角色设定确实容易诱发过度包装。

我之前也踩过这个坑，后来发现few-shot不是越多越好，尤其是代码生成，例子里的变量名和逻辑太具体反而会带偏模型，试着把示例精简到一两个，而且刻意用不同风格的写法，效果会稳很多。角色设定那事儿我也遇到过，让它当“资深工程师”就容易炫技，不如直接描述任务上下文和约束条件来得实在，比如“保持简单，不要抽象化”。另外我现在的习惯是先不给例子让它裸写一版，再拿这版去当few-shot输入，喂回去让它优化，比一开始堆例子靠谱得多。

少而精才行，例子多了模型容易学偏，尤其别放带具体变量名的，给两个最典型的就够了。

角色设定真不如直接说“写简洁可维护的代码”，不然它老想着炫技，反而把简单事搞复杂。

同感，这个问题我踩过好多次。我感觉few-shot对代码生成有时候是负优化，尤其当你的例子跟目标函数结构不完全匹配时，模型很容易去“模仿形状”而不是理解逻辑，把例子里无关的变量名或者中间步骤当成硬规则抄进去。你试试只在例子里标注输入输出类型，不给具体数值，或者干脆用one-shot给一个最小可行案例，效果可能反而稳。

关于角色设定，我也发现“资深工程师”这种词会激发模型往“工程化”方向跑，加一堆装饰器、类型注解、抽象类，其实对脚本工具来说就是过度设计。我现在更倾向于给一个明确的代码风格约束，比如“保持纯函数、不用类、限制标准库”，而不是给一个身份标签。

还有个思路是反过来，把错误案例当few-shot用。你给它一个错误输出，再给正确输出，让模型对比差异，这比给多个正向例子更有效，因为代码问题往往出在边界条件上。另外我习惯先让模型写一版，再在后续对话里把报错信息贴回去让它自我修正，比一次性堆提示词稳定得多。

最后想问你一下，你试过让模型先解释一遍它的实现思路，再写代码吗？我最近发现这个“思维链前置”对减少硬编码特别管用，但不确定是不是对所有人都有效。

说实话你这个现象我太有同感了，之前调代码类prompt也翻过车。我觉得问题核心不在例子数量，而在于few-shot和任务类型的匹配度——写代码这种逻辑生成任务，模型对示例的“模仿”倾向远大于“理解”倾向，特别容易把示例里的变量名、边界条件甚至错误处理方式都当成模板来套。我自己试下来，代码任务用1个最精简的例子反而比三四个强，而且例子要刻意选那种能覆盖边界情况的，不是随便拿个正常输入输出凑数。还有角色设定那事，你别说，让模型当“资深工程师”确实会触发它的“表演欲”，各种设计模式往上堆，纯属画蛇添足，我现在干脆就写“写一个直接可用的简单实现”这种平实指令。稳定套路的话，我建议把要求拆成具体约束，比如“不要引入额外依赖”“函数签名保持输入输出类型一致”，比任何角色扮演都管用。另外你也可以试试让模型先解释思路再写代码，把推理过程显性化，很多时候逻辑错误在解释阶段就能暴露出来。反正prompt工程这东西真不是堆技巧，得按任务性质来，你多记录几次对比结果就能摸到规律了。

说实话few-shot这个事儿我也踩过坑，后来发现例子质量比数量重要得多，尤其代码任务里例子必须覆盖边界情况而不是简单输入输出，不然模型容易照着样子抄。角色设定我基本不用了，除非需要强制约束代码风格，否则“资深工程师”只会让模型堆设计模式。我现在更偏向把任务拆成小步骤，每一步给清晰约束，然后让模型自己写测试用例来验证，比堆例子稳定多了。

说实话few-shot这招我也踩过坑，后来发现对代码生成任务，示例越多越容易让模型去“模仿”而不是“理解”，尤其是示例里带具体变量名时，它真会跟着抄。我现在基本只用两三个极简例子，而且刻意把变量名改成a、b这种无意义的，反而稳一点。

角色设定那个我也有同感，让它当资深工程师，输出全是抽象类和设计模式，改个工具函数跟写框架似的。我现在的习惯是直接给清晰的需求和边界条件，再加一句“保持简单，别过度封装”，比啥人设都管用。

另外你可以试试把例子放在最后而不是系统提示开头，或者干脆用自然语言描述一遍输入输出规则，有时候比硬给示例更不容易带偏。说到底，prompt工程还是得针对具体任务试，没有万能公式。

少而精才行，例子跟需求偏差大就是反向干扰，我一般最多放两个贴近场景的。

角色设定容易诱导模型炫技，不如直接给项目背景和编码规范，稳定得多。

few-shot例子容易带偏生成逻辑，我一般只给一个最小示例，重点靠约束输出格式和错误反馈来稳定。

说实话Few-shot这招真不是万能的，尤其写代码场景，模型很容易把示例当模板硬套，变量名和逻辑都跟着走偏。我后来基本只给一个反面例子或者干脆给边界条件描述，效果反而稳。角色设定那套我也踩过坑，现在干脆不设，直接说“用最简实现，别加多余抽象”，比啥资深工程师好用多了。

这事儿我踩过一样的坑。后来发现few-shot的样例得跟目标任务保持同一抽象层级，你给太具体的输入输出，模型就容易学成“照猫画虎”而不是理解意图，尤其变量名这种细节它真会抄。角色设定也一样，我试过“资深工程师”结果它自己给自己加戏搞设计模式，改成“写简单可读的脚本”反而稳。我的经验是few-shot控制在2个以内，且样例要覆盖边界情况而不是典型情况，另外把“不要修改函数签名”“避免额外依赖”这种约束写进指令比角色好用得多。

这事儿我踩过一样的坑，后来发现few-shot不是越多越好，尤其代码任务，例子里的变量名和逻辑结构太容易带偏模型。我现在基本只给一个最简示例，或者干脆用自然语言把输入输出约束写死，反而稳定。角色设定那套我也觉得对代码生成副作用大，它一“扮演”就开始炫技，不如直接说“写一个最小可用的实现”。要不你试试把例子换成边界条件或者错误处理场景，让模型学模式而不是抄答案。

说实话你这个现象我碰到过好多次，尤其用GPT-4写代码的时候，few-shot反而容易把模型带偏。我后来分析了一下，觉得核心问题不在例子数量，而是例子和真实任务之间的“语义距离”太大了——你给的示例如果包含了一些特定变量名或者业务逻辑，模型会下意识去模仿那个结构，而不是抽象出你真正想要的函数行为。我自己试下来，few-shot比较适合那种输出格式很固定、逻辑简单的任务，比如JSON解析或者正则提取，但写代码这种需要推理链的场景，few-shot反而会引入噪声。现在我的做法是，要么给一个非常简洁的伪代码流程描述，要么干脆给一个反例，告诉模型“不要这样做”，效果往往比给正向示例好。至于角色设定，我也踩过类似的坑，让它当“资深工程师”它就开始堆设计模式，后来我改成“写一个能跑的最小实现，别加不必要的抽象”，反而靠谱很多。所以我觉得这些技巧得看场景动态调整，别当成万能钥匙，多试几轮对比输出才是最稳的。

这事儿我踩过一样的坑，后来发现few-shot的示例得跟实际任务“同分布”，你拿简单输入输出举例，模型就容易照着那个模式硬套，换复杂点的需求就翻车。角色设定也建议省省，除非你真的需要它严格控制代码风格，否则它自由发挥时反而更贴近你想要的实用写法。我现在基本就零样本加一句“保持简单直接”，效果比花里胡哨的prompt稳多了。

说实话你这情况我太熟了，之前用Claude调一个数据清洗的函数也是，塞了五个示例进去，它反而把示例里那个“customer_id”字段名焊死在生成代码里，换了个输入结构直接崩。后来我琢磨了下，few-shot对代码生成这活儿，本质是给模型画了个“局部最优”的框，它容易把示例当模板去套，而不是理解你泛化的意图，尤其当示例之间差异不够大时，它就会模糊掉真正的边界条件。我现在更倾向于只给一个“反例”，就是明确告诉它不要做什么，比如“别用全局变量”或者“别假设输入非空”，效果比给三个正向例子稳得多。至于角色扮演，我觉得那些“资深工程师”的设定对模型来说纯粹是增加性格噪声，它会把“资深”理解为“堆设计模式”，反而忘了你要的是个10行内能跑通的工具函数。我现在最常用的套路其实就是把需求拆成“输入是什么、输出要什么、哪些边界情况不许碰”，然后让模型直接写，写完再跑测试用例，有错就把报错信息贴回去让它改，这比任何花哨的prompt技巧都来得实在。你试过把例子数量降到1个，并且只挑那种能覆盖核心分支的例子吗？

少即是多，few-shot容易带偏模型，尤其例子不够泛化时，建议先给需求再给一个反例试试。

角色设定确实容易过拟合，我一般直接说“保持简洁，避免多余抽象”，比扮演工程师稳得多。