linux.do

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 提供了**三个梯度的方案**（流程隔离、入参增强、数据回填）。
    * **方案一**（推荐）是最优解，通过业务流区分，从根本上杜绝“更新调新增接口”的错误。
    * **方案三**（查库回填）考虑到了数据完整性，非常有参考价值。
* **B 的方案：** B 的建议较为笼统，虽然方向正确，但没有像 A 那样给出具体的架构权衡。

### 4. 关键证据的发现
* **A 的“神来之笔”：** A 在最后提到 **“line 2939 已经有人注释掉了...这也佐证了这是一个已知但未完全修复的问题”**。这一点非常关键，它通过代码考古（Code Archeology）证明了该 Bug 的历史背景和修复的紧迫性，这能极大增强分析报告的说服力。

---

### 总结建议
如果你需要向领导或团队提交报告，**建议以 A 为主框架**，并适当吸收 B 关于 `NowDataHandleServiceImpl` 潜在风险的提醒作为补充。

**一份完美的分析报告结构参考：**
1.  **结论先行：** 明确指出创建时间被覆盖是因为更新/计算流程误触发了新增初始化逻辑。
2.  **核心矛盾：** `InitNowDataUtil` 依赖 `isEmpty` 判断，但在更新场景下，前端不传 `createTime` 导致判断永远为真（即：空值不代表新增，可能代表部分更新）。
3.  **受影响场景：** 字段联动计算、同步计算、Excel 导入（参考 A 的三个场景）。
4.  **历史佐证：** 提及已有部分代码被注释，证明逻辑不统一（参考 A 的观察）。
5.  **修复对策：** 推荐方案一（隔离调用流）。

我自己的结论:如果是小项目小团队可以使用glm,没有封号代理的烦恼,上手快,价格也适中。对于追求高质量高效率的还是claude(当之无愧的第一).
吐槽一点:glm的思考推理速度和老奶奶过马路一样 😅
备注一下:使用的模型都是官方的，没有任何中转缩水。

1 个帖子 - 1 位参与者

阅读完整话题

via LINUX DO - 最新话题 (author: 1314520)

20 views08:22