GLM的使用感受

问题描述：

使用了一下glm对比感受
之前一直是使用claude、codex的，glm的出发点是想体验一下国产模型的能力(看看是否有它宣传的强度)
我先是使用的claude的sonnet对比glm5.1模型(想着先试试水不直接和opus对比了，主要感觉没有对比性哈哈哈)
我使用的方法是同一套提示词帮我分析一处代码的逻辑性问题,两个结果我自己显而易见的站在了claude方。
这是我丢给gemini分析的结果(A是sonnet,B是glm):

从逻辑严密性、排查深度和修复建议的可操作性来看，**A 的分析结果更好**。 以下是详细的对比评估，说明为什么 A 的分析更胜一筹： ### 1. 根因挖掘的深度 * **A 的优势：** A 不仅定位到了代码位置，还**精准捕捉到了业务逻辑的误区**。它指出 `ObjectUtil.isEmpty(value)` 这个保护逻辑的假设（“没有值就是新增”）在更新场景下是不成立的。这种对“逻辑假设错误”的洞察，比单纯描述代码执行过程更深入。 * **B 的局限：** B 虽然也列举了场景，但更多是在描述现象，对于“为什么这个空值检查会失效”的本质挖掘略逊于 A。 ### 2. 场景覆盖的完整性（Excel 导入） * **A 的亮点：** A 额外发现了一个非常隐蔽且关键的场景——**场景 3：Excel 导入 (ExcelLoadDataEngineServiceImpl)**。在企业级应用中，Excel 导入覆盖旧数据导致创建时间丢失是极高频的 Bug 来源。A 能关注到非 UI 操作的后台逻辑，说明分析更加全面。 * **B 的亮点：** B 提到了 `NowDataHandleServiceImpl` 的无条件覆盖，这虽然也是一个风险点，但 B 自己也承认“当前未发现被调用”。相比之下，A 发现的 Excel 场景是真实存在的业务威胁。 ### 3. 修复方案的架构思维 * **A 的方案：** A 提供了**三个梯度的方案**（流程隔离、入参增强、数据回填）。 * **方案一**（推荐）是最优解，通过业务流区分，从根本上杜绝“更新调新增接口”的错误。