VSCode Ollama本地模型+cline实现agentic coding

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插件的话,roocline两个都可以,但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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
```markdown
<task>
'ncm_converter.py' (see below for file content) 'ncmdump.py' (see below for file content) 'README.md' (see below for file content) 有两个python文件,根据readme文档,哪一个是正确的
</task>

<file_content path="ncm_converter.py">
(文件内容)
</file_content>

<file_content path="ncmdump.py">
(文件内容)
</file_content>

<file_content path="README.md">
(文件内容)
</file_content>



# TODO LIST RECOMMENDED
When starting a new task, it is recommended to create a todo list.




1. Include the task_progress parameter in your next tool call

2. Create a comprehensive checklist of all steps needed

3. Use markdown format: - [ ] for incomplete, - [x] for complete



**Benefits of creating a todo list now:**

- Clear roadmap for implementation

- Progress tracking throughout the task

- Nothing gets forgotten or missed

- Users can see, monitor, and edit the plan



**Example structure:**
```

- [ ] Analyze requirements

- [ ] Set up necessary files

- [ ] Implement main functionality

- [ ] Handle edge cases

- [ ] Test the implementation

- [ ] Verify results

```javascript



Keeping the todo list updated helps track progress and ensures nothing is missed.


<environment_details>
# VSCode Visible Files
(No visible files)

# VSCode Open Tabs
(No open tabs)

# Current Time
2025/9/6 下午5:35:52 (Asia/Shanghai, UTC+8:00)

# Current Working Directory (g:/coding/python/pyNCMDUMP) Files
.gitignore
LICENSE.txt
ncm_converter.py
ncmdump.py
README.md
requirements.txt

# Git Remote URLs
origin: https://github.com/qhgz2013/pyNCMDUMP
upstream: https://github.com/allenfrostline/pyNCMDUMP

# Latest Git Commit Hash
c914b17aa923077dad90be7e762c183a870efdfd

# Context Window Usage
0 / 65.536K tokens used (0%)

# Current Mode
ACT MODE
</environment_details>
```

然后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_fileprocess_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刀(笑)。