最近谷歌正式发布 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 还是能认出这是《 甄嬛传 》，以及大部分的人物，就是出现了非常大的错误，把甄嬛认成了华妃。

也因为这个错误导致对剧情的推测也产生了幻觉。

从这个结果来看，或许目前 AI 的多模态理解对文字的依赖还是比较大。

最后，因为今天 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 展示了如何用一句话让 Gemini 3 写一个功能完善的 3D 乐高引擎原型。

知危将这个视频传递给 Gemini 3，令其分析这个引擎的 UI 组成和功能。

Gemini 3 的分析结果很精细，甚至能精准到视频第 19 秒展现了重新上色功能，整体基本完全准确。

这个编码案例其实很多网友并不买账，他们自己用相同提示词写的 3D 乐高引擎完全不是那么回事。

所以，知危也顺便将分析结果提炼成提示词，进入下一个测评，也就是编程能力测评。

编程能力测评

提示词（ 基于视频分析原文 ）：

基于Three.js、html技术，构建一款名为 BRICK BUILDER 的3D乐高积木构建软件。

采用经典且直观的 三段式 (左-中-右) 布局，配合深色模式 (Dark Mode) 界面，旨在减少视觉疲劳并突出彩色的积木模型。

以下是对该软件UI构成和核心功能的详细分析：

1，顶部全局导航栏 (Top Toolbar)

这是软件的控制中心，主要负责工具切换和项目管理。

基础工具 (左侧):

Select (选择箭头): 用于选中场景中的积木。

Add (加号): 默认模式，用于放置新积木。

Paint (油漆桶): 用于给已放置的积木重新上色（视频 00:19 处展示了此功能）。

Delete(橡皮擦)：用于删除已有积木块。

历史操作: 包含 撤销 (Undo) 和 重做 (Redo) 箭头。

项目管理 (右侧):

Clear: 清空画布。

New Project: 新建项目。

Export PNG: 将当前模型截图导出为图片。

Save Project: 保存当前进度。

2，左侧资源库面板 (Left Sidebar - Library)

这里是用户的“零件箱”，用于寻找和选择积木部件。

搜索栏 (Search): 允许用户通过名称快速查找特定积木。

分类标签页 (Tabs): 将积木部件分为 Basic (基础砖), Plates (板件), Slopes (斜坡砖), Projects 等类别，方便筛选。

缩略图列表: 视觉化展示积木的形状（如 1x1, 1x2, 2x4 砖块），点击即可选中作为当前笔刷。

3，中央3D工作区 (Center Viewport)

这是核心交互区域，用户在此进行搭建。

3D 网格底板 (Grid baseplate): 提供空间参考，帮助用户对齐积木。

智能吸附与预览 (Smart Snapping & Ghost Preview): 当鼠标悬停在网格或已有积木上时，会显示半透明的“幽灵砖”预览（红色半透明），告知用户积木即将落下的位置。积木会自动吸附到网格点或其他积木的表面。

交互反馈: 放置积木时有轻微的动画效果。

4，右侧属性与设置面板 (Right Sidebar)

该区域用于控制外观、视角和选中物体的属性。

视角控制 (View Cube/Buttons): 位于面板左上角的小图标，允许用户一键切换视图：

3D: 自由透视视角。

TOP / FRONT / SIDE: 快速切换到顶视图、正视图或侧视图（视频 00:14-00:17 展示了此功能）。

颜色调色板 (Colors): 提供预设的乐高标准色（红、橙、黄、绿、蓝、黑、白等）。用户可以在放置前选择颜色，或配合油漆桶工具使用。

属性 (Properties):

Position (X, Y, Z): 显示当前选中积木的坐标。

Rotation: 包含一个按钮（通常是旋转90度），用于调整积木方向。

场景设置 (Scene):

Grid: 开关网格显示。

Shadows: 开关阴影渲染，用于提升真实感或节省性能。

5，底部状态栏 (Footer)

提供统计信息和操作提示。

统计数据: 左下角显示 Bricks (积木数量) 和 File Size (文件大小)。

上下文提示: 屏幕底部中间会根据当前工具显示提示文本，例如 Place Brick (Click to rotate) 或 Paint Brick (Click to select)，这是非常好的UX设计，降低了学习成本。

6，总结与UX亮点

极简主义: 界面没有复杂的菜单层级，所有常用功能都平铺在界面上，所见即所得。

清晰的逻辑: “左侧选材 -> 中间搭建 -> 右侧调整”的操作流非常符合直觉。

视觉辅助: 预览（Ghosting）和网格吸附功能极大地降低了在2D屏幕上操作3D物体的难度，确保积木不会放歪。

⬆️ 向上滑动文字

将以上提示词用于 Gemini 3 生成 3D 乐高引擎，如果做得好，那便是多模态理解和编程双剑合璧。

最终实现的 3D 乐高引擎能够成功运行，虽然没有完全按照分析细节来实现，或者说没有完全复刻原版，而是简化了很多。

