本文来自微信公众号： 知危 ，编辑：大饼，作者：知危编辑部
6月中旬上线并开源的GLM-5.2，在当前顶级模型日趋封闭的背景下显得尤为特别。
而更特别的是：口碑非常好，好到给人一种不真实感。
那么，GLM-5.2究竟是不是真正意义上的国产开源模型突破？测一测便知道。
我们会先从基础测试开始，拿几个小游戏和小型软件试试，然后要再上一个高度，在接近企业生产级的环境比如拥有将近5万文件数的开源版Excel也就是LuckySheet中，对比Claude Opus 4.8和GLM 5.2的表现。
基础能力测试
首先，快速过一遍基础测试。
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的界面示例如下，权限管理功能在右上角的“保护工作表内容”中。
点击“保护工作表内容”按钮后，如下图所示，如果勾选最上方的“保护工作表及锁定的单元格内容”，则当前这个工作表内所有单元格都不能再编辑（但工作表本身还可以被删除）。
如果在上图最下方的“允许用户编辑区域”中选定部分单元格（比如界面示例中的标黄部分），则这些单元格可以编辑，并适用上图中间的“允许此工作表的用户进行”中的规则。比如去掉勾选“设置单元格格式”，则在黄色区域内的单元格不能再设置字体、加粗等格式，但可以做其它勾选的编辑权限，比如删除行、排序等。
那么，这个权限系统的槽点和不足有哪些呢？主要有四点。
首先，要保护的工作表，怎么还能被直接删除呢？
其次，不能对文档中所有工作表统一设置权限，需要一个一个操作，很影响效率。
第三，权限定义范围仅限于工作表和单元格，没有扩展到整个工作簿（一个Excel文档涉及的工作空间），比如对“导出”、“打印”、“截图”等功能的约束。
最后，也是对生产环境而言最重要的，缺乏一个“用户-角色-权限”体系。比如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区域，点击后打开“工作簿权限设置面板”。
功能要求如下：
提供对当前工作簿所有工作表（Sheets）的统一权限配置能力，可批量设置每个Sheet的protection状态与authority配置。
支持一键应用权限模板（如：全只读/部分可编辑/完全开放）。
权限配置需覆盖：sheet是否可删除（继承protectSheetDelete）；单元格编辑权限；插入/删除行列权限；格式修改权限。
Claude Opus 4.8第一次开发失败，左下角的🔒图标按钮中的“工作簿级统一权限管理功能”，在编辑一次并点击“确定”生效过后，就无法再次编辑，点击"确定"按钮没有反应，也不能真正阻止工作表被删除。
经过两次提醒它debug，Claude Opus 4.8发现了问题：工作簿权限面板采用了只初始化一次的模式，后续打开时只是查看状态。并成功修复。
如下图所示，左下角点击🔒图标，就会启动“工作簿权限设置”配置界面，这里可以集中对所有工作表统一进行权限管理。当为“sheet12”工作表勾选“保护”、“禁止删除”后，“sheet12”就不能被编辑和删除了。
回到“保护工作表内容”这边，可以看到“保护工作表及锁定的单元格内容”、“禁止删除此工作表”已经对应地被勾选上，只要取消勾选，就能正常编辑和删除。
另外，在“工作簿权限设置”中，取消勾选“sheet12”的“修改格式”，并勾选“保护”，效果相当于为图中标黄区域禁止了“修改格式”。
不过，Claude Opus 4.8其实对最后一句提示词的理解没有抓到我的隐含意思，把“允许此工作表的用户进行”规则的管理加了一层抽象和简化，属于吃力不讨好了。
并且，“允许用户编辑区域”功能没有被加入进来，这实际上是不完整的，时间原因只能先忽略这一点。
最后，对所有工作表，可以一键统一设置权限，切换三种模式。
为了不让GLM 5.2也做吃力不讨好的权限抽象的活，我在提示词最后一句中做了调整，提醒它把权限集合直接搬过去就行。
提示词：
在现有Luckysheet权限系统基础上扩展“工作簿级统一权限管理功能”。
新增一个入口按钮，固定放置在左下角UI区域，点击后打开“工作簿权限设置面板”。
功能要求如下：
提供对当前工作簿所有工作表（Sheets）的统一权限配置能力，可批量设置每个Sheet的protection状态与authority配置。
支持一键应用权限模板（如：全只读/部分可编辑/完全开放）。
权限配置需覆盖：sheet是否可删除（继承protectSheetDelete）；单元格编辑权限；插入/删除行列权限；格式修改权限等“保护工作表内容”中的“允许此工作表的用户进行：”中的所有权限。
GLM 5.2很顺利地解决了这个问题，没有出现bug，并且界面简洁而直观。
它把权限模版、“允许此工作表的用户进行”中的权限细节，以及工作表列表，完全分开，从而可以做自由组合。
使用上很直观，但也有一些小缺陷。Claude Opus 4.8需要重复列出所有权限，但可以一次性逐个配置完，GLM 5.2的界面则更适合批量配置。
在第二步的较量中，Claude Opus 4.8在代码层输的有点难看，业务理解上我帮了GLM 5.2一把，所以不算数，UI层上两者各有千秋。
第三步是增加整个工作簿的权限定义，比如对“导出”、“打印”、“截图”等功能的限定。
提示词：
在现有Luckysheet权限体系基础上，扩展“工作簿级（Workbook Level）权限”。
当前权限定义主要集中于工作表（Sheet）和单元格区域（Range），缺少对整个工作簿功能的统一控制。请设计并实现一套工作簿级权限模型，用于控制用户对整个文件的操作能力。
新增权限项包括：
是否允许导出；
是否允许打印；
是否允许复制任意数据；
是否允许使用截图功能；
把这些新功能汇总到“工作簿级统一权限管理功能”的配置界面中。
Claude Opus 4.8很顺利实现了这个功能，毕竟这是相对简单的需求，不需要像之前那样处理两个配置界面之间的映射。
GLM 5.2也很顺利实现了这一功能，虽然在配置后会提示“应用到所选工作表”，但其实都会应用到整个工作簿，无论切换到哪个工作表。
在第三步的较量中，双方打成平手。
在最关键的第四步，我们要分两小步实现“用户-角色-权限”体系，第一小步实现“角色-权限”体系，第二小步实现“用户-角色”和“用户-权限自定义”体系，结合起来才是完整的。
这个体系在真实环境中需要结合用户数据库来实现，且要多人云端操作才能验证，为把验证过程集中在本地和单人，需要有一个角色或用户切换机制。
“角色-权限”体系下的权限定义如下表所示：
前面都是准备工作，到这里才是本次测试中最有难度的部分。
“角色-权限”体系提示词：
你需要在“不依赖后端用户系统”的前提下，为Luckysheet设计并实现一个Google Sheets级别的权限系统。
本任务用于本地测试环境，不需要真实账号系统，也不需要处理协同编辑冲突。
========================
一、背景约束
========================
使用Luckysheet作为基础表格引擎
不允许依赖后端用户系统（无Firebase/Auth/DB）
用户在打开工作簿时“手动选择角色”
角色仅用于本地模拟
不需要处理协同编辑冲突（重点说明：可以忽略operational transform/CRDT）
========================
二、目标（核心）
========================
请设计并实现一个“权限引擎（Permission Engine）”，实现类似Google Sheets的权限体系：
支持三种角色：
Owner；
Editor；
Viewer；
权限架构：
Owner：
查看数据；
评论数据；
分享数据（复制、导出、打印、截图等）；
编辑数据；
编辑工作簿、工作表、单元格权限细节；
Editor：
查看数据；
评论数据；
分享数据（复制、导出、打印、截图等）；
编辑数据；
Viewer：
查看数据；
评论数据；
其中：
Owner拥有全部权限。
Editor可以查看、评论，并在Owner设置的权限规则下进行分享和编辑数据。
Viewer只能查看和评论数据，永远不能分享、编辑、设置权限。
鉴于Claude Opus 4.8第二步的表现不太令人满意，所以我把effort参数从high提高一级，改成了xhigh。
Claude Opus 4.8成功实现了三种角色的分配，验证可行，并且可以通过右上角的按钮随时切换角色，这个需求没有明确提出，但它考虑到了，这对结果验证很方便。
所有者在工作表和单元格级别的操作效果和未设置角色系统时基本相同，而工作簿级权限对所有者是失效的。
这符合常理，毕竟工作簿权限是资产性质，工作表和单元格权限是内容性质，后者和编辑者更匹配。
编辑者不能打开和配置“工作簿权限设置”和“保护工作表”内容，需要遵循所有者设置的工作簿、工作表、单元格权限来操作。
在下图中，当管理者设置了不能截图后，编辑者的截图操作就被禁止了。
查看者除了阅读和评论以外什么都不能做，在下图可以看到工具栏部分除了“评论”都变灰色了，并且如果想对工作表进行复制、删除、重命名操作，也会无效化。
不过，Claude Opus 4.8并没有禁止查看者平移、隐藏工作表，算是个小瑕疵。
考虑到GLM-5.2运行时间之长，因此没有调整effort参数，在默认的high effort设置下，GLM-5.2最后没有完成这个任务。
比如打开工作簿后，没有弹出角色选择页面，而是直接进入了工作簿，点击左下角的全局权限设置会被禁止，但其它编辑功能还能正常使用，可能是被默认分配了编辑者角色，但界面中没有可以切换角色的按钮，所以没法再继续验证。
为公平起见（但不保证严格公平），我们把effort参数从high提升一档到xhigh，再试一次后，终于成功了，这一次GLM-5.2也在右上角设置了角色切换功能。
所有者可以自由编辑权限，编辑者在权限约束下工作，查看者除了评论以外什么都不能做，这些关键点都验证通过了。
值得注意的是，和Claude Opus 4.8相同，GLM-5.2也认为所有者不受工作簿权限的限制。
第一小步的较量不好判断胜负，还是只看第二小步的表现吧。
在第二小步，我们要实现“用户-角色”和“用户-权限自定义”体系，这样更符合协同办公软件的真实设置，直观理解是所有者可以从基于用户ID分配权限。
其中，“用户-权限自定义”体系是属于每个用户的个性化权限设置，和角色默认值有潜在逻辑冲突，会是一个考察重点。
“用户-角色”和“用户-权限自定义”体系提示词：
将权限系统的控制粒度从角色级升级为用户ID级，并为Owner增加协作者管理权限。
本任务用于本地测试环境，不依赖任何后端用户系统，也不需要真实登录。
========================
一、核心前提（非常重要）
========================
不使用后端
所有用户在进入工作簿时，根据列表从中选择一个userId（唯一标识）。一共有10个userId，其中有1个Owner，2个Editor，7个Viewer
权限完全在前端模拟
不需要协同编辑冲突处理（忽略OT/CRDT）
========================
二、系统目标（升级版）
========================
Owner协作者管理（关键升级点）：
Owner可以：
基于userId设置、修改协作者角色，可修改为Editor或者Viewer
如果是Editor，可对指定userId分配权限细节，支持权限覆盖role默认值
触发按钮放置在UI右下角。
Claude Opus 4.8成功地新增了这个功能。
现在，作为所有者Alice，我们可以和之前一样，通过“工作簿权限设置”配置适用全局的权限，比如把截图权限去掉。
也可以在右下角的“协作者管理”中，配置每个用户的自定义权限，可以看到，刚打开界面时，编辑者Bob和Carol的截图权限都被取消勾选了。如果把一个观看者Dave设置成编辑者，其拥有的权限也是默认把截图取消勾选。所以同步逻辑没有问题。
实测Bob的截图操作确实被禁止了。
重头戏来了，在“协作者管理”这个界面，你可以任意给编辑者设置和“工作簿权限设置”不一样的、冲突的权限，比如给Bob再加上截图权限，去掉编辑权限。（细心的朋友会发现这两个权限项的文字被加粗了）
经验证Bob变得可以截图了。
也变得不能编辑了，双击标黄单元格没有反应。
并且，这时候，无论Alice再怎么修改或刷新“工作簿权限设置”，都不会影响在“协作者管理”中编辑过的权限细节，比如截图。
那原来方便的同步逻辑就彻底失效了？
并不是，只需要在“协作者管理”界面中，把Bob的权限“重置为默认”，就能恢复同步逻辑。这时也能看到，“截图”字样的加粗格式消失了。
可以说，Claude Opus 4.8把潜在的逻辑冲突梳理得很明白。
但不足之处在于，“协作者管理”中对编辑权限的设置过于简单粗暴，没有匹配“工作簿权限设置”的粒度。
GLM-5.2交付的成果则是有些奇怪。
首先，角色和用户切换界面做的很漂亮。
但用户自定义权限设置中，编辑者的权限细节没有和“工作簿权限设置”相匹配，这样最重要的同步逻辑无法实现，处理自定义权限中的冲突也不需要了，“工作簿权限设置”会一直存在潜在的矛盾。
其实，GLM 5.2是采用了另一种更省事的方式，所有编辑者优先遵循“工作簿权限设置”中的配置，还有若存在冲突，则优先推论“没有这项权限”。
比如在“工作簿权限设置”中开放所有分享权限，在“协作者管理”中关闭编辑者Bob的分享权限，则Bob不能再进行分享。
如果在“工作簿权限设置”中保护某个工作表，在“协作者管理”中打开Bob的编辑权限，Bob也不能编辑。
这样的权限体系会更安全，但编辑者的自定义权限只会比全局设置更少，不会更多，自定义的灵活性不够，也不符合提示词要求“支持权限覆盖role默认值”。
并且，对于自定义权限，GLM 5.2是接近照搬了提示词中的字段，这里面“编辑结构”的意义难以理解，经过测试发现其实和“编辑数据”是重复的，评论权限的独立设置并无太大必要性。
所以，在第二小步的较量中，Claude Opus 4.8在业务理解和逻辑处理上完胜。
好了，测评结束！
最后看看Token用量对比，根据官网，GLM-5.2的总用量大约是40M。
根据Claude Code的统计，这里忽略之前测试用的Claude Fable 5，Claude Opus 4.8的总用量大约是759k，GLM-5.2的总用量大约是4M，这和官网十倍的差距不知道是什么原因。
以上结果不代表一个编程小白也可以用Claude Opus 4.8或GLM-5.2上手企业生产环境的权限系统开发，这个测试虽然上下文环境复杂得多，但也只是基于功能实现层面。企业生产环境中的权限系统本质上是业务规则的表达，而不只是技术问题，包含大量隐含规则，更不用说还要考虑攻防博弈、系统可扩展性、责任机制这些因素了。
最后总结一下。
就测评结果而言，在工程实现能力上，GLM-5.2已经能够在比较大型的真实项目中与Claude Opus 4.8展开正面竞争；但在复杂业务系统设计、权限模型抽象、规则冲突处理等偏架构和产品层面的能力上，Claude Opus 4.8仍然有比较明显的优势。
但GLM-5.2也确实展现出了令人意外的大型代码库理解能力和一次性开发成功率。
不谈比较，就模型本身而言，无论是小游戏开发、网页版Excel、还是接近企业级场景的权限系统改造，GLM-5.2大部分时间都没有出现“中途崩溃”、“上下文失忆”、“功能做到一半跑偏”等问题，在UI设计上可以说非常惊艳。即便面对LuckySheet这种接近5万个文件规模的大型代码库，它依然能够持续理解项目结构，并完成跨模块修改。
当然，GLM-5.2也暴露出了一个非常明显的问题：耗时。
在LuckySheet权限体系的开发中，GLM 5.2基本每一个需求都花了将近一个小时来实现，大部分耗时都花在验证上。GLM-5.2在复杂任务上的一次性成功率远高于过往开源模型，可能是大量验证和反思带来的收益。但从实际使用角度看，这依然是一个不可忽视的问题。
好在，速度的问题很大概率是算力问题带来的，如果获得更多算力，未来能够在保持现有完成度的前提下，将大型任务的执行速度大幅提高，那么它对闭源顶级Coding Agent的竞争力还会进一步提升。