兄弟，文章写得不错，但有些地方我需要挑挑刺。
先说第一个问题：SWE-Bench 只测 bug 修复。你拿这个分数来论证「32B 能暴打 671B」，是不是有点偷换概念？SWE-Bench 是已知问题+已知代码库的补丁生成，真正的软件工程还包括需求分析、架构设计、代码重构。一个能修 bug 的 agent 不等于一个能写系统的工程师。你说「20分之一的参数，95%的性能」，但这 95% 只是在一个非常窄的维度上的 95%。
第二个问题：测试时缩放（TTS）8 倍。文章里把 57.8%→70.2% 吹得很厉害，但代价是推理时间 ×8。你认真算过账吗？一次 bug 修复从 5 分钟变成 40 分钟，这放在生产环境里就是事故。而且这个 TTS 需要 8 个并行 GPU 实例，一个 3090 跑 4-bit 量化都勉强，你跟我说 8 个并行？这篇文章完全没有讨论量化后 TTS 的可行性。是不是把理想实验室条件和真实部署混为一谈了？
第三个问题：数据来源。文章很骄傲地说「让 agent 自己运行，只保留成功轨迹」，但跑 agent 的是 Claude 和 GPT。也就是说，你开源的 32B 模型，是用闭源 API 生成的数据训练的。这跟开源精神的「开放」是同一个词吗？你训练数据的成本——调用 Claude 跑成千上万个 issue 的轨迹——如果公开明细，可能比很多小公司的年度云预算还高。这算「开源」还是「闭源数据蒸馏的二次分发」？
第四个问题：32B 量化。文章说「单张 3090 就能跑 4-bit 量化」，但全篇没有任何关于量化后性能损失的讨论。4-bit 量化对 coding agent 的影响，尤其是 agent 需要精确编辑文件、执行命令的场景，会不会导致幻觉率上升？原始模型 37.2%，量化后还能剩多少？这个数据你在哪里？
最后也是最根本的问题：从 37.2% 到 70.2% 的进化曲线。仔细看那张表格，每个模型用的训练数据、框架、评估设置都不一样。你怎么确定这是「模型变强了」，而不是「benchmark 被过拟合了」？不同的数据生成策略、不同的 agent 框架、不同的测试协议——把这些混在一起画一条「进化曲线」，是不是把苹果和橘子放在一起统计了？SWE-Bench 的数据污染风险你在文章里自己提到了，但紧接着就用这个可能被污染的 benchmark 来论证进化。这逻辑闭环是不是有点太快了？
说到底，32B 模型确实让人兴奋，但兴奋归兴奋，数字归数字。这篇文章的结论是「模型大小不是一切」，但用了一堆有问题的数字来论证这个结论。我的看法是：数据质量确实重要，但这篇文章的数据质量论证本身，需要被更严格地审视。
#OpenHands #SWE-Bench #AI-coding #质疑 #千寻