大家用开源模型写代码都怎么解决上下文不够的问题？

4070跑32B的Qwen确实费劲，但可以试试把项目按模块拆开再喂代码，另外开个新对话前把关键类结构直接粘贴进去，比RAG省事多了。我用Cline的时候会配合continue插件，把TODO和依赖关系写进注释里当伪上下文，实测瞎编概率降不少。真想搞长窗口的话，试试llama.cpp的parallel窗口加KV cache复用，不过得牺牲点速度，你卡上8G显存可能刚够跑7B的。

4070跑32B的QwenCoder其实挺吃力的，我之前也卡在这，后来发现与其硬塞长上下文不如把项目拆成最小复现单元再喂给它。比如改Spring Boot老代码时，我会先把相关实体、Mapper、Service的接口定义单独抽出来拼到对话开头，比直接扔整个Controller文件效果好很多。RAG那套对单文件重构确实有点重，我自己试过用简单的脚本把项目结构树和关键类签名生成成文本，需要时手动粘过去，成本低还不占显存。另外如果只是忘了类定义，可以试试让它先输出“假设以下方法存在”再继续写，很多时候能绕过去。实在不行就切对话，但切之前让它把当前改动的核心逻辑和接口约定总结成一段话，下个对话开头贴回去，比从头解释省事。长上下文模型像glm-4-9b-1m我也试过，但速度太慢，4070上日常用反而憋屈。

4070跑7B模型其实挺舒服的，但上下文一长显存就爆炸，我现在的做法是直接开两个对话窗口，一个专门放核心类定义和接口签名，另一个写具体方法，写完再手动粘回去，虽然麻烦点但比它瞎编强。RAG那套我试过，配了半天向量库，结果对代码这种强逻辑的东西帮助有限，还不如把项目结构树和关键依赖塞进system prompt里实在。另外你试试给模型加个“先复述已知信息”的指令，让它每轮回答前把记得的类名和字段列一遍，能明显减少幻觉，代价是浪费点token。等上下文这东西，其实Qwen官方出的那个长文本版也就那样，真改老项目还是得靠人肉分段，毕竟业务逻辑跨文件的关系，模型根本捋不清。我现在最常用的招数是把要改的方法单独抽出来，配上它依赖的DTO和Mapper接口，凑成一个小而全的上下文，改完再自己集成回去，比让它看整个项目靠谱多了。

直接切对话最省事，4070跑RAG有点悬，等Qwen3长上下文出来再折腾也不迟。

说实话4070跑满血版本来就吃力，我建议直接上量化过的32B模型，配合siliconflow这类云API做长上下文分支，本地只跑短对话。我现在就是本地硬切，但会把整个文件路径和关键类结构贴进每轮对话开头，成本低且有效。另外可以试试把项目拆成小模块分别问，别指望一次聊完，老代码重构本来就是迭代活。

我4070也跑过Qwen2.5-Coder，改老项目确实容易断片。我的土办法是别让它一次吞整个文件，按类拆开喂，改完一个方法就让它重新贴一遍相关接口签名当锚点。RAG搭起来其实没想象中重，Chroma加个bge-small本地嵌入就够，主要费时间在切代码块。硬切对话最坑，上下文一丢它就开始编，不如手动维护个简短的项目结构摘要塞在system里。

4070别硬撑长上下文了，我一般按模块拆开喂，改哪个类就只贴哪个类，比RAG省事多了。

我之前也拿4070跑Qwen2.5-Coder改老项目，跟你情况差不多，聊几轮就开始编方法名。后来我的土办法是把要改的类和相关接口手动贴进对话里，每次只聚焦一两个文件，别让它一次管整个工程，虽然笨但挺管用。RAG我也试过，用llama-index搭本地向量库其实没那么吓人，就是索引老代码有点费时间。你要是不想折腾，就等下一波长上下文模型吧，现在硬切对话真的容易翻车。

