测试 Gemini 2.5 Flash 的编程与视频理解能力

我从一个最初由 Gemini 2.5 Pro 制作的 3D 演示开始。我没有把原始代码交给 Flash，而是下载演示视频并上传到 Google AI Studio，要求它用 Three.js 在单个 HTML 文件中重建所见内容。界面显示，这段视频占用了约 10,500 个词元，上下文窗口为 100 万词元。

Flash 思考了 22 秒，生成了代码和解释。结果与原视频并不完全相同，但我可以旋转形状、改变颜色、放大组成它的小方块，还能在立方体、金字塔、圆环、平面和波形之间切换。

我加入了具体的导入映射指令，因为此前 Flash 生成的程序多次无法在本地加载 Three.js。有了这条指令，这些示例在我的环境中可以运行；我之前测试 Gemini 2.5 Pro 时没有遇到同样的问题。Pro 速度更慢、价格更高，但我认为它的能力更强。

接下来我重新使用魔方提示词。在之前的测试中，Gemini 2.5 Pro 第一次尝试就生成了可运行的版本。Flash 渲染出了一个可以调整大小和旋转的魔方，颜色大体正确，不过画面看起来比预期更暗。

Flash 的第一次尝试在我按下打乱按钮时失败：控制台显示打乱完成，却记录了零步。旋转单个面时也出现了不自然的颜色变化。我猜再给几个提示词也许能修好，但这个例子我只测试了首次尝试。

求解按钮也没有明显地解开魔方，还产生了错误。这很重要，因为看起来逼真的可视化不等于能正常工作的模拟。我把它与之前的 Pro 结果对比：据我观察，Pro 第一次就完成了这个任务。

接下来，我要求生成一个交互式 Three.js 血流场景，包含红细胞、白细胞和病毒，并提供病毒数量、复制、白细胞行为、流动和模拟速度的控件。我要求使用单个 HTML 文件，方便运行演示。

生成的代码在本地运行时出现 Three.js 引用错误，我将错误复制给模型；它在 Canvas 中则可以运行。我认为它在 Canvas 中一次通过，但要说明，本地配置需要修正。

这个模拟允许我旋转和放大血流场景、增加病毒数量，并调整复制和白细胞设置。两种要求的病毒类型——隐蔽型和快速复制型——标注为尚未实现，因此结果没有满足提示词的全部要求。

我在 X 上发现一个鸭子分类游戏，将视频上传给 Flash，要求它用单个 Python 文件和程序化动画重建。游戏目标是移动一个白色分类角色，将鸭子按颜色分组。界面显示视频只占用一个词元；我对这个数字持怀疑态度，没有把它当作实际成本。

模型识别出标题和游戏画面、跟随光标的移动、碰撞及边界等元素。我经过几轮来回调整设置，最后得到一个与视频很相似的版本，虽然精灵图没有那么精致。

在生成的游戏中，我可以驱赶彩色鸭子，看着它们从边缘弹回。胜利条件在之前的一个版本中有效，但在展示的版本中失效了。尽管有这个缺陷，我仍觉得根据视频重建游戏的结果令人印象深刻。

制作人 Alex 使用一份详细的 HTML5 Canvas 提示词制作塔防游戏。他先构思一个基本想法，再用 LLM 帮忙编写规格，要求游戏包含多波颜色不同的气球和五种攻击方式各异的防御塔。

演示中放置了减缓敌人速度的冰塔，以及攻击敌人的飞镖塔。第一波结束后，玩家赚到钱，下一波敌人更强。基本机制可以运行，不过画面和复杂程度还有提升空间。

我再次使用一个复杂的贪吃蛇提示词，要求采用 Pygame、加入视觉效果、不同食物以及人机对战。我之前用 Pro 生成的版本视觉效果很抢眼；Flash 也生成了一个可玩的双蛇游戏并加入特效，但我觉得视觉表现稍逊。

Flash 生成的贪吃蛇程序有 677 行代码。根据我的经验，两个 Gemini 2.5 模型都曾生成异常长的输出；这是我与其他模型比较的个人观察，并非受控测试，也不是通用的代码行数限制。我认为 Flash 更快、更便宜，因此选择哪个模型要看具体任务。

Alex 还要求 Flash 用 Python 和 Pygame 制作两名 AI 玩家对战的俄罗斯方块。规格包括 10×20 棋盘、不允许暂存方块或 T-spin，以及在消行时向对方发送垃圾行。这些基于规则的玩家以减少空洞和堆叠高度、同时消行为目标。

Alex 做了许多后续修改，才让 Flash 版本达到画面中展示的效果。两名 AI 玩家放置方块并交换垃圾行，直到其中一方堆到顶部。这个最终结果来自反复迭代，并非一次生成。

随后我用同样的俄罗斯方块提示词在 Pro 上运行一次。结果的外观和行为都很相似，包括 Flash 版本也出现的显示截断问题；在我的演示中，它运行得更慢。两个版本的迭代次数不同，这并非受控基准测试。

另一位创作者分享了高尔顿板示例：小球穿过钉阵落入分箱，分布趋向钟形。我采用了创作者的文字提示词，还下载参考视频，让 Flash 看看预期效果。

第一个结果缺少底部的接球槽。我上传视频，要求模型添加接球槽，随后又反复调整宽度，并修复小球落下后消失的问题。Flash 收到反馈后重新生成代码的速度让我印象深刻。

完成后的模拟提供小球数量和大小、下落间隔、重力、钉子大小和间距、分箱数量、弹跳及摩擦等控件。某些组合会让小球卡住，增加分箱数量也会导致空间不够，因此并非每个控件都如预期运作。

Alex 的下一个例子是绘图应用模拟。虽然讨论之初称其为 iPhone 应用，但提示词要求的是模拟，输出结果是一个 Python 程序。它提供画笔设置、颜色、橡皮擦、矩形、填充以及保存 PNG 的功能。

最后一项测试中，我上传了一部 16 分钟的 Popeye 动画片，并就其中画面的细节提问。界面显示上传内容使用了约 283,000 个词元。我据此推算，100 万词元的上下文窗口可能容纳接近一小时的视频，不过实际容量取决于视频的处理方式。

我问 Popeye 在大约第八分钟与几只狮子搏斗。Flash 回答是两只，我随后核对了视频。它还识别出开头附近一块有两条蛇的标牌上的文字：“Isle of Sinbad — Beware”，以及骷髅和交叉骨图案。

更难的一个问题是，十分钟左右的木桶上写了什么。我核对了视频：该场景的大部分时间里文字都被部分遮挡，答案包括“XXX”和“buckshot”。这些例子表明它在几个选定问题上成功，但不能说明它全面理解了视频。

我的结论是，在这些例子中，Flash 在很多方面接近 Pro，同时响应更快、成本更低，但它并非在每个案例中都有同等能力。许多任务并不需要最昂贵的前沿模型，因此我建议根据实际工作选择。