编辑 | 听雨
出品 | 51CTO技术栈（微信号：blog51cto）
别急着写代码，先教AI怎么干活。
这是 Google Cloud Platform 开发者体验部门副总裁Keith Ballinger 最近在《The New Stack Agents》节目上说的一句话，也是一针见血地指出了当下AI开发的最大误区。
Ballinger 是少数依然亲自写代码的高管之一，同时深度参与了最新的 “智能体化” 编程工具的研发与使用。他目前负责的核心产品——Gemini CLI，是 Google 直接对标 Claude Code 与 Codex 的竞争者。
很多程序员沉迷于让 AI 写更多的代码，但Ballinger 认为，目前的智能体工具仍处于“初期阶段”，要真正发挥潜力，就别急着写代码，先写好文档：
要真正让 AI 成为高效开发者，人类开发者需要放慢速度、写清楚文档、规划项目、描述架构。AI 不会读心，它需要你告诉它要干什么。
他指出，开发者太常使用“一次性尝试”的方式，这无法向模型提供足够的信息，了解开发者的意图以及问题的整体上下文。
图片
Ballinger 还认为，从长远来看，未来大部分开发者甚至可能不再需要查看代码，而只需要写下意图（intent）。
他透露，未来 Gemini CLI 将支持子智能体（sub-agents）协作；自动监控代码测试、CI/CD 部署、日志与运行状态；具备“AI-aware shell”，让命令行本身成为一个智能环境。
小编为大家整理了这期播客的精华内容，干货满满，你将了解到：
- Google 开发者体验部的工作内容
- Ballinger的早期AI编程经历
- Gemini CLI 与 Agentic 编程理念
- AI 编程最佳实践（写文档、写计划、架构驱动）
- 编程语言的未来与自然语言交互
- Ballinger 关于 AI、CLI、科研工具的观点
建议收藏细读，enjoy!
Google 开发者体验部的工作
主持人：
谷歌开发者体验部听起来包含很多内容，能先简单介绍一下吗？
Keith Ballinger ：
嗯，G 实际上代表 GCP（谷歌云平台），但有趣的是，它也包括很多非 GCP 的项目，所以我可能应该重命名它。GDE（Google Developer Experience）组织负责一系列开发者工具和服务，包括一些经典的 GCP 工具和服务，比如 Cloud Build 或 Cloud Deploy。同时我们也做很多 AI 代理式编码工具，比如 Gemini CLI，这其实不是 GCP 独有的产品。还有 Go 团队，他们为我工作，负责开源世界的项目，以及 Flutter、Dart 等谷歌开发者项目，每个人都应该注册这些项目。总之，涵盖了谷歌开发者相关的主要内容。现在我们重点关注的，是代理式编码，也就是如何让开发者更有趣地使用 AI。
主持人：
你是怎么把这些工作理清楚的？在推动 AI 的同时，如何平衡 Go、Flutter、Dart 等其他项目？
Keith Ballinger ：
这是个好问题。我觉得最重要的是，AI 并不是完全独立的东西，它能辅助代码的各个环节。所以即使你在投资 Go 团队，你其实也在支持代理式编码。例如 Go 团队有很多出色的静态分析工具和 LSP（语言服务器协议），在这些基础上，我们又建立了 MCP，使得在使用 Gemini CLI 编码 Go 更加方便。这些工具已经存在多年，它们对 AI 编码依然非常有用。所以不必总是纠结于“这是不是纯 AI 投资”，每项投资在很多方面都能兼顾 AI 编码。
早期的AI编程经历
主持人：
在聊这个之前，我想了解一下你的职业经历。你曾在 Xamarin 工作，大约十年前，是个重要的开源项目。后来 Xamarin 被微软收购，你去了 GitHub，现在在谷歌。能谈谈你的职业路径吗？
Keith Ballinger ：
我第一份开发工作是在 Intel，90 年代末在那里待了几年。然后 1999 年我加入微软，八年里一半时间做 .NET 和 C#，Andrew Salzberg（C# 的创造者）就在我隔壁办公室。所以从那时起我一直在做开发工具。
离开微软后，我做了很多创业项目，想积累各种经验，但最享受的还是面向开发者的项目。比如，我是 Standard Treasury 的首位工程师，这家公司为银行构建 API，面向开发者，后来被硅谷银行收购。至于 Xamarin，这很有趣，CEO Nat Friedman 曾聘我做顾问帮他找产品副总裁，最后我被邀请直接担任 VP 产品，这对我来说有点意外，因为我以前主要是工程师，管理经验有限，但我就接受了，并自学了相关管理书籍。
后来 Xamarin 被微软收购，我在微软成为开发者服务的总经理，负责 Azure DevOps 和内部工程系统。之后我促成了微软收购 GitHub，顺利地加入了 GitHub，成为 CEO 和工程高级副总裁。
主持人：
这很契合。我曾参加 GitHub Universe 大会，看到很多创业公司，也看到 Google Jules，但它不属于你的组织，对吗？
Keith Ballinger ：没错，Jules 是实验室项目。Google Labs 做前沿服务和应用，尝试一些风险较高的想法。如果某个项目效果好，会转入产品团队。Jules 是例子，它与 GitHub（尤其是 Issues）关联，可半匿名使用。这种方法论和技术也应用到其他免费或企业付费产品上。
主持人：
是的，Jules 类似 OpenAI Codex 之类的项目。
Keith Ballinger ：Anthropic 的 Spot Code 也是类似思路。我觉得 Jules 与其他项目有不同，它有更具体的 GitHub 工作流，而 Gemini CLI 是独立的项目，也会有 Web 界面。Codex Web 和 Claude Code 做的是更通用的功能。
主持人：你提到很多人只会“单次调用”式使用 AI，你最初是怎么开始使用AI的？
Keith Ballinger ：我从小就对开发工具和技术感兴趣，甚至是 Marvin Minsky 的邮件笔友，很早就对 AI 有兴趣。2012 年我组建过 Bayes Hack 团队，用 ML 为非营利组织服务。
在 GitHub，我们开始做 Copilot。当时 OpenAI 有了比较好的模型（Codex），能处理编程任务。最初我们做的只是代码补全，非常互动，帮助用户熟悉 AI。之后人们开始使用聊天功能，如 ChatGPT 或 Gemini 做 AI 编码。再后来，出现了代理（agent），模型能代表用户使用工具，这带来了行业的有趣变化。大约去年中，工具使用型模型开始流行，人们不仅仅做代码补全或聊天，而是能执行半自动任务。
之前，我自己充当工具，把 Gemini 提供的代码复制到项目中，还跑测试并反馈结果。CLI 出现后，这个过程自动化了，效率大大提高。
现在，我看到行业中大家对最佳实践理解差异很大。要高效使用 AI，需要像对待同事一样协作，遵循开发中的基本流程：写用户指南、技术设计、项目计划等。这能显著提升 AI 的成果。我有一个开源项目能演示这个方法。
主持人：
那展示一下吧。
Keith Ballinger ：
好的，我共享屏幕。这是我的桌面，你能看到一个叫 Line Counter 的文件吗？
主持人：
看到了。
Keith Ballinger ：很好。你可以在我的 GitHub 上找到 Conductor 仓库。我用它来设置项目，其中包括计划文件、代码风格指南、工作流、状态文件、启动 AI 的提示、用户指南、架构等。
图片
主持人：
看起来很详细，这是你亲自写的，对吗？
Keith Ballinger ：是的，但主要是 Markdown 文件。
主持人：
我想说的是，这种方法还是很冗长。未来会不会简化？
Keith Ballinger ：我希望不会。我喜欢创作过程，参与思考问题和解决方案。AI 可以帮助，但仍需要我提供足够的信息。
（然后 Keith 演示了如何用 Conductor 文件指引 AI 创建“智能行计数器”工具，生成项目结构、用户指南、架构文档等。通过这种迭代方法，可以完成复杂项目，例如他开发的针对 LLM 的编程语言 aether。）
图片
主持人：
那你如何保证输出正确？很多时候 prompt 的结果应用到开发环境可能不准确。
Keith Ballinger ：我用 AI 帮助验证。我使用 TDD 方法，让 AI 写测试，逐步实现功能。主要通过测试和示例验证，而不逐行检查代码。
主持人：
你在这个过程中发现了新的开发体验吗？
Keith Ballinger ：
是的。很多最好的软件来自工程师的痛点。我的很多项目也是为了好玩，同时确保工具质量。比如我开发了 Dev Sense，用于分析 Git 历史。灵感也来自生活，比如为我制作的生日漫画，让我想到如何用 AI 创建漫画生成器。
主持人：
在使用这些代理时，你遇到过哪些问题？
Keith Ballinger ：
最早 CLI 出现之前，我必须充当工具，操作繁琐。CLI 出现后，这个问题得到解决，更高效、更自然。
CLI 的复兴与“AI终端”
主持人：
为什么 CLI （命令行界面）最近又流行了？现在几乎所有代理都有 CLI。
Keith Ballinger ：因为我们从未放弃终端。终端给开发者很大控制权，专注任务，不受复杂 UI 干扰。终端使用自然，与现代开发、开源生态契合，所以成为很理想的界面。
主持人：
CLI 现在在 AI 世界里是一个很有意思的话题，因为 Frederick 已经完成了。我很好奇你怎么看终端本身的演进，Gemini CLI 是不是直接把 AI 带进了终端？
Keith Ballinger ：是的，我觉得这是一个非常有趣的问题——终端本身会不会变得更具 AI 能力，或者会不会出现越来越多在终端里具备 AI 功能或受 AI 影响的命令工具？
大约一年前，我做了一个原型，为 Cube Cuddle 写了一个扩展叫做 Cube Cuddle AI，当时代码很糟糕，团队后来重写了它。现在它是 Cube Cuddle 的一部分，你可以用自然语言查询，然后 Cube Cuddle 就能执行操作，比如“现在哪些节点出问题了”。这是一个例子，说明工具可能越来越多地具备这种能力。另外，你也可以看到终端本身变得更 AI 化，Warp 就是一个例子。当然，现在最常见的 shell，除了终端之外，是 bash 和 zsh。
我一直在思考的一件事，我之前做过一个原型，我的团队又做了一个更好的原型，就是——我们能不能创建一个“AI 感知的 shell”？每种交互方式都是一种可能性，就像你可以有一个理解你操作的桌面应用，或者网页。我的猜测是，这些趋势都会发生，因为它们都有很有意思的用例。
主持人：
你如何看 CLI 和 IDE，以及其他可能使用这些工具的场景之间的交接？上次我们谈过 Gemini CLI 和 Z 的集成。
Keith Ballinger ：如果我没记错的话，是的。让我再分享一下屏幕，我展示给你看。这种情况在所有工具中越来越多，非常有意思。
图片
比如我在 VS Code 里，可以直接在 VS Code 的终端里启动 CLI，它可以工作。而且，现在越来越多的 IDE 都能用它。我可以问：“这个文件是干什么的？”它知道我打开了哪些文件，比如我打开了 mod Dors，它会读取并告诉我内容。所以你不必在不同工具之间切换，你可以让它们深度协作。我认为这可能会成为开发者喜欢的工作流。
编程语言的未来：从代码到意图
主持人：
我很好奇关于编程语言的演进。如果我们谈终端的演进，也涉及很多相关内容。你刚才说，通过生成式 AI，你不需要非常精通 Rust，可以让机器帮你生成正确代码。那么，我们对代码本身的思考会有变化吗？新的编程语言会因此产生变化吗？
Keith Ballinger ：这是一个非常有趣的问题，因为存在很多不同观点，没有人能确定。我个人相对乐观，这可能是少数观点。宏碁就是一个例子。
我认为我们应该设计针对 LLM的编程语言，让我们作为开发者“基本不用看代码”。换句话说，开发者关注系统设计、架构、用户界面等，代码本身成为黑箱。这是抽象的自然进化。
我们从穿孔卡开始，逐步到 C 这种紧贴汇编的语言，再到 Java、C# 等更高抽象的语言。我认为下一步的抽象是——我的意图，想做什么，以及如何组合出一个体验或应用。在这种情况下，可能不需要手写代码。当然，总会有人热爱写代码，他们在某些场景下仍然有竞争优势。
我希望他们享受编程，但我认为未来更多人不需要深入写代码。
还有一个有趣的现象——有人做过实验，把两个智能体放在一起通信，随着时间推移，它们发明了一种非常紧凑的“自造语言”互相交流。非常有意思，我很想看到它的发展。
主持人：
这种抽象层是自然语言吗？还是一种元编程语言？自然语言不够精确吧。
Keith Ballinger ：
我也不确定。但我以前反对自然语言，觉得会有更精确的交互方式。但随着经验增加，我认为自然语言其实可以很精确，比如教科书或非虚构类作品，写得很清楚。只要具备良好的表达能力和问题分解能力，就能有效与 AI 交互。
你可以训练人们学习新的语法或视觉语言，但那需要额外学习。我认为重点是提升人的写作和问题分解能力，这是核心技能。
主持人：
这和今天程序员的技能不同吗？
Keith Ballinger ：
我不这么认为。伟大的程序员本身就是优秀的写作者，他们记录问题、方案、设计，然后把业务问题转化为技术解决方案。未来，在 AI 编程世界，可能写代码不再是核心技能。
主持人：
那依赖推理的系统有什么权衡吗？因为你依赖机器做结论，它可能有限制。
Keith Ballinger ：你能具体说说吗，我没完全明白。
主持人：
AI 本质上是黑箱，我们不能追踪它内部逻辑。如何确保推理准确？现在代理尝试做推理，但需要完整系统来验证结果。
Keith Ballinger ：我理解了。一方面，研究者正在做类似“AI MRI”的工作，分析模型在生成 token 时的内部电路。另一方面，和人类程序员一样，我不必了解他们的大脑细节，只需有效沟通即可。
同时，我们需要方法评估 AI 系统的表现，比如它是否偏离预期。很多技术正在开发中，包括 CI/CD 测试和生产环境监控。总体上，模型的可靠性越来越高，但我们仍需创新方法。
Gemini CLI 将支持子代理协作
主持人：
回到 CLI，谈谈 Gemini CLI 的现状吧。CLI 和 Gemini 的交互是现在的主要模式吗？这是最终形态吗？
Keith Ballinger ：
绝对不是终点。我觉得我们还在第一局，或者刚热身。基本功能已经能用，比如和 Gemini 对话、使用工具、进行推理，但还有很多优化空间。
模型会越来越智能，有人认为未来只需薄薄的代理代码封装，但我认为我们总会有更多功能可以加入封装中，有些功能最终会并入模型。
关键方向有几类：一是 UX/UI，比如在 CLI 或 AI 应用中，如何与 AI 交互、批准工具或生成子代理等；二是处理更大问题，比如子代理、问题分解、监控运行时系统、收集数据反馈。
举个例子，我希望用 Gemini CLI 写代码、提交、运行 CI/CD、部署到 Cloud Run，然后监控数据反馈。比如告诉 Gemini CLI 用 GitHub CLI 监控 PR 的 Actions，如果失败就自动修复，需要时询问我，直到 PR 成功。接下来可以从 Cloud Run 下载日志、发请求、判断是否正常并调整。
这些都是工作流优化问题，Gemini CLI 在 UX、工作流、性能优化等方面正在投入很多。
主持人：
那 Gemini CLI 和后台代理怎么配合？在 CLI 中，我可以观察 Gemini 的操作。
Keith Ballinger ：
很快就可以。我们有子代理功能，你可以启动它们。CLI 本身也能作为后台代理，我经常启动另一个 CLI 实例并监控它。
主持人：
你怎么监控子代理？
Keith Ballinger ：每个 CLI 都在构建基础设施，比如命令查看聊天记录等。我之前的系统是自定义方式——给子代理一个状态文件，父 CLI 定期检查它。Gemini CLI 是开源项目，可以从社区 PR 和讨论中获得很多创意。
主持人：
Gemini CLI 很大一部分代码是由 Gemini CLI 自己写的吗？
Keith Ballinger ：
是的，我们早期就开始用它开发它自己。整个团队经常用 CLI 来开发 CLI。
主持人：
CLI 能理解代码上下文吗？
Keith Ballinger ：
可以。你可以手动给 CLI 提供上下文，比如某个文件名，它会读取并生成单元测试。Gemini 有很大的上下文窗口，也会自己决定读取哪些文件构建上下文。
行业上还需要改进上下文管理。上下文越大，出错概率越高。子代理可以接收特定任务的精确上下文，这也是一个创新方向。
主持人：
这会涉及状态管理问题，对吗？如何管理分布式环境中的状态？
Keith Ballinger ：
是的，项目有整个 SDLC，需要管理状态。我通常用状态 markdown 文件存储信息。大团队使用 AI 时，也需要协调各代理，让它们知道所需信息。可能会有“主代理”掌握整体情况。我们在这个方向上仍在探索，但进展很快。AI 生成和 AI 消费的文档能帮助很多，但这是静态的。
还需要理解部署拓扑、服务负载等信息。这些都是 Gemini CLI 早期发展阶段需要迭代的地方。
主持人：
这也涉及处理能力问题，每个代理可能有自己的状态，这需要强大基础设施。像 Google 这样的云服务提供商几乎是必须的，因为谁能提供足够计算能力管理这些代理？
Keith Ballinger ：
你说得对，我在 Google，可能有偏见，但我来这里的原因之一就是 Google 有所有这些资源，TPU 能提供强大支持。
主持人：
其他云服务商呢？
Keith Ballinger ：当然有其他，但你说得对。GCP 有 Cloud Assist，其中有 Investigations 功能，它可以分析日志，收集运行时环境信息，帮助诊断问题。
这种状态管理和 AI 代理结合的用例非常有效，可能比其他用例都要好。
与AI共写论文
主持人：
我知道你之前在节目开始前聊到过，用这些模型做科学和数学类的问题，有些人可能会说它们还不够好，但显然它们越来越强。你对这方面的兴趣从何而来？
Keith Ballinger ：
嗯，我其实不是特别专业，但我非常喜欢数学和科学，总是想尝试新的方法。过去几个月，我花了很多时间用 Gemini 来做数学和科学相关的论文写作、研究、形式化验证等。我并不是专家，但这边有很多科学家可以帮我。事实上，我可以给你展示一个例子，我来分享我的屏幕。看看我是否打开了它。是的，这是我用 Gemini 写的一篇论文示例，我用了一个叫 Coauthor 的工具，我稍后会介绍。它主要做 LaTeX 管理，还有代码建模和绘图等。
主持人：
你觉得可能不在科学出版领域的人，也能用它吗？
Keith Ballinger ：正是如此。最终，我这里有一篇论文——研究黑洞的误差校正效应。虽然这篇论文不是我自己编码完成的，但它是通过 Gemini 迭代构建的，同时做了实验和形式化验证。
图片
我创建的工具叫 Coauthor。我来给你演示一下。它基本上是一套提示和操作手册，包括 LaTeX、Lean 使用指南，还有用户指南和代码风格指南，非常类似于 Conductor。我还有一个安装脚本，安装后它会调用 Gemini CLI 来控制整个过程。相比我直接在 Gemini CLI 里操作，Coauthor 会先收集上下文信息，再启动 CLI，帮我管理整个流程。
图片
我觉得这是一个非常有趣的思路。在科学和数学领域，人们一直在研究如何实现自主操作，比如“自主科学家”，这是很有趣的。但在编程世界，我们起步时不是从这里开始的。科学、数学和编程有很多相似之处。在编程领域，我们是从代码补全、聊天、带工具的聊天，然后是半自主，最终逐步实现更自主的代理。科学和数学领域也是逐步累积的。很明显，Gemini CLI 在这类工作中非常有用，因为它是互动的，只有在互动之后，才可能发展到完全自主的一次性操作。
主持人：
你提交过基于 Coauthor 的论文，并通过同行评审了吗？
Keith Ballinger ：我不认为自己是科学家。我关注的是流程，而不是去发明新的科学或数学知识。
主持人：
将来可能会有一个学术研讨会，所有参会者都是 Agent，所有演讲者也是 Agent，它们代表自己生成的论文。
Keith Ballinger ：我一点都不意外。现在不同期刊对 AI 参与论文写作的接受程度不一样。一般来说，你必须说明在论文中使用 AI 的情况。有些期刊只允许 AI 对写作进行润色，有些期刊则更开放。我相信未来会越来越宽松。
我展示的那篇论文，基本上是 AI 完成的，我沿途提供指导，就像我做 Ether 编程语言时一样。但过程是互动的。我现在合作的物理学家和数学家，也会用这些工具加速工作，而不是完全交给 AI。未来或许会出现自主科研的代理，但现在让科学家更高效，就已经非常有价值。
主持人：
那场景会不会是我们在 AI 学术会议上喝啤酒，机器人给我们讲解论文？
Keith Ballinger ：
我等不及了，真的有太多有趣的可能。
主持人：
然后它们会喝机油。机器人团队总说，机器人经常出故障，所以进展没有预期那么快。
Keith Ballinger ：娱乐产业已经高度依赖 AI，因为我们喜欢娱乐。你会看到更多这种情况，比如漫画创作、视频内容、音频内容等。随着依赖增加，系统的可靠性也必须更高。
完全 vibe coding对未来的影响
主持人：
时间差不多了，我们看看是否有观众提问。
来自 Joshua 的问题，关于你之前提到的“不可能计算”（impossible computing），你觉得“完全 vibe coding”在未来一年会有多大影响？
图片
Keith Ballinger ：好问题。我提到“impossible coding”是有些理想化的意思，我希望大家觉得没什么不可能，通过编码几乎可以实现一切。
具体影响取决于“完全 vibe coding”的定义。我认为，知识工作者和普通用户都可能用 vibe 编程，比如为单次生日派对创建网站，RSVP 后就消失。对知识工作者尤其如此，他们可以为自己创建业务应用。
例如，营销人员用 Gemini Enterprise 创建辅助文案写作的应用。这类工具能极大提升效率，因为软件需求远超供应。
关键是要保证交接顺畅。如果营销人员做了一个应用，内部工程团队之后需要接手。AI 可以在第一步就捕捉到开发意图。
像 Excel 或 Access 数据库那样，90 年代人们没有技术背景也能做复杂工具，但后来往往得重写。未来或许无需每次都重写。
主持人：
也可能每次都重新创建应用，而不需要保存，只是即时生成界面。
Keith Ballinger ：
是的，未来的桌面操作系统可能会实时动态生成用户界面。但我认为我们正在进入一个既奇怪又激动人心的世界。
最近阅读的书籍
主持人：
最后一个问题，我看到你十年前的博客，总是有阅读推荐。你现在在读哪些科学或数学书籍，有推荐吗？
Keith Ballinger ：我用 Kindle。最近在读 Adrian Tchaikovsky 的《地球的碎片》，读到一半，非常喜欢。
主持人：
我没怎么读过他的书。
Keith Ballinger ：
这是我第一次读他的小说。最近我读了《大脑的7.5堂课》，非常好。还有 Scott Myers 的作品，以及《第四个时代》，去年重读了 John Rawls 的《正义论》，都很有趣。最精彩的是最近两年读的《明天，明天，明天》。
主持人：
太棒了，我也喜欢那本书。
Keith Ballinger ：
去年圣诞节我送给员工，作为创作者，这本书完美捕捉了创作精神。
这是我十年来读过的最好的书之一，我推荐给每个人。它完美呈现了团队合作和创作的精神。还有人际关系、人与人的互动及其变化，很酷。
主持人：
今天就到这里吧，时间超了，但讨论非常精彩。
Keith Ballinger ：
当然，我很享受这次对话，谢谢邀请。
参考链接：https://www.youtube.com/watch?v=29jwD9vJl3I&t=12s
