用prompt调教开源模型做代码生成，效果总是不稳定怎么办？

试试把示例放在prompt最后，或者用few-shot固定几个极端例子，小模型对顺序确实敏感。

同感，Qwen和DeepSeek这些小参数模型对prompt的措辞确实挺敏感的，尤其是示例顺序稍微一变输出就跑偏。我试过把关键步骤拆成子任务，用“逐步指令”限定输出格式，比如“第一步：检查缺失值，第二步：打印统计结果，第三步：填充”，这样逻辑连贯性会好很多。另外，在prompt里加一句“严格按照示例顺序执行”也能减少忽略步骤的情况，你可以试试看。

试试把示例拆成两步：先给个“检查缺失值”的单独示例，再给“填充”的示例，顺序别混一起。

试试把“先检查再填充”拆成两步prompt逐步引导，小模型对复杂指令的分解能力确实弱一些。

说实话这问题我也踩过坑，小模型对指令的边界理解确实比闭源API模糊，你那个“先检查再填充”的例子，本质是它把示例当成了独立任务而不是约束条件。我试过把要求拆成多步，比如先单独问“缺失值有哪些类型”，再让它写处理逻辑，输出稳定很多，另外把“检查”这种动作写成代码注释夹在prompt里，比在描述里强调有用。你可以试试固定一个模板，把变量名和列名都写死，别给它自由发挥的空间，效果能提升不少。

试试把关键约束拆成独立步骤写进prompt，别全塞一段话里，小模型吃这套。

这个现象太正常了，我拿Qwen2.5-Coder跑数据清洗时也踩过一模一样的坑。你发现没，开源小模型对指令的语义权重分配特别敏感，尤其是“先检查再填充”这种带顺序的约束，它可能把注意力全放在“填充”这个动作上，前面的检查步骤就被当成背景板忽略了。我后来试了个笨办法，就是把关键步骤拆成单独一行，用“步骤1：检查缺失值；步骤2：填充”这种显式编号，比在长句里塞条件靠谱得多。另外我发现一个规律，这类模型对否定词和前置条件的理解特别弱，你不如把“忽略检查”改成“必须输出检查代码”，正面引导比负面禁止有效。还有一个土方子，就是固定一个“模板开头”，比如每次都在prompt最前面写死“你是一个严格遵循步骤的Python助手”，后面内容再变，模型也容易保持行为一致性。至于语法错，我觉得跟temperature设置有关系，默认值偏高，你试试调到0.2以下，稳定性会明显提升。最后想说，别指望开源模型像GPT-4那样听懂隐含逻辑，把它当个“需要喂碎肉”的实习生，把每个判断条件都拆成显式规则，效果能好一半。

试试把检查步骤单独拆成一条不可省略的硬性规则写进system prompt里，别混在示例里。

试试把关键步骤拆成独立小prompt，每步验证输出再接下一步，比一次性大prompt稳得多。

说实话你这个问题挺典型的，小模型对prompt的敏感度确实比闭源API高不少，因为它们指令跟随能力和上下文建模都弱一些，稍微一改措辞就可能丢信息。我自己的经验是，与其反复调自然语言，不如把任务拆成更死的步骤，比如明确写出“第一步读取，第二步检查每列缺失率，第三步按XX策略填充”，甚至直接用伪代码给个骨架，模型反而更容易照着走。另外你提到的示例顺序问题，其实也跟模型的注意力机制有关，它更偏爱靠后的内容，所以如果你要强调“先检查”，就把这个步骤放在示例的最后部分重复一次，别指望它从前面就能记住。还有一个土办法，就是固定一个你觉得效果最好的prompt模板，然后只改变量部分，比如列名、文件路径，别动整体结构和措辞，这样输出稳定性会高很多。说到底，开源模型更像一个需要哄着写代码的实习生，你得把要求拆到最细，还得反复验证结果，别指望它能像GPT-4那样帮你脑补意图。你要是真觉得太折腾，也可以试试给模型加一些few-shot的完整例子，比如给它一个“缺失值处理”的输入输出对，让它照着格式套，比单纯描述规则管用。

试试把关键步骤拆成子任务，一步步喂给它，别指望一次生成完整逻辑，小模型吃这套。

