来源与核验
材料来自 OpenCLI 的 Twitter/X thread 读取结果。该命令返回了原帖、媒体 URL、互动数、发布时间，以及评论区中若干回复和作者澄清。
opencli twitter thread "https://x.com/gmi_cloud/status/2054775793977532689" --limit 80 -f json --trace retain-on-failure
作者：gmi_cloud；发布时间：2026-05-14 04:08:19 UTC；OpenCLI 返回时互动数约为 139 likes、9 retweets。原帖带有一段 X 视频媒体。
边界说明：OpenCLI 返回的 thread 没有包含完整 prompt、每个模型的逐项输出文本、采样参数、重试次数、人工评分规则，也没有显示是否所有模型使用同一工具链。因此本文把它当作“现象观察和测试启发”，而不是严格的科学 benchmark。
原帖主张
GMI Cloud 用一个足球踢球动画任务对比多个模型，结论是这批开源模型没有把动作做对。
被测试的模型
原帖点名：DeepSeek V4、Gemma 4、MiniMax M2.7、Kimi K2.6、Xiaomi MIMO v2.5 Pro、Qwen 3.6 Max、Hy3 Preview、GLM 5.1。
原帖想证明什么
表层说法是“开源模型空间推理差”。更精确地说，它指出：这些模型在把“踢足球”这样的人类动作转成可执行动画时，容易破坏脚、球、身体、接触时机和运动方向之间的因果关系。
评论区有人把这理解为“闭源模型更强”。作者对一个直接追问回复了 “actually yes”，但后来也澄清：这不是否定所有开源模型，只是这个任务的结果不好。
上方视频为 OpenCLI 返回的原帖媒体 URL。若 X 的媒体链接过期或阻断，仍可通过原帖链接查看。
这个任务到底测了什么
它不是传统的文本问答，也不是纯静态图像生成。它更像一个从语言到动画的综合压力测试。
公开可见信息里，输入任务可概括为“生成一个足球踢球动画”。评论中有人提到 HTML/CSS/JS，但 thread 没有给出完整 prompt，因此不能假设所有细节。
输出不是一句答案，而是一个动态动画结果。模型要把自然语言转为视觉对象、动作序列和运动效果。
直观评分对象是动画是否“像一次踢球”：脚是否接触球、球是否因接触而运动、方向是否合理、身体动作是否连贯。
这不是只测“会不会写前端代码”。模型可以写出可运行动画，却仍然没有正确表达动作因果。代码可运行和动作正确是两件事。
评论区争议
这个 thread 的评论区其实帮我们把原帖主张拆开了：产品体验、模型能力、开源闭源对比、评测严谨性，不应该混在一起说。
“你是在说闭源模型更好吗？”
有用户直接追问是否意味着非开源模型做得更好。GMI Cloud 简短回复 “actually yes”。这使原帖从“开源模型失败”进一步带上了“闭源领先”的对比意味。
“这个标题是不是太 clickbait？”
另一位用户认为，不同模型擅长不同任务，不能因为一个任务就推出“开源模型不行”。GMI Cloud 回应说，这不是他们的意图；他们也做过其他游戏/任务对比，开源模型在一些任务里表现很好，但这次测试确实没有做好。
“一次生成失败不等于不能用”
有人指出，更差的模型可能只是需要更多调 prompt 和人工迭代。对一些场景，开源模型的成本、可控性、部署自由度仍然值得。
“有些失败结果也有风格价值”
有人觉得 Gemma 的结果像足球动漫特效，不一定完全不可用；也有人说 MIMO 的 motion 很好笑。这说明用户在真实场景中会混合评估“动作正确性”和“视觉/娱乐价值”。
“闭源模型补充样例”
评论中有人贴了 closed-source model 和 GPT 5.5 的视频结果，也有人问 Gemini 3.1 Pro 会怎样。但这些回复没有形成同一 protocol 下的系统评测，因此只能作为补充观察。
为什么足球踢球动画会难
这个任务看起来简单，是因为人类有非常强的动作常识。对模型来说，它把几个不同能力绑在了一起。
1. 空间关系
模型要知道人物、脚、球、地面之间的位置关系。脚必须朝球运动，接触点必须在合理位置，球不能从身体后方凭空飞出。
2. 时序因果
踢球不是单帧图像，而是一个动作链：摆腿、接触、传递动量、球飞出、身体恢复。很多生成结果会有运动感，但没有前后因果。
3. 简化物理
球的速度方向应该由脚的运动方向决定。即使不做真实物理仿真，动画也需要满足人眼可接受的接触和反应关系。
4. 代码表达
如果任务要求生成 HTML/CSS/JS，模型还要把空间和时序计划落到坐标、关键帧、transform、transition 或 canvas 逻辑中。
5. 局部片段拼接
LLM 很擅长拼接“football”“kick”“animation”“rotate”“translate”等代码片段，但片段组合不自动保证动作语义正确。
6. 缺少外部执行反馈
如果模型只一次性输出代码，不运行、不看视频、不自我修正，它很难发现脚没碰到球、方向错、动作穿模等视觉错误。
证据强度
这个 thread 作为产品观察很有信息量，作为严格模型结论则证据不足。关键在于区分“看到的问题”和“可推出的结论”。
| 命题 | thread 支持情况 | 更严谨的说法 |
|---|---|---|
| 这批模型在足球踢球动画任务上表现不好 | 较强 原帖提供了视频对比，评论也主要围绕结果展开。 | 在 GMI Cloud 展示的这个任务样例中，这些模型没有稳定产生符合动作常识的踢球动画。 |
| 开源模型普遍空间推理差 | 中等偏弱 样本和任务范围太窄，且缺少完整 protocol。 | 该任务提示开源模型在动态空间/动作生成上存在明显短板，但不能推出所有开源模型整体都差。 |
| 闭源模型一定更好 | 较弱 评论中有补充样例，但没有同条件对照。 | 闭源前沿模型可能在这类任务上更稳，但需要同 prompt、同采样、同重试预算、同评分标准的对比。 |
| 一次失败说明模型不可用 | 较弱 评论区已经指出 one-shot 失败和可迭代使用是不同问题。 | 一次生成失败说明默认体验不稳，不等于经过提示工程、工具调用和执行反馈后仍不可用。 |
如果要做成真正评测
这个 thread 最有价值的后续方向，是把直观失败案例改造成可复现的动态空间推理 benchmark。
应该公开什么
需要公开完整 prompt、模型版本、采样参数、生成次数、是否允许自我修复、是否允许运行浏览器/视频预览、失败样例和成功样例。
如果是代码生成任务，还要固定渲染环境，例如浏览器版本、画布尺寸、依赖库、执行时长和录屏方式。
应该怎么打分
不要只给“好/坏”。可以拆成：脚球接触正确性、球运动方向、动作时序、身体姿态连贯性、物体不穿模、动画完成度、视觉美观度。
这些维度应该分开，因为一个结果可能物理错但视觉好，也可能物理对但画面粗糙。
一个更稳的 protocol：
1. 给定 20-50 个动作任务：踢球、投篮、开门、倒水、挥拍、跳绳等。
2. 每个模型同样 prompt，同样采样预算，同样重试次数。
3. 记录 one-shot、best-of-N、带执行反馈自修复 三种模式。
4. 人工或视觉模型按细粒度 rubric 打分。
5. 分开报告：代码可运行率、动作正确率、物理一致性、视觉质量。Insight
这个 thread 的深层意义，不是开源和闭源的口水战，而是“会生成文本/代码”和“能构造可执行世界模型”之间的距离。
我的判断：足球踢球动画是一个小任务，但它切中了模型能力的一个硬边界。很多 LLM 已经能把“动画”这个词映射到 CSS keyframes、canvas 或 transform 代码；但它们未必在内部形成了“脚接触球后球才被加速”这种可操作的因果结构。结果就是：表面上动起来了，语义上却没有踢球。
对用户意味着什么
如果你的目标是快速得到一个“差不多能看”的动画，模型失败后仍可以靠多轮提示和人工修补使用。但如果目标是低人工成本地产生物理/动作一致的交互内容，one-shot 生成目前还不可靠。
对模型研发意味着什么
未来改进不只是堆更多文本数据。更可能需要执行反馈、视频/物理世界模型、动作分解、中间状态表示、渲染后自评，以及能把视觉错误反向转化为代码修复的循环。
最终结论
把原帖强表达压缩成更可辩护的版本。
更严谨的一句话
GMI Cloud 的 thread 显示：在一个足球踢球动画样例中，多款开源模型没有稳定生成符合动作常识的结果；这不是严格证明“开源模型空间推理整体很差”，但它很清楚地提示，当前模型在语言到动态物理场景的转换上仍然缺少可靠的动作因果建模。