用Prompt调教LLM写代码，为什么总是忽略我给的代码示例？

试试把示例代码直接混进需求里描述，再加一句“输出必须复用这些函数名”，比单独强调有用。

试试把示例代码直接塞进few-shot里，别用标签包，让模型先模仿一段再让你要的活。

试试把示例代码的重点行直接写进生成要求里，比如“返回变量必须叫result_list”，比让它自己悟强多了。

我碰到过一模一样的情况，后来发现问题多半出在“示例”和“指令”的权重分配上。你给200行代码，模型其实会把它当成“参考资料”而不是“硬性模板”，尤其当你的新功能描述里隐含了别的常见模式时，它很容易被自己的先验习惯带跑。我试过最有效的办法是把示例里最关键的那几个变量名和函数签名单独摘出来，直接在生成要求里写“必须复用以下标识符：xxx、yyy”，而不是让它自己去总结风格。另外，“请逐行模仿”这种话太抽象了，模型不知道“逐行”到底意味着什么，你得给它一个可检查的硬约束，比如“输出代码中不得出现示例之外的变量名”或者“每个函数的参数顺序必须与示例保持一致”。还有个细节，你用的xml标签本身可能没问题，但如果你在示例前后加了太多解释性文字，注意力反而会被稀释，我通常会把这个标签放在Prompt最末尾，并且前面只留一句“以下是不可更改的代码基准”。至于长度，200行确实有点尴尬，模型对中间部分的记忆会减弱，你可以考虑把示例拆成两段，一段管变量风格，一段管函数结构，分别配上对应的指令。最后提醒一下，如果模型实在不听，试试把温度调低，或者换一个对指令遵循更强的模型，有时候不是你的Prompt不行，是模型本身的天生惯性太大了。

试试把示例代码放最后，或者拆成小段夹在指令里，太长确实容易飘。

我之前也踩过这个坑，后来发现问题可能不在长度，而是LLM对“示例”和“指令”的权重处理不一样。你可以试试把示例代码直接放在生成任务的前面，紧挨着让它模仿的那句要求，别用标签包裹，有时分隔符反而让模型当作独立段落忽略了。另外“逐行模仿”这种词太模糊，不如明确说“输出中所有变量名必须与示例X、Y一致”，或者干脆给它一个填空式的骨架，让它只补中间逻辑，这样它就没法自由发挥了。

说实话200行示例确实有点长，模型很容易把注意力分散到不相关的细节上，我一般会挑最核心的10-20行作为“锚点”，然后在prompt里直接说“变量命名必须和例子里的XXX保持同一规则，函数结构也按这个来”，比笼统说“严格按照示例”管用得多。另外建议你把示例代码放在prompt最末尾，紧跟着你要它写的那段逻辑，中间别插别的描述。还有个小技巧，如果它还是跑偏，就故意给它一段错误的代码让它改，有时候比让它凭空生成效果强。

这问题太真实了，我试过给模型塞一堆参考代码，结果它更像是在“抄思路”而不是“抄结构”。后来我发现，与其把示例放在前面，不如在Prompt末尾单独强调“所有变量名必须从示例中提取，禁止自创”，效果会好一点。另外200行确实太长了，模型注意力会分散，我一般只挑最核心的50行当锚点，剩下的用文字描述清楚逻辑。你也可以试试把示例代码拆成两段，中间穿插你要它完成的子任务，这样它更容易对齐上下文。

这问题太真实了，我也踩过类似的坑。200行示例对LLM来说确实容易让注意力涣散，它可能只抓了开头结尾的结构，中间细节全丢了。你可以试试把示例拆成几个小段，每段后面紧跟一句“按这个风格写下一部分”，比一次性全丢给它管用。另外“逐行模仿”这种词太抽象，不如直接说“保持变量名和函数签名完全一致，不要重命名”，效果会好很多。

遇到过类似的坑，后来发现把示例代码放在prompt最后面，紧挨着让模型开始生成的位置，比放前面管用得多。另外别光说“模仿”，试着在示例里挑几行有代表性的变量名和函数结构，直接要求“新代码里必须出现这些名字和这个嵌套层级”，比那种笼统的约束明确多了。200行确实偏长，我一般拆成两三个小示例分步喂，每个控制在50行内，模型反而记得住。你也可以试试在生成后加一轮“对照示例逐条检查命名”的自我修正指令，能救回来不少。

这问题我踩过好多次坑，200行示例对LLM来说确实太长了，它的注意力会在中间段飘掉，只记住开头和结尾的风格。我试过把示例压缩到50行左右，只保留最核心的命名和结构骨架，效果比全量塞进去好很多。另外“逐行模仿”这种指令对模型来说太抽象了，不如直接在示例后面加一句“输出代码的变量名必须使用camelCase，函数必须保持单职责”，用具体规则代替模糊要求。
还有个偏方是把示例代码放到Prompt的最后，紧挨着生成请求，利用模型对结尾内容的记忆优势，你可以试试看。

试试把示例代码直接塞进few-shot里，别用标签强调，让模型照着抄格式最管用。

这问题我也踩过坑，200行示例对LLM来说其实很容易“淹没”在上下文里，它更关注你指令里靠后的部分。你可以试试把最关键的那几个函数单独抽出来，放在Prompt的最末尾，并明确说“下面这段是风格基准，所有新代码必须保持相同的命名和结构”，比笼统说“严格遵循”管用得多。另外别用“请逐行模仿”，它反而会过度纠结细节，把逻辑带偏，直接给正反例对比效果更好。

