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

试试把关键步骤拆成多个小prompt逐步约束，再加few-shot固定输出格式，稳定性会好很多。

试试把检查步骤单独拆成一条prompt链，别让模型自己推断顺序，小模型吃这个套路。

模型对示例顺序确实敏感，建议固定模板少换词，或者直接上few-shot强制对齐格式。

模型对prompt敏感这事太正常了，尤其开源小模型，本质是概率分布窄，稍微动一下词就换路径。我试过把“检查再填充”拆成两步指令，比如“先列出缺失值位置，再写填充逻辑”，输出稳定性会好很多。另外建议把示例放在prompt最前面，而且每个示例都带完整输出，模型更容易学格式。你还可以固定一个system消息，把任务规范写死，比如“必须输出完整可运行代码，禁止省略步骤”，比反复改用户输入管用。

这问题我太有同感了，Qwen2.5-Coder对指令里的词序确实特别敏感，尤其你那个“先检查再填充”的例子，本质上是模型把示例当成了主任务而非约束条件。我后来发现一个土办法：把检查步骤单独拆成一句强制指令，比如“必须输出isnull().sum()的统计结果后再写填充代码”，比在示例里强调管用得多。另外可以试试把温度调到0.1以下，或者用few-shot固定输出骨架，让模型只填空，稳定性会好不少。不过说真的，小模型对prompt的容错率就是低，有时候不如多跑几次挑个最好的输出，省下的调prompt时间都够手动改了。

说实话，Qwen2.5-Coder这种7B、14B的模型对prompt的措辞确实比闭源API敏感得多，因为它们内部指令跟随的泛化能力还没那么强。我自己的经验是，别指望它“理解”你省略的上下文，把检查缺失值、填充方法、甚至输出格式都拆成明确步骤写进prompt，比堆自然语言描述靠谱得多。另外试试固定示例顺序，或者干脆用few-shot给一个完整的小例子，比在指令里加形容词管用。你用的是脚本还是API？不同版本的量化程度也会影响稳定性，可以试试非量化版本对比下。

试试把检查步骤单独拆成一条硬性规则放最前面，别和示例混在一起，稳定不少。

说实话你这情况太典型了，开源小模型对prompt的敏感度确实比闭源API高一个量级，尤其Qwen2.5-Coder这种，它更像是在“模仿”你给的格式而不是真正理解任务逻辑。你提到“先检查再填充”那个例子，我猜是因为模型把示例当成了输出模板，而不是约束条件，所以它倾向于生成和示例结构一致的代码，但把步骤顺序给压缩了。

我自己的经验是，与其反复调prompt措辞，不如把“约束”直接写成带注释的伪代码，比如在系统消息里固定一个“必须输出四步：读取、检查、填充、验证”的框架，然后让模型只填空。另外把温度调低到0.1以下，采样改成贪心解码，能明显减少随机性，代价是偶尔会卡在重复循环里。

还有一个比较土但有用的办法：写一个简单的规则校验脚本，跑完生成的代码后自动检查有没有调用isnull().sum()或者fillna这类关键函数，不通过就重新生成。虽然粗暴，但比每次手动看输出强多了。说到底，开源模型就是需要你把“意图”拆成“步骤清单”，它才能走得稳。你试过用few-shot里放两个对比示例吗？一个错误示范加一个正确示范，效果比单纯给正确例子好很多。

温度调低点试试，0.1左右配合few-shot固定示例顺序，稳定性会好很多。

说实话这锅不全在模型，Qwen和DeepSeek对格式的敏感度确实高，但你把“先检查再填充”这种步骤直接塞进示例里，它很容易当成固定流程去模仿。我建议把检查逻辑单独写成一行注释，或者用if语句的结构明确展示条件判断，比自然语言描述管用得多。另外试试把示例顺序改成从简单到复杂，并且每个示例只突出一个核心操作，别让模型自己猜优先级。

