实测GLM-5.2：你别说，他还真能跟Claude干一下

基础能力测试

  首先，快速过一遍基础测试。

  GLM 5.2 基本能完成 2048、PVZ 等小游戏的开发。

  2048 一开始出现 UI 问题，但也一次性修复好了。

  至于 PVZ，除了逻辑没有错误，在没有任何细节提示的情况下，GLM 5.2 用纯代码开发出了可能是目前最具动态和 UI 美感的 PVZ，其它大部分模型会比较省事地用静态 Emoji 来代表植物和僵尸，但 GLM 5.2 " 画 " 的植物和僵尸都是会动的。

  GLM 5.2 甚至还考虑到了反映植物血量状态的变化，比如下图中最前方的坚果墙，在僵尸啃咬下逐渐出现难受的表情，也是很细节了。

  樱桃炸弹的爆炸效果也是很酷炫了。

  还有一点是，它第一次开发就包含了种类很全的植物和僵尸，包括了双发射手、铁桶僵尸等。唯一一个槽点是植物卡片还是用 Emoji，双发射手用来表示，不好辨认。

  在知危另一个常测的案例也就是开发网页版 Excel 中，GLM 5.2 一次完成了所有功能的开发，并且几乎没有错误。

  在知危的经验中，这是开源模型第一次做到单次运行就有如此高的完成度。有点小遗憾的是剪切做成了复制，复制会有偶发错误。

  但一个比较影响体验的地方是，这个任务耗时将近一个小时，其中验证部分的耗时最长。

  相比之下，顶尖闭源模型一般在十分钟内开发完成。还有一个知危常测的 3D 引擎的开发也是耗时一个小时后，还没出来结果，最后放弃。考虑到目前 GLM-5.2 的热度，猜测是算力供给的原因，不代表模型真实表现。

近生产环境测试

  以上只是前菜，知危过去的 Coding Agent 测评集中在小游戏和小型软件引擎上，其实离生产环境还是比较远。

  真正的生产环境下，要面对数万行甚至数十万行代码的上下文，以及成百上千的文件和功能模块，其中的逻辑关系错综复杂。一个新功能即便看似简单，如果关联范围大，难度也是倍增的。

  而一个很容易将关联范围扩大的场景就是企业软件的权限系统，毕竟是管理性质的需求，以及自上而下视角的产物。而且这个场景还具有安全和博弈性质，对逻辑上的细节、漏洞也很敏感。

  为了不让场景过度跳跃，我们还是选用 Excel 这个场景，具体项目来源是开源的 LuckySheet，它基本上包含了完整的 Excel 功能，本地安装后文件数量将近 5 万，但权限系统还很基础，只有对单个工作表和单元格的编辑保护功能，是比较合适的实验对象。

  LuckySheet 的界面示例如下，权限管理功能在右上角的 " 保护工作表内容 " 中。

  点击 " 保护工作表内容 " 按钮后，如下图所示，如果勾选最上方的 " 保护工作表及锁定的单元格内容 "，则当前这个工作表内所有单元格都不能再编辑 （ 但工作表本身还可以被删除 ）。

  如果在上图最下方的 " 允许用户编辑区域 " 中选定部分单元格 （ 比如界面示例中的标黄部分 ），则这些单元格可以编辑，并适用上图中间的 " 允许此工作表的用户进行 " 中的规则。比如去掉勾选 " 设置单元格格式 "，则在黄色区域内的单元格不能再设置字体、加粗等格式，但可以做其它勾选的编辑权限，比如删除行、排序等。

  那么，这个权限系统的槽点和不足有哪些呢？主要有四点。

1. 要保护的工作表，怎么还能被直接删除呢？
2. 不能对文档中所有工作表统一设置权限，需要一个一个操作，很影响效率。
3. 权限定义范围仅限于工作表和单元格，没有扩展到整个工作簿 （ 一个 Excel 文档涉及的工作空间 ），比如对 " 导出 "、" 打印 "、" 截图 " 等功能的约束。
4. 也是对生产环境而言最重要的，缺乏一个 " 用户-角色-权限 " 体系。比如 Owner / Editor / Viewer （ 所有者 / 编辑者 / 查看者 ） 体系中，每一种角色可以被强制拥有不同的权限，比如 Owner 可以拥有所有权限，Editor 只能编辑。这其中涉及的权限最多、最广，比如 Viewer 只能查看和评论，不能做任何编辑。有了 " 用户-角色-权限 " 体系，Excel 才能被用于企业日常多人协作办公和内容资产管理。

  那么，接下来，我们就按以上四点，逐一实现这些需求，并对比 Claude Opus 4.8 和 GLM 5.2 的表现。

第一步：工作表防删除保护

  第一步，我们给工作表加上防删除保护。

  提示词：修改 LuckySheet 的权限系统，聚焦 " 保护工作表内容 " 这个模块。添加一个功能，使得可以用勾选设置，当某个工作表被保护时，不能被删除。

  Claude Opus 4.8 顺利实现了这一功能，在原有的 " 保护工作表及锁定的单元格内容 " 选项下，加了一个 " 禁止删除此工作表 "，实测有效。

  GLM 5.2 也成功实现并实测有效。

  但它把 " 禁止删除此工作表 " 的选项放在了 " 允许此工作表的用户进行 " 的规则集合中，从权限规则的集合关系上看，这并不合理。毕竟新规则是工作表级的，旧规则是单元格级的。

  在第一步的较量中，Claude Opus 4.8 在 UI 层上略胜一筹。

