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

说实话200行示例确实有点长，LLM的注意力窗口虽然大但越靠后的内容权重越低，建议把示例精简到50行以内，只保留最核心的命名和结构特征。另外“逐行模仿”这种指令不如直接给一个“对比清单”，比如明确列出变量名前缀、函数返回类型这些硬性要求，让它逐项核对。我试过在示例后面加一句“如果输出不符合上述规则，请先自我检查再回答”，效果比单纯强调“严格遵守”要好一些。

说实话你这问题我太有同感了，之前调LLM写重构代码时也栽过同样的坑。我感觉核心问题不在示例长度，而是模型对“示例”的理解权重天生就低于显式指令，你给200行它可能只抓了前几十行的梗概。有个偏方你可以试试，别光在开头说“请参考”，而是把示例代码拆成几个小段，每段后面紧跟一句针对性的硬约束，比如“这一段里所有变量都必须是snake_case，函数必须保持单出口”，这样相当于把注意力钉死在具体行上。另外你说用xml标签包代码，我猜模型可能把标签本身也当成了格式噪音，不如直接说“以下代码块是唯一标准，禁止改动其中命名和结构”，然后只放一次示例，别在正文里反复提。我试过最管用的是在结尾加一句“输出前自己检查一遍：是否每个变量名都来自示例？是否有新增函数？”，这比“逐行模仿”有效得多，因为它是让模型做自检而不是空泛地模仿。最后如果还是飘，建议把示例压缩到50行左右的核心骨架，剩下的用伪代码描述，模型对精炼模板的忠实度反而高很多。

说实话你这问题我也踩过坑，200行示例确实容易让模型“看花眼”，它更倾向于抓全局模式而不是逐行死磕。我后来发现把示例拆成几个小函数块，每个块前加一句“这是唯一参考风格”，比堆一个大代码块管用得多。另外别用“请严格”这种抽象词，直接说“变量必须用camelCase，函数必须带xxx前缀”这种具体规则，它反而更听话。你也可以试试在示例和需求之间加一句“现在忽略以上所有，只按示例的命名和结构写”，有时候能强制它切换注意力。

这问题我太有同感了，200行示例确实容易让模型“抓大放小”，它可能只学了模块逻辑，细节风格全丢了。建议你别只给代码，可以单独拎几行关键命名和函数签名出来，放在示例后面，用“必须匹配这些模式”这种硬性要求，比让它自己归纳有效得多。另外试试把示例拆成两段，一段讲结构，一段讲风格，中间隔开，比堆一起更不容易被忽略。

这题我熟，之前也栽过跟头。你给的示例太长确实会摊薄注意力，尤其当新功能逻辑和示例重叠度不高时，模型更倾向“自由发挥”。我后来是把示例代码结构拆成几个小注释块，比如“// 变量风格：xxx // 函数骨架：xxx”，放在生成目标紧邻的上方，比单独堆一大段管用。另外“逐行模仿”这种词对部分模型反而会触发过度拟合，不如直接说“输出代码中所有标识符必须能在示例里找到同名或同前缀”，试试这个硬约束。

这问题太真实了，我试过给模型喂几百行的参考代码，结果它只学了开头那几行的风格，后面全放飞。感觉不是长度问题，是它默认把示例当“背景信息”而不是“硬性规则”，你可以试着在示例前面加一句“以下代码是唯一允许的命名和结构来源，不要引入任何外部风格”，然后把关键变量名直接写进需求里，比让它自己总结有效得多。另外，如果模型还是不听，试试把示例里的函数头单独拎出来，用“必须复用这3个签名”这种指令，比“逐行模仿”更具体。我当时也是折腾了好几轮，最后发现把示例压缩到20行以内，同时把要遵守的规则用编号列出来，效果才稳定。

试试把示例精简到最核心的20行，然后明确要求“每个函数首行注释标出模仿点”，这样模型更容易锁定重点。

200行示例确实有点长了，模型很容易“看了后面忘了前面”。我一般会把示例压缩到最核心的30行左右，只保留想让它模仿的那几个特征，比如命名和函数切分方式。另外光说“严格模仿”太虚了，可以改成“输出前先列出你从示例里提取的命名规则，再按这些规则写代码”，逼它显式对齐一遍。还有个偏方是把示例放在Prompt最后、紧挨着你的生成要求，位置越近影响越大。

