代码安全审计历来是 AI 难以真正落地的场景之一——误报率高、漏报率高、工程师信任度低。Semgrep 的这次测评打破了一个隐性假设：最强的安全检测模型不一定来自参数量最大或知名度最高的厂商。 测试对象是 IDOR（不安全的直接对象引用）漏洞，这是 OWASP Top 10 中的高频漏洞类型，通常出现在权限校验逻辑缺失的 API 端点。GLM 5.2 采用 750B 参数 MoE 架构，实际激活 40B 参数，在这项任务上取得 F1=39%，Claude Code 的对应值为 32%。F1 同时反映精确率和召回率，在安全检测任务中比单纯准确率更有意义——漏报一个真实漏洞比误报一个假漏洞代价更高。 价格差距是另一个关键变量。GLM 5.2 的定价据称（自报）为同级模型的 1/6。如果同时满足"更高检测率"和"更低成本"，替换动机就非常明确。Coinbase 案例恰好印证了这一趋势——从西方模型转向中国模型的成本节约是可量化的。 然而，评测结果需要谨慎解读。首先，IDOR 检测是一个相对局限的子任务，不能代表整体安全审计能力；其次，F1=39% 在绝对意义上仍然不高，意味着超过 60% 的 IDOR 实例未被捕获；第三，Semgrep 自己的规则引擎已经覆盖大量常见漏洞模式，AI 模型在这里的角色更多是补充而非替代。 对于实际部署安全扫描系统的团队，这次测评的实践建议是：在目标代码库类型和漏洞类型上自行跑评测，而不是直接套用 Semgrep 的数据。不同语言、不同业务逻辑的 IDOR 表现可能差异显著。 HN 554 分的热度也说明，"哪个模型最适合安全任务"正在成为开发者社区的实用议题，而不只是学术讨论。