等一下，这是 CLI 还是 GitHub Action 还是 GitHub 应用程序？…

> 我最近尝试在Google Cloud中做一个基本操作（添加一个服务账户），但由于默认规则已过时，且由于其令人困惑的用户体验而难以更改，所以被禁止了。 同样，我尝试联系一些人工客服处理账单问题，但被拒绝了，因为自动检查认为我不值得咨询除文档页面以外的任何内容，而我并不理解这些文档，所以我放弃了，转而使用了另一个云服务提供商。

> 因为它们到处都是，精力分散 他们确实有很多要分散的。但确实重叠程度很高。

> 尽管他们可以访问我的Google账户和我的手机，但他们的Gemini应用毫无用处。 这对我来说最有趣了。当你打开应用时，Gemini会说： “你好，Vasco” 在欢迎界面上。然后我向这个伟大的智能提出这个问题： “我的名字是什么？” “我不知道你的名字。我是一个AI，我没有访问你的个人信息的权限。” 我知道为什么会这样，但这真的很搞笑。

而且这无法像普通的gemini cli那样进行身份验证，看起来它需要一个API密钥，因此目前通过OAuth的免费、标准和企业计划都无法进行身份验证，只能使用Google AI Studio的免费层级，这与gemini-cli的免费层级不同，并且有更严格的速率限制。

我认为谷歌有一些“孵化”空间，他们在里面有团队在开发可能或可能不会成功的东西。所以，当某样东西真的成功时，它就成了自己成功的受害者。这会让人感到困惑，因为它不是一种“核心”的谷歌产品，无法与其他谷歌产品很好地融合在一起。NotebookLLM似乎又是另一个例子。 我个人更希望谷歌即使这样会更令人困惑，也继续进行这种实验。 或者我可能错了。但跟随NotebookLLM的发展，似乎开发它的团队有相当大的自主权。

gemini-cli 是一个命令行工具，它调用 Gemini 并调用常见的文本工具和 MCP 来使用工具。 这似乎只是一个插件，你在 GitHub 上执行某些操作，然后将通知发送到在云上运行的 gemini-cli，然后 gemini-cli 做出响应并将通知返回。 基本上就是省去了你克隆特定提交、手动调用 gemini-cli，然后手动上传结果的麻烦。

他们需要在自己的研究文化和软件文化之间建立一个界限。一个组织，两种文化。 你描述的这种混乱实际上在研究环境中是一个显著的积极因素。这不是分散精力，而是多样化和解耦自己的努力。你不能集中计划所有的创新。 但对于客户和研究产出之间的界面，这涉及到软件和产品问题，显然需要不同的方法。

Jules 在虚拟机中异步运行，并在代码的独立检出中工作。 gemini CLI 与用户同步运行（除非你 YOLO），在你自己的目录、你自己的机器、你自己的代码检出中运行。 两种不同的模式。