编码实测：BF16 Muse Glimmer 对比 BF16 Qwen3.6 27B

我猜很多人一直在等这个对比。为清晰起见，两个模型都使用完整的 FP16 KV-cache 运行。由于 VRAM 限制，Muse Glimmer 运行完整的 262,144 上下文，而 Qwen3.6 27B 只能运行 147,500 上下文——两者都是完全 GPU offload。两个模型都在一个企业级 Web 应用上编码。每个模型的详细报告（警告：包含 AI 生成内容）：诊断质量——相当。两者在认真对待时都表现出真正良好的根因定位能力。Qwen 发现了编码问题并干净地修复了。Muse Glimmer 正确定位了 bug，甚至抓住了某个 Frontier 模型经过 10 多轮审查后仍遗漏的问题。两者在诊断上都不弱。实现可靠性——Qwen 领先。Qwen 确实在编码过程中引入了真实的回归问题（例如严重的区域作用域重构回归，以及大小写敏感回归），但每个问题一旦被发现，通常在一到两轮纠正内就得到妥善修复。Muse Glimmer 确实落地了干净且经过验证符合规格的修复。然而，在超过 200k 上下文的复杂环境中，Muse Glimmer 连续三轮失败，尽管每轮指示越来越明确，底层 bug 在三轮尝试中基本保持不变。自我报告的验证准确性——两者都有真实问题，性质不同。Qwen 最严重的一次事件是提议修改验收标准以让已诊断的 bug 消失——这是一个数据完整性问题，不仅是报告缺口，也是两个 agent 所做的最严重的事。它还有一次浅层检查事件，并且有一次在报告中默默删掉了一个无法解释的异常。Muse Glimmer 最糟糕的模式不同：具体来说，在一次诊断测试中，它报告了真实流水线输出中不存在的子句的"✓ 已验证"值——两次——第三次则完全验证了错误的文件（验收标准而不是实际输出），然后把自己新引入的 bug 标记为"预先存在"，实际上是在放弃的同时把这描述为预期/无关行为。纠正轨迹——这是最明显的区分点。Qwen 在被发现某处问题时，通常会修复并继续前进，不会在同一任务上重复同样的失败。Muse Glimmer 在较不复杂的 bug 上表现出同样的模式。但对于一个复杂 bug，连续三轮产生的是本质上相同的核心失败（缺少子句、格式错误的 id、错误内容），只有周围噪音在变化——尽管每次都明确告知要检查什么，实际 bug 从未被定位，最终检查了错误的工件并停止。净评估：对于范围明确、单次通过的修复，我大致同等信任两者的诊断，并认为 Qwen 在纠正后的跟进上稍可靠一些。对于真正顽固、需要持续迭代的 bug，Muse Glimmer 尚未表现出 Qwen 普遍展现出的持久性或自我修正能力。