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

角色设定真的容易用力过猛，我之前也踩过坑，现在基本只给约束不给身份。

few-shot例子得和实际任务保持同分布，变量名太具体就容易带偏，试下只给伪代码或骨架。

说实话few-shot这玩意儿真不是越多越好，我试过给三个例子模型就老爱模仿例子的写法，最后只留一个最典型的效果反而稳。角色设定那个我也踩过坑，它一旦代入“资深工程师”就开始加类型注解和抽象类，写个小工具完全没必要，直接说“用最简单的方式实现”反而靠谱。

我现在的习惯是，先裸跑一遍看结果，再根据具体错误给一条针对性修正提示，比堆例子高效多了。你不如试试把任务拆成更小的函数描述，让模型每一步只干一件事，出错概率会低很多。另外变量名硬编码的问题，可以在提示里加一句“不得使用示例中的变量名”，基本能解决。

few-shot真不是越多越好，例子得跟目标任务高度对齐，不然模型容易学歪。角色设定我一般只用在复杂任务上，简单工具函数反而画蛇添足。

你这个问题我踩过一样的坑，few-shot别贪多，两三个够了，而且例子得跟目标输出结构高度一致，不然模型容易跑偏。

角色设定确实容易引发过度设计，我后来干脆只在代码注释里提要求，效果反而稳。

few-shot例子得跟实际任务同分布，不然模型容易抄错，尤其变量名这种细节，我一般控制在一个例子内。

角色设定确实容易放飞自我，我后来都改成“写简洁可维护的代码”这种具体指令，比假人设管用。

说实话few-shot这玩意儿真不是越多越好，我试过给两三个精炼例子反而比四五个强，关键是例子的边界要清晰，别让模型误以为你只想要那种模式。角色设定我基本不用了，除非是特别固定的风格任务，不然它一“入戏”就容易自作聪明加一堆没用的抽象层。我现在更倾向把需求拆成原子化的函数描述，配上输入输出约束的伪代码，比堆例子稳定得多，你可以试试用类型注解和docstring把逻辑焊死。

说实话few-shot这玩意儿真不是越多越好，我试过给两三个精炼例子效果还行，给到五个以上模型就开始找规律硬套了。你那个变量名被硬编码的问题，大概率是示例里的上下文太具体，模型把“例子”当成了“模板”。角色设定我建议直接砍掉，尤其写代码时，“资深工程师”这种词会让模型往复杂了整，我都是直接说“写一段简单可读的代码”，效果反而稳。我现在基本就靠把需求拆成小函数+明确输入输出类型，比堆技巧靠谱多了。

少样本这玩意儿真得看场景，代码生成跟文本分类不一样，例子里的变量名和逻辑太容易被模型当成模板硬套了。我试过把示例缩减到一个，并且刻意用跟目标函数完全不同的业务语义，反而稳定不少。角色设定那个我也踩过坑，给它安头衔容易触发"炫技模式"，不如直接说"保持简洁，优先用标准库"来得实在。现在我的做法是：先零样本跑一遍，再针对报错或边界情况补一个针对性例子，比开局就堆一堆示例靠谱得多。

这事儿太真实了，few-shot选不好就是给模型带沟里，我一般只放一个最简例子，多了必翻车。

角色设定那招我也踩过坑，别让它演大神，直接说“写简单能跑的代码”反而靠谱。

说实话Few-shot这玩意儿真不是越多越好，我踩过坑，例子一多模型容易把“格式”当“规则”，尤其代码任务里它会把示例的变量名和结构当成硬约束。我后来一般只放1-2个最典型的例子，而且刻意让示例之间的逻辑差异大一点，反而稳。角色设定那个我也试过，演“资深工程师”确实容易飘，后来我改成“写简洁可维护的代码”这种指令式约束，效果比角色扮演靠谱多了。

说实话你这情况我太熟了，few-shot真不是万能的，尤其写代码这种任务，模型很容易把示例当模板去套，反而忽略了你prompt里真正的需求描述。我个人感觉，加例子的时候得选那种能覆盖边界情况的，而不是简单的一对一输入输出，不然模型就会学歪，你说的硬编码变量名就是典型症状。另外我猜你可能把例子放在系统提示里了？我现在习惯把示例放在用户消息最后，紧贴着当前任务，这样模型会更倾向于参考格式而不是内容本身。关于角色设定，我试过几次也觉得弊大于利，“资深工程师”这种设定会让模型自动开启炫技模式，各种设计模式往上堆，明明一个函数能解决的事非要拆成三个类。我的稳定套路是，先不给例子让模型写第一版，然后我用测试用例去跑，哪里错了再把那个具体的错误场景作为反例加进去，这样例子就是“精准打击”而不是“误导”。你试试把例子数量从三四个减到一两个，并且刻意选那种输出风格差异大的，看看会不会好点？

