CodeGeeX体验GLM4.5模型与实践

339 阅读1分钟

背景

各模型概要

image

性能评估

image

实践

Ghost Comments

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

image

代码BUG修复

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

image

增加注释

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

image

解释代码

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

image

实战代码扩展性修改PK

提示词

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

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

image

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

对比TONGYI LINGMA+Qwen3-coder

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

image

对比Trae+Gemini 2.5 Pro

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

image

Kiro+Claude 4.0

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

image

二次对话生成单元测试

image

Trae+Kimi-K2

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

image

总论

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