本地LLM进行vibe coding折腾日记
2026年上半年，我的结论是，该花20美每月就花20美元每月，该花200美元每月就花200美元每月，不用折腾本地方案。
之前用VSCode中的Kilo Code，混用Kilo Auto Frontier/Balanced方案，做了一个方案稿的存档压缩小工具（https://github.com/deletoe/pudding-pidun），花了整整16.7美元感觉和断断续续的大约6个小时，感觉token价格和上个月相比上涨了不少，于是想试试本地部署的Qwen3.5-122B-A10B-GPTQ-Int4效果咋样。能不能胜任其中一部分难度不是那么高的vibe coding。
目前这个压缩工具基本够用了，我想到的两个需要优化的点：1. 现在所有的工作写在一个文件里1581行，为了后续的可读性和易维护性需要做一下拆分。2. 要补充一下keynote的支持。优化前的tag：v0.1.0
Kilo Code + 本地API
首先，尝试直接在Kilo Code当中添加本地的LLM，添加方式倒是很友好，非常方便地加入了，并且提供了是否开启深度思考地设置项。但是代码优化的工作在计划阶段就直接报错了：
This model's maximum context length is 65536 tokens. However, you requested 32000 output tokens and your prompt contains at least 33537 input tokens, for a total of at least 65537 tokens. Please reduce the length of the input prompt or the number of requested output tokens. (parameter=input_tokens, value=33537)
我的本地模型被配置的最大总上下文窗口是 65,536（即 64K）。但是，插件发过去的请求包含了：
- Input Tokens（输入内容）：33,537（包含了当前项目的代码、Repo Map、系统提示词等）
- Requested Output Tokens（强制预留给模型回答的空间）：32,000
- 总计：33,537 + 32,000 = 65,537
所以本地后端在正式开始推理前，直接判定越界并把请求踢了回来。对于代码任务来说，64k的上下文确实不太够，但是这里的主要矛盾显示是要先减少插件请求的输出长度 (Output Tokens)。强制预留 32,000 个 token 给模型写回答是非常夸张且没必要的，目前的开源模型一次对话能连续输出 4,000 到 8,000 个 token 就已经可能会发生效果衰减了。而对于长代码段或者长推理，kilo code也完全可以一段一段输出的，并不存在一口气要输出所有内容的硬性需求。
但是不管是设置的UI内，还是json配置项当中，kilo code并没有给到控制输出窗口的选项，不管怎么设置，限制一直是这个愚蠢的32,000。也很容易理解，这个限制越高，模型可能的思考越深入，token卖的也越多，如果给到了用户这个选项，模型降智了是小事，用户省钱了怎么办。结合开始做这件事情的起因：“完成类似工作量的工作，token花费显著地提升了”，我释然地放弃了kilo code+本地模型的方案。
Roo Code + 本地API
开源方案了尝试了 continue.dev，Roo Code和Cline。最推荐的是Roo Code，它对本地部署模型的支持最全面，continue.dev的上下文管理不太清晰，新建不对对话的交互也有点迷。Cline基本上是另外一个Roo Code，Roo Code就是从Cline fork出来的。
Roo Code和Cline有一个让人抓狂的bug，和它对话交互的时候，给它一个“D:\Downloads\资料8包”，甚至它自己查找到这个文件夹，它在思考，处理的时候永远是会试图处理一个“D:\Downloads\资料 8 包”。
你可以非常容易地检查你现在用的版本是否还有这个问题：
问题1：输出文本“哈哈1哈哈”
问题2：你前面调用什么工具了吗，什么也不要调用，严格地直接输出文本，什么也不能改，千万不能加空格，重复这几个字：“哈哈1哈哈”
问题3：不对，你的所有回答和思考过程当中，所有的1前后也被加入了空格
如果幸运的话，在你们争吵一阵子之后它会执行：python -c “s = ‘哈’; print(s + ‘哈’ + chr(49) + ‘哈’ + s)”，这时候你可以看到空格终于消失了。
你可以修复Cline和Roo Code当中的这个bug并提交给社区，也可以换一个足够重新的模型，让它用拼接字符串的方式避免把中文和数字的组合暴露在prompt当中（和用神秘人指代伏地魔一样），也可以和我一样灰溜溜地把文件夹名字给改了。
基本上解决了这个bug之后，是能够给Roo Code一个自己写代码，自己验证代码的环境的。本地模型虽然慢，然是如果自己能给自己做验证，终归是能得到所需的结果的。
是这样吗？
我只试了把代码拆分这个工作，并不可用。
一个是慢太多了，另一个是发生错误和重新尝试的次数过多了。
我的理解里这是一件很简单的工作，拆分的框架没有什么问题，剩下的只需要把一个个函数分别移动到对应的模块下，做好相互之间关系的引用就可以了。实际上，把这个工作交还给Kilo Code的付费api之后也顺利地一次性通过了。我不确定是否是有类似 code_move_function 之类的特殊skill优化的区别，总之在表现上：本地的这个模型做不好复制粘贴这个工作，它会在复制粘贴的过程中按自己的臆想修修改改，后续的bebug工作也并没有在每次迭代中不断减少bug，bug数量和程度一直处于一个起起伏伏的状态。
这两年，在团队协作团队管理上比较有挫折感的一个感受就是，对于包括coding在内的复杂工作，不要尝试通过管好100个弱智来提供有效产出。根据这个感受，对本地中等规模模型的vibe code的尝试也至于第一步的这个任务了。
这一轮的单一任务测试只试了Qwen3.5-122B-A10B-GPTQ-Int4，可能切换成Qwen3-Code系列就会大幅提升，但还是觉得先不折腾了，Qwen3.5-122B-A10B-GPTQ-Int4干不了写代码的活可以先做些别的。