作为谷歌负责开发者工具的产品管理高级总监，Ryan J. Salva 得以近距离观察 AI 工具如何改变编程方式。他此前曾在 GitHub 和微软任职，如今负责 Gemini CLI 及 Gemini Code Assist 等工具，推动开发者进入智能体编程的新世界。
他的团队于周二发布了新的第三方研究，展示了开发者实际使用 AI 工具的情况以及仍需取得的进展。我与 Salva 就这份报告及其个人使用 AI 编程工具的经历进行了交谈。
本次采访已进行删减和润色，以控制篇幅并提升清晰度。
谷歌每年都会发布一份开发者趋势调查报告——但今年的报告重点聚焦于 AI 工具，特别是“代理型开发者”（agentic developers）在编程方法上愿意走多远。研究结果中有什么让你感到意外吗？
一个非常有趣的发现是开发者开始使用 AI 工具的中位时间。他们发现这一时间是 2024 年 4 月，这与 Claude 3 和 Gemini 2.5 的发布时间相当吻合。这标志着推理或思维模型时代的开端，与此同时，我们在工具调用（tool-calling）方面的能力也有了显著提升。
对于编码任务，你确实需要能够利用外部信息来解决问题，因此它可能需要执行 grep 搜索、编译代码等。如果代码编译成功，它可能还会运行单元测试和集成测试。我认为，工具调用确实是赋予模型在推进过程中自我纠错能力的关键环节。
你个人是如何使用 AI 编码工具的？
我目前的大多数编码工作都是用于业余项目，而且我大部分时间都在使用基于命令行的工具。其中包括 Gemini CLI。此外，我也会少量使用 Claude Code 和 Codex。但你永远不会单独依赖某一款终端工具，因此我在 IDE 的使用上非常多样化。我会用 Zed、VS Code、Cursor 和 Windsurf，全都用，因为我对了解世界如何运作以及行业如何演进充满兴趣。
在专业方面，产品经理通常依赖于文档，所以第一步就是利用 AI 帮助我编写规格说明和需求文档。
我很好奇这是如何运作的。你用 Gemini CLI 来构建 Gemini CLI，但我想象它不可能自己运行自己。
开发任务通常以一个 issue 开始，可能是有人提交的 GitHub issue，比如某个 bug。说实话，很多时候这是一个描述不够充分的问题。因此，我会使用 Gemini CLI 来创建一份更完善的 Markdown 格式需求文档。这通常会生成大约 100 行既具技术性又注重结果的规范说明。然后，我会基于该规范以及团队文档中的一般偏好，使用 Gemini CLI 编写代码。
在整个工程团队中，我们有多层规则和 Markdown 文档供模型读取，这些文档明确了我们的工作方式：例如如何进行测试、如何管理依赖项等等。因此，当模型生成代码时，它也会参考这些文档。
随着 Gemini CLI 进行故障排查，我会让它更新我的需求文档，注明“我已修复此步骤，现在进入下一步”，依此类推。每一步都会创建自己的提交（commit）和拉取请求（pull request），因此我可以随时回滚或撤销操作。
我认为，我大约 70% 到 80% 的工作是在终端中使用自然语言，尝试利用 Gemini CLI 来构建需求，然后让 Gemini CLI 为我编写大部分代码，最后我会用当前使用的任何 IDE 去审查和阅读这些代码。但总的来说，我更倾向于将 IDE 作为阅读代码的地方，而不是编写代码的地方。
你认为原始计算机代码还有未来吗？或者我们最终会将一切都转移到终端窗口中？
三十年来，IDE 一直是软件开发中进行所有工作的场所。你拥有 IDE、浏览器以及终端窗口。
我认为这种情况在很大程度上仍然如此，但我推测，随着时间的推移，我们将花费更多时间与需求打交道，而在 IDE 中花费的时间会逐渐减少。而且我认为这种变化可能会在一个相当长的时间跨度内逐步发生。
人们对此对软件开发职业发展的影响感到诸多焦虑。如果十年后我们不再查看代码，这对开发者意味着什么？他们是否还有工作岗位？
我认为，开发者的工作将更像架构师。重点将是把庞大而复杂的问题分解为更小、可解决的子任务。你需要关注更宏观的视角，思考你试图实现的目标，而不是纠结于用于将其表达为机器码的中间语言。