1. 背景

        说好的要拥抱全开源工具，对Anthropic封杀国内接入其大模型服务行为是愤慨的，开始安装了Claude Code之后试用一下子就没继续了，奈何opencode给我留下那么多烂摊子，让我对Qwen系列小模型能力产生极度怀疑，大功率的开源大模型，没硬件资源也安装不上啊，如今天GLM5.1那不是一块GPU能搞定好的。

        继续使用Claude Code源于一个偶然，刚好运维线上发现一个bug，需要在一个老Java业务系统去bugfix,  我已经好久没接触那个系统代码了，想想用Claude Code试试，就把产品人员写的bug单里的文字抽取出来写了一个usecase.md，在claude命令行上@引用一下，让它给一个修改plan，我自己都不记得在哪个代码文件了，很快，claude竟然找出来了，给出了修改细节，直指代码文件行。

        我感觉不对，跟它说应该是另一个文件的一个接口，然后它很快分析出来说不对，那个接口已经处理好了，不用修改，我细看了一下，和发现问题的运维人员确认一下，还真是这么回事，claude全对了，我竟然错了！

        于是我震惊了，产品人员写的全是中文，没提任何类和方法，claude应该是通过产品人员的文字去Java代码里的注释或注解说明去分析出来的吧。

        还有，它一路飙中文，我都没做什么设置，也没提醒它，想想opencode不停提醒还一次次全文，最后，claude的修改总结，不管是表格还是文字说明，让人一看就明白，很舒服，顺眼。

        是不是Claude Code可以解决手头这个被opencode折腾的一团乱麻的真实数据分析预测项目? 

2. 换枪

        下午立即行动exit掉opencode, claude上场先接手重构那个最烂的class, 先来一个plan，速度就比opencode快多了，看看plan靠谱，切换到edit模式执行，很快搞定，看看代码质量，比opencode好多了，信心终于回来了，可能不用手工coding了。

        之后系列的数据结构重构、已有功能bugfix、新功能开发，半天时间搞定既定计划任务，细节不必说了。

        这里要说一下的是对比分析：大模型服务是同一个本地内网自建的vLLM + Qwen3.5-35b-A3B-FP8, opencode和claude code同时接入同一个vLLM服务，同时去解决同一个项目需求，其编程能力相差这么大，这和大模型推理能力有什么关系呢，这难道不是证明前端工具其自身能力是很重要的，不然是用不好大模型能力的。

        下面列举几个说法：

        另外两家要靠谱一点：

3. 总结

        不要老是怀疑现在你接入的大模型是不是能力不足，也要想想你到底用好了它没有。

        对我司来说，claude code接入Qwen3.5，都能处理编程这么复杂的事情，用Qwen来处理我们那点业务逻辑，按道理是胜任的，就是我们会不会使用了，因为从opencode和cluade code同时连接qwen3.5-35b-a3b-fp8的相差这么大的表现看，模型是相同的，推理能力是肯定相同，那么不同的当然是客户端的处理、编排能力了，我们做程序也就是处在客户端侧的位置了，如果我们在Prompt工程、Context工程、Hermes等不用心去使用，效果可能很不如意，然后我们把责任全推给大模型LLM能力上，这实属浪费资源。

        Claude Code 51万行源代码泄露，Gemini 3.1 Pro 对 Claude Code 源码的客观锐评：“天才写的代码，凡人维护不了”。