最近谷歌正式对外发布 Gemini 3 后，其基准测试成绩断档级领先，大家也是各种前端 vibe coding 玩得不亦乐乎。
但知危比较在意的两个点是，一方面谷歌宣布 Gemini 3 是世界上最好的多模态模型，也强调 Gemini 3 对用户意图的理解，“ 无需过多提示就能获得所需信息 ”，这就让 Gemini 3 的 ToC 属性变得很强。
另一方面，Gemini 3 在编程能力的基准测试上并没有实现对其它模型的断档级领先（ 甚至这两天内 OpenAI 就拿出了 GPT-5.1 Codex Max 来狙击 Gemini 3 ），谷歌也没有强调 Gemini 3 在幻觉、指令遵循等方面的优势，但这些维度其实才是企业级场景最关心的，否则你在用 AI 编程的时候，不管模型多么博学多才，总会没那么放心，就怕改 Bug、修漏洞比手写代码还辛苦，所以 Gemini 3 的 ToB 属性是否够强还有待进一步考察。
为了深度感受 Gemini 3 的 ToC 和 ToB 属性，在本次测评中，知危着重体验Gemini 3 的多模态理解和编程能力，至于科研能力，本次评测没有涉及。
具体而言，在多模态理解能力方面，知危主要是让 Gemini 3 理解视频，包括电视剧、体育比赛、软件操作等场景的视频，看 Gemini 3 能理解到什么程度，幻觉多不多，是否够专业。此外，看到 Gemini 3 在 ARC-AGI-2 上面翻倍的亮眼成绩，知危也忍不住在相同场景中给 Gemini 3 再上上难度。
编程能力方面，知危基于过去的测评经验，会直接拿一些需求多且杂的场景让 Gemini 3 一次做出来，如果不成功或者错误太大，不会给太多挽尊的机会。这些场景包括一次写完 Excel、看 UI 截图写 3D 引擎、看视频写 3D 引擎等。知危也会在不同的平台上都测试类似场景，包括网页版 Gemini、Cursor 以及谷歌自己新推出的编程 IDE Antigravity。
其实，目前很少有 AI 模型能直接分析视频的，国内只有通义千问提供这个功能。
我们拿《 甄嬛传 》中最具张力的一场戏，也就是 “ 滴血验亲 ” 来测试一下Gemini 3（ 在网页版 Gemini 中调用 Gemini 3 Pro，也就是思考模式 ）看不看得懂。因为网页版上传视频有 100M 的限制，所以将视频分成了好几段输入。
在第一段视频中，皇后先向皇帝提出了 “ 滴血验亲 ” 的狠招，随后呈现甄嬛等人的反应。
Gemini 3 的表现令人惊讶，几乎无任何错误，对各个人物的动作、心思、表情，以及更宏观的派系解析和剧情背景，都做出了非常准确的解释。
当进一步提示 Gemini 3 做更细致的逐帧逐秒分析时，它也是不负众望。
台词和潜台词都很精准，但最能展示多模态能力的，是对微表情的捕捉。比如皇后引导皇帝实施滴血验亲时，Gemini 3 描述皇后的表情动作为 “ 身体微微前倾，语重心长，眉头微蹙，眼神看似诚恳，实则紧盯着皇帝的反应 ”，你们可以看看对不对。
再看看以下几个精彩瞬间，动作和表情也是描述的很到位，虽然 “ 嘴唇微张 ” 等一些细节是 Gemini 3 自己加戏和夸大，“ 眼神游移 ” 应该要更后面才出现，这里更多是 “ 纯粹的恐惧 ”。
只是看到分析的最后一句话，知危才意识到，Gemini 3 分明知道后面的剧情进展，毕竟 Gemini 3 的训练数据已包含了《 甄嬛传 》的各种视频、文本资料，能分析到这个程度或许并不令人意外。
而且，台词语音其实是很好的对齐模态，台词能提供精准的语义提示，并和视频时间线做对齐，假设已经有大量文本语料给《 甄嬛传 》做了逐帧分析，那 Gemini 3 可能很大程度上不是基于视频来理解的。
所以，若是分析无声音的同样一段视频，效果又如何呢？结果，Gemini 3 还是能认出这是《 甄嬛传 》，以及大部分的人物，就是出现了非常大的错误，把甄嬛认成了华妃。
最后，因为今天 Nano Banana Pro 刚好上线，知危也在对话的末尾让Gemini画一幅漫画来呈现剧情，结果还是很惊艳的（ 可能 Nano Banana Pro 太火，谷歌自己服务器撑不住了，没实际生成图像，最后是用 Lovart 的 Nano Banana Pro 画出来的 ）。
这里还有一个非常离谱的地方，Nano Banana Pro 生成的这张漫画图，右下角更不可思议的是 “ 腾讯动漫 ” 的水印。。。
也不知道谷歌拿腾讯动漫练 AI 有没有合法买数据授权，假如没有的话欢迎腾讯联系本编辑部搜集证据，索赔之后记得分我们点
为进一步避免模型对训练数据的依赖，基于 Gemini 3 的知识截止日期是 2025 年 1 月，知危决定用 Gemini 3 来分析 2024-2025 赛季 NBA 总决赛雷霆 vs 步行者第一场的最后两分钟（ 比赛时间 ）的视频片段（ 这一场比赛实际是在 2025 年 6 月份举行的，晚于 Gemini 3 的知识截止日期 ）。
相比电视剧，理解体育赛事有不一样的复杂度，虽然不要关注微表情，但运动员动作大，且和篮球、其他运动员有物理交互，更有快速的空间移动和频繁的视觉遮挡，相关训练语料也更少，难度会更大。
在第一次的简单分析中，Gemini 3 的回答表明了它认为这一场比赛不存在，它甚至认为这是 NBA 2K 游戏的模拟画面。当然，它准确地认出了这是 NBA 雷霆 vs 步行者的总决赛，以及一开始的赛况。
在接下来的关键镜头分析中，Gemini 3 能准确描述步行者球员的 “ 横撤步 ” 运球动作，要知道当时的实况解说员并没有说出这个 “ 横撤步 ” 术语，只是 Gemini 3 把球员身份认错了，应该是 2 号的内姆哈德而不是 23 号的內史密斯。
之后对第二回合、第三回合攻防的分析，Gemini 3 的描述都是准确无误的，除了内史密斯的 “ 犹豫 ” 其实指的是在 “ 上篮 ” 和 “ 投篮 ” 之间的犹豫，而不是上篮之前要不要减速的犹豫。
Gemini 3 虽然还是没改正对身份的错误认识，但对动作的分析非常专业，它把刚才的 “ 横撤步 ” 改为更精准的 “ 向右后方撤步 ”，并且球员在做撤步前，先做了向左侧突破然后变向的连续假动作，这些描述并不是 Gemini 3 对实况解说的鹦鹉学舌，而是自主做出来的分析（ 这里对左右方位的定义可能和我们直观理解上相反，但还是可以解释通的 ）。
在第四回合雷霆的 2 号球员亚历山大单打强攻拿回两分，并把比分重新拉大到 105:110 后，到第五回合，对雷霆的 9 号球员卡鲁索的防守策略分析中，Gemini 3 出现了严重幻觉。
卡鲁索是在内姆哈德运球时被雷霆球员拍掉球后立马上前抢球，并没再次出现 Gemini 3 所言的 “ 双脚站定，双手护胸 ” 的动作，这时裁判哨响，但在该片段内，并没有给出裁判结果，Gemini 3 则立马判定是内姆哈德进攻犯规。
为了再次检验 Gemini 3 对实况解说语音的依赖程度，知危也上传了无声音版本的同一片段给 Gemini 3 分析。
这一次，Gemini 3 的分析出现了很明显的错误或模糊不清的情况，比如（ 00:16-00:55 ）这一段，Gemini 3 描述 “ 视频出现剪辑跳跃 ”，但实际上在这段期间，雷霆和步行者先后进行了一次进攻未得分，最后雷霆的亚历山大凭借单打强攻得到两分。
并且（ 00:56-01:08 ）时间段内，被撞倒在地的球员应该是 2 号球员内姆哈德，而不是 0 号球员哈利伯顿。
但总体来看，Gemini 3 达到的准确率还是令人感到意外的，大部分情况下都能分析出是哪位球员执行了什么动作，以及对比分或比赛的贡献。
知危接下来还将后续比赛片段（ 一直到步行者的 0 号球员哈利伯顿在最后时刻三分绝杀雷霆 ）在同一个对话中传递给了 Gemini 3 继续分析，Gemini 3 结合实况解说语音还是能保持基本准确的水平，对步行者的 43 号球员西亚卡姆的高光时刻的分析很到位，并盛赞西亚卡姆给出了 MVP 级别的表现。
总体而言，Gemini 3 对体育视频的分析掌握程度还是不如对电视剧的分析。虽然能够基于实况解说的提示和视觉线索，给出更精细的描述和适当的宏观分析，但幻觉率过于高，超出了实用限制。并且，在该场景也是非常依赖解说语音的，而不是原生地对视觉线索有足够精细的理解。
最后也是用 Nano Banana Pro 画一页漫画来呈现内姆哈德后撤步三分的高光时刻。这一次画面精细度和剧情还原度也是很高，但内姆哈德相对别的球员以及在球场的空间站位呈现的不是很准确，后撤步则像是在冲浪，可能在空间智能或透视作图方面还不是很擅长。
推特上有一个帖子比较火，Pietro Schirano 展示了如何用一句线D 乐高引擎原型。
知危将这一个视频传递给 Gemini 3，令其分析这个引擎的 UI 组成和功能。
Gemini 3 的分析结果很精细，甚至能精准到视频第 19 秒展现了重新上色功能，整体基本完全准确。
这个编码案例其实很多网友并不买账，他们自己用相同提示词写的 3D 乐高引擎完全不是那么回事。
所以，知危也顺便将分析结果提炼成提示词，进入下一个测评，也就是编程能力测评。
采用经典且直观的 三段式 (左-中-右) 布局，配合深色模式 (Dark Mode) 界面，旨在减少视觉疲劳并突出彩色的积木模型。
Paint (油漆桶): 用于给已放置的积木重新上色（视频 00:19 处展示了此功能）。
缩略图列表: 视觉化展示积木的形状（如 1x1, 1x2, 2x4 砖块），点击即可选中作为当前笔刷。
智能吸附与预览 (Smart Snapping & Ghost Preview): 当鼠标悬停在网格或已有积木上时，会显示半透明的“幽灵砖”预览（红色半透明），告知用户积木即将落下的位置。积木会自动吸附到网格点或其他积木的表面。
视角控制 (View Cube/Buttons): 位于面板左上角的小图标，允许用户一键切换视图：
颜色调色板 (Colors): 提供预设的乐高标准色（红、橙、黄、绿、蓝、黑、白等）。用户都能够在放置前选择颜色，或配合油漆桶工具使用。
Rotation: 包含一个按钮（通常是旋转90度），用于调整积木方向。
极简主义: 界面没有复杂的菜单层级，所有常用功能都平铺在界面上，所见即所得。
清晰的逻辑: “左侧选材 - 中间搭建 - 右侧调整”的操作流非常符合直觉。
视觉辅助: 预览（Ghosting）和网格吸附功能极大地降低了在2D屏幕上操作3D物体的难度，确保积木不会放歪。
将以上提示词用于 Gemini 3 生成 3D 乐高引擎，如果做得好，那便是多模态理解和编程双剑合璧。
最终实现的 3D 乐高引擎能够成功运行，虽然没有完全按照分析细节来实现，或者说没有完全复刻原版，而是简化了很多。
知危套用之前 GPT-5 在 Cursor 一次运行成功的提示词，再次输入到网页版 Gemini 3 中，试图复刻。
但最终写出来的 Excel 有一堆 Bug，比如字体格式有时能用有时不能用，文本对齐、复制剪切功能也有各种意想不到的问题，简直是灾难现场，不如上次对 GPT-5 的测试 ( 传送门 )。
结果，写出来的网页版 Excel 完全没有办法交互，鼠标点击没有反应，也不能输入，甚至不能显示单元格，应该说比网页版表现还差吧。
发现一个错误，即单元格编辑器和选中高亮显示会在滚动时与网格分离，因为它们位于视口容器而非内容容器中。已将它们移至正确的容器。
但它发现的错误和单元格相关，这并不是最关键的，甚至实际界面中都看不到有任何单元格。
接下来，知危极大降低了要求，只让 Antigravity 写了一个《 2048 》游戏，看看产品本身是否有问题。
果然，在 Cursor 上调用 Gemini 3 Pro，就能用相同提示词顺利完成 Excel 原型的开发，而且也是一次成功。
还是紧接前面提到的 3D 乐高引擎案例，我们在 Cursor 上再试一遍，因为 Cursor 无法输入视频，所以只用了 UI 截图。
第一次尝试，让 Gemini 3 Pro 参考 3D 乐高引擎的UI界面截图来开发。
前面因为分析 3D 乐高引擎视频被带进了编程能力测评的坑，但多模态理解测评的难度还没真的上来，我们继续这个维度的测评。
为了提高多模态分析的难度，自然还是要上 ARC-AGI-2 这个测试集，毕竟 Gemini 3 在这个基准测试集中的提升幅度是最大的。
ARC-AGI-2 的官方发布使用 json 表示二维网格，例如下图是该项目的 GitHub 中包含的一个评测集中的数据部分展示：
通过顺手 vibe 一个小型程序能将这个矩阵转换成图像（ 每个数字代表在图像中的坐标和颜色 ），如下图所示：
这个结果并不意味着 Gemini 3 在类似 ARC-AGI-2 场景中的实际表现，毕竟实验设置不一样，只是也表明 Gemini 3 在静态图像的空间认知和逻辑分析上还是比较初级的，过程有理有据，但低级错误令人头疼。
通过这个测评，可以认为，Gemini 3 在各种多模态理解和编程场景中，都给出了局部亮眼、整体不稳定的表现，比如：
所以 Gemini 3 给人的感觉就是巨好玩，但不够令人放心，毕竟跨越不同模态确实有趣，但聚焦单个模态才是专业，换句话说就是 ToC 属性爆棚，ToB 属性还不够。
他有点像一个优秀大学毕业的高学历实习生，知识素养足够，但真让他干活他也是错漏百出。
总之，我们暂时认为 Gemini 3 玩一玩是很不错的，但是还是最好还是不要把它用到生产环境，万一出什么样的问题也不好解决。（ 昨天吃到个不知真假的瓜，有人用 Gemini 3 来 Coding 的时候被删了 800G 重要文件 ）
或许，谷歌这次能这么强得益于其生态中拥有的丰富模态的海量数据，随之带来的缺点是谷歌还来不及将模型的足够可靠。
