Gemini3.0，中文能力真的拉跨了

在 Claude 4.5 面前，Gemini 3.0像个初出茅庐的新兵蛋子

11月19日凌晨，Gemini 的 AI studio 悄悄上线了  3.0  preview 版本。

从之前透露的信息看，这次的升级点侧重在编程能力，尤其是前端代码。

我不是前端开发者，代码写得再好跟我关系不大，所以我只测了：写作能力。

Claude 4.5 Sonnet 在这方面已经让我非常满意了，基本上一次过，不用反复改稿，我在之前的文章已经测过：Claude4.5：第一个让我不用改稿的AI写手

那么 Gemini 3.0 呢？

结果让我挺失望的，在我测试的几个模型里，它的写作能力垫底。

我用的是跟 Claude 4.5 Sonnet 同一个case：基于搜集到的多篇「上下文工程」的技术文章，写成小白能看懂的科普文。

Gemini 3.0 的输出只有1000多字。

（篇幅有限，我就先放开头）

不是说短不好，而是这1000字的信息密度不够，开头用了「你有没有过这样的经历」的套路，中间列了几个观点，但每个观点都点到为止，没有展开，没有让人眼前一亮的类比，也没有足够的例子支撑。

而且，那个老毛病还在，它依然喜欢在中文后面加括号注释英文单词，比如「提示词工程(Prompt Engineering)」「上下文工程(Context Engineering)」...无语😅

这个习惯在Gemini 2.5 Pro时代就有了，我以为3.0会改，结果还是一样，这让整篇文章读起来很割裂，像是在看一份没翻译完的文档。

对比一下其他模型：

Claude 4.5 Sonnet 写了3000字，开头直接用场景描述抓人：「花了大力气搭建的RAG系统，检索到了一堆相关文档，但AI助手给出的答案还是驴唇不对马嘴」，然后用咨询顾问的类比把抽象概念讲透，结尾还能升华到「思维革命」。

GPT-5.1 也不错，标题就很有力：「真正决定 Agent 成败的，不是模型本身，而是你喂进去的世界」，虽然文风没有Claude那么自然，但信息量够，结构清晰，还算ok，改改也能用。

旧版本的 Gemini 2.5 Pro 虽然也有括号病，但起码信息量是够的，该展开的地方会展开，该举例的地方有例子。

而 Gemini 3.0，在写作这件事上，真的是御三家里垫底（起码目前我用起来是这样的，测了别的 case，也一般）

写作这件事，目前还是Claude 4.5 Sonnet最好使。

不是说它完美，而是它真的理解什么时候该铺垫，什么时候该直给；它会用类比和例子，而不是堆砌术语；它甚至能在结尾给你一个「原来如此」的认知冲击。

这种能力，目前其他模型还真做不到。

对于Gemini 3.0，我只能说：这还是preview版本，希望哈基米越做越好。

下面是3.0写的完整版本，你可以自己感受一下：

别再痴迷“提示词魔法”了：Karpathy 力推的“上下文工程”，才是 AI 的下一个进化形态

你有没有过这样的经历：明明用的是最先进的大模型，写了一大段精心雕琢的提示词（Prompt），但 AI 给出的回答依然像个只会背书的书呆子？或者，两个同样接入 GPT-4 的应用，一个聪明得像那个即使你没说完话懂你意思的同事，另一个却像个甚至记不住你名字的客服机器人？

这背后的差距，往往不在于模型本身，也不在于你会不会写“咒语”般的提示词，而在于一个正在席卷 AI 圈的新概念——**上下文工程（Context Engineering）**。

今年 6 月，AI 大神 Andrej Karpathy 在推特上带火了这个词。这不仅仅是一个新术语的诞生，更标志着我们对待 AI 的方式正在发生一场范式转移：从手动“调教”模型，转向构建智能的“信息生态系统”。

这篇深度解读将为你剥离炒作，提炼出“上下文工程”最反直觉、也最具冲击力的 5 个认知升级。

1. 提示词是给用户用的，上下文才是给开发者造的

很多人第一反应会问：“这不就是给‘提示词工程’换了个更高级的名字吗？”

大错特错。 语言塑造思维，这次改名至关重要。

“提示词工程”（Prompt Engineering）通常是面向用户的微观操作：你试图通过更好的措辞、扮演角色（Role-playing）或提供示例（Few-shot），来诱导模型输出更好的结果。它更像是在和人聊天时的“话术”。

而“上下文工程”是面向开发者的宏观系统设计。它是一门关于**“在该让模型知道什么的时候，精准地喂给它什么”**的科学。它不再是你写给 AI 的一段话，而是一个动态的、自动化的系统，负责在后台清洗数据、检索知识、剪裁噪音，最终将一个完美的信息包“注入”到模型的短期记忆中。

