本文针对Java工程研发场景，对比了GLM4.5、TONGYI LINGMA+Qwen3-coder、Trae+Gemini 2.5 Pro以及Kiro+Claude 4.0等多个大型语言模型在代码重构、注释生成、代码解释和单元测试生成等方面的表现。在代码重构方面，GLM4.5虽然综合能力尚可，但与Claude 4.0相比存在差距；Gemini 2.5 Pro虽然解决了依赖问题，但代码修改后存在编译错误；Claude 4.0则展现出较强的模型能力，能够运用设计模式进行代码重构，但未能修改单元测试。文章旨在通过实际案例，为开发者在选择和使用大模型进行代码开发时提供参考和启发。

💡 GLM4.5在Java代码重构任务中表现尚可，但与Claude 4.0相比存在一定差距，其优势在于国产和开源，适合在CodeGeeX等插件环境下进行尝试。

🚀 Gemini 2.5 Pro通过StringRedisTemplate类解决了代码依赖问题，但修改后的代码存在编译错误，未能达到理想的OOP编程效果。

🌟 Claude 4.0在代码重构方面展现出较强的能力，能够运用设计模式进行重构，但其模型能力虽强，却未能同步修改单元测试。

💬 在代码注释生成方面，模型速度较快，但未能生成方法头部的注释，表明在细节处理上仍有提升空间。

📄 模型在解释代码方面表现出色，不仅提供文字解释，还能生成流程图，为代码理解提供了多维度支持。

背景

各模型概要

性能评估

实践

Ghost Comments

看那些右箭头，就是动态注释，没有真实写入文件

代码BUG修复

总体一般，没有智能体的特色，只有CodeGeeX问答模式。

增加注释

速度快，但不生成方法头部的注释

解释代码

文字解释后，生成了流程图

实战代码扩展性修改PK

提示词

@workspace #codebase 此处，我们使用类强制转换为RedisVectorStore类，如何避免直接依赖实现类RedisVectorStore, 修改为优雅代码实现

IDEA+GLM4.5 符合OOP思想，面向接口编程思想。

接下来我们PK其他几个模型

对比TONGYI LINGMA+Qwen3-coder

虽然也实现避免依赖，但又依赖jedispool，不是我们想要的结果

对比Trae+Gemini 2.5 Pro

抽取了，使用StringRedisTemplate类解决问题, 但最终不我们想要的OOP编程. 并且Code代码修改完，还存在编译问题。

Kiro+Claude 4.0

采用相对复杂的代码重构，LLM使用了设计模式进行重构，模型能力的确比较强。但没有修改单元测试。

二次对话生成单元测试

Trae+Kimi-K2

采用投机取巧方法，用了反射来解决问题，也不是我们想要的。

总论

         GLM4.5 代码综合能力还可以接受，重构类任务相比Claude4模型确实有一点距离，但其国产与开源。本文我们于JAVA工程研发代码场景，在CodeGeeX插件与其他插件，模型下进行对比尝试。直观对比看效果。
希望对大家有帮助与启发。