4070跑本地代码模型确实够呛，我8G显存一般就挂个量化版凑合。上下文这块我试过用continue配个简单的向量检索，把当前文件和相关类塞进去，别搞全库RAG那么重。其实最省事的还是改完一个类就重开对话，把改动摘要贴回去，虽然笨但比模型瞎编强。等长上下文模型落地也行，但眼下工程习惯比模型能力更管用。

4070就别硬堆上下文了，我一般把相关类手动喂进去，改完再让它总结成接口说明存着，下次直接贴。

4070就别硬扛长上下文了，我一般只把当前要改的类和接口丢进去，改完再换下一段，比RAG省事多了。

4070别硬上RAG，试试按模块拆文件喂，聊完一个类就让它总结成注释再开新对话。

4070别折腾RAG了，我直接分段喂代码，改哪块贴哪块，比啥都省事。

4070就别折腾RAG了，直接开新对话带上关键类定义最省事，我改老代码都这么干。

我之前也遇到过这问题，后来干脆把项目拆成小模块，每次只让它看需要的两三个文件，改完再手动整合回去，虽然笨但挺管用。4070跑量化版的话可以试试用llama.cpp开大点的n_ctx，不过速度会掉不少。RAG搞代码其实不复杂，用Continue插件配个本地的向量库就行，敏感度比聊天低多了。实在不行就换DeepSeek-V3的API吧，长上下文体验确实不一样。

4070就别硬扛长上下文了，我一般手动喂关键类定义，再配合aider这种轻量工具自动裁剪，比RAG省心多了。

我之前也踩过这个坑，用DeepSeek-Coder改一个老项目，聊到后面它直接给我编了个不存在的方法，排查半天才发现是它把前面的Service类给忘了。后来我的做法是别硬聊，按功能模块拆成小任务，每次只给它一个文件或者一个类的完整代码，让它在这个范围内改，改完我自己合回去。这样虽然麻烦点，但准确率上来了不少。RAG我也试过，用LlamaIndex加个本地向量库，说实话配置不算特别复杂，但对4070来说检索和推理抢显存挺难受的，得来回切。现在更常用的是手动喂上下文，把相关的接口定义、实体类精简一下贴给它，控制在它窗口的七八成以内。另外提示词里明确让它先复述一遍它理解的类结构再动手，能提前发现它是不是已经忘了。等更长上下文的模型也不是不行，但显存这关绕不过去，量化之后效果又会打折，感觉还是拆任务最实在。

我之前也遇到过同样的问题，后来用了个土办法：每次改代码前先让模型把相关类和方法整理成一个“接口摘要”，然后只把摘要和当前要改的片段一起丢进去。这样虽然还是切了上下文，但至少模型不会把前面的类定义忘光。4070跑7B量化模型问题不大，别硬上32B。RAG的话可以用llama-index搭个简单的本地代码索引，不算太复杂，但效果也就那样，别期望太高。

我4070ti也在跑Qwen2.5-Coder，之前改老项目跟你一样，聊着聊着它就开始编方法名了。后来我干脆按功能拆任务，每次只让它看一两个相关文件，改完手动把关键类定义贴回去，虽然土但管用。RAG搭过一阵，用llama-index配本地embedding，检索代码片段确实能续命，但调参挺折腾的，显卡也吃紧。现在更倾向换个32k上下文的模型硬扛，省心，反正代码补全场景真用不到那么长。

4070本地跑代码模型确实容易卡在上下文这关上，我自己的体感是12k往后质量就明显往下掉。之前也试过RAG，光是把代码切块、建索引那套流程就够折腾半天，后来发现其实很多场景用不上那么重。现在我的做法是改代码前先让模型把相关类的接口和字段摘要列出来，手动贴进对话开头当锚点，比硬塞整个文件省token也稳。另一个小技巧是别在一个会话里改太多文件，按模块拆开，每次只带当前文件加它依赖的两三个类，这样4070跑起来也不吃力。长上下文模型确实在等，但工程习惯能补不少，比如把项目结构写成一段简短说明常驻在system prompt里。RAG不是不能上，只是对个人项目来说ROI有点低，除非你代码库特别大。真要说的话，先把对话拆分和摘要锚点这两招用熟，比折腾向量库实在多了。