“上下文工程是一门精心设计填充上下文窗口的艺术与科学。”

—— Andrej Karpathy

如果你还在纠结用什么形容词来修饰 Prompt，你是在做文科题；如果你开始思考如何动态调度信息流，你才是在做上下文工程。

2. “越多越好”是最大的陷阱：警惕“上下文中毒”

随着各大模型纷纷卷出 100 万甚至 1000 万 token 的超长上下文窗口，一种懒惰的思维开始蔓延：把所有文档、聊天记录、代码库一股脑丢给 AI 不就好了吗？

事实证明，这不仅无效，甚至有害。 上下文工程揭示了一个反直觉的真相：更多的上下文 ≠ 更好的回答。

LangChain 的开发者提出了一个极具洞察力的概念——**上下文病理学**。当过多的信息被塞入窗口时，会出现以下症状：

• • 上下文分心（Distraction）： 就像考前复习给了你一整箱书而不是重点笔记，模型会在海量无关信息中迷失，抓不住核心指令。
• • 上下文中毒（Poisoning）： 错误的信息（如幻觉产生的链接或过时的文档）一旦混入，会被模型当成“真理”反复引用，导致后续推理全盘皆输。
• • 语境冲突： 两份文档说法不一，AI 被迫“站队”或胡乱拼凑。

真正的工程能力，体现在你会如何**做减法**，而非做加法。

3. 像管理数据库一样管理语境：增、删、改、查

如果说 Prompt 是写作，那么上下文工程更像是写 SQL 代码。LangChain 将落地策略极其精准地归纳为四个动作，这完全颠覆了我们对“对话”的理解：

• • 写入（Write）： 强迫 AI 在回答前先在“草稿本”上思考，或将关键决策写入“长期记忆”。哪怕对话结束，核心认知不丢。
• • 筛选（Select）： RAG（检索增强生成）的进阶版。不只是检索，还要重排序（Re-ranking），确保每一条喂给模型的信息都是“高相关、高质量”的。
• • 压缩（Compress）： 将冗长的历史对话摘要成几句精炼的状态同步。这不仅是为了省钱，更是为了提高信息密度。
• • 隔离（Isolate）： 这是最精彩的一点。与其让一个 AI 知道所有事，不如通过“泳道”隔离，让不同的 Agent 只看到它完成任务所需的那一部分信息，从根本上杜绝信息的相互干扰。

4. Agent 的“双重人格”：既是大脑，也是搬运工

在上下文工程的视角下，AI Agent（智能体）的角色发生了根本性的变化。

过去，我们认为 Agent 是单纯的**消费者**——我们喂给它上下文，它消费信息并产出答案。

现在，Google DeepMind 的研究指出，Agent 必须同时是上下文的**创造者**。

想象一个复杂的任务：帮你规划东京旅行。

Agent 不能只等着你投喂信息。它必须自主判断：“我现在缺少航班价格信息”，然后调用工具去搜索，获取数据，清洗格式，并将这些新信息**回填**到自己的上下文中。

这种“感知缺失 -> 主动获取 -> 构建上下文 -> 再次推理”的闭环，才是智能体能够独立完成复杂任务的秘诀。上下文不是静态的背景板，它是 AI 自己搭建的脚手架。

5. 告别“调参侠”，迎接“上下文架构师”

在深度学习时代，工程师们调侃自己是“炼丹师”或“调参侠”，试图通过调整超参数来获得更好的结果。

在 AI 应用时代，这种“玄学”正在被工程学取代。虽然我们还不能完全摆脱手动写 Prompt 的尝试，但趋势已经非常明显：结构化战胜了直觉。

即使是一个简单的客服场景，优秀的上下文工程也会将“查询重写”、“文档分块”、“系统提示设计”和“结果过滤”变成一套自动化的流水线。Shopify 甚至已经将“能否为 AI 加载正确的上下文”作为衡量员工效率和系统设计的标准。

未来的 AI 竞争，不再是谁的模型参数更大，而是谁的**“外脑”**（上下文构建系统）更精密。

写在最后

Andrej Karpathy 的推文之所以能激起千层浪，是因为他点破了行业内的一种集体焦虑：我们已经有了爱因斯坦般的大脑（大模型），但我们还在用便利贴（Prompt）给它传递信息。

上下文工程，就是致力于为这个大脑打造一个现代化的图书馆和操作系统。

所以，下一次当你对 AI 的回答不满意时，不妨先停下修改 Prompt 的手，问自己一个更本质的问题：

“如果我是这个 AI，以我目前收到的这些杂乱无章的信息，我能推理出正确答案吗？”