200行示例确实有点长了，模型很容易只抓个大概印象就开始自由发挥，尤其是变量命名这种细节，它训练时见过的“主流风格”会强势覆盖你给的局部模式。我一般会把示例压缩到最核心的30到50行，只保留真正想让它模仿的那几个函数，然后把命名规则单独拎出来写成几条硬性约束，比如“所有布尔变量必须以is开头、工具函数一律用动词加名词”，这样比塞一大段代码管用。还有个坑是xml标签，很多模型对它的解析优先级并不高，换成普通的代码块或者干脆用“示例开始/示例结束”这种自然语言标记，反而更容易被当成强约束。你也可以试试在示例后面加一句“如果生成的变量名不在上面出现过的列表里，就重新生成”，这种自检式指令有时候比“请逐行模仿”更有效。另外温度调到0.2左右也有帮助，默认温度下模型太爱“创作”了。

200行确实太长了，模型注意力容易散。试试把示例精简到三五十行，只留最核心的风格特征。

这个问题我太有共鸣了，之前做类似事情也踩过一模一样的坑。200行示例对现在的模型来说其实不算长，问题往往不在长度，而在于示例和指令是“分离”的——模型把它们当两段独立信息处理，生成时更容易被自己预训练里的编码习惯带跑。我后来发现一个挺管用的做法，是把要求直接嵌进示例里，比如在关键变量旁边加注释说明“这个命名风格必须保留”，让约束和代码本身长在一起，而不是飘在外面。另外“严格按照”这种话对模型来说太虚了，它根本不知道你指的到底是命名、缩进还是拆分粒度，你得把每一条具体规则拆开说，比如“函数不超过20行”“参数名用下划线小写”这种可验证的点。还有个可能是你给的示例里有好几套风格，模型自己都糊涂了，最好只留最典型的那一小段当锚点，剩下的用文字描述。最后生成的时候可以要求它先复述一遍你的风格规则再写代码，这一步能逼它把注意力真正放上去。

200行示例确实有点长了，模型很容易只看个大概就开始自由发挥。我一般会把示例压缩到最核心的30行左右，然后单独列几条硬性规则，比如“变量名必须用下划线风格”。另外可以试试让它在写之前先复述一遍你给的命名规范，确认它真的读进去了再动手。光靠“请严格模仿”这种话，模型经常当耳旁风。

200行示例确实有点长了，模型很容易在后面生成时把前面的细节淡忘掉，这不是你指令写得不够狠，而是注意力机制本身就有这种衰减。我自己的经验是，与其把整段代码塞进去让它“照着写”，不如把示例拆成两部分：一部分是命名规范清单，比如变量前缀、大小写习惯、常用缩写，用几行文字总结出来；另一部分是结构骨架，只保留函数签名和调用关系，把具体实现删掉。这样模型抓重点的概率会高很多。另外你可以在示例后面紧跟一句“新代码中所有变量名必须从以下列表中选择”，把可选范围收窄，比单纯说“严格模仿”有效得多。还有个偏方是把示例放在系统消息里而不是用户消息里，有些模型对系统消息的遵循度会更高。逐行模仿这种约束对生成任务其实不太现实，因为它要写的是新功能，不是复现，所以重点还是把风格规则显式化、清单化。

这个问题我踩过坑，说实话200行示例对大多数模型来说确实有点长了，注意力机制在长上下文里对中间部分的细节保留会明显衰减，尤其你还用xml标签包起来，模型可能把它当成“参考资料”而不是“必须复刻的模板”。我试过比较有效的做法是把示例拆成两部分，一部分是“结构骨架”（比如只保留函数签名和关键变量名），另一部分才是完整实现，然后在prompt里先让模型复述你要求的关键命名规则，再让它生成。另外“请逐行模仿”这种约束其实效果有限，因为模型没有真正的逐行对齐能力，它更像是在做风格迁移。你可以试试在示例后面加一句“如果你不确定某个变量名，必须从上面示例中复制，禁止自己发明”，这种负向约束有时候比正向强调更管用。还有个小技巧是把示例里的命名风格总结成几条显式规则，比如“所有布尔变量以is_开头、工具函数以_前缀”，规则比示例更容易被模型稳定遵循。最后如果项目允许，直接上few-shot加微调或者用支持结构化输出的API，比纯靠prompt硬调要省心得多。

写得挺好，建议补充一些性能数据。

我之前也遇到过类似问题，后来换了方案。

200行示例确实有点长了，模型注意力容易分散。我一般会把示例精简到最关键的三五十行，只保留命名和结构特征最明显的部分，剩下的靠文字描述补。另外可以试试在示例后面直接让它先复述一遍你要求的命名规则和函数拆分方式，确认它理解了再让它写代码，比单纯加“逐行模仿”管用。

200行示例确实有点长了，模型很容易抓不住重点。我一般会把示例精简到最核心的20-30行，只保留想让它模仿的那几个特征，剩下的用文字描述。另外可以试试让模型先复述一遍它从示例里提取到的命名规则和结构，确认它真的“看到”了再让它写。还有个偏方是在示例后面加一句“如果你偏离了上面的命名风格，我会让你重写”，有时候比“请严格遵循”管用。