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

试试把示例代码直接塞进few-shot的输入输出对里，比写一堆指令管用得多。

试试把示例代码放在Prompt最开头，紧随其后直接让LLM输出，别给太多铺垫，亲测有效。

我之前也踩过这个坑，后来发现把示例代码直接放在Prompt最前面，紧跟着写“基于以上代码风格，完成以下任务”会比放后面管用很多。另外200行确实太长了，模型注意力很容易被中间部分稀释，不如只挑最核心的30-50行作为风格锚点。还有个偏方是让模型先复述一遍你的命名规则和结构要点，再让它动笔写，相当于强制它“读题”。你可以试试把示例精简一下，同时用“沿用xxx函数的分层逻辑”这种具体指向性描述，比泛泛说“严格模仿”有效得多。

说实话你这问题我太有共鸣了，之前调LLM写重构代码也遇到过一模一样的坑。后来我琢磨出个规律，模型对“示例”的理解其实更偏向于“参考语义”而不是“严格模板”，尤其超过100行之后，注意力分配会明显偏向开头和结尾，中间那些变量名和结构细节早就被稀释了。我试过最有效的办法是把示例代码拆成几个小模块，每个模块单独配一段极简的说明，然后在prompt末尾加一句“每个函数必须复用示例中的命名前缀，比如用user_开头，否则输出无效”，这种硬性约束比“请模仿”管用得多。另外你也可以试试把示例代码和生成要求混在一起写，比如在关键变量名后面直接加括号标注“必须保留”，而不是全堆在开头。还有个偏方是故意在示例里留点小错误，然后告诉模型“修正这些错误但保持其他结构不变”，注意力反而容易被锚住。说到底，200行对上下文窗口来说不算长，但模型对“示例”的优先级天生低于“直接指令”，所以得把约束从“建议性”改成“条件性”，甚至用伪代码描述结构都比给完整示例强。你下次不妨先让模型复述一遍示例里的关键约定，再让它动笔写新功能，相当于加一道即时校验，会好很多。

这问题我太有共鸣了，之前调LLM写重构代码时也栽过同样的跟头。后来我琢磨出来一个歪招，就是别光给示例，而是把示例里最关键的那几个变量名和函数签名直接写进你需求描述里，比如“新功能的入口函数就叫generateReport，参数列表和示例里那个buildReport保持一致”，这样等于帮模型画了个重点，它注意力再飘也得先满足你点名的部分。另外200行确实偏长了，模型对中间区域的记忆很模糊，我一般只留20行左右最代表性的片段，剩下用伪代码概括行为，反而更听话。还有个小技巧是故意在示例里留几处注释，让它模仿你的注释口吻，这样它为了对齐风格，连代码结构都会跟着贴过去。你那个“逐行模仿”的指令其实有效，但得放在示例前面，并且说成“输出时保持与示例相同的缩进、命名、函数拆分粒度”，比单纯说“严格”管用。我猜你最后生成出来变量名全变，大概率是模型觉得你的风格跟训练数据里的主流风格冲突，它默认走了概率更高的路径，所以得靠重复关键信息来强行拉回权重。要是还不行，试试把示例和生成任务拆成两次对话，先让它复述示例里的风格要点，再让它写新代码，这招对长上下文特别灵。

遇到过类似的坑，200行示例确实容易让模型“抓大放小”，它更关注整体逻辑而不是细节命名。试试把示例切成几个小段，每段前面直接加一句“这段里变量名必须照抄”，比笼统说“严格按照”有效得多。另外别用xml标签，用普通代码块反而更不容易被忽略，我猜是模型对xml的解析优先级低于代码token。

试试把示例代码精简到最核心的50行，再明确要求“变量名和函数结构逐行对齐”，太长确实容易飘。

试试把示例代码放到prompt最前面，紧跟着再写要求，让模型先看例子再干别的，比放后面管用。

试试把示例直接塞进few-shot里，配一个输入输出对，比写一堆指令管用多了。

