Google I/O 结束了，我把 Gemini 4.0 拿来写了三天代码
Google I/O 2026 结束那天，我正在调一个定时任务的并发 Bug。
Gemini 4.0 发布的推文在屏幕右边闪了一下，我扫了一眼——200万 Token 上下文、原生多模态、编码能力号称大幅提升——然后继续盯着我的日志文件。
等 Bug 修完，我想，行，就拿它练一下。
接下来三天，我把 Gemini 4.0 拉进了两个真实在跑的项目：一个是内部的 Python 数据处理服务，另一个是一个 Node.js 写的 API 网关。不是玩具 demo，是平时会出 incident 的那种。
第一天：200万 Token 上下文，真的用上了
之前写过一篇《遗留代码让我崩溃了三次，第四次我把 AI 拉进来了》，说到用 AI 读老代码的经历。那次主要是拿 Claude 跑的，最大的瓶颈是上下文装不下整个文件树。
Gemini 4.0 的 200 万 Token 窗口是真的存在。我把那个 Node.js 网关项目的核心文件全塞进去了——大概 12 个文件，总计 8000 多行——然后直接问：这个项目里请求限流逻辑在哪里，有没有并发问题？
它给出了一个完整的分析，指出了三处可能的竞态场景，其中一个是 Redis 计数器在高并发下的写入顺序问题。
我去查了代码——那个问题确实存在，是半年前一个临时补丁留下来的。
当时有点惊讶。因为这类问题需要把多个文件的逻辑串联起来看，之前用其他模型都要人工引导，告诉它”重点看这两个文件”。Gemini 4.0 自己把上下文消化掉了，然后直接给到关键点。
不过速度稍慢。200万 Token 进去之后，第一次响应大概等了 15 秒，比 Claude 4.7 的这类任务慢一些。
第二天：写代码的感觉
代码补全这件事，Gemini 4.0 的风格比较……干净。
举个例子，我让它给一个 FastAPI 接口补全参数校验逻辑，它给的代码没有多余的注释，也没有多余的 import，变量名选得比较克制。对比 GPT-5.5 经常给我一个”完整示例版本”塞了一堆我不需要的东西，Gemini 4.0 更像是在配合我已有的风格写，而不是展示自己会多少。
这个特点在重构的时候更明显。
我让它把一个 500 行的数据清洗脚本拆成三个模块，它没有急着给代码，先问了我两个问题：这些模块之间会不会有共享状态？有没有现有的 utils 可以复用？
我回答完，它给出的拆分方案基本符合我的直觉，改动量也比较小。
当时我的感受是：它比 GPT-5.5 更”有礼貌”，但也更慢一步。
第三天：踩坑时间
Gemini 4.0 在某些情况下会出现一个我暂时叫做”信心过满”的问题。
具体说：我让它修一个 Python 脚本里的日期解析错误，它给了一个修复方案，我看了觉得没问题就合进去了。跑测试——全绿。
然后第二天线上出了一个只在特定时区下才会触发的边界条件。
回头查，Gemini 4.0 当时用的是 datetime.strptime，没有考虑到 UTC 偏移的情况。它的解释是”标准格式下可以正常解析”——这句话没有错，但它没有主动问我这个服务跑在什么时区。
Claude 4.7 处理同类问题时，通常会在给方案之前问清楚运行环境。这算是 Gemini 4.0 目前的一个短板：对隐含假设的敏感度不够高。
我跑的另一个坑：在处理嵌套 JSON 结构时，它生成的代码在路径不存在时不抛异常，直接返回 None，导致下游静默失败。这种”防御性过头”的写法需要注意，生产代码里宁可显式报错。
三天下来的位置
我用了一个不太严格的方式来给这三个模型做了一个场景分工：
快速原型、初稿生成：GPT-5.5 依然最快，生成密度高，适合从零开始搭框架。
大上下文整体理解、跨文件分析：Gemini 4.0 的优势区间，200万 Token 是真能用到的。
复杂逻辑、边界条件处理：Claude 4.7 更谨慎，会主动问假设，适合核心路径的代码。
这个划分不一定对每个人都适用，但对我的项目来说，目前是这么用的。
Gemini 4.0 是一个真实意义上的改进，不是那种”发布会上改进、实际没什么感觉”的升级。200 万 Token 不是噱头，它解决了一个我之前用 AI 工具时绕不过去的问题——上下文放不下整个代码库，所以只能片段式地告诉它”关注这里”。
但”信心过满”的问题值得注意，尤其是在生产代码里，不能直接用它给的方案而不做 review。
下周打算拿它试试跑一次完整的 PR review，看看在更大的 diff 下表现怎么样。有结果再写。