用Claude Code和GLM 5.1写完一个小功能后,我发现AI始终解决不了一个细节问题

最近尝试用Claude Code配合GLM 5.1开发一个简单的前后端交互功能。整个过程基本没有手写多少代码,前端页面、Java接口、数据查询逻辑都由AI生成。需求并不复杂:用户输入一个业务ID,前端调用后端接口,

Java服务查询数据库后返回结果。代码生成得很快,请求发送正常,接口响应也正常,但最终查询结果始终为空。数据库明明存在对应数据,可功能就是达不到预期效果。

最开始我以为是SQL语句或者参数映射出了问题,于是把完整代码和日志再次交给Claude Code和GLM 5.1分析。

两个模型都给出了各种排查建议,包括检查Mapper配置、数据库连接、事务设置以及接口参数绑定,但始终没有定位到真正原因。

后来我直接打印请求参数进行对比,很快发现问题所在。数据库中的业务ID是19位Long类型,而AI生成的前端代码直接使用JavaScript Number进行传输。

由于JavaScript大整数存在精度限制,请求发送时数字最后几位已经发生变化。后端收到的值看起来没问题,但实际上和数据库中的真实ID已经不是同一个数字,自然查询不到数据。

修复方法非常简单,把Long类型统一按字符串传输即可,几分钟就解决了问题。

这次经历让我感触很深。无论是Claude Code还是GLM 5.1,在代码生成方面确实能够大幅提升开发效率,但面对Java Long精度丢失、JavaScript大整数处理、前后端参数传递这类细节问题时,最终还是需要开发经验来判断。

代码生成越来越容易,但问题定位能力依然是开发者最核心的价值。只有真正理解代码的人,才能把AI工具的价值发挥到最大。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注