#145. Gemini 如何打造世界顶级 AI 编码模型？ - 跨国串门儿计划

本报告基于对《跨国串门计划》第145期播客的完整ASR原文分析，系统性地还原并深入阐释了谷歌 Gemini 编码能力团队在构建全球顶尖AI编码模型过程中的战略演进、核心理念、技术突破与未来愿景。该播客以一场由 Gemini 产品负责人 Connie Fan 与研究负责人 Danny Tarlow 主导的深度对话为核心，全面揭示了从早期评估标准的局限性到“氛围编程”（vibe coding）范式的兴起，再到长上下文、推理能力与世界知识融合等关键要素如何共同塑造出当前最先进的编码模型。整个讨论不仅是一次技术路线的复盘，更是一场关于“什么是真正有价值的AI工具”的哲学思辨，其核心在于超越传统竞赛式评估，转向以真实开发者工作流为锚点的系统性重构。

报告的核心洞察在于，Gemini 团队之所以能够实现质的飞跃，根本原因并非单一技术指标的提升，而是一套完整的认知体系变革：他们重新定义了“优秀编码模型”的本质——它不应仅是代码补全的精准执行者，而应是一个能理解复杂业务语境、具备跨文件协作能力、支持多轮交互决策，并能在百万级代码库中进行深层推理的智能体。这一转变体现在多个维度：首先，团队主动放弃了以“人类水平”竞赛编程为唯一目标的传统路径，转而聚焦于真实开发场景中“多文件编辑”、“代码库上下文理解”与“长期任务规划”等更具挑战性的需求；其次，他们将“氛围编程”从一种边缘现象升华为核心战略方向，强调通过自然语言指令即可完成从创意构思到可运行代码的全流程转化，从而赋能非专业程序员；再次，模型能力的跃迁被归因于对“推理能力”、“世界知识”与“百万级长上下文窗口”的协同强化，而非孤立的代码生成优化。这些洞见共同构成了一幅清晰的图景：一个真正的AI编码助手，必须像一位资深工程师一样思考、协作与决策，而不仅仅是语法正确的代码拼接器。

最终，本报告不仅呈现了技术细节，更揭示了背后驱动创新的组织文化与价值观：一个充满好奇心、不惧失败、以用户反馈为唯一指南的团队，以及对“真实世界价值”的坚定信念。无论是面对内部工程师的严苛检验，还是外部用户的多样化期待，团队始终秉持“让开发者开心”的精神，持续推动通用能力的全面提升。这种以人为核心、以真实场景为导向的开发哲学，正是 Gemini 能够在激烈竞争中脱颖而出的根本原因，也为整个AI工具生态的发展提供了极具参考价值的战略范式。

Gemini 编码模型的突破性进展，其起点并非技术参数的简单堆叠，而是一场深刻的评估范式革命。在项目初期，团队曾面临一个普遍存在的认知陷阱：将“竞赛编程”（competitive programming）作为衡量模型编码能力的黄金标准。这一标准虽由 OpenAI 等机构率先建立，旨在量化模型在特定问题上的表现，但其内在逻辑存在根本性缺陷。正如 Danny Tarlow 所指出的，一个在竞赛中表现出色的模型，其能力往往局限于解决独立、短小、结构清晰的问题，这与现实世界中软件开发的复杂性相去甚远。> “竞赛编程确实是目标之一。但是问题在于一个特别擅长 lead code 的人并不一定就是团队里最给力的成员，对吧？” 这句反问直指核心矛盾——竞赛成绩反映的是个体在高压下的快速解题能力，而非团队协作、系统设计、长期维护等综合工程素养。因此，将此作为模型能力的唯一标尺，无异于用“能否在10秒内写出斐波那契数列”来判断一个软件架构师的水平。

