背景
各模型概要

性能评估

实践
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插件与其他插件,模型下进行对比尝试。直观对比看效果。
希望对大家有帮助与启发。