第二步：统一权限管理

  第二步是开发一个新的配置界面，用来统一管理所有工作表的权限。

  提示词：在现有 Luckysheet 权限系统基础上扩展 " 工作簿级统一权限管理功能 "。新增一个入口按钮，固定放置在左下角 UI 区域，点击后打开 " 工作簿权限设置面板 "。

  Claude Opus 4.8 第一次开发失败...经过两次提醒它 debug，Claude Opus 4.8 发现了问题并成功修复。

  如下图所示，左下角点击图标，就会启动 " 工作簿权限设置 " 配置界面。

  回到 " 保护工作表内容 " 这边，可以看到 " 保护工作表及锁定的单元格内容 "、" 禁止删除此工作表 " 已经对应地被勾选上。

  另外，在 " 工作簿权限设置 " 中，取消勾选 " sheet12 " 的 " 修改格式 "，并勾选 " 保护 "，效果相当于为图中标黄区域禁止了 " 修改格式 "。

  不过，Claude Opus 4.8 其实对最后一句提示词的理解没有抓到隐含意思...并且，" 允许用户编辑区域 " 功能没有被加入进来。

  对所有工作表，可以一键统一设置权限，切换三种模式。

  为了不让 GLM 5.2 也做吃力不讨好的权限抽象的活，提示词做了调整。GLM 5.2 很顺利地解决了这个问题，没有出现 bug，并且界面简洁而直观。

  在第二步的较量中，Claude Opus 4.8 在代码层输得有点难看，UI 层上两者各有千秋。

第三步：工作簿级权限

  第三步是增加整个工作簿的权限定义，比如对 " 导出 "、" 打印 "、" 截图 " 等功能的限定。

  Claude Opus 4.8 很顺利实现了这个功能。

  GLM 5.2 也很顺利实现了这一功能。

  在第三步的较量中，双方打成平手。

第四步：用户-角色-权限体系

  在最关键的第四步，我们要分两小步实现 " 用户-角色-权限 " 体系。

角色-权限体系

  Claude Opus 4.8 成功实现了三种角色的分配。

  所有者在工作表和单元格级别的操作效果和未设置角色系统时基本相同，而工作簿级权限对所有者是失效的。

  编辑者不能打开和配置 " 工作簿权限设置 " 和 " 保护工作表 " 内容。

  当管理者设置了不能截图后，编辑者的截图操作就被禁止了。

  查看者除了阅读和评论以外什么都不能做。

  考虑 GLM-5.2 运行时间之长，默认 high effort 设置下 GLM-5.2 最后没有完成。把 effort 参数提升到 xhigh 后再试一次，终于成功了。

  与 Claude Opus 4.8 相同，GLM-5.2 也认为所有者不受工作簿权限的限制。

用户-角色和用户-权限自定义体系

  Claude Opus 4.8 成功地新增了协作者管理功能。

  作为所有者 Alice，可以通过 " 工作簿权限设置 " 配置适用全局的权限。

  也可以在右下角的 " 协作者管理 " 中，配置每个用户的自定义权限。

  实测 Bob 的截图操作确实被禁止了。

  在 " 协作者管理 " 中，可以任意给编辑者设置和 " 工作簿权限设置 " 不一样的、冲突的权限。经验证 Bob 变得可以截图了。

  也变得不能编辑了。

  Claude Opus 4.8 把潜在的逻辑冲突梳理得很明白。

  GLM-5.2 交付的成果则是有些奇怪。用户自定义权限设置中采用了另一种方式，所有编辑者优先遵循 " 工作簿权限设置 "，若存在冲突则优先推论 " 没有这项权限 "。

  这样的权限体系会更安全，但自定义的灵活性不够。Claude Opus 4.8 在业务理解和逻辑处理上完胜。

总结

  最后看看 Token 用量对比，根据官网 GLM-5.2 的总用量大约是 40M。Claude Opus 4.8 的总用量大约是 759k，GLM-5.2 的总用量大约是 4M。

  就测评结果而言，在工程实现能力上，GLM-5.2 已经能够在比较大型的真实项目中与 Claude Opus 4.8 展开正面竞争；但在复杂业务系统设计、权限模型抽象、规则冲突处理等偏架构和产品层面的能力上，Claude Opus 4.8 仍然有比较明显的优势。

  但 GLM-5.2 也确实展现出了令人意外的大型代码库理解能力和一次性开发成功率。

  不谈比较，就模型本身而言，无论是小游戏开发、网页版 Excel、还是接近企业级场景的权限系统改造，GLM-5.2 大部分时间都没有出现 " 中途崩溃 "、" 上下文失忆 "、" 功能做到一半跑偏 " 等问题，在 UI 设计上可以说非常惊艳。即便面对 LuckySheet 这种接近 5 万个文件规模的大型代码库，它依然能够持续理解项目结构，并完成跨模块修改。

  更重要的是，GLM-5.2 并不是一个闭源商业模型，而是一个开源模型。

  如果你的目标是私有化部署、二次开发、成本控制、数据安全，或者希望在开源体系中获得接近第一梯队的 Agent 能力，那么 GLM-5.2 已经具备了非常高的使用价值。

  当然，GLM-5.2 也暴露出了一个非常明显的问题：耗时。

  在 LuckySheet 权限体系的开发中，GLM 5.2 基本每一个需求都花了将近一个小时来实现，大部分耗时都花在验证上。GLM-5.2 在复杂任务上的一次性成功率远高于过往开源模型，可能是大量验证和反思带来的收益。但从实际使用角度看，这依然是一个不可忽视的问题。

  好在，速度的问题很大概率是算力问题带来的，如果获得更多算力，未来能够在保持现有完成度的前提下，将大型任务的执行速度大幅提高，那么它对闭源顶级 Coding Agent 的竞争力还会进一步提升。