为什么 Gemini 在谷歌内部编码工具中被禁用？谢尔盖·布林的说法解释
“谢尔盖·布林 谷歌 Gemini 禁令”这句话使得该集内容听起来比实际证据所支持的更为戏剧化。谷歌并未禁止 Gemini 的公开使用，监管机构也没有禁止它，布林也没有说该模型未能通过安全审查。他描述的是一种更狭窄、更奇怪的情况：一个列出编码工具的谷歌内部网页将 Gemini 列入了“禁止”一侧。
这个故事来源于布林 2025 年 5 月 20 日在迈阿密参加 All-In Live 活动。它于 2026 年 7 月在科技报道和社交媒体上再次出现，因此许多读者将其视为新鲜新闻。核心事实是真实的，但确切的政策理由从未公开披露。
来源: Wikimedia Commons / Asoundd, CC BY-SA 4.0
主要收获
- 布林表示，Gemini 出现在谷歌内部一则涵盖员工可用于编码的工具的“禁止列表”中。
- 他仅将原因描述为历史性的和“奇怪的”；谷歌并未就该规则发布详细解释。
- 布林还表示，该规则并未真正强制执行，但内部网页仍然存在，并造成了真正的批准问题。
- 经过长期的内部争议和升级，该限制最终被解除。
- 这不是针对 Gemini 的公开禁令，也不是谷歌认为 Gemini 不安全或非法的证据。
谢尔盖·布林实际说了什么
在采访中，布林谈到了他重返谷歌技术一线工作。他解释说，他开始接触公司系统的不同部分，提交小的代码更改并进行实验，以便他能够直接理解这项技术，而不是仅仅通过高管简报来了解。
随后，谈话转向了 AI 辅助编码。布林表示，谷歌维护着一个定义哪些工具可以被使用、哪些不能被使用来编写代码的列表。Gemini，即谷歌自己的旗舰 AI 系列，在该内部页面的禁止一侧。他说这种情况“让他大吃一惊”，并提到了一个历史原因的集合，而不是一个清晰的当前理由。
❝ 我的意思是，没有人会执行这项规定，但确实存在这个内部网页。 ❞
2025 年 5 月 20 日在迈阿密 All-In Live 活动上发言的谷歌联合创始人
布林表示，他反对这项政策，并且解决这个问题花费了“惊人”的时间。他还说，问题最终得到了解决，谷歌正在尝试不同的内部和外部 AI 编码工具，以确定什么真正提高了开发人员的工作效率。
为什么 Gemini 被禁止使用谷歌的内部编码工具？
最准确的答案是：谷歌尚未公开给出具体原因。布林没有提到安全事件、版权纠纷、隐私泄露、编码性能不佳或监管命令。他自己的解释是，Gemini 出于他认为不再有意义的历史原因而被列入了内部禁止使用列表。
这种措辞暗示了一个过时的批准决定或一项已过时的情况的政策。它没有告诉我们最初的情况是什么。任何关于该限制是由于源代码泄露、模型幻觉、许可问题或内部竞争引起的说法都超出了公开证据的范围。
来源: commons.wikimedia.org
大型公司通常会控制哪些编码助手可以访问存储库、提示和开发环境。布林的账户显示了批准列表如何与公司当前的产品策略脱节。
内部“禁止列表”通常意味着什么
批准的工具列表是一种治理机制，不一定是对产品的好坏的评判。在软件组织中，编码助手可能需要审查，因为它可能接收专有代码、检索存储库上下文、生成许可内容、调用外部服务或存储遥测数据。在批准工具之前，安全团队还可能需要身份控件、日志记录、区域处理规则和合同保证。
谷歌 Gemini Code Assist 的公开文档说明了企业买家现在期望的控制类型。它描述了通过托管身份进行身份验证、基于 IAM 的访问和数据保护承诺。这些公开的控制有助于解释为什么编码工具受到谨慎管理，但它们不能证明为什么 Gemini 出现在谷歌自己历史性的内部列表中。
有关这些数据问题的更广泛解释，请参阅 Zerlo 关于谷歌 Gemini 数据隐私问题的指南，该指南区分了消费者活动设置和企业数据治理承诺。
这个故事并不意味着什么
| 常见解释 | 可用证据支持的内容 |
|---|---|
| 谷歌禁止了所有 Gemini | 否。布林描述的是一个内部编码工具批准页面，而不是公开产品禁令。 |
| Gemini 未通过已确认的安全审计 | 布林的说法中未披露任何此类发现。 |
| 谷歌工程师完全无法使用 Gemini | 布林说该规定并未真正强制执行，尽管正式的内部页面仍然列出了限制。 |
| 事件发生在 2026 年 7 月 | 最初的公开报道可追溯到 2025 年 5 月 20 日；该故事后来于 2026 年的报道中再次出现。 |
| 限制仍然存在 | 布林说问题已解决，谷歌正在推出和测试 AI 编码工具。 |
消费者 Gemini、Gemini 模型和编码产品并非同一事物
部分混淆源于将“Gemini”用作多个层级的单一标签。Gemini 可以指谷歌 DeepMind 的模型系列、公开的 Gemini 聊天应用程序、开发者使用的 API，或 Gemini Code Assist 等编码产品。内部政策可以批准一个部署而限制另一个，因为数据流、用户身份、存储库访问和日志记录安排各不相同。
来源: commons.wikimedia.org
公开的 Gemini 网页应用与连接到私有存储库的企业编码助手不同。布林的轶事涉及内部编码工具批准，而不是对这个面向消费者的界面的普通访问。
谷歌于 2025 年 5 月 20 日宣布，个人版 Gemini Code Assist 和其 GitHub 代码审查产品普遍可用，并由 Gemini 2.5 提供支持。这次公开推出与布林的采访发生在同一天，这使得内部限制显得尤为矛盾，但仍未揭示旧的内部列表何时被创建或何时被移除。
桑达尔·皮查伊移除了禁令吗？
布林清楚地描述了在正常流程难以解决后进行升级。几篇后续报道将谷歌和 Alphabet 的首席执行官桑达尔·皮查伊确定为帮助解除限制的高管。然而，在相关采访片段的广泛流传的文字记录中，当时并未明确提及皮查伊。最稳妥的说法是，布林将争议升级到了高级领导层，并表示问题已得到解决；报道将最终干预归功于皮查伊。
这种区别很重要，因为病毒式传播的摘要经常将一个非正式的轶事变成精确的企业时间表。谷歌没有公布内部网页、原始决策记录、批准团队或正式的事后分析。公开证据主要来自布林自己的说法及其后续报道。
为什么这个轶事对谷歌以外也很重要
这个事件是 AI 采用如何可能被组织结构而非模型能力所减缓的一个有用的例子。一个公司可能公开推广 AI 产品，而内部的安全、法律、采购和工程系统仍然将其视为未批准。结果是战略意图与日常开发人员访问之间的差距。
有三个教训值得注意：
- 批准列表需要负责人和过时审查。一个没有当前负责人的规则可以在其最初理由消失后仍然存在。
- “内部测试”需要一个批准的部署路径。员工不能仅仅因为公司构建了一个产品就负责任地在机密工作上测试它。
- 升级不能替代治理。布林可以把问题向上提交；普通工程师需要一个记录在案的流程来挑战过时的限制。
因此，这个故事中最有趣的部分不是谷歌曾经不信任 Gemini。证据并未证实这一点。而是谷歌的内部控制系统显然未能跟上谷歌自身 AI 战略的步伐，甚至一位联合创始人也发现纠正起来异常困难。
常见问题解答
谷歌 Gemini 真的被禁止在谷歌内部使用了吗？
据谢尔盖·布林说，Gemini 出现在内部的“禁止列表”中，员工被允许使用该列表中的工具进行编码。他还说该规定并未真正强制执行，所以“列为未批准”比说所有内部 Gemini 使用都被技术性阻止更准确。
为什么谷歌将 Gemini 列入禁止使用列表？
谷歌尚未公布原因。布林仅提到了不寻常的历史原因。安全、隐私、知识产权和采购问题是编码工具批准流程的常见原因，但在这起案例中，没有任何原因被证实是根本原因。
谢尔盖·布林是什么时候讲述这个故事的？
他在 2025 年 5 月 20 日迈阿密的一次 All-In Live 采访中讲述了它。这段轶事于 2026 年 7 月再次流传，使得那些没有看过原始采访的读者觉得它是新鲜事。
桑达尔·皮查伊撤销了 Gemini 的禁令吗？
后续报道称，布林将此事升级到了桑达尔·皮查伊，并且皮查伊支持解除限制。布林公开的说法证实了升级和解决，尽管通常可获得的文字记录并未在相关段落中清晰地提到皮查伊。
Gemini 被认为不适合编码吗？
布林没有这么说。没有公开的安全故障或正式的安全评估被引用为内部列表的原因。谷歌后来扩展了基于 Gemini 的编码产品，并发布了企业安全和数据治理控制。
Gemini 是否仍然被禁止使用谷歌的内部编码工具？
布林说问题已经解决，谷歌正在测试和推出多种 AI 工具以提高开发人员的工作效率。没有公开证据表明相同的限制仍然有效。
底线
谢尔盖·布林关于谷歌 Gemini 禁令的故事最好被理解为一次内部治理失败，而不是一次公开禁令或关于 Gemini 不安全的确认性判断。Gemini 出现在编码工具的“禁止列表”中，原因据布林所称是历史性的且难以理解。他挑战了这项政策，将其升级，并表示最终得到了纠正。未知的是最初的理由、哪个团队拥有该规则以及它过时了多久。