但至少基础的砖块、添加、删除、上色、视图、旋转、导出等是都有的，足够完成一个最粗糙的作品。

上面案例所采用的 Three.js 毕竟是 Javascript 的库，如果能用纯 Javascript 写出足够复杂的前端场景，那才更厉害，为此自然还是得测试写一个的 Excel 原型才能让人信服。

知危套用之前 GPT-5 在 Cursor 一次运行成功的提示词，再次输入到网页版 Gemini 3 中，试图复刻。

提示词如下：

请帮我开发一个功能完整的网页版Excel应用，技术栈使用HTML、CSS、Javascript，需要实现以下核心功能模块：

-第一阶段：基础功能（核心优先级）

网格渲染系统：

实现1000×1000单元格的虚拟渲染；

优化滚动性能，确保流畅体验；

横坐标（A、B、C等）和纵坐标（1、2、3等）需要与单元格精确对齐；

滚动时坐标轴与内容区域保持同步，无偏移；

单元格编辑功能：

双击单元格进入编辑状态，编辑框与原单元格完全重合；

Enter键保存内容并向下移动到下一个单元格；

Tab键保存内容并向右移动到下一个单元格；

支持空值和默认值的正确处理；

编辑栏应可编辑，实时显示和修改当前选中单元格的值；

富文本格式工具栏：

实现独立的格式按钮，每个按钮状态基于当前选中单元格的格式属性独立判断；

字体大小调整；

加粗、斜体、下划线、删除线（按钮状态互相独立）；

文本对齐：左对齐、居中、右对齐；

背景颜色设置；

一键清除格式功能；

UI界面要求：

顶部工具栏包含所有格式设置按钮；

名称框显示当前选中单元格坐标（如A1、B2）；

编辑栏显示并可编辑当前单元格内容；

整体界面美观，具有现代化设计风格；

-第二阶段：高级功能（扩展功能）

行列操作：

点击行号后，按=键在下方插入新行，按-键删除当前行；

点击列号后，按=键在右侧插入新列，按-键删除当前列；

删除后自动重排坐标编号，保持连续性；

添加最小保护机制，避免删除最后一行或列；

复制粘贴操作：

实现Command/Ctrl+C（复制）、Command/Ctrl+X（剪切）、Command/Ctrl+V（粘贴）快捷键；

支持单元格内容和格式的复制粘贴；

支持行列的整体复制粘贴操作；

撤销恢复系统：

实现Command/Ctrl+Z（撤销）和Command/Ctrl+Y（恢复）功能；

维护操作历史栈，限制最大100层以控制内存；

页面刷新时清空操作栈；

选择功能：

支持单元格多选（拖拽选择矩形区域）；

支持整行、整列选择；

选中状态的可视化反馈；

-第三阶段：完善功能（产品化）

数据导入导出：

支持导出为CSV格式文件；

支持导出为JSON格式文件；

确保导出的文件能在Microsoft Excel中正确打开；

UI美化优化：

添加滚动动画效果；

优化阴影和渐变效果；

提升整体视觉体验和交互流畅度；

响应式设计，适配不同屏幕尺寸；

⬆️ 向上滑动文字

但最终写出来的 Excel 有一堆 Bug，比如字体格式有时能用有时不能用，文本对齐、复制剪切功能也有各种意想不到的问题，简直是灾难现场，不如上次对 GPT-5 的测试 ( 传送门 )。

知危怀疑是网页版 Gemini 的 Agent 能力不足，就切换到谷歌新推出的编程 IDE Antigravity，用相同的提示词来测试。

结果，写出来的网页版 Excel 完全无法交互，鼠标点击没有反应，也不能输入，甚至不能显示单元格，应该说比网页版表现还差吧。

为了再给它一次机会，我提示它自行检查并修复。

第一阶段：基本功能

发现一个错误，即单元格编辑器和选中高亮显示会在滚动时与网格分离，因为它们位于视口容器而非内容容器中。已将它们移至正确的容器。

但它发现的错误和单元格相关，这并不是最关键的，甚至实际界面中都看不到有任何单元格。

接下来，知危极大降低了要求，只让 Antigravity 写了一个《 2048 》游戏，看看产品本身是否有问题。

测试发现游戏能运行，视觉效果也很好。

但 Agent 运行有一些问题，会无限期的停留在测试阶段。

到此，只能认为 Antigravity 作为编程 IDE 产品还不够成熟完善。为了最大程度发挥 Gemini 3 的编程水平，知危决定在 Cursor 上测试。

果然，在 Cursor 上调用 Gemini 3 Pro，就能用相同提示词顺利完成 Excel 原型的开发，而且也是一次成功。

目前为止，知危拿这个案例测试过很多大模型，只有 GPT-5 和Gemini 3 Pro 是能一次成功的。在 UI 审美上，Gemini 3 Pro 比 GPT-5 更好。