更为关键的是，这种评估方式忽略了现代软件开发的本质特征：它是一个高度依赖上下文、涉及多文件协同、跨越长时间跨度的复杂系统工程。当开发者面对一个崩溃的错误报告时，问题可能分散在数百个文件中，需要模型具备强大的全局视野和跨文件推理能力，而这恰恰是竞赛环境所无法模拟的。> “对比一下软件开发人员的日常工作，可能会遇到一个关于某个崩溃的错误报告。我不知道这个问题可能分散在代码库中上百个不同的位置，我需要去排查。所以模型所需的能力集合远比竞赛编程所包含。” 这一论述揭示了评估标准与真实需求之间的巨大鸿沟。如果模型只能处理孤立的代码片段，那么它在面对真实世界的复杂性时将束手无策。因此，Gemini 团队的首要战略调整便是彻底摒弃这种“脱节”的评估框架，转而将目光投向那些更能体现开发者实际工作内容的场景。

这一重构的直接结果是，团队将关注焦点从“代码补全”扩展到了“整个代码库级别的任务”。具体而言，他们开始重视“多文件编辑”（multi-file editing），即模型能够理解并修改分布在多个文件中的相关代码，以实现一个连贯的功能变更。> “我们特别关注进行多文件编辑进行比，这里有几十行代码给你更大的改动，我们更关注的是如果你有一个小时的时间坐下来，在你正在工作的代码库的上下文中真正想完成的事情是什么？” 这一描述生动地勾勒出了理想的工作场景：开发者不再需要手动查找和拼接代码，而是可以将一个模糊的意图（如“让这个功能支持多语言”）交给模型，模型则能自动识别所有相关的代码模块，并做出协调一致的修改。这种能力的实现，标志着模型已从被动的“代码生成器”进化为主动的“系统协作者”，其价值远超任何单一的基准测试分数。

此外，团队还意识到，即使在“代码补全”这一相对狭窄的领域，传统的“预测下一个词元”范式也已显露出局限性。> “那种预测下一个词元的范式在尝试进行更大规模编辑时就不再有效了。” 这种范式本质上是一种局部优化，它无法理解代码的整体语义和长远影响。当开发者需要进行大规模重构或引入新架构时，模型若仅凭局部上下文进行预测，极易产生逻辑冲突或破坏现有系统的稳定性。因此，Gemini 的成功，从根本上说，是建立在对“真实工作流”深刻理解之上的。它不再追求在某个孤立的、人为设计的测试集上取得高分，而是致力于成为开发者在日常工作中不可或缺的“伙伴”，帮助他们从繁琐的重复劳动中解放出来，专注于更高层次的创造性思考。

如果说评估标准的重构是战略层面的奠基，那么“氛围编程”（vibe coding）的提出，则是 Gemini 模型在应用层面实现范式跃迁的标志。这一概念并非简单的技术术语，而是一种全新的工作哲学，它将AI编码模型的角色从“辅助工具”彻底转变为“创作伙伴”甚至“灵感激发者”。其核心要义在于，开发者无需再精确地定义每一个技术细节，只需通过自然语言表达一个模糊的、富有想象力的“氛围”或“愿景”，模型便能将其转化为可执行的代码。> “人们已经在使用当前这代模型做一些非常酷的事情了。但你同时也能看到作为下一个前沿领域，这里面蕴藏着多少可能性，我们会思考这些……” 这句话不仅承认了现状的惊人潜力，更预示了未来的无限可能。

这一范式的兴起，其驱动力源于对开发者真实需求的深刻洞察。许多开发者，尤其是非专业程序员或初学者，常常拥有丰富的创意和解决问题的意愿，却受限于技术门槛。> “了解 AI 是如何赋能非专业程序员。让他们也能通过简单的自然语言将奇思妙想变为现实。” 这正是“氛围编程”最核心的价值所在：它打破了技术壁垒，使得创造力本身成为生产力。例如，一个没有编程经验的设计师，或许无法写出复杂的算法，但他可以告诉模型：“我想做一个能根据用户心情推荐音乐的应用，界面要简洁优雅。” 模型则能理解这一抽象需求，并生成一个包含前端界面、后端逻辑和数据处理的完整原型。> “只要用户能够验证最终的成果并对输出有信心，很多事情都可以通过氛围来完成。” 这一判断揭示了“氛围编程”的可行性边界——它不要求模型完美无瑕，而是要求其输出足够可信，足以让用户进行验证和迭代。

