加载失败
这条消息说的是 Gemini API 的 File Search 新增了 multimodal 能力，也就是不只处理纯文本，还可以面向更多类型的资料做检索和上下文注入，属于典型的 multimodal RAG 场景。评论很快把话题扩展到 Google AI Studio（Google 的 Gemini 开发者控制台）本身：有人抱怨它的搜索只能搜标题、Ctrl+F 不稳定，甚至不能删除聊天记录。还有人拿 Claude Desktop（Anthropic 的桌面客户端）那种会把项目文件切块、索引并按主题自动注入上下文的做法来对比，认为这类基础体验 Google 早就该补上。整串讨论最后又延伸到 Gemini 3 Pro、GPT 5.5、API 费用控制、以及本地部署的隐私替代方案，反映出大家关心的不只是新功能，而是整个产品成熟度和可用性。
很多评论并没有继续讨论 File Search 本身，而是先吐槽 Gemini 和 Google AI Studio（Google 的 Gemini 开发者控制台）的基础搜索体验。有人说只能搜对话标题，不能搜内容，而且滚动会让 Ctrl+F 失效，等于把最基本的查找功能做坏了。还有人提到浏览器里的 Gemini 搜索同样很差，甚至连删除对话都做不到，给人的感觉是内部根本没人认真当日常工具在用。
一派观点认为 Gemini 的模型和产品都已经明显落后于 OpenAI 和 Anthropic。有人用同样的代码仓库重构任务做对比，表示 Gemini 3 Pro 折腾了 8 天都没完成，而 GPT 5.5 几小时就交付并且还做了改进。也有人直说 Gemini 需要大量手把手引导，默认状态很懒、指令遵循差，甚至觉得它更像和开源模型同一档位。
也有评论认为 Gemini 并非完全没用，而是在某些长尾场景里很强。有人做 reverse engineering 时发现，Gemini 和 Flash 模型能从非英语的小众社区网站里抓到更新更快的信息，而其他模型要么答案过时，要么胡编乱造。还有人强调它在 uptime、文档分析成本，以及大厂级安全性上更有吸引力，至少在企业和生产环境里不容易被轻易排除。
不少人把问题归结为 Google 内部组织结构，而不是单纯的技术欠缺。有人认为搜索团队和 Gemini 团队几乎像两家公司，彼此缺少协作，所以搜索领域的积累没有真正传到 Gemini App 上。另一些评论则把这说得更直白：Google 体量太大，无法让 19 万员工全面协同，只能围绕特定项目做局部合作，产品体验自然会碎片化。
在更实用的层面，有人只关心 Gemini API 现在能不能设每个 key 的花费上限。此前因为没有这个功能而放弃使用的人表示，现在已经可以通过 spend caps 来限制支出。只是这个能力要通过 AI Studio 配置，而且据说有大约 10 分钟延迟，说明功能补上了，但流程仍不算顺手。
还有一条明显不同的思路，是干脆不要云端大模型，而是选择本地方案。有人宣传自己的 HugstonOne，强调它可以在 32GB RAM 的笔记本上跑 multimodal RAG，主打 GDPR 和 HIPAA compliant、无订阅、无隐私顾虑。这个视角把重点放在数据主权和可控部署上，而不是继续追求更强的云端模型。
RAG: Retrieval-Augmented Generation，检索增强生成；先从外部资料库检索相关内容，再把结果喂给模型生成答案，常用于 File Search、知识库问答。
RLHF: Reinforcement Learning from Human Feedback，基于人类反馈的强化学习；用人工偏好来对齐模型行为，评论里用来解释模型是否“听话”。
spend caps: API 费用上限；给每个 API key 或账号设置消费封顶，避免费用失控。