@googledevs: The standard software validation loop takes too much time, time you often don’t have. See how YouTube engineers moved a…

The standard software validation loop takes too much time, time you often don’t have.

See how YouTube engineers moved at lightspeed and democratized AI prototyping by rebuilding a full mirrored version of the platform using AI Studio, letting anyone safely test prototypes against live data.

Dive into the full playbook on Emergent: http://goo.gle/emergent

TL;DR

YouTube 工程师通过构建一个灵活、安全的原型栈，将 AI 产品的验证周期从几个季度缩短到几周，解决了“随性编码”在大型组织中的风险与速度悖论。

那 5% 的幸存者：为何多数 AI 应用死在验证阶段

我编码的产品已经进入了它们的黄金时代。随性编码（vibe coding）和智能体工程（agentic engineering）让开发者能够将想法在数小时内变成可用的应用。但当那个大创意达到生产门槛时，它几乎总是失败。

只有 5% 的 AI 编码应用在现实世界中存活下来。另外 95% 在验证阶段就失败、崩溃、坠入深渊。这个事实令人抓狂。为什么会这样？我们该如何解决？

我叫 Stephanie Wong，作为 Google Cloud 开发者项目的全球负责人，我可以独家接触到 Google 内外的团队，分享你在其他地方找不到的工具和最佳实践。我们将编写开发者所需的行动手册，帮助他们跻身那 5% 的精英行列。在本期《Emergent》中，我们将深入探讨 Google 如何验证 AI 产品——一个简单但激进的想法，它将在你起步时改变你的构建方式。

加入这场竞赛令人兴奋：你随性编码出一个很棒的 app，它可能成为出色的产品。这是纯粹的创造力，迭代再迭代，但因为无法为演示获取真实数据，它失败了。你解决了那个问题，但又得不到反馈，所以再次失败。与团队达成一致，失败。即使通过了验证阶段，这些过程也需要时间。而随着开发者承受着自上而下的压力，要求越来越快地交付，这些时间你往往没有。这一切让我们感觉陷入了无休止的障碍赛跑。更糟的是，当你打开 X，会看到人们炫耀他们刚刚发布的新玩具。他们到底是怎么做到的？全是假的吗？AI 的黄金时代真的是虚幻的金矿吗？

拥抱失败，但别在组织里摔得太狠

首先，让我们深呼吸。AI 开发是马拉松，不是短跑，我们需要精神耐力来解决这个问题。那么想想：问题可能不是“他们怎么成功的”，而是“他们为什么没有失败”。为了回答这个问题，我拜访了我的导师 Addy Osmani——todo MVC、Chrome DevTools 和 agent skills 背后的明星工程师。

Addy 说：“你首先需要了解我的一点是：我一直在失败。我认为不用担心失败是可以的，因为失败是不可避免的。我一直在尝试构建一个 AI 周报开发者新闻项目，用了很多不同的并行编码智能体，一次尝试使用多达 10 个。我把任何孤立的任务尽可能委托给这些智能体，而把那些细微、复杂一点的任务留给自己处理。通常我会稍微关注变更是否落地、是否渲染、看起来对不对，然后就合并这些变更。我这样做时基本是‘莽一把’。但如果我一直合并变更而不注意细节，事情最终会出问题。两个应用就因为我不注意细节而崩溃了。所以随性编码和智能体工程很像驾驶喷机：它们让我移动更快、灵活机动，但速度越快，越容易失败。而失败是我们真正进步的唯一途径。”

虽然我同意开发者应该拥抱失败，但当你在一个没有用户的个人项目上工作时，这要容易得多。当我和团队在 Google 内部构建时，我不是在独自驾驶；而是一个需要可靠、准确、安全且合规的大有机体的一部分。规则严格得多，审批层级复杂难行。即使在预生产阶段，如果我开始随性编码，结果也不总会好，失败的风险和后果要高得多。

所以开发者需要以光速移动，同时最小化风险。但仅靠随性编码做不到。或者能吗？为了找出答案，我需要找到一个人，他不只是迫降了他的飞机，而是迫降了更大的东西。是时候学习如何在最大规模上失败了。

YouTube 的 Benji Bear：当速度与风险在规模上碰撞

在广泛搜寻 Google 最大的失败后，我终于发现了 YouTube 的 Benji bear。好吧，显然我是在开玩笑。Benji 与失败相去甚远。事实上，他是那位机智的工程师，提出了一个新颖的解决方案来解决一个你可能很熟悉的问题——与初创公司相比。

“构建 YouTube 可能会慢一些。比如几年前，我们想重新设计播列表页面，一个小团队花了多个周期，不是发布它，而只是向老板展示一个丑陋的演示，看看‘这是我们要的方向吗？’这类问题在尝试使用全新技术的功能时尤其棘手，比如 YouTube 以前从未扩展过的语言模型。尝试做到这一点感觉几乎不可能。”

正常情况下这是有意为之。YouTube 庞大的生产服务器处理数十亿用户，遗留代码已有 20 年历史。你不能冒险用实验性、快速随性编码应用的技术债务来超载那个代码库，尤其是当故障范围可能影响一个基本上已经是公共设施的平台时。幸运的是，YouTube 有防护栏来防止现实中这种灾难，但你懂的。

Benji 和他的团队难以像他们想要的那样快速移动、廉价构建或轻松转向。这还不算 DeepMind 每隔几周就有新发布。到演示完成时，即使是好主意也可能显得过时，Benji 有严重的错失恐惧症。这是风险与速度的悖论，规模宏大。你不敢相信 Benji 是如何解决这个难题的。