这问题我太有同感了，之前调LLM改代码的时候也踩过一模一样的坑。你那个200行的示例其实不算长，但问题可能出在LLM对“风格”的理解上，它更擅长抓语义而不是格式细节，你让它“严格按照风格”，它反而会把注意力全放在功能实现上，变量名那些就自动“优化”成自己的习惯了。我后来试了个办法，就是直接把示例代码里最关键的那几个函数签名和变量名抽出来，单独写成一条“硬性规则”，比如“必须使用user_id和order_list这两个变量名，禁止改名”，效果比笼统的“请模仿”好很多。还有就是别把所有示例堆在Prompt开头，可以把它放在指令后面，紧跟着一句“请基于以上代码的命名和结构，同样风格地写出新函数”，这样上下文靠得近，注意力会更集中。至于“请逐行模仿”这种话，我试过，有时候反而会让它过度复制逻辑，连注释都抄，挺头疼的。另外你也可以试试把示例代码压缩到50行以内，只留最核心的骨架，剩下的用注释描述，这样LLM反而更容易抓住你要的结构。说到底，LLM不是不听话，是它太想“帮你改进”了，你得把约束条件变成不可协商的规则，而不是建议。

试试把200行精简到核心50行，再在结尾加一句“每个函数前用注释标明模仿自哪个示例”，效果会好很多。

试试把示例代码直接塞进它的few-shot区，放前面比放后面管用，我这么干效果立竿见影。

示例别一股脑全给，挑最核心的三五个函数当模板，它反而学得更像。

把示例放前面当few-shot，后面再跟任务指令，效果比放中间强。另外200行确实太长，精简到50行以内试试。

这问题我太有同感了，之前调LLM写重构代码也栽在同样的坑里。我后来发现，它其实不是“忽略”示例，而是把示例当成了参考数据，不是“指令”——你光说“请遵循”没用，它更吃那种“必须用示例里的xxx，不要用别的写法”的硬性要求。你试试在示例代码后面直接跟一句“如果生成代码里出现任何不同于上述命名风格的变量，请标注为错误”，比“请逐行模仿”管用得多。另外200行确实有点长，模型注意力会分散，我一般会拆成两到三个小片段，每个片段对应一个具体功能点，然后在每个片段后面紧跟着写“基于此生成新函数”，效果会好很多。还有个偏方，把示例里的变量名改成特别有辨识度的前缀，比如proj_开头，这样模型就算想自由发挥，也容易下意识跟着这个模式走。说到底，LLM写代码更像“风格迁移”而不是“严格复刻”，你得把约束从“请你”改成“必须”，从描述变成强指令，试试看会不会好一些。

太长确实容易飘，试试把示例拆成几个小片段，每个片段单独强调要模仿的点。

试试把示例代码放在Prompt最后，紧挨着生成指令，太长确实会被中间内容冲淡注意力。

这问题我也踩过坑，200行示例对LLM来说确实太长了，注意力会分散到后面就忘了前面的风格。我试过最有效的办法是把示例压缩到20-30行核心代码，然后在Prompt里直接说“用这段代码的风格写”，比“请严格按照”管用得多。另外别用xml标签，有时候反而干扰它理解，直接放纯文本代码块就行，你可以试试。

这个问题我太有共鸣了，之前调LLM写重构代码时也踩过同样的坑。你试的那些方法我都试过，后来发现关键不在示例长度，而是它默认你的示例只是“参考风格”而不是“硬性规范”。我现在的做法是直接在Prompt里声明“以下示例是唯一允许的命名和结构模板，任何偏离都视为错误”，然后只给一个最小可复现的片段，比如10行核心函数，而不是整个200行。另外，把示例放在Prompt的最后一段靠近生成位置，比放在开头效果更明显，因为注意力机制对结尾的上下文更敏感。还有个土办法，就是干脆在生成后用脚本检查变量名列表，强制替换成你定义的命名，虽然笨但很稳。至于“逐行模仿”，我试过，对短代码有用，但代码一长它就开始自由发挥了。你不如试试把示例拆成多个小模块，每个模块单独给它一个指令，这样它反而更听话。

我之前也踩过这个坑，后来发现把示例代码放到Prompt最前面，并且明确要求“先输出一段对示例的总结，再写新代码”，效果会好很多。200行确实容易让注意力分散，试试只挑出最关键的两个函数做范例，剩下的用自然语言描述结构。另外，让它先复述一遍你的命名规则再动工，比单纯说“严格遵循”管用得多。

我之前也踩过这个坑，后来发现把示例放在Prompt最前面、紧跟着任务描述会好很多，模型对开头和结尾的内容注意力更强。另外别只让它“模仿”，试着明确说“所有变量名必须从示例中挑选，函数结构保持一一对应”，这样约束更硬。200行确实偏长，如果可能的话拆成几个小例子分步给，每个例子配一个子任务，效果比一次性塞给它强。还有个小技巧，在示例代码后面加一句“如果偏离示例风格，请先输出你打算修改的理由”，有时候能让它自己刹住车。