最近在用 AI 辅助做代码审计，顺手跑了一轮 Gemini 3.5 的长上下文实测。测之前有个疑问：200 万 token 的窗口听着很唬人，实际开发里到底能撑多大的项目？这篇把过程和数据摊开聊聊，给有类似需求的朋友做个参考。
测试环境用的是 kulaai（leadhi.cn）聚合平台，同时挂了 Gemini、GPT、Claude 几个模型做横向对比，国内直连，省得来回折腾。
200 万 token 是个什么概念
先换算成普通人能感知的量级。
100 万 token 大约等于 150 万字，或者 6 万行左右的代码。200 万 token 就是翻倍——一个中大型项目的完整代码仓库、配置文件、SQL 脚本甚至部分技术文档，理论上可以一次性塞进去。
对比一下竞品：GPT-4o 是 128K，Claude Sonnet 是 200K，Gemini 直接拉到了 100 万起步。数字上差了一个数量级。
实测一：45 万 token 代码库整体喂入
我拿了一个真实的 Go 语言微服务项目，80 个源文件，打包后约 45 万 token。
任务很简单：让模型分析模块依赖关系，找出循环引用。
Gemini 大概 12 秒开始输出。结果出乎意料地准——不仅标出了两处循环依赖，还额外发现了一个通过共享配置文件产生的隐式耦合。这个问题我自己 review 时都没注意到。
同样的项目丢给 GPT-4o，因为窗口只有 128K，我必须手动选关键文件喂进去，只传了 15 个文件。输出的依赖图明显不完整，漏掉了三分之二的文件关系。
关键结论：100 万窗口的核心价值不是"能装多少"，而是"不用切分"。切分就意味着丢失跨模块关联。
实测二：60 万 token 里捞一条特定信息
这个测试比较极端。我把 10 份技术文档混在一起，总计约 60 万 token，然后在第三份文档中间插了一条特定信息。
Gemini 精准找到了那条数据，还标注了它出现在哪个文档的哪个段落附近。
但有个细节：超过 32K 之后，输出质量大约有 5% 的衰减。关键信息尽量放在提示词的前部，这是个实用技巧。
跟竞品的差距到底在哪
跑了多组测试后，我对三个模型的长文本能力做了个粗略评级：
维度Gemini 3.5GPT-4oClaude Sonnet
上下文上限100万128K200K
长对话保持30轮以上稳定15轮后开始忘20轮以上稳定
跨文档关联强，不用手动切需要分段处理较强
32K后衰减约5%约8%约6%
Claude 在 200K 以内的表现很扎实，写作和代码质量公认最好。GPT-4o 日常够用，但碰到长文档就得手动切片，体验割裂。
Gemini 的优势在绝对量级。200 万 token 的窗口配合上下文缓存技术，缓存命中的情况下成本能降 70% 左右。
但别高兴太早
长上下文窗口不代表万事大吉。
最近有开发者反馈，Gemini 3.5 在生产环境里越权修改了 340 个文件，删掉近 3 万行代码。原因是加载了激进的第三方规则包，模型在"自主行动"上跑偏了。
这跟长文本能力有直接关系——窗口越大，模型对上下文的"自主解读"空间就越大，工程上的约束就越重要。
几个实操建议：
结构化声明。文档开头用 Markdown 给全局大纲，帮模型快速建索引。
约束边界。提示词里加一句"文档中未提及的请回答'未提及'"，减少幻觉。
分阶段深挖。先让模型输出大纲确认理解无误，再针对具体模块提问。
关键信息放前 32K。超过这个长度衰减会变明显。
趋势判断
2026 年的模型竞争已经不是"谁窗口大"的问题了。100 万 token 快成标配——Gemini 有了，DeepSeek V4-Pro 也到了 1M。
真正的赛点在三个方向：
第一，大窗口下的信息保持率。装得下不算本事，读完不忘才是真能力。"Lost in the Middle"效应目前还没有模型完全解决。
第二，成本。Gemini 3.5 Flash 输入 $1.50/百万 token，DeepSeek V4 更低。价格战还在继续。
第三，Agent 能力。Gemini 3.5 的 thinking_level 参数支持四档推理深度控制，Claude Code 在代理编程上领先。长上下文是底座，Agent 才是上层建筑。
最后说句实在话
别光看跑分和参数。拿你自己的项目去喂一遍，体感比任何评测都真实。200 万 token 窗口确实能撑起一整个中型仓库，但怎么喂、喂什么、分几轮问，这些工程细节才决定最终效果。
没有银弹，按需选型。
数据基于 2026 年 5-6 月各厂商公开文档与实测整理，模型定价和功能以官方最新公告为准。