这一范式在实践中已展现出惊人的生命力。一个典型的案例是，团队成员在使用早期版本的模型时，尝试从零开始制作一款平台跳跃游戏。> “我当时在看的一个例子是一款类似平台跳跃的游戏，但它设计的一个平台角色根本跳不上去，它。” 面对这一难题，开发者并未陷入调试的泥潭，而是向模型发出指令：“检查所有5个不同的关卡，找出哪些平台是可到达的，哪些是不可到达的，然后进行调整。” 模型随即展现出令人惊叹的推理能力：它不仅分析了每个平台的位置，还计算了角色的跳跃高度，并基于物理规则判断可达性。> “然后就看着他大概思考了一分钟，检查了所有这些情况，然后成功的进行了编辑。” 最终，模型不仅修复了问题，还确保了游戏的可玩性。这一时刻被参与者称为“哇，这太酷了的时刻”，因为它完美体现了“氛围编程”的精髓：模型不是在机械地执行命令，而是在理解意图、进行推理、并自主采取行动，最终达成一个复杂的目标。

值得注意的是，“氛围编程”并非仅服务于业余爱好者。对于专业开发者而言，它同样具有颠覆性意义。> “所以我认为在氛围编程领域有很多非常有趣的事情正在发生，人们已经在使用当前这代模型做一些非常酷的事情了。” 这表明，即使是经验丰富的工程师，也在利用这一范式来加速原型设计、探索新想法或自动化重复性任务。例如，一个工程师可能只需输入“帮我分析一下这个API调用的性能瓶颈”，模型就能自动收集日志、生成可视化图表，并提出优化建议。这种从“写代码”到“定义问题”的转变，极大地提升了开发效率，使工程师得以将精力集中在更具创造性和战略性的任务上。

Gemini 模型之所以能成为“世界顶级”的编码模型，其根本原因在于它成功地将“编码”视为一个综合性智能活动，而非孤立的代码生成任务。这一成就的取得，依赖于三大支柱的协同进化：强大的推理能力、丰富的世界知识以及百万级的长上下文窗口。这三者相互依存，共同构成了模型在复杂场景下卓越表现的基础。

首先，推理能力是模型从“语法正确”走向“逻辑正确”的关键。在处理真实世界问题时，模型必须能够进行多步推理、因果推断和假设检验。> “我们谈论模型的代码能力越来越强，这是不可否认的事实。但是这是如何发生的？” 这一追问揭示了问题的本质：代码能力的提升并非来自对代码语法的单纯记忆，而是源于模型对问题本质的理解和解决路径的规划。例如，在处理一个涉及数学计算的场景时，模型不能仅仅生成公式，而必须理解公式的物理含义和适用条件。> “比如你想解决一个应用题来帮助。帮助别人做家庭作业，也许先把它转换成代码会很有用。代码可以清晰的表述谁有多少苹果，哪些数字需要相乘等等。” 这说明，代码不仅是执行指令的载体，更是进行逻辑推理和问题建模的工具。模型必须具备将自然语言问题转化为可计算形式的能力，这本身就是一种高级推理。

其次，世界知识是模型理解上下文、做出合理决策的前提。一个优秀的编码助手，必须了解其所处的生态系统。> “代码可以清晰的表述谁有多少苹果，哪些数字需要相乘等等。” 这个例子看似简单，实则蕴含深意：它要求模型理解“苹果”是实体，“数量”是属性，“相乘”是操作，这背后是对现实世界关系的认知。> “我认为这是一个非常有趣的方向。这种情况发生的频率有多高？” 这个问题引出了一个核心挑战：有多少用户查询实际上可以通过编写代码来解决？答案是，比例相当可观。> “我觉得现在的情况还是比较保守的，比如如果你说做这个事情模型可能不会生成代码，除非你明确要求它这样做。” 这暴露了一个巨大的机会：如果模型能自动识别出“潜在的代码解决方案”，并主动提供，那么它的价值将呈指数级增长。例如，当用户询问“如何为我的小企业做税务规划”时，模型不仅能给出建议，还能自动生成一个简易的税款计算程序，这正是将世界知识与代码能力无缝结合的典范。

