NovaXCode 这条一句话吐槽 "gemini 4 pro cooked r…

NovaXCode 这条一句话吐槽 "gemini 4 pro cooked really hard 💀"——但仔细想想，"cook" 这个词在不同任务上意思不一样，把"哪些任务容易 cook 翻车"拆开看才有价值。

Gemini 4 Pro 这代 cook 的典型场景：

• 复杂多步推理——尤其是需要"先做规划、再执行、再验证"的链条，到第 5 步左右模型会开始脑补步骤，跟原意偏离；
• 代码长上下文重构——一次塞一个完整仓库让它改一个方法，结果经常是改了不该改的地方，diff 一打开全是无关改动；
• 多模态混合理解——图片 + 长文本同时输入时，模型对图片细节的引用经常错位（"图片左下角那个红框里的按钮"→ 实际指错）；
• 工具调用 schema 严格场景——Agent 框架对返回字段要求严格时，Gemini 偶尔会"自由发挥"字段名，要补 schema 校验兜底；
• 中文长 prompt——同上，对英文 prompt 的稳定性明显好于中文。

为什么会这样（推测）：

• Gemini 系列的训练数据偏长上下文，模型在"长但松"的任务上很强，但在"短但严格"的任务上容易过度发挥；
• 上一代 Gemini 在 benchmark 上以多模态 / 长文为主，这一代延续了这个倾向，代码 / 工具调用不是它的甜蜜点；
• inference-time scaling 的策略跟 Claude / GPT 不一样，长链任务更容易踩到 staleness。

实操层面的几条经验：

• 长 prompt 任务首选 Gemini，短 prompt + 严格 schema 的用 Claude；
• Agent 框架对接时强制开启 JSON Schema 校验，必要时把 Gemini 换成"输出层约束"模式；
• 多模态场景尽量让模型"少看图多看文字"，减少图片细节错位的概率；
• 中文任务如果 prompt 超过 2000 字，先让模型自己总结一遍提纲再正式跑，能显著降低"自由发挥"概率。

一句话总结：Gemini 4 Pro 不是不好用，是"用错地方就容易 cook"——选对任务才能发挥它的长板。