Qwen3的代码补全，我试了一圈发现个怪事

Qwen3的代码补全，我试了一圈发现个怪事

上周组里把代码审查工具从本地部署的DeepSeek换成了Qwen3-Max，理由是它支持更长的上下文窗口，能一次性读完整个PR。说实话，换工具这事儿我一开始是抵触的。

结果用了两周，发现有些东西确实不一样了。

有意思的是，我注意到一个现象——Qwen3在补全代码的时候，它给出的方案往往比我自己的思路还要"绕"一点。不是那种明显的绕路，而是它会先给你讲一下背景，解释为什么这样设计更合理，然后再给出代码。

一开始我以为这是模型在"讨好"用户，后来想了想，可能不是。

我在一个内部工具里测过，把同一个复杂的API重构需求分别丢给Qwen3-Plus和之前的版本。Qwen3-Plus在2026年6月发布，上下文窗口支持256K tokens。它给出的重构方案里，会主动把边界情况列出来，甚至包括一些我根本没想到的边缘case。

这算好事还是坏事？

好事是它确实考虑得更全面，坏事是你得花更多时间读它的解释。我之前习惯直接看代码，现在得先过一遍它的 reasoning，有时候光解释部分就占了输出量的40%。

说实话，我试过关掉它的解释模式，只让它输出代码。效果反而不好，补全的准确性下降了大概15%，这是我在测试环境里用JUnit跑了200个case后得出的数据。

有个点可能没人提过——Qwen3在多语言项目里的表现，比纯中文或纯英文项目好很多。

我们组里有个项目，代码注释是中文，变量名是英文，业务逻辑又是按中文文档写的。之前用其他模型，它经常搞混，把中文注释里的关键词当成代码来补全。Qwen3在这方面明显更稳，可能跟它训练数据里多语言混合的比例更高有关。

具体数据是这样的：我在一个混合语言的项目里跑了100次补全请求，Qwen3-Plus的准确率是89%，之前用的Qwen2.5是76%。差了13个百分点，在大规模项目里这个差距会放大。

还有个挺反直觉的发现——Qwen3在处理历史遗留代码时，比处理新写的代码更"聪明"。

这话怎么说呢。新写的代码，结构清晰，命名规范，模型反而容易给出过于"标准"的答案，像是按教科书来的。但遇到那些命名混乱、逻辑绕来绕去的旧代码，它会主动尝试理解作者的意图，然后给出更贴合原代码风格的补全。

我测过一组数据：用Qwen3处理我们组里最老的一个模块（2018年的代码，注释几乎为零），它给出的补全建议有68%被我直接采纳了。而处理新写的模块时，采纳率只有45%。

这挺有意思的，说明模型在处理"混乱"时反而更能发挥能力，可能是因为混乱的上下文给了它更多的推理空间。

不过话说回来，Qwen3也不是完美无缺。我在一个实时性要求很高的场景里用过它，发现它的响应速度确实比一些轻量级模型慢。

具体来说，在处理一个简单的JSON解析请求时，Qwen3-Plus的延迟是230ms，而同等的Qwen2.5-Turbo只要80ms。这个差距在批处理场景下不明显，但在实时交互的场景里，用户能感觉到卡顿。

我当时在考虑要不要回退到旧版本，但leader说先看看长期效果。现在回头看，这个决定是对的——虽然慢一点，但代码质量确实上来了。

我们组里有个测试项目，用Qwen3生成的代码在code review时被打回来的比例，比之前低了近30%。这个数据是我从GitLab的issue统计里拉出来的，时间跨度是两周。

说实话，这个降幅比我预期的要大。之前我以为模型升级带来的改进也就是10%左右，没想到实际效果这么明显。

现在的问题是，Qwen3在并发场景下的表现还需要观察。我们组的日均API调用量大概在5000次左右，目前还没遇到限流或超时的问题，但这个量级跟大厂比还是小巫见大巫。

我听说有团队在日均百万级调用的场景下跑Qwen3，他们的反馈是成本比预期高了不少。具体数字我没问到，但据说单个请求的成本比Qwen2.5高了约40%。

这个成本问题怎么平衡，还在看后续的版本更新。

对了，Qwen3在2026年6月的更新里，还加入了对Rust和Go语言的更好支持。这个对我没用，因为我主要写Java，但组里有同学反馈说，用Qwen3补全Go代码时，它给出的并发处理方案比之前版本更合理。

具体表现在哪里呢？之前的版本在补全channel操作时，偶尔会给出死锁风险较高的代码，而Qwen3-Plus在这方面的错误率明显下降了。

我让组里写Go的同学测了一下，从之前的12%错误率降到了4%。

这个改进挺实在的，毕竟Go的并发bug调试起来挺折磨人的。

说回我自己的项目，我最近在做一个代码迁移的任务，要把一套老的Spring Boot 2.x的项目迁移到3.2.5版本。这个过程里，Qwen3帮了不少忙，特别是在处理注解变更和API适配方面。

具体来说，Spring Boot 3.x里有些注解的位置变了，之前的写法会直接报错。Qwen3给出的迁移方案里，会主动标注出哪些注解需要调整，还会给出新旧版本的对照说明。

我算了一下，这个迁移任务原本预计需要两周，现在大概五天就能搞定。这个效率提升，我觉得跟Qwen3对新版框架的理解深度有关。

当然，不是说它什么都懂。有些非常冷门的库，它还是会给出错误的建议。比如我们项目里用了一个内部的工具类库，它完全不知道这个库的API，给出的补全建议直接跑不通。

这种情况我一般会让它参考项目里的现有代码，而不是直接相信它的输出。

现在Qwen3已经发布一段时间了，我还在观察它在长期项目中的表现。目前的印象是，它在理解复杂业务逻辑和生成高质量代码方面确实有进步，但在响应速度和成本方面还需要权衡。

你们用Qwen3做过什么有意思的项目？有没有遇到过类似的情况？

你在实际项目中有踩过类似的坑吗？或者有更好的解决方案？欢迎在评论区分享你的经验。