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

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