同一份SVG代码,鹈鹕在Safari里骑着自行车,戴船长帽,篮子里还搁了一条鱼。切到Chrome或Firefox,自行车还在原地,鹈鹕却整只消失了。

这是llm-gemini 0.33测试Gemini 3.7 Flash时暴露的一个渲染差异。起因是SVG里一个空的<filter>标签,三家浏览器处理方式完全不同。这次更新本身信息量不小,新增了几个模型,插件也同步适配了LLM 0.32的新功能。但真正值得记一笔的,是这个鹈鹕消失的插曲——它说明AI生成的代码好看,不等于能在所有环境里站得住。

更新了什么

llm-gemini 0.33新增支持三个生成模型和两个嵌入模型,同时适配LLM 0.32。

模型类型备注
gemini-3.7-flash生成模型提供高/中/低三档thinking effort,不再提供minimal档
gemini-3.6-flash生成模型保留minimal档
gemini-3.5-flash-lite生成模型—
gemini-embedding-2嵌入模型—
gemini-embedding-001嵌入模型—

适配LLM 0.32之后,用户能看到模型的推理轨迹,也能调用CodeExecution这类服务端工具。命令行敲一句llm -m gemini-3.7-flash -T CodeExecution '用python算13的阶乘乘以3',模型会自己跑代码给出答案。

这里要说清楚一点:所谓推理轨迹,是模型输出的中间步骤展示,不等于模型内部真实、完整、可审计的思维过程。它多给了一层可看,不是多了一层保证。

鹈鹕去哪了

作者拿"画一只骑自行车的鹈鹕"当固定测试题。高thinking effort下,3.7 Flash画出的图相当完整:绿色弯把自行车、篮子里一条鱼、红白格子围巾、船长帽。这只是这一次测试的结果,不代表thinking effort越高画得必然越好。

问题出在渲染,不在生成。

浏览器显示结果原因
Safari鹈鹕+自行车完整可见对空<filter>元素容忍度高
Chrome鹈鹕消失,只剩自行车遇到空filter,直接跳过整个套用它的图形
Firefox鹈鹕消失,只剩自行车同上

鹈鹕套用了那个空filter,自行车没有,所以自行车留下,鹈鹕不见。这是浏览器渲染引擎的差异,跟Gemini 3.7 Flash的推理能力是两件事。不该把这次插曲读成模型能力退步,也不该读成Chrome、Firefox普遍存在渲染故障——它只在这一种特定写法下才会触发。

这提醒了谁

对使用LLM CLI、Gemini API写代码的开发者,这事该记一笔:AI生成的SVG、图表、UI代码,浏览器兼容性这类老问题一个都没被跳过。生成器不会因为是AI写的,就自动帮你适配好每个渲染引擎。

对前端开发者尤其现实。现在不少人已经习惯让模型直接吐SVG图标或界面代码,在自己常用的浏览器里扫一眼、感觉对了就合入主干。这次的教训很直接:发布前至少切一遍Chrome、Firefox、Safari,比继续追问模型"能不能画得更好"更值。

接下来该盯的,不是Gemini又出了几个新模型,而是这类空标签、边界写法引发的渲染差异,会不会在更多AI生成代码里反复出现。如果这次是个案,影响有限;如果这是Gemini这类模型输出SVG时的通病,那才该被写进上线前的检查清单。

庄子说"吾生也有涯,而知也无涯"。模型的能力边界在扩张,人手动检查的精力却没跟着涨,这中间的缝,才是真正会出事的地方。

生成不难,验证才难;鹈鹕一换浏览器,立马露了底。