“我希望培养更多的创业文化，让团队中的任何人都能受到激励去构建新功能，并在几周内（而不是几个季度）进行验证，同时考虑到平台的技术复杂性。” 没错。“当我们观察人们正在做的项目，尤其是这些新的 AI 功能时，实际落地的团队都在全力以赴地原型设计。开发者喜欢用 AI Studio 来随性编码原型，但如果你一直在关注，你已经知道这还不够，因为你从零开始。这是‘空白画布问题’。你无法在 YouTube 服务器上测试原型，也无法看到它与 YouTube UI 的交互。没有 API 访问或真实数据来验证你的原型，你就完蛋了。你不如用纸和剪刀做原型，然后称之为‘随性手工’。”

因此，为了在生产环境中进行原型设计，Benji 需要将 Addy 所喜爱的快速、高风险、AI 集成编排性质，直接连接到 YouTube 上，但又并不真正连接。

原型栈：在平行宇宙中重建 YouTube

“我知道我需要构建一个灵活、安全的原型环境，一个最小化技术债务、减少人们为测试一个想法而需要导航的层级和系统的环境。”

Benji 和他人构建的解决方案不仅对 YouTube 的 AI 产品开发产生影响，而且对 Google 整体都有影响。这就是他们的原型栈——一个快速的全栈产品验证平台。它允许开发者：

• 访问实际有用的数据用于他们的随性编码原型
• 查看他们的原型在 YouTube UI 上的外观和性能
• 实时点击和混搭他们的试点项目

它包括对 YouTube 数据和 AI Studio 模板的 API 访问，再加上 AI Studio 强大的智能体编码能力，他们可以在 AI Studio 中提供完全镜像的 YouTube 版本。它通过在一个平行的宇宙中重建 YouTube 来解决空白画布问题。

“在 AI Studio 中重建 YouTube 相对容易构建。YouTube Recap 和 YouTube Ask 等许多功能首次通过只读 API 访问真实 YouTube 数据库进行随性编码。我们以最大灵活性进行实验，可以在几周内将新版本的功能带给用户体验者。这个过程让我们能够使用 DeepMind 最新最好的模型，所以我们从不觉得自己落后了。”

所以现在 Benji 和他的开发者可以迭代、混搭、收集数据、对齐愿景、完善原型。然后他们只需从 AI Studio 复制粘贴到生产服务器。嗯，不完全是。虽然 Google 的用户现在可以快速随性编码一个很棒的原型，但它仍然是随性编码的，而 YouTube 仍然是一个庞大的组织，充满复杂的代码和强大的防护栏。我们为原型清除的那些层级在投产时又会涌回来。这些层级产生摩擦，通过它们需要付出真正的代价。Benji 的解决方案：拥抱一次性代码。

“我就是这么告诉所有人的。用原型证明想法，然后在生产中坚定地重写。所以重建一个经过验证的想法比打磨一个凌乱的原型更快。” 没错。“这正是拥有双轨系统的美——任何人都可以构建原型，即使你不是程序员。”

而这正是 Benji 平台的真正天才之处。它消除了工程和政治障碍，这些障碍常常阻止有前途的想法越过执行障碍。在我们有编码原型系统之前，只有少数像 Benji 这样的工程师可以为 YouTube 构思和构建新功能。但通过访问实时 API 进行原型设计重写了规则。它改变了构建者、产品经理、用户体验研究员和工程师之间的关系。它开放了竞争环境，赋权每个人测试自己的想法，增加了好想法突破的机会，并提供支持系统帮助你在失败后反弹。通过允许我们所有人尝试——是的，失败——它让编码民主化。

从 YouTube 到 DeepMind：原型栈如何改变 Google 的文化

自从 Benji 的团队创建并部署这些连接的 AI 系统以来，YouTube 的文化发生了变化。原型设计现在成了标准，Benji 被 DeepMind 招募，把他构建的沙盒应用到整个 Google。现在每个开发者都可以通过 API 可访问的演示来进行原型设计，用定量数据证明某件事有效。

“所以我想追问的是，人们如何将 Benji 所构建的东西应用到他们自己的团队？”

“解决方案是利用 AI Studio 或 Google 技术栈中其他工具的力量，创建你自己的原型栈。好吧，我想这得留到另一个视频了。但现在，简单的解决方案是什么？”

“简单的解决方案是转变你的心态。”

“哦好吧，转变心态。下一步呢？”

“使用原力？”

“不，但我想你说得对，Addy。心态转变从我做起。你看，原来 95% 规则从来不是问题。事实上我们应该鼓励人们更多失败，壮观地失败。这样你才能得到最好的想法。有了 AI，我们不再是简单的程序员。我们是安全的建筑师。我们的工作是建造桥梁——这些桥梁不一定防止失败，而是让失败更成功。”

“对工程师来说，为他们的组织构建一个原型栈现实吗？”

“是的，事实上，这是必要的，因为最大的风险不是破坏系统，而是错失时机。只有通过拥抱自下而上的方法，你才能释放团队的潜力。而 Benji、他的团队和 AI Studio 已经给了你钥匙。在 AI 产品的黄金时代，开发者有充分的理由保持希望，因为你们是变革的推动者。而接受这一事实的公司和团队，将赢得 AI 竞赛。”

Source: YouTube Video: How YouTube engineers moved a… (Google Developers)