说实话这问题我也踩过不少坑，Qwen和DeepSeek这些小参数模型对prompt的敏感度确实比闭源API高一个量级，因为它们没有经过那么强的指令对齐训练，更像是在“猜”你的意图而不是“理解”。你那个“先检查再填充”的例子，我猜是模型把示例当成了独立输出而不是执行顺序，所以它会倾向生成一个看起来完整但逻辑断裂的代码块。我自己的经验是，把任务拆成多轮对话比一次性给长prompt稳定得多，比如先让它生成检查缺失值的部分，跑通了再让它写填充逻辑，每一步给一个明确的小目标。另外，可以试试在prompt里强制加“输出完整Python代码，不要解释”这类约束，有时候能减少它自由发挥的空间。还有个偏门但有效的做法，把示例放在prompt最后而不是中间，或者用注释把步骤编号写在代码里，比如# Step 1: check missing，模型跟着编号走的概率会高很多。最后说一句，如果项目允许，不如直接上Qwen的32B或者MoE版本，7B和14B在这个场景下确实容易让你怀疑人生。

这问题太真实了，我拿Qwen写SQL也这样，换个词就翻车。后来发现把“先检查再填充”拆成两步提示，比如先让它输出检查逻辑，再单独让它写填充代码，效果稳很多。另外把示例放在prompt最前面比放后面管用，感觉小模型对后文注意力衰减特别快。你可以试试把任务拆细，每步单独生成再拼起来，别指望一步到位。

试试把示例拆成多轮对话逐步引导，别一股脑全塞prompt里，小模型扛不住上下文漂移。

这个现象太正常了，小模型对格式和上下文的敏感度确实比闭源API高不少，尤其Qwen2.5-Coder这种，本质上是在用“概率记忆”而不是“逻辑理解”来生成代码。我试过把检查步骤单独拆成一行指令，比如“第一步：检查缺失值；第二步：填充”，比塞在长段落里稳定得多。另外建议你固定示例的模板，比如每次都写“输入→输出”的完整对，别只改几个词，模型容易被局部措辞带跑。你用的温度参数调低点试试，0.1左右输出会保守很多，代价是偶尔会重复代码，但至少不容易逻辑跳变。

说实话你这情况太典型了，开源模型对prompt的敏感度确实比闭源API高一个量级，尤其是7B-14B这种规模，本质上就是概率分布更陡，你换几个词它可能就跳到另一个模式里去了。我自己用Qwen2.5-Coder写SQL也遇到过类似问题，后来发现一个关键点：别把“步骤”写成自然语言描述，而是直接给输入输出对，比如你那个“先检查再填充”，就别写“检查缺失值”，直接给一段“data.isnull().sum()”的输出样例，模型反而能学得更准。另一个技巧是固定prompt模板，把变化的部分锁死，比如用注释占位符标出“此处为检查逻辑”，然后让模型只填那一段，类似于少样本里的“格式锚点”。还有个小坑，就是你给的示例顺序其实影响很大，我试过把正确示例放前面、错误示例放后面，稳定性会好一截，但别用“不要做X”这种负向描述，模型反而容易学会X。最后，如果实在不稳，可以加一个自校验步骤，让模型先生成代码，再让它自己写一段断言或者print检查结果，有时候能自己纠错。总之别太指望小模型一步到位，把它当个需要反复“对齐”的工具用，会省心很多。

这个现象我太有同感了，qwen和deepseek在小样本下对prompt的措辞确实比闭源API敏感得多，本质上是它们指令跟随的泛化边界更窄。你举的“先检查再填充”例子，其实暴露了一个关键问题：模型把示例当成了优先级排序，而不是逻辑链条，所以它会机械地模仿你最后提到的动作。我自己的经验是，与其反复调自然语言描述，不如把约束直接写进代码注释里，比如在函数定义上方用#强制要求if missing check，这样模型反而更听话。另外，把任务拆成两步走会稳很多——先让模型生成一个纯pandas骨架，再让它补全细节，比一次性生成完整脚本的成功率高不少。还有个土办法，如果你发现某次输出不错，就把那个prompt连同输出一起存下来当few-shot模板，下次直接用，比随机微调有效。最后想问下，你有没有试过把温度调到0或者加top_p=0.9？这种小模型采样随机性其实比想象中更影响最终结果。

这问题太真实了，小模型对prompt的敏感度确实高，建议试试把检查步骤单独拆成一条硬性规则写前面。

说白了就是别指望它推理，得把流程拆成它不得不执行的步骤。

试试把示例和指令拆成两步说，先让它输出检查逻辑再写填充，分步引导会稳很多。

模型对格式比内容更敏感，固定一套模板别老换词，指令里用同一个动词开头，输出能稳定不少。

这问题我太有同感了，Qwen和DeepSeek对措辞的敏感度确实夸张，有时候把“检查缺失值”改成“先看下有没有空”结果就差很远。我试过把任务拆成两步prompt，先让它输出处理逻辑的伪代码，再让它转成Python，稳定不少。另外示例顺序影响大可能是因为模型在学局部模式，你可以试试把关键约束放在最后一句，或者固定用“步骤1/2/3”的格式，比自然语言描述靠谱。