Gemini 的产品和研发负责人分享了关于优秀编码模型、Vibe Coding 以及编程语言未来的见解。他们认为，竞技编程和简单的代码补全并不能完全反映开发者的实际工作。Gemini 团队关注数据和方法论、代码库上下文的重要性以及 Vibe Coding 的兴起。他们致力于赋能非专业程序员，并通过“代码就是一切”的愿景，将代码能力与其他能力相结合。评估方面，团队注重真实世界的价值和实用性，并面临泛化性挑战。面对复杂代码库，团队采用长上下文能力和 Agentic 编码策略。短期目标包括解决工具调用问题、改进用户交互和提升特定用例表现。此外，模型的风格也至关重要。最后，团队选择通用模型而非代码专用模型，看重其超越代码的知识需求和开发流程的复杂性。

💡 谷歌 Gemini 团队认为，一个优秀的编程模型主要取决于“数据和方法论”。他们强调了代码库上下文的重要性，目标是让模型能够帮助开发者在代码库的上下文中进行复杂的更改。

🎯 Gemini 团队关注 Vibe Coding 的兴起，即那些不一定是专业程序员的人，利用工具扩展他们使用编程的能力。团队希望赋能那些不具备专业编程技能的人，让他们能够自己完成一些基本的事情。

🔥 Gemini 团队秉持“代码就是一切”的愿景，认为代码能力的提升也能反哺 Gemini 的其他能力。例如，可以将自然语言问题转化为代码问题来解决。

📊 评估方面，团队的目标是理解、预测并押注真实世界的价值。他们关注评估的实用性，并认识到编程模型的最大挑战在于构建能够同时适用于所有用例的能力。

🌐 Gemini 团队选择通用模型而非代码专用模型，因为代码模型需要“世界知识”，并且代码意味着“软件开发过程的越来越多部分”。通用模型能够将所有这些相互关联，并协同工作。

Gemini 的产品和研发负责人录了个视频

讨论了一下关于关于优秀编码模型的理念以及 Vibe Coding 的影响，以及编程语言的未来

很多见解挺好的，说明 Gemini 的代码能力进步还是有方法的

视频：https://youtu.be/jwbG_m-X-gE?si=u0nz9RxOaUlhW_Ab

总结了一些我觉得重要的内容：

📌 谷歌 Gemini 团队的编码模型训练方法论

🎯 Gemini 早期编程目标及其局限性

1️⃣ 竞技编程（Competitive programming）：尽管像OpenAI等公司在评估模型编程能力方面做了很好的工作（如human eval），但竞技编程的能力并不一定等同于一个强大的团队成员所需要的技能，因此这与开发者最终的需求有所偏差

2️⃣ LMS（Language Model Systems）：这也不是日常开发工作的真实写照

3️⃣ 代码补全（Code completion）：这虽然更具生产力，但其应用空间有限，不足以体现模型现在和未来能够实现的所有功能。

Danny Tarlo认为，前两个目标并不能真正反映开发者的实际工作，而第三个目标则不够宏大。

仅仅关注竞技编程是不够的，因为它无法涵盖软件开发人员日常工作中的更广泛能力需求。竞技编程通常是在一个"非常自给自足的环境中"工作，从零开始构建相对简短的解决方案。然而，软件开发人员日常工作涉及处理大型代码库中的错误报告，这些错误可能分散在"代码库中一百个不同的位置"。因此，模型需要的能力集远大于竞技编程所包含的。

💡 Gemini 编程优化当前关注的"核心要素"：

1️⃣ 数据与方法论：Danny强调，一个优秀的编程模型主要取决于"数据和方法论"，太鸡贼了最重要的内容一笔带过。

2️⃣ 代码库上下文的重要性（Repo Context）：代码库上下文是如此重要。模型不仅要处理代码补全，更要支持"多文件编辑，比只给你几行代码更大的更改"。目标是让模型能够帮助开发者在代码库的上下文中进行需要一小时完成的复杂工作。

3️⃣ "Vibe Coding"与专业开发者：他们也看到"Vibe Coding"的兴起。这指的是那些不一定是专业程序员，或者只有少量编程经验的人，利用工具扩展他们使用编程的能力。Andre Karpathy关于"live coding"的推文进一步普及了这个概念。团队的最大愿望是赋能那些不具备专业编程技能的人，让他们能够自己完成一些基本的事情。

🔥 代码就是一切

• 代码作为通识能力：代码能力的提升也能反哺Gemini的其他能力。有些问题可能起初不是一个编程问题，但可以将其转化为代码问题来解决，例如帮助学生解决数学应用题，或者在代码空间中进行推理。

• "代码就是一切"的愿景："代码就是一切"。举例说，用户询问报税技巧等自然语言问题，其核心需求其实可以通过生成一个"最基本的报税计算"来解决，即便用户没有明确要求"编写一个迷你Quickbook"。

📊 评估（Evals）与挑战：

• 真实世界价值：团队的目标是"理解、预测并押注真实世界的价值将走向何方"。要专注于"这个领域的核心基本挑战，这些挑战对于真实世界的价值是有用的"。

• 评估的实用性：最能反映真实情况的评估是"在AB测试中发布一些东西，看看真实世界会发生什么"。这不切实际，因为不能指望一个新模型在创业公司运行一年来评估其成功。他们需要寻找实用的替代指标。

• 泛化性挑战：编程模型的最大挑战在于，需要构建"能够同时适用于所有用例的能力"。用户使用代码模型的方式多种多样，模型需要能够泛化到所有这些不同的使用场景。

🗂️ 面对处理越来越复杂的代码库（如百万行代码的monorepo）的问题，有两种主要策略：

1️⃣ 长上下文能力：让模型能够将整个代码库作为上下文来处理，并在一个步骤中解决问题。

2️⃣ Agentic编码（Agentic Coding）：模型像人一样工作，通过代码搜索、查看文件层级、跳转阅读代码等方式，自主地解决问题。

🎯 Gemini 团队在编程优化上的短期目标：

• 解决2.5 Pro版本中"工具调用功能"的可靠性问题，特别是在代码上下文和Agentic模型进行代码编辑方面
• 细致调整用户交互，确保用户体验更流畅
• 改进模型在特定用例类别上的表现

✨ 模型在风格上的表现也至关重要，例如在生成网页UI时，除了功能正确，还需要美观和符合专业标准。Connie提到，有时即使模型犯了两次错误，但如果它表现得"有点调皮"，说"第三次会成功"或"这真的很难，我们再试一次"，这反而能让用户"原谅Gemini"，并建立信任。她强调，"这种风格，比如语气、个性，不一定是你在编码中认为关键的东西，但它在人们接受这些模型的方式中却很重要"。

🌐 为何选择通用模型而非代码专用模型：

• 超越代码的知识需求：代码模型需要"世界知识"，而不仅仅是代码本身。例如，一个"Taylor Swift排名应用"就需要对世界有一定了解，而不仅仅是代码。

• 开发流程的复杂性：代码意味着"软件开发过程的越来越多部分"，并需要连接到各种不同的信息，其中一些是代码特定的，一些则不是。

• 通用模型的优势："将所有这些都看作是相互关联的，我们都在为模型的通用能力而共同努力，我们将努力找到最佳方式让一切协同工作，拥有一个真正优秀的通用模型，这对我来说是一个很好的方向"。事实证明，这种方法成功地构建了一个出色的编程模型，同时在其他方面也表现出色。