用Prompt调教开源模型写代码，结果总是漏函数，怎么破？

我也遇到过类似问题，尤其是开源模型对嵌套约束容易“漏细节”。后来我发现把异常处理拆成单独指令效果更好，比如先让模型写基础函数，再追加“给上面代码加上try-except处理超时和HTTP错误”。另外试过在Prompt里直接给代码框架，让模型填空，比纯描述指令靠谱得多。

试试把异常处理的具体类型写进prompt里，像“捕获Timeout和HTTPError并打印”，模型会更听话。

试试把异常类型直接写进prompt里，比如“必须包含try/except捕获Timeout和HTTPError”，模型会更听话。

试试把异常类型和位置直接写在prompt里，比如“在请求和解析后分别加try-except”。

我试过类似的情况，感觉开源模型对多步骤指令确实容易丢细节，尤其是异常处理这种“非核心”逻辑。后来我改成把约束拆成几条分步指令，比如先让他写基础爬虫，再单独强调“给每个请求加try-except”，效果比一股脑全塞进prompt好不少。另外试试在prompt里加个示例输出格式，比如明确标出“函数名: xxx，参数: xxx，异常类型: xxx”，模型会更老实照做。

这个问题我太有同感了，尤其是Llama 3和Qwen 2.5在复杂指令上确实容易“偷工减料”。我自己的经验是，这类开源模型对“多步骤约束”的理解，其实更吃Prompt的“结构层次”而不是字数多。比如你提到“包含异常处理”，最好拆成两步：先明确说“请按以下步骤输出：1. 函数签名，2. 网络请求部分，3. 异常捕获逻辑，4. 返回值”，并且给每个步骤一个具体示例，比如“超时异常用try-except包裹，HTTP错误用status_code判断”。另一个很实用的技巧是在Prompt结尾加一句“请确保所有代码块都以def开头，并且没有遗漏except语句”，这能强制模型回溯结构。另外，我试过把“请完整输出”换成“请输出可以直接运行的完整代码”，效果会好一些，因为模型对“可运行”这个目标的认知更明确。不过说到底，开源模型在指令遵循上确实不如闭源模型稳定，有时候它们会把“异常处理”理解成“举例说明”而不是必须实现的部分。你试试把约束条件用列表加数字编号写清楚，同时在Prompt里加一个“反面示例”，比如“不要只写try而不写except”，这样模型更容易理解你的真实意图。

这个问题其实挺典型的，我也踩过类似的坑。Llama和Qwen这类开源模型对长指令里的优先级分配确实比较弱，尤其当“输出完整代码”和“处理异常”同时出现时，模型往往倾向于先保证代码逻辑能跑通，而把异常处理当成可选项忽略掉。我后来试过把prompt拆成两步：第一步只要求生成基础功能代码，第二步再单独追加一段“请在上面的函数里补充try-except和超时设置”，效果明显好很多。另外你提到“请完整输出”时好时坏，我觉得可能是因为模型会把“完整”理解成“代码行数完整”，而不是“逻辑结构完整”——所以我现在会明确写“请确保函数定义、参数、返回值、异常处理四个部分都齐全”。还有一个细节，如果你在prompt里用“必须”“强制”这类词，对Llama 3的约束力比“请”强不少，你可以试试把“请处理”改成“必须处理网络超时和HTTP错误”。另外检查一下模型temperature是不是设太高了，0.2以下能让它更老实。你用的具体是哪个量化版本？如果量化太狠（比如4bit），模型注意力分散的概率会更高，漏函数的频率也会增加。

把约束条件拆成子任务分步喂给它，或者先用示例格式定个框架，效果会稳定很多。

你这问题我太有同感了，Llama 3和Qwen 2.5在代码生成上确实容易“偷懒”，尤其是多步骤指令里，模型会默认跳过它觉得“不关键”的部分。我试过把Prompt拆成两层结构：第一层写“请生成一个完整的Python函数”，第二层再列具体要求，比如“必须包含try-except处理requests异常、超时和HTTPError”，同时用分隔符把函数定义和逻辑块分开。另外，开源模型对“完整输出”这种抽象指令理解不深，不如直接给个反面例子，比如“不要省略函数签名和异常捕获，类似这样：def crawl(url): try: ... except ...”。还有个小技巧是在Prompt末尾加一句“请先输出函数框架，再填充细节”，这样模型更容易按步骤执行。不过说到底，这些模型对长指令的注意力分布确实有问题，有时得靠few-shot示例强制它模仿格式，你可以试试给一个短一点的完整爬虫例子作为参考，效果会比纯描述好很多。

试试把约束条件拆成小步骤写进prompt里，比如先要求定义函数，再逐条加异常处理，效果会好很多。

试试把“函数”改成“完整的Python脚本”，再加个示例输出格式，模型会更听话。

