三周前，Google发布了Gemini 3。
几小时内，Hacker News上涌入了1700多个点赞、1000多条评论。这种热度，在AI领域已经很少见了——大家多少有些”发布疲劳”。
但让我最感兴趣的不是发布本身，而是一条高赞评论：
“I asked Gemini 3 to solve a simple, yet not well documented problem in Home Assistant this evening. All it would take is 3-5 lines of YAML. The model failed miserably. I think we’re all still safe.”
翻译过来就是：我让Gemini 3解决一个简单的Home Assistant配置问题，几行YAML就能搞定，结果它完全搞砸了。我觉得我们的饭碗暂时还是安全的。
这条评论戳中了一个核心矛盾：Gemini 3在数学推理上刷新了所有记录，但在”简单”的现实任务上却依然翻车。这到底说明了什么？
作为一个AI工程布道者，我想认真聊聊这个问题。不是为了吹捧或贬低，而是帮你建立一个更准确的判断框架。
先说数据。这次发布确实有几个数字让人很难忽视。
MathArena Apex——一个专门测试极限数学推理的基准——Gemini 3 Pro拿到了23.4%的得分。听起来不高？对比一下：Gemini 2.5 Pro是0.5%，Claude Sonnet 4.5是1.6%，GPT 5.1是1.0%。这不是进步，这是断层式的碾压。
有个HN用户做了个有意思的测试：他把Project Euler最新发布的问题（11月16日的970号）喂给Gemini 3，这个问题大概率不在训练数据里。结果呢？Gemini思考了5分10秒，输出了一段Python代码，答案正确。而人类排行榜上最快的三个人分别用了14分钟、20分钟和1小时14分钟。
另一个数据点是SimpleQA——测试模型事实准确性的基准。Gemini 3 Pro达到了72.1%，而GPT 5.1是34.9%。超过两倍的差距，这在”减少幻觉”这件事上是非常显著的。
LMArena的Elo分数达到了1501，历史新高。
这些数字放在一起，很难不让人觉得Google这次确实搞出了点什么不一样的东西。
但问题来了。
HN上另一个用户分享了他用Gemini 3写浏览器脚本的经历。任务很简单：从某个网站抓取价格信息，计算折扣百分比。他甚至预先告诉了模型需要匹配哪些HTML元素、解析哪些内容——相当于把脚手架都搭好了。
结果？模型输出了”看起来非常convincing但完全跑不通的代码”。他让它迭代了很多次，甚至给出正确方向的提示，依然不行。
这位用户的困惑很有代表性：
“It gives me an extremely weird feeling when other people are cheering that it is solving problems at superhuman speeds… It seems almost impossible that LLMs can both be so bad and so good at the same time, so what gives?”
LLM怎么可能同时这么厉害又这么差？到底发生了什么？
我认为这里有几件事值得分开来看。
benchmark和现实任务的差异
比大多数人想象的大得多
数学竞赛题有一个特点：答案可以验证。给一个数学问题，你可以用穷举、符号推理、或者直接验证最终答案来确认对错。这意味着模型可以通过强化学习反复尝试，直到找到正确路径。
而Home Assistant的YAML配置？MPV播放器的参数设置？这些东西的”正确”高度依赖上下文，没有统一的验证器，文档可能不完整或者过时。更关键的是：这类任务在训练数据中的表示远不如Python代码或数学推理那么丰富。
一个高赞评论提到了解决方案：他把Home Assistant的源代码下载下来，放在项目目录里，然后在提示词里明确要求模型”必须参考源代码”。这样做之后，99%的问题都解决了。
这说明什么？模型的能力边界很大程度上取决于它能访问什么上下文，而不是它”知道”多少。
“step change”和”incremental improvement”
的区分可能真的成立了
那位数学数据的差异太大了。从0.5%到23.4%，不是通过堆数据或堆算力能解释的。
有分析认为，Gemini 3可能在架构上引入了某种”可验证搜索”机制——不只是概率性地生成下一个token，而是能够检测自己的错误、回溯、尝试其他路径。这跟传统LLM”一次性生成”的模式有本质区别。
如果这是真的，那它解释了几件事：为什么数学这么强（因为数学答案可以验证），为什么事实准确性提高了（因为可以检查和纠正），但为什么在某些现实任务上依然翻车（因为这些任务缺乏清晰的验证信号）。
Antigravity的设计哲学值得关注
Google和Gemini 3一起发布了Antigravity——一个”agent-first”的编程工具。跟Cursor或Windsurf不同，它不是把AI塞进传统IDE，而是从头设计了一套以AI Agent为中心的工作流。
Ethan Mollick在测试后写道：
“I don’t communicate with these agents in code, I communicate with them in English and they use code to do the work.”
他描述的工作流程是这样的：给Agent布置任务，它去执行，遇到需要确认的地方会ping你，你可以批准或修改它的计划，然后它继续。整个过程更像是管理一个队友，而不是在和聊天机器人对话。
这里面最有意思的一点是：Agent在做事的时候会主动征求你的许可。这跟传统的”你输入prompt、模型输出结果”的模式完全不同。它暗示着一种新的人机协作范式——你不再是”使用”AI，而是”指挥”AI。
当然，HN上也有人指出Antigravity存在prompt injection的安全风险。还有人做了个开源的本地替代品叫EchoCopi，不依赖Google云也不锁定模型。生态已经开始形成了。
所以这些对AI工程师意味着什么？
我整理了几个可以立刻行动的点。
- 如果你在做推理密集型应用——数学辅导、代码审查、数据分析——Gemini 3值得认真测试。不是因为它完美，而是因为在这些场景下它可能真的比竞品强一大截。
- 如果你在做实际产品，记住上下文管理比模型选择更重要。那个Home Assistant的例子说得很清楚：同一个模型，给它正确的参考文档，表现可以从”完全不行”变成”几乎完美”。把精力花在优化你的RAG管道、设计更好的工具调用，可能比追新模型更有价值。
- 如果你在设计AI产品的交互，Antigravity的”主动征求许可”模式值得研究。用户对AI的信任问题，很大程度上来自于”不知道AI在做什么”。让AI的决策过程可见、可控、可打断，可能是建立信任的关键。
最后，保持怀疑但保持关注。模型能力在benchmark上的提升不会自动转化为你的应用场景的提升。但如果一个模型在基础能力上有了质变——比如真正学会了”检测错误并回溯”——那它在很多下游任务上的改进可能只是时间问题。
三年前ChatGPT发布的时候，我在给学生讲课时说过一句话：这玩意儿改变世界的速度会比我们预期的快得多。
三年后的今天，我依然相信这一点。但我也越来越清楚地看到：变化不是均匀发生的。某些能力会突然跃迁，某些能力会顽固地停留在”还差那么一点”的状态。作为从业者，我们的工作不是追着每次发布狂欢或焦虑，而是准确判断哪些变化是真的，以及这些变化对我们正在做的事意味着什么。
Gemini 3给我的感觉是：数学和推理能力确实在进入一个新阶段，但”通用智能”还有很长的路要走。那个写不出3行YAML的模型，和那个5分钟解出数学竞赛题的模型，是同一个模型。
这大概就是我们这个时代最有意思的地方。
如果这篇对你有帮助，欢迎转发给同样关注AI工程的朋友。有想法也欢迎评论区聊
参考资料：
- Gemini 3官方发布：
- Hacker News讨论：
- Ethan Mollick评测：
- Google Antigravity：
来源 https://mp.weixin.qq.com/s/0prEEIJWV1nMppwHkMd7vA
作者 LLM明训