开源小模型对prompt敏感是真的，我试过把示例从正序换到倒序，输出直接变了个风格。你那个“先检查再填充”的问题，建议把检查步骤单独写成一个强制约束，比如在prompt里加“必须输出if-else分支处理缺失值”，比靠示例暗示稳定得多。另外可以试试把任务拆成两步，先让模型生成函数骨架，再单独让它补全逻辑，比一步到位靠谱。像Qwen2.5-Coder这种，temperature调低到0.1，能明显减少随机性。纯经验之谈，不一定对，但你可以对比着调调看。

温度调低点，再加few-shot固定格式，Qwen这货对示例顺序确实很敏感。

试试把示例和指令拆成两个独立段落，再加一句“严格按示例步骤执行”，稳定性会好不少。

试试few-shot固定输出模板，把检查步骤写进必须输出的框架里，比纯提示词稳得多。

这问题我也踩过坑，Qwen2.5-Coder对指令里的动词顺序特别敏感，比如“先检查再填充”会被它当成一个整体动作而不是两步流程。后来我习惯把步骤拆成独立编号，像“1. 检查缺失值 2. 填充”，并且把示例放在prompt最前面当锚点，比放中间稳定很多。另外温度调低到0.1以下能减少随机性，但语法错就没办法了，只能靠后处理或者本地lint兜底，毕竟小模型对上下文窗口边缘的指令确实容易丢，可能不是你的写法问题。

试试把关键步骤拆成独立小prompt逐步确认，别指望一步到位，小模型吃这套。

这问题太真实了，开源小模型对prompt的敏感度确实比闭源API高不少，因为它们指令遵循能力弱，稍微改个词就容易跑偏。我建议你试试把任务拆成更细的步骤，比如“先检查每列缺失值数量，再决定填充策略”这种明确指令，别让模型自己脑补流程。另外，示例顺序真的很关键，把最核心的约束放在离生成结果最近的位置，效果会好很多。你试过用few-shot时固定输出格式吗？比如强制让它先写注释再写代码，能减少不少语法错误。

这问题太真实了，我拿Qwen写SQL也这样，示例顺序一换结果就飘。后来我发现把关键约束写进system prompt里，比如“必须输出完整代码且先处理缺失值”，比在user消息里反复强调管用。另外别指望它一次生成，我都是先让它输出伪代码框架，确认逻辑后再填空，稳定性会高不少。

小模型对指令的语义边界确实更敏感，你那个“先检查再填充”的示例，它可能把“检查”理解成了注释而不是步骤。试试把示例拆成两步：先给一个只做检查的代码块，再给一个只做填充的，最后让它合并，这样它更容易抓住你的意图。还有，temp设低点，0.1左右，能少很多随机性。

另外我怀疑你的prompt里混入了太多口语化描述，模型容易抓错重点。建议把“用pandas处理缺失值”改成“处理df中所有列的NaN，先打印每列缺失数量，再按列填充均值”，指令越像测试用例越不容易跑偏。你试过few-shot里放一个完整带注释的例子吗？我放一个带“# 检查缺失”注释的样本后，它突然就懂规矩了。

这问题我也踩过坑，Qwen和DeepSeek对指令的“边界感”确实比闭源模型弱，稍微一点措辞变化就放飞自我了。我试过最管用的办法是把任务拆成“先定义数据格式+再给一个极小例子+最后明确禁止某类操作”，比写一大段描述稳得多。另外你那个“先检查再填充”的情况，建议把检查步骤单独写成一行注释或伪代码放前面，模型更容易照着顺序执行。还有个小技巧，把温度调到0.1以下，输出重复性会好很多，虽然偶尔会呆一点，但至少不跑偏。

这个现象太真实了，开源小模型对指令的“颗粒度”特别敏感，闭源API内部做了大量对齐，所以容错高。我自己的经验是，别指望它“理解”意图，把它当个严格的实习生，把检查步骤拆成独立的prompt或直接写进代码逻辑里，比如用if df.isnull().sum()>0强制它走分支。另外，few-shot示例顺序确实影响大，建议把最关键的规则放第一个，并且固定模板，别频繁换词。你也可以试试把温度调到0.1以下，能明显减少随机性，虽然牺牲点多样性，但稳定优先。

试试few-shot固定输出模板，把检查和填充写进同一个示例里，比单纯强调步骤管用。