最后，百万级长上下文窗口是实现上述能力的技术基石。没有足够的上下文容量，模型就无法理解大型代码库的全局结构，也无法进行跨文件的关联分析。> “把一个百万行代码库扔进模型的上下文窗口，让它去完成一堆事。” 这一设想虽然在技术上极具挑战性，但其背后的逻辑是清晰的：只有当模型能“看见”整个代码库时，它才能像一名资深工程师那样进行全局优化。然而，团队也认识到，完全依赖“一步到位”的方法是不切实际的。> “我觉得随着规模的不断扩大，比如你永远不可能把谷歌的单一代码库 monorepo 放进去，仅仅对所有那数百万行代码进行一次推理来解决某个错误成本就会高的离谱。” 因此，团队正在探索“基于智能体（agentic）的方法”，即让模型像人一样，通过搜索、跳转、逐步推理的方式来解决问题。> “如果我把你扔进一个大型代码库，你会使用代码搜索，你会查看文件层级结构，你会四处跳转。你会阅读一些代码，然后你会搜索其他东西，这正是基于智能体的方法所采用的解决方案策略。” 这种混合策略——既保留了“一步到位”的魔力感，又引入了可扩展的智能体机制——代表了未来发展的必然方向。

Gemini 团队的成功，不仅源于技术上的突破，更得益于一套严谨且高效的验证与反馈机制。他们深知，任何模型的优劣，最终都必须由真实世界的使用者来评判。因此，团队构建了一个从内部专家到外部用户的多层次反馈闭环，确保模型的发展始终贴近真实需求。

最核心的验证来源是内部工程师群体。> “我认为谷歌最酷的事情之一就是我们拥有超过10万名工程师，遍布各种语言技能和不同的技术栈等等。” 这一庞大的人才库，为模型提供了无与伦比的实时反馈。> “为了弥补目前编码评估中对于专业开发者细微品味的认知空白，能够获得这种广泛的实时反馈是非常宝贵的。” 这意味着，模型不仅要能生成正确的代码，还要符合专业开发者的编码风格、命名规范和最佳实践。> “比如假设他正在值班，某个系统着火了，情况非常糟糕，他需要扭转局面，什么时候他才会真正相信 Gemini 不会把事情搞砸？” 这个问题极具代表性：在高压、高风险的生产环境中，模型的可靠性是决定其生死的关键。> “或者你之前在播客里请了 Emma 当她说这很有主见的时候，Emma 是很有主见的。” 这表明，团队不仅关注模型的“技术能力”，更关注其在关键时刻能否赢得信任，成为值得依赖的“战友”。

与此同时，团队也高度重视外部开发者的反馈。> “我认为相当相似。当然用户群体是不同的，比如康尼提到的那些开发者，我们可能没有与外部特定用力的高带宽沟通渠道。” 尽管外部反馈的获取渠道不如内部高效，但其价值同样不可替代。外部开发者往往代表了更广泛的应用场景和更真实的使用痛点。> “但是就这些用例中模型能力的关键点而言，我不认为这里存在任何方向上的分歧，我认为对于不同的人群所需的能力集合是明确的，只是有所不同，但对于类似的外部开发者和内部开发者，我认为他们在期望方面是相当一致的。” 这一判断表明，无论身份如何，开发者对“可靠”、“高效”、“易用”的核心诉求是共通的。

为了进一步挖掘模型的潜力，团队还在探索更具前瞻性的评估方法。> “我最近最喜欢的一个伪评估 pseudo Eval 也是我喜欢跟 Danny 念叨的哈，是我在网上看到一个帖子，一个不太懂人工智能的人说，如果人工智能这么聪明，为什么不能把鸡蛋价格降下来？” 这个看似荒诞的问题，实则触及了AI终极价值的命题：模型的真正价值，不在于它能多快地写出一段代码，而在于它能否解决真实世界中的重大问题。> “你在多大程度上帮助了广大人民，你在多大程度上造福了整个社会，那才是真正的评估。” 这种评估方式，将模型的能力从“技术指标”拉回到“社会价值”的维度，迫使团队思考：我们的模型是否真的在创造有意义的改变？