把关键约束直接写进代码注释里，比如#必须包含try-except，模型反而更听话。你可以试试先让它输出函数骨架再补细节。

说实话我也踩过这个坑，Llama和Qwen对“完整输出”这种指令的理解经常飘，尤其是当prompt里塞了多个约束条件时，模型很容易只抓表面需求，把异常处理当作次要信息给丢了。我觉得问题可能出在指令的顺序和粒度上，你可以试着把“必须包含try except”这种硬性要求单独拆成一条明确的规则，放在函数签名之前，而不是混在描述里。另外开源模型对“步骤感”很敏感，建议用分点或者编号列出每个必须出现的代码块，比如1.导入库 2.定义函数 3.异常处理 4.返回结果，这样模型会把它当成一个清单去执行。我自己常用的一个技巧是给一个“反面例子”，告诉它“不要只返回requests.get那一行”，有时候比正面要求更管用。还有个小细节，你试试把“请写一个”改成“请按以下结构实现”，然后直接给一个伪代码框架，让模型去填充，漏函数率会低很多。最后想说，这类模型对多步骤指令的跟随能力确实有限，别指望一次成型，多轮对话里让它补全缺失部分反而更稳定。

试试把异常处理直接写进需求里，比如“必须用try包裹requests.get”，模型漏的概率会小很多。

我一般会把完整代码结构拆成两段prompt，先让它补函数签名再补逻辑，比一次性输出稳多了。

这问题我太熟了，Llama和Qwen系列对“完整输出”这种指令经常选择性失聪，感觉它们对代码结构的优先级判断跟咱不是一回事。我后来发现一个挺有用的招，就是在Prompt里把函数签名直接写死，比如“def fetch_title(url, timeout=5):”然后后面接“请补全函数体”，这样模型至少不会把函数定义给吞了。另外你那个“一步一步来”可能反而会诱导它把思考过程输出成注释，然后代码本体就被压缩了，我试过明确要求“只输出最终代码，不要解释”效果反而稳定些。还有个思路是把异常处理拆成单独的Prompt，先让它生成主逻辑，再单独让它补一个try-except包裹层，最后手动拼一起，虽然麻烦但成功率很高。说到底开源模型对多约束的遵循能力确实有天花板，有时候不如直接用个小的专门微调代码模型，比如DeepSeek-Coder，对这种任务明显更听话。你要是想省事，可以试试在Prompt里给个极简的示例输出格式，比如贴一段残缺的代码让它填空，比纯文字描述约束要直观得多。

这问题我太熟了，Llama和Qwen对长指令的尾段注意力特别差，你让它先做A再做B，它经常把B给吞了。我现在的做法是把异常处理拆成单独一行要求，比如“必须在函数内部用try包住requests.get”，比泛泛说“处理异常”管用得多。另外试试把函数签名直接写在prompt里让它填空，比如def fetch_title(url):，比让它自己凭空写函数完整度高一截。

这问题太典型了，我试过让Llama 3写个带重试的请求封装，它也是把异常处理给吃了，感觉开源模型对“隐含约束”的响应确实飘忽。后来我学乖了，干脆在prompt里直接给一个残缺的代码骨架，让它填关键部分，比如明确写上“def fetch_title(url): try: ... except Timeout: ... except HTTPError: ...”，这样它反而老实很多。你也可以试试把异常类型具体列出来，比单纯说“处理错误”有效得多，另外把“完整输出”换成“输出完整可运行代码，不要省略任何except块”这种命令式措辞，命中率会高一点。

把约束拆成小步骤喂给它，让它先写函数骨架再补异常处理，比一口气全塞进去靠谱多了。

这问题我太有同感了，Llama和Qwen对“完整”这个词的理解真的飘忽不定。我后来发现，与其靠语气词强调，不如直接把输出格式焊死在Prompt里，比如明确写上“输出一个名为fetch_title的Python函数，包含try-except-finally结构，且必须用pass占位未实现逻辑”。另外，你试试把“异常处理”拆成具体场景，像“分别捕获requests.Timeout和requests.HTTPError，并打印错误后返回None”，模型对具体分支的把握会比笼统指令强很多。还有个偏方，就是故意在Prompt里给个错误示例，说“不要像这样只写try不写except”，有时候反向约束反而能触发它补全。我自己用Qwen 2.5时，发现它特别吃“角色设定”这一套，比如加一句“你是一个严谨的Python工程师，提交前会自查代码”，漏函数的情况能少一半。不过说实话，开源模型对多步指令的“全局规划”能力确实弱，哪怕GPT-4也偶尔抽风，所以最稳的还是自己先写个函数骨架，让模型只填关键行。对了，你试过把任务拆成两条Prompt吗？第一条让它列处理步骤，第二条再让它按步骤写码，我这么干之后漏定义的概率低了不少。

把异常处理直接写进示例代码里，再让模型仿写，比光用文字约束靠谱多了。