大家用Qwen2.5-Coder写代码时，长上下文真的靠谱吗？

本地跑32B本来就吃紧，长上下文一多注意力就飘，脑补变量属于老毛病了。

这问题我太有同感了，32B本地跑本来就吃紧，长上下文一多注意力就散，模型容易把“合理猜测”当成“事实依据”。我后来试过把相关代码先手动精简成伪代码再喂进去，效果反而好不少，但真到跨文件重构还是得靠工具链。DeepSeek-Coder我也试过，单文件能力差不多，长上下文的幻觉问题也没根治，建议直接Cursor配Claude或者GPT-4o，省心太多。

说实话32B本地跑这个上下文长度本来就有水分，Ollama默认的context size经常被截断，你可以先检查下num_ctx是不是真的设到8k以上。另外这模型对跨文件引用本来就弱，它更擅长单文件内的局部重构，你指望它像人一样追踪多文件依赖确实有点难。我现在是拿它当高级补全用，跨文件逻辑还是自己理清楚，真要全自动改项目还是得上Cursor那种带索引的方案。

说实话32B本地跑这个体量，跨文件确实容易自作聪明，它本质还是按token概率在补全，不是你给多少它就严谨守多少。我试过把三个文件合并成一个带清晰分隔符的伪文件，效果比分开喂好点，但碰到真正的大项目还是得靠RAG或者直接上长上下文版本。你那个system prompt大概率被后续代码内容稀释了，Ollama默认的上下文长度要手动调，不然它根本记不全。如果只是日常改代码，Cursor的补全体验确实更稳，DeepSeek-Coder写算法题还行，项目级重构还得看你对它的调教程度。

32B本地跑这个规模，跨文件本来就容易放飞自我，它那个“根据上下文推断”其实是把注意力分散到无关token上了。你试试把system prompt换成“仅引用输入中出现的代码块”，或者干脆把三个文件合并成一个带明确注释的伪文件再喂进去。我拿它改过中型项目，发现显式标注每个文件的类名和函数签名比纯靠自然语言描述靠谱得多。要是图省事直接上Cursor吧，毕竟它那套索引机制不是Ollama能比的。

说实话你这情况我也踩过坑，32B本地跑确实容易在长上下文里“自作聪明”，尤其是多文件关联时，它更倾向补全逻辑而不是严格遵循system prompt。我觉得不完全是上下文窗口的问题，Ollama默认的上下文设置可能没调够，但就算拉到16K，模型对跨文件引用的理解还是偏弱，它更像在“猜”而不是“查”。我试过把相关代码块手动拆成更小的片段分别提问，效果反而好一些，但那样就失去“喂整个项目”的意义了。DeepSeek-Coder我也用过，单文件任务更稳，但跨文件一样会幻觉，只是没那么夸张。真要干正经活，我觉得Cursor那种把整个代码库索引起来的方案才是正解，本地模型目前更适合做局部重构或者写测试，别指望它管全局。你也可以试试给每个文件加个清晰的注释头，标明依赖关系，有时候能减少它瞎编的概率，但根治还得等模型进化。

说实话32B本地跑长上下文就是会这样，我试过把函数拆成单文件喂进去反而靠谱点。