在深入探讨核心观点的同时，播客中还穿插了大量丰富而深刻的细节，共同勾勒出一幅完整的图景。从历史角度看，团队对早期AI编码研究的回顾揭示了技术演进的必然性。> “在2013年我去做博士后研究的时候，他们给了我一个实习生。那是我第一次有机会完全自主的定义一个项目，并与其他人一起完成它。就在那时，我开始研究构建源代码的生成模型。” 这段经历表明，尽管早期模型（如循环神经网络）在处理“未定义变量”这类基本规则时表现拙劣，但研究者们早已预见了将程序作为输出的宏大愿景。> “你可以构建更结构化的模型。将更多的人类知识融入到架构设计等方面，然后你就可以构建一些模型，它们生成的样本看起来更真实，并且能捕捉到其中一些特性。” 这些早期努力，为后来的Transformer架构和大模型时代奠定了基础。

在模型发展路径上，团队展现了极强的战略定力。> “我们花了很多时间讨论长远的未来，也回顾了我们所做的一切的历史。” 这种对历史的反思，使团队能够避免盲目追逐短期热点，而是专注于构建真正可持续的能力。> “我们非常清楚地听到了一个反馈，那就是在工具调用功能方面存在一些问题，尤其是在基于代码的上下文中。” 这种对“微调”和“流畅性”的持续关注，体现了团队精益求精的态度。

关于未来，团队提出了诸多富有启发性的猜想。> “Python 和 Javascript 或者 Typescript 会不会成为有史以来最后的编程语言？” 这一问题引发了对编程语言生态的深刻思考。> “不过我不会低估两点。第一仅仅通过提供编程语言的规范作为上下文，模型本身可能就能做得非常好。” 这表明，模型的强大泛化能力可能打破语言壁垒，为新语言的诞生创造机遇。> “第二，我们正处于一个人们如何使用编程语言以及用它们做什么的剧烈变化时期。” 这暗示了未来可能出现的颠覆性创新。

最后，团队的文化特质是其成功不可或缺的软实力。> “如果收到了负面反馈，团队里没有人会采取辩解的态度，团队里的每一个人都充满了好奇心，并且真心实意的想把模型做得更好。” 这种开放、谦逊、以学习为导向的集体心态，是任何技术突破都无法复制的宝贵财富。> “能身处这样的氛围中和这样一支不可思议的团队一起工作，感觉真的太棒了！” 这不仅是对团队的赞美，更是对一种理想工作状态的向往。

综上所述，本次播客通过对 Gemini 编码模型发展历程的深度剖析，为我们揭示了一条通往下一代AI工具的清晰哲学路径。其核心启示在于：真正的技术突破，始于对“真实世界价值”的深刻理解，成于对“系统性能力”的协同构建，终于对“集体智慧”的持续敬畏。

首先，它挑战了唯指标论的思维定式。在AI领域，人们习惯于用排行榜、基准测试来衡量进步，但 Gemini 的实践证明，这些指标往往是片面的、甚至是误导性的。一个模型是否“好”，不应由它在某个封闭测试集上的得分决定，而应由它在真实工作流中为用户创造的价值来衡量。> “我们希望理解预测并押注于那些能够产生真实世界价值的领域，我们要确保不会过度优化某个方面。” 这一理念要求我们跳出“技术至上”的窠臼，将用户的需求置于一切工作的中心。

其次，它确立了“通用智能”的发展方向。Gemini 的成功，不是因为它是“代码专家”，而是因为它是一个“通用智能体”。它将编码能力视为其整体智能的一部分，而非孤立的技能。> “我们认为所有这些不同的能力之间的关联性有多大？” 这个问题的答案是：它们高度关联。> “代码可以清晰的表述谁有多少苹果，哪些数字需要相乘等等。” 这说明，代码是连接世界知识与逻辑推理的桥梁。未来的AI工具，必然是一个能够跨领域、跨模态协同工作的“超级智能体”，而不是一个个功能单一的“工具箱”。

最后，它彰显了组织文化的决定性作用。技术可以被模仿，但一个充满好奇心、勇于承担失败、以用户为中心的团队文化，却是难以复制的。> “团队里的每一个人都充满了好奇心，并且真心实意的想把模型做得更好。” 这种精神，是推动创新的永恒引擎。

因此，Gemini 的故事不仅是一次技术的胜利，更是一场关于“如何构建真正有用的产品”的思想实验。它告诉我们，当我们把目光从“机器能做什么”转向“人类能通过机器做什么”时，我们才真正走上了通往未来的大道。