0. 一点小吐槽#
不得不说，最近的coder模型真的是快速更新换代，而且代码理解+需求能力水平也在不断增强，现在连复杂点的task都能直接用ai跑了。
想当初今年年初那时候，其实自己试过用ai写过一些代码，用api调的某大模型。但怎么说呢，效果其实还算有点一言难尽。假如说接入ai前是60%的开发时间+40%的自测时间，那么用ai开发时间基本上就只会变成：15%写需求让ai生成or修改代码+40%自己去找ai写出来的代码里面的bug+40%的自测时间（笑）。运气好点中间那段时间找bug的时间可能会少点，但感觉整体质量不太可控。
所以基本上，个人只会让ai做些比较简单的体力活，比如去年的deepseek-coder-v2:16b模型，就用continue插件接到vscode做inline code complement，比如：
除了coding以外，也就用LunaTranslator跑跑llm的sakura翻译模型，比如：
扯远了。最近Qwen3 coder模型出来之后，感觉也有试一下的价值，试试就试试，反正也就试些简单的体力活。
1. Setup#
模型用的是Qwen3-Coder-30B-A3B-Instruct-GGUF，用的Q4_K_M量化。装过ollama的情况下，直接敲ollama run hf.co/unsloth/Qwen3-Coder-30B-A3B-Instruct-GGUF:Q4_K_M就能跑起来了。在context window小的情况下还勉强能占满24g显存用gpu跑，大一点基本上就会用cpu+gpu的混合模式，用上完整的256k那就只能纯cpu跑了。不过对不算复杂的任务来说，64k就够用了。
（截第一张图的时候还开着个mumu模拟器挂着个游戏）
vscode插件的话，roo和cline两个都可以，但cline有个好处就是能自己调本地模型的context window，用roo的话就只能跑满256k context window，不能自己调大小。
2. 效果#
简单用自己fork的pyNCMDUMP仓库试水。总共有3个task去测试模型：简述类task、单点功能修改task、多点功能修改task
2.1 简述类task#
@/ncm_converter.py @/ncmdump.py @/README.md 有两个python文件，根据readme文档，哪一个是正确的
task一开始，Cline会把任务+文件都扔给llm，这段prompt相当消耗token，大概会用掉10+~20+k的token，内容如下：
1 | ```markdown |
然后llm就会用些内置的指令去读文件内容/文件夹内容。
当然，给出这个结论似乎也没毛病，回想一下确实任务描述还有点问题，应该问的是：哪个文件的代码更新一些，这样说明能准确一点，单问一个“哪个是正确的”还是有点过于笼统。
2.2 单点功能修改task#
在上面的任务上，接着让llm做一个小改动，内容如下：
修改@/ncm_converter.py 这个文件，当转换后的文件存在时仍然进行强制转换
llm也能够用cline内置的replace_in_file工具，把对应位置的代码给注释掉。
修改完后完成任务。
2.3 多点功能修改task#
比较常见的场景就是给代码加点简单的小功能or实现点小的需求改动，比如：
把修改的功能优化一下，加一个—force参数，当这个参数存在的时候才跳过进行强制转换
执行的话，更偏向于一个地方一个地方地去改。
第一次修改的是dump_single_file，加了个参数，把上一步注释掉的代码改成新的。
第二次修改的是给parser加了个--force参数，并传给dump。
第三次修改是在调dump_single_file的process_file这地方，补上新的参数。
第四次修改是在dump调用dump_single_file的地方，加上新的参数。但在dump函数的参数里面漏了。后面才发现了。
所以第五次修改则是把上面漏掉的给加回去……
最后的代码变更为：
最终的任务状态：
这一串任务执行下来，一共花了57k的context window。复杂点的task得自己评估下这个值要改成多大了。
3. 结论#
其实在测Qwen3-Coder-30B-A3B-Instruct-GGUF之前，先用了qwen2.5-coder-tools 14b模型试了下水，但效果觉得还是有点一言难尽。30b模型对14b而言还是碾压级别。只能说parameter size is all you need。大模型除了有点烧钱以外，其实效果会更好，这个就得看自己对ai coding的依赖程度和预算了。之前用公司的api key的去跑sonnet 4.0，一个下午就能花掉整整30刀（笑）。