这问题我太有同感了，之前做重构的时候也栽在过这上面。我后来发现一个比较管用的思路是别让模型去“理解”你的示例，而是直接把示例当成“模板”来用，比如在Prompt里写“直接复制以下代码的命名和结构，只修改逻辑部分”，比你说“请模仿”要有效得多。另外，200行确实有点长，模型注意力在长上下文里很容易被中间部分带跑偏，你可以试试把示例拆成几个小段，每段后面紧跟对应的生成任务，而不是一次性全塞进去。还有一个偏方是故意在示例里留一点小错误或者特殊注释，让模型注意到“这是必须遵循的基线”，有时候反而能拉回它的注意力。不过说实话，指望LLM100%按规矩来不太现实，我现在都是先生成再拿脚本自动检查命名规范，不符合就让它重写，比反复调Prompt省心多了。

遇到过一模一样的情况，后来我发现问题大概率出在“示例”和“指令”的权重博弈上。你给200行代码，对LLM来说就像喂了一本参考书，但它默认你的核心诉求是“生成新功能”，所以会优先遵循任务指令，示例反而被当成背景噪音了。我试过最有效的办法是，把示例代码压缩到50行以内，只保留最关键的变量命名和函数骨架，然后在Prompt里直接写“如果输出中任何一个变量名或函数结构与示例不一致，整个输出将被视为无效”，这种强约束比“请严格按照”有用得多。另外，你提到用xml标签包起来，这其实容易让模型把示例当成一个整体块来“跳过”，我改用“下面是一段示例，其中每个变量名和函数名都是硬性规则”这种引导语，效果会好很多。还有个细节，如果你发现它还是飘，可以试试在示例后面紧跟一句“现在，请用完全相同的风格，把以下需求实现为代码”，把新需求直接放在示例后面，而不是隔着一大段说明文字。最后，长示例确实会稀释注意力，但更关键的是，LLM对“风格”的理解往往停留在语法层面，你最好把“变量命名风格”具体化，比如“所有布尔变量用is开头，所有函数参数用单字母缩写”，这样它才能真的执行。

这题我熟，之前调教模型写脚本也踩过这坑。200行示例对上下文窗口来说确实容易稀释注意力，尤其是xml标签它可能只当成了普通文本。建议你把示例代码精简到最关键的那几个函数，然后明确告诉它“只模仿这里面的命名和结构，别自己发挥”，再让它先复述一遍你的要求再开始写，效果会好很多。

另外可以试试把“请严格按照”这种话删掉，改成“如果偏离以下风格，代码将无法运行”，这种负面后果的表述往往比正面强调更管用。我试过在后面加一句“生成前先列出你打算使用的变量名清单”，也能强制它聚焦。

你这情况我太熟了，之前调LLM写个数据清洗脚本，给了它我自己写的函数命名习惯和异常处理模板，结果它给我整出个完全不同的风格，气得我差点把示例糊它脸上。后来我发现问题可能不在示例长度，而是LLM对“示例”的理解更偏向“参考内容”而不是“必须遵守的规范”，你光说“严格”没用，它觉得只要逻辑对就算完成任务了。我试过比较有效的办法是把示例代码拆成小块，每块后面直接用自然语言描述“这里用了xxx命名方式，因为yyy”，相当于帮它提炼出规则，而不是让它自己从代码里悟。还有个土办法，就是把你不想让它改动的函数名和变量名单独列出来，用“以下名称必须原样使用，不要替换成同义词”这种硬性清单，比放在代码里管用得多。至于“逐行模仿”这种指令，我试过，有时候会让它过度照搬结构反而忽略功能需求，不如明确说“保持函数输入输出接口不变，内部实现可以优化”来得平衡。说到底，LLM更像是个理解力有限的实习生，你得把你要的规则拆成它听得懂的操作步骤，而不是指望它从长示例里自己归纳。

这问题我太有同感了，试过把示例放前面放后面、加粗关键行，效果都差不多。后来发现把示例代码直接拆成“变量名表”和“函数结构图”两段，再让LLM先复述一遍规则，最后才生成代码，成功率会高不少。另外200行确实有点长，模型容易抓大放小，我一般只留最核心的30行，其他写成伪代码注释，反而更听话。

说实话我也踩过这个坑，后来发现问题可能不在示例长度，而是LLM对“风格”的理解跟咱们不一样。你给200行代码，它确实会看，但注意力分配是呈衰减的，尤其是中间部分最容易丢，开头结尾的指令反而更有效。我试过把示例拆成几个小段，每段前面单独强调“变量命名用下划线”“函数保持单返回值”这种具体规则，效果比一大坨整体约束好很多。另外“请逐行模仿”这种话太抽象了，模型不知道什么叫“逐行”，你不如直接说“第一行到第十行的函数签名必须原样保留，内部实现可以改”。还有个偏方，把示例代码放在Prompt最后，然后紧跟一句“现在生成新代码，开头必须与示例第一行完全一致”，利用位置偏见强制它锚定。不过说实话，如果项目复杂，这种调教成本真不如自己改几行变量名来得快，LLM当个快速草稿生成器用就行，别指望它完全复刻你的风格。

试试把示例代码放最后，前面只留任务描述，亲测比夹在中间管用。