同感，few-shot这玩意儿真不是越多越好，尤其写代码场景，模型很容易把示例当模板抄，反而丢了泛化能力。我一般最多给1-2个对比性强的例子，而且刻意让输入输出差异大一点，逼它学逻辑而不是抄格式。角色设定那套我也踩过坑，什么“资深工程师”纯属心理暗示，不如直接给任务约束和边界条件管用。现在更倾向用“先描述功能+再给输入输出类型+最后加一句避免什么”的结构，比堆例子稳多了。

少而精的例子确实容易带偏，我一般最多给一个反例或者干脆不给，让模型自由发挥反而稳。

角色设定那套我也踩过坑，越资深越容易炫技，不如直接说“写最简实现”。

说实话few-shot这个坑我也踩过，后来发现例子里的变量名和注释风格容易被模型当成“标准答案”模仿，尤其是小项目里函数逻辑简单时反而会干扰它理解真实需求。我现在的做法是只用1个最精简的例子，并且刻意让例子里的命名和上下文无关，或者干脆用注释描述输入输出类型，效果稳定很多。角色设定那个我也试过，感觉对复杂架构有点用，但对工具函数就是副作用，它老想给你整设计模式。要不你试试把例子放在用户消息末尾而不是系统提示里，有时候位置影响也挺大的。

few-shot里例子太具体反而会带偏模型，我一般只放一个最简结构，角色设定更是纯玄学。

few-shot确实不是越多越好，我试过放两个精确例子最稳，多了就容易串味。

说实话这事儿我踩过一模一样的坑，后来发现few-shot对代码生成其实是个双刃剑。模型很容易把示例里的局部变量名、甚至缩进风格当成某种“隐含约束”去硬套，尤其是当你的示例跟目标函数结构相似但逻辑不同时，它反而会去模仿表面模式而不是理解意图。我觉得关键在于示例要选那种“边界情况”或者“易错点”，而不是完整的功能演示，数量上两三个就顶天了，再多模型就开始找规律了。至于角色设定，我现在的做法是让它“先写最简实现，再讨论优化”，直接避免它自嗨式地加类、加抽象。另外我最近发现一个相对稳的套路：把任务拆成“先描述输入输出约束，再要求它列出测试用例，最后才写函数体”，这样模型不容易跑偏。你试试把例子换成“反例”——比如明确告诉它哪种写法是错的，有时候比给正例管用得多。

我最近也踩过类似的坑，few-shot的例子如果跟目标任务的复杂度不匹配，模型反而会过度拟合示例里的模式，尤其代码任务里很容易把变量名带偏。我后来改成只给一个极简例子，或者干脆用自然语言描述清楚边界条件，效果稳多了。角色设定那个我也试过，确实容易诱发“炫技式”代码，现在基本不用，直接说“用最直接的方式实现”反而更靠谱。感觉prompt工程的核心还是让模型理解你的约束，而不是给它太多发挥空间。

这事儿我也踩过坑，few-shot里例子如果跟目标任务的边界条件差太远，模型很容易被带偏，尤其代码这种对上下文敏感的输出，示例里的变量名和逻辑模式会被当成默认模板。我现在一般只放一个最贴近需求的例子，或者干脆用自然语言把输入输出规则描述清楚，比堆例子稳得多。角色设定那套我也觉得对代码生成用处不大，反而容易让它追求“架构美感”忽略实用性，我试过直接说“写个能跑的最小实现”效果反而好。你要是遇到复杂逻辑，不如拆成小函数一步步喂给它，比一次性塞个大需求靠谱。

说实话few-shot这个坑我也踩过，后来发现例子越“干净”越好，最好只覆盖边界情况，而且数量控制在2个以内，多了模型容易把例子当模板去套。角色设定那个我倒是觉得看场景，写工具函数真没必要，反而会诱导它追求“优雅”牺牲可读性。我现在基本就靠把需求拆细，一步一确认，比堆技巧稳多了。

跟你感觉差不多，few-shot这招对代码生成真得慎用，模型很容易把示例当模板抄，尤其例子不够泛化的时候。我后来基本只给一个最简结构示例，或者干脆用注释描述预期行为，反而稳定。角色设定我也踩过坑，什么“资深工程师”一加，它就开始给你上设计模式，烦死了，现在我就明确要求“用最直接的方式实现，别搞抽象”。