但接下来的测试再次让知危大跌眼镜。

还是紧接前面提到的 3D 乐高引擎案例，我们在 Cursor 上再试一遍，因为 Cursor 无法输入视频，所以只用了 UI 截图。

第一次尝试，让 Gemini 3 Pro 参考 3D 乐高引擎的UI界面截图来开发。

结果还是依样画葫芦写了个不能交互的网页。

知危给了它最后一次机会，将前面在网页版 Gemini 3 分析推特视频后得到的提示词，再一次提供给 Cursor 中的 Gemini 3 Pro，结果这个网页仍然是不能交互的。

到此，基于这些实测结果判断，Gemini 3 的编程能力还是能达到顶尖水平，也有足够的代码审美，但发挥是不够稳定的，不管是幻觉率还是对指令遵循的细致全面程度，还没有达到业内最高水平。

前面因为分析 3D 乐高引擎视频被带进了编程能力测评的坑，但多模态理解测评的难度还没真的上来，我们继续这个维度的测评。

为了提高多模态分析的难度，自然还是要上 ARC-AGI-2 这个测试集，毕竟 Gemini 3 在这个基准测试集中的提升幅度是最大的。

但知危不是拿公开的评估集来再测一次，测试设置需要针对多模态这个属性做一些调整。

ARC-AGI-2 的官方发布使用 json 表示二维网格，例如下图是该项目的 GitHub 中包含的一个评测集中的数据部分展示：

样本：e376de54.json，https://github.com/arcprize/ARC-AGI-2/blob/main/data/evaluation

通过顺手 vibe 一个小型程序可以将这个矩阵转换成图像（ 每个数字代表在图像中的坐标和颜色 ），如下图所示：

知危不想按照官方设置使用 json 为输入，而是要以图像作为输入传递给 Gemini 3，并且为防止大模型吸收基准测试数据作为训练数据取巧，会对这个评估集样本再做一些微调（ 修改 json 数据再转换为图像即可 ）。比如下图中，左图是原评估集样本，右图是微调后的样本，黑边与数据无关可忽略。

按这个思路，知危制作出了两个新的谜题。这是第一题：

下图是准确答案，应该按照排第二的长度值重组所有斜线。

Gemini 3 的分析框架是对的，但得出的结论却是：取最大长度统一（ 无法理解，真的就差一点点啊 ）。

在下一道题中，知危对原评估集样本做了如下改动（ 样本：247ef758.json ）：

这是第二道题的完整呈现：

下图是准确答案，方框的四条边上如果有某个颜色构成十字相对方位，该颜色对应的方框外几何素材就可以放入方框内十字交叉点的位置。这里因为微调了颜色，第四组的蓝色几何素材也要放入方框内。

Gemini 3 有理解到规则是对左侧素材的筛选，但错误地把筛选规则理解为基于素材的形状，映射位置规则有理解到要基于方框边框像素点，但没有精确到十字交叉点。

所以，它最终得出来的答案也是错误的。

这才测了两道，Gemini 3 就都错了。要知道这还是 ARC-AGI-2 中比较简单的题。

样本：4c7dc4dd.json

这个结果并不代表 Gemini 3 在类似 ARC-AGI-2 场景中的实际表现，毕竟实验设置不同，只是也表明 Gemini 3 在静态图像的空间认知和逻辑分析上还是比较初级的，过程有理有据，但低级错误令人头疼。

好了，到了这里，本期内容的全部测评就结束了。

通过这个测评，可以认为，Gemini 3 在各种多模态理解和编程场景中，都给出了局部亮眼、整体不稳定的表现，比如：

能多维度分析电视剧剧情和人物，却把主角给认错；

能自主分析运动员连续动作，却编造不存在的球员动作；

能逐帧分析视频，却高度依赖语音；

能写全UI解析，却不能完整复刻；

能写好Excel，却写不好3D乐高引擎；

图片理解框架很有逻辑，却败在尺寸比较的一小步；

所以 Gemini 3 给人的感觉就是巨好玩，但不够令人放心，毕竟跨越不同模态确实有趣，但聚焦单个模态才是专业，换句话说就是 ToC 属性爆棚，ToB 属性还不够。

他有点像一个优秀大学毕业的高学历实习生，知识素养足够，但真让他干活他也是错漏百出。

总之，我们暂时认为 Gemini 3 玩一玩是很不错的，但是还是尽量不要把它用到生产环境，万一出什么问题也不好解决。（ 昨天吃到个不知真假的瓜，有人用 Gemini 3 来 Coding 的时候被删了 800G 重要文件 ）

或许，谷歌这次能这么强得益于其生态中拥有的丰富模态的海量数据，随之带来的缺点是谷歌还来不及将模型调教的足够可靠。

当然，毕竟潜力太大，我们还是期待谷歌和 Gemini 家族的后续发力。

撰文：流大古

编辑：大饼