Snowflake的AI编码五阶段工作流框架

Vivek 介绍了 Snowflake 如何在整个工程组织中系统性地推广编码智能体——先从不受限制的自由实验开始，再把行之有效的方法总结成一套共享术语体系，其中包含 14 种“AI 设计模式”：从“先用自然语言制定计划”，到隔离并行智能体，再到通过持续更新的技能减轻值班负担。Vivek 详细讲解了软件开发的“内循环”和“外循环”，介绍了 Snowflake 内部用于衡量工程师在这条连续路径上进展程度的 Yegge 量表，并分享了一个三人团队如何借助编码智能体，让 Snowflake 查询编译器的性能提升了 40 倍。

详细介绍 Snowflake 的“专注周”：工程师会获得专门的时间，用来补齐最佳实践，或进一步探索技术前沿。

探讨“先锋派／定居派／怀疑派”框架，说明如何根据工程师采用 AI 工具的不同阶段提供支持，以及为什么这种转变可能引发类似悲伤五阶段的心理反应。

介绍 Snowflake 如何将发布验证时间从 15 天缩短到 1 天，以及为什么增加自动化测试并未以牺牲生产稳定性为代价。

展望面向值班和事件响应的四步成熟度模型，其中 AI 智能体最终可能承担主要值班职责。

在 LinkedIn 上与 Vivek Raghunathan 建立联系。

Eira May：大家好，欢迎收听 Leaders of Code。我们正在旧金山举行的 Snowflake Summit 现场录制本期节目。如果这是你第一次收听，Leaders of Code 是 Stack Overflow 播客中的一个栏目，我们会邀请资深工程领导者，与他们探讨正在开展的工作、如何打造优秀团队，以及他们目前正在应对的最大挑战。我叫 Eira May，是 Stack Overflow 的 B2B 编辑。今天与我一起参加节目的，是 Snowflake 工程高级副总裁 Vivek Raghunathan。欢迎来到节目。

Vivek Raghunathan：感谢邀请。

Eira May：不客气。这一周到目前为止过得怎么样？

Vivek Raghunathan：非常令人兴奋。每年的这个时候，我们都能向所有人展示过去一年取得的成果。看到客户与我们打造的产品互动、亲自体验这些成果，是一种不可思议的经历。这一周让我对接下来一年的工作充满动力，因为我们知道自己走在正确的道路上。我们正在打造能够为客户带来巨大价值的东西，而他们也认同我们对未来的愿景。

Eira May：太棒了。说到未来愿景，我们这周反复听到的一个话题，就是工程领导力正在发生某种转变。随着代码生成成本，也就是编写一行代码的成本逐渐趋近于零，瓶颈就不再主要是编写代码了，对吧？它开始转向更多围绕团队管理与协调、意图定义，以及从战略层面思考如何真正创造业务影响的工作。所以我想知道，作为 Snowflake 的工程领导者，面对这些变化，你是否开始以一种截然不同的方式思考工程领导力应该是什么样子？

Vivek Raghunathan：在我看来，一个更有意思的问题是：生产软件这门生意本身正在发生怎样的变化？因为从某种意义上说，岗位和人们所做的工作，是软件业务如何最终产出软件的一种外在衡量指标，对吧？过去 12、18、24 个月里，我们一直在用一种相当系统的方法推进这件事。我也很乐意详细介绍。我的理解是，代码首先在工程师的脑海中形成，然后出现在他们的工作站或某种云端工作区中，之后还要经过一系列环节，最终才能进入 main 或 master 分支，对吧？

Vivek Raghunathan：我把它称为软件开发的内循环。软件还有一个外循环：代码进入 main 分支之后，需要发布到生产环境。接下来还有一个我称之为软件开发“第二外循环”的过程，也就是生产环境中发现了缺陷，这些问题会以支持工单、事故，或者系统中某种异常检测结果的形式回流；而我们需要考虑的是，为响应这些缺陷所做的修复，如何再次进入 main 分支。如果你愿意，可以把它称为“外循环二”。然后就是你刚才问的问题：在这个新世界里，角色和职责会是什么样子？构建软件这件事本身正在如何变化？面对软件构建方式已经发生变化这一事实，你又该如何调整组织结构？所以我把它拆分成了这五项任务。我很乐意深入讨论其中任何一项。我们正在沿着这五个方向，以非常系统的方式推进，几乎是逐步铺垫，最终抵达你问题中提到的最后一个方向。

Eira May：好的。我很想从头开始，请你为我们再详细拆解一下。

Vivek Raghunathan：很乐意。我认为内循环在某种程度上是最容易理解的，因为从根本上来说，编码智能体能让你更轻松、更快速地编写更多、更好的代码，对吧？

Vivek Raghunathan：我们一开始采取的方法，很大程度上源自 Andy Grove 曾经说过的一句话。我想这句话现在非常流行，经常被人反复引用。他说，面对任何平台级转变，你都需要先让混乱充分发生，然后再去控制混乱。所以我们最初采取的方法就是：让混乱充分发生。养成习惯很难，打破习惯也很难。我们鼓励大家使用编码智能体，而且只衡量采用率。我们不衡量代码行数，不衡量 PR 数量，也不衡量任何这些很容易被人为操纵的指标。我们只衡量：你每天是否使用两次？是否有 95% 的人每周都会使用？

Vivek Raghunathan：我们会鼓励你用它编写代码、审查代码、理解代码、撰写设计文档，以及完成各种工作，对吧？我们会为你提供所有可能的工具。你想用任何工具，我们都不会拒绝，对吧？很明显，这个阶段更多是在让混乱充分发生，而不是控制混乱。这就是第一步。

现在，混乱已经充分发生了。很多人都在使用编码智能体。我们有 95% 的工程师每周都会活跃使用它们，我想准确数字是 97%。但他们使用这些工具时，效率都一样高吗？这是接下来要问的第二个问题，对吧？每天用它节省 20 分钟，和用它完成 80% 的工作，两者之间存在巨大差异。我认为，区分“正在使用编码智能体”的人和“已经掌握编码智能体、能够有效使用它”的人，关键就在于 14 种 AI 设计模式。我是非常有意地使用“设计模式”这个词的。对于软件工程行业的从业者来说，我们都知道“四人帮”和那本包含大量设计模式的书，比如工厂模式、命令模式，等等。那本书几乎创造了一套语言，用来描述应该如何思考，才能更高效地编写软件，对吧？我认为，人们使用编码智能体的方式也会经历类似的过程。

所以，截至目前，我们大概发现了 14 种模式。我从零开始编号，因为你身处 Next，而这些模式代表了我们最无畏的探索者——也可以说是我们的“AI 统领”——所发现的有效使用编码智能体的方法。这些人正处在技术最前沿。下面我举几个模式的例子。

Eira May：好的，我很想听。请介绍一个。

Vivek Raghunathan：模式一叫作“用自然语言制定计划”。它的意思是，先进行规划，在编码智能体中使用计划模式。先用 Markdown 明确计划是什么，然后再编写代码，对吧？等我们……我很乐意在笔记本电脑上演示给你看。我们还为这 14 种模式制作了一套 XKCD 风格的漫画，以便在组织内部轻松传播这些知识。我记得模式四叫作“把你的机器人隔离起来”。它的意思是，你可以只用一个智能体，但这样速度会比较慢；你也可以启动一批智能体，让它们协同工作，但这样又会陷入混乱；或者，你可以使用 git-worktrees，让每个智能体彼此独立地运行，对它们进行一定程度的隔离，让它们分别处理任务。这可以大幅提升我们大多数工程师的生产力。

Eira May：明白了。也就是从混乱中建立秩序。

Vivek Raghunathan：从混乱中建立秩序。

Vivek Raghunathan：模式八是我所说的 TLA 模式，也叫 TLF 智能体模式。你的编排器，也就是你正在对话的智能体、主智能体，绝不会持有大量上下文。它会把工作委派出去，使用某种形式的智能体团队来实际完成任务。因此，它的大脑始终有余力与你交流。模式十一和十二——或者说十二和十三——是新的模式。它们是围绕持续学习展开的。这些模式认识到，你可以挖掘记忆，并在夜间将其提升为技能；随着你的使用，系统会由此变得越来越好。如果以多人协作的方式来做，让团队中的每个人都参与其中，就能充分利用团队的集体经验。现在，这 14 种模式中的每一种，都是我们最优秀的编程人员、最优秀的 AI 前沿工程师正在使用的模式。于是，我们有了这 14 种模式，也就有了一套共同语言，可以用来讨论如何提升工程团队的技能，或者说如何让他们掌握新技能。完成这一步之后，就可以进入我所说的第三阶段，也就是控制混乱。对吧？

Vivek Raghunathan：到了这个阶段，你会采用其中一些已经铺好的模式，并思考：如何让组织里更多的人使用它们？我们发现，最有意思的方法其实很简单，就是为他们专门腾出空间和时间。为此，我们会举办所谓的“专注周”。我们会相当定期地开展这种活动，在这一周里，组织中的每个人都会从日常工作中抽出时间，专门研究和探索这些东西。这有两个目的。组织里大概 95% 的人属于我所说的“利用者”。这个词听起来可能很有攻击性，但它表达的意思其实非常简单：他们只想知道哪些是已经铺好的路径，然后直接使用。

Vivek Raghunathan：对吧？

Eira May：直接把好东西给我就行。

Vivek Raghunathan：直接把好东西给我。我不想经历所有这些学习过程，只想直接使用。对吧？

Vivek Raghunathan：我的博士研究方向是强化学习，所以“探索与利用”对我来说是非常常见的概念。因此，这些人就是“利用者”。组织里有 95% 的人，他们需要时间去利用这些成果。他们不了解这些模式，会说：“我太忙了。”而组织中另外 5% 的人，则是我所说的“无畏的探索者”。正是这些人在铺路、创建这些最佳实践。他们会自己挤出时间：周末做，晚上做，甚至有时候和朋友出去玩时，还在忙着把一个移动应用接入 Cortex Code，然后折腾各种东西。这些用户、这些工程师所需要的，只是专门用于探索的时间。因此，我们会给他们这一周，让他们去探索……我把这称为“抬高下限和提高上限”。对第一类人，我们是在抬高下限；对第二类人，我们是在提高上限。这些还只是内循环。

Eira May：我喜欢这个说法。

Vivek Raghunathan：对吧？

Vivek Raghunathan：这样做的结果是，以我们目前的大致情况来看，97% 的工程师每周都会活跃使用编程智能体；代码产出同比增长了大约 1.5 倍，与三年前相比可能增长了 3 倍。还有合并代码所需的时间之类的指标——我们知道，高绩效团队的特征之一就是能够快速审查代码。他们就像一支乐队，彼此即兴呼应。

Eira May：是的。你开始看到这些成果不断叠加，然后……是的。

Vivek Raghunathan：所以，这类指标全都在向右上方增长。每一项指标都提高了 1 到 2 倍——

Vivek Raghunathan：……这还只是内循环，对吧？

Vivek Raghunathan：我说过一共有五个阶段。这还只是内循环。

Vivek Raghunathan：在外循环方面，我们正在使用 AI，从根本上重新思考外循环的每一个步骤。我认为外循环包含三个步骤，对吧？第一，我们能否更快、更好地发布代码？第二，我们能否进行更严格的测试？能否拥有数量多得多、质量好得多、覆盖率高得多的测试？第三，我们能否更聪明地调试？对于第一步——这一点对我们的客户非常重要——我们的客户是企业客户，我们并不是一家面向消费者的初创公司。我们的客户对时间表有明确要求。

Vivek Raghunathan：我们的客户希望永远不要有任何 bug 进入生产环境，而作为软件工程师，这一点很难做到。

Eira May：是的，这个要求确实很高。

Vivek Raghunathan：但在去年的这个时候，我们还需要花费……我们会对完整版本进行广泛的验证。我们会运行数十万个任务，一遍又一遍地执行所有性能基准测试，确保没有任何指标出现退化。客户的具体查询也是回归基准测试的一部分，他们会把自己的内容贡献进来。对于所有可能覆盖的情况，我们覆盖了其中的 90%。这些工作过去需要花费长得离谱的时间。比如去年的这个时候，我们批准一个版本需要 15 天。我们的许多同行发布版本的速度都非常慢。我之前所在的是一家消费级公司，我们过去会非常频繁地发布。因此，在过去 12 个月里，我们把验证时间缩短到了一天。这其中很大一部分归功于更好的工具和更严格的工程纪律，但也有很大一部分来自对编程智能体的使用：它们可以自动处理这样的流程：“哦，我们发现了一个 bug，这是阻塞版本发布的问题。”接着，它会诊断发生了什么，甚至可能自动在 GitHub 上提交一个 PR，然后让负责这段代码的人查看并确认：“这个问题修复了吗？是否修复了我看到的问题？”通过这种方式，我们把时间从大约 15 天缩短到了一天，同时仍然能够安全发布。昨天 Christian 宣布的所有功能，都可以照常发布。测试数量增长了大约 3.5 倍。LM 让编写测试变得非常容易，所以大家都充分利用了这一点。我记得其中一种模式——可能是模式二——基本上就是：先使用编程智能体为你的功能编写测试，然后再编写代码，对吧？

Vivek Raghunathan：这相当于对十年前测试驱动开发的一种全新演绎。各个团队一直都在这样做。当然，这些测试的数量增长了 3 倍。这意味着，尽管我们的速度变得更快……有人问我：“如果你们的发布周期更短、发布速度更快，这是不是意味着质量正在退化？”

Vivek Raghunathan：答案是否定的。实际上，我们的发布也变得安全得多，进入生产环境的 SK 补丁少了很多。最后是可观测性和调试，对吧？

Vivek Raghunathan：我们正在彻底重新思考这方面的工作。我们有一千名工程师，截至目前，他们大概已经编写了 7,000 项技能。这里的核心洞见是，AI 让我们能够彻底改变运维生命周期，因为大量运维知识产权都困在工程师的脑子里。我称之为团队的集体经验。比如，这个告警触发时，应该执行这个操作。

Eira May：确实。对，是的。

Vivek Raghunathan：因此，我们可以把大量通常被称为运行手册的内容——这类文档很快就会过时——改造成可进行版本管理的技能 CI/CD 工作流。它们是 CoCo 编程智能体的一部分，并被打包到称为“配置档案”的单元中。例如：“哦，如果流式处理出了问题，这就是调试该问题所需的一组技能。”

Vivek Raghunathan：所有客户问题都有一项影响范围技能，用来判断哪些客户受到了这个问题的影响。

Vivek Raghunathan：对吧？这样做的第一个好处，是把团队的集体经验编码进可重复执行的工作流中。原本存在于人们脑海中的复杂、确定性工作流，现在可以交给 LLM。第三件可以做到的事情是：值班真的很烦人。我的大多数团队都不想值班。

Eira May：是的，这确实不是什么受欢迎的工作。

Vivek Raghunathan：所以，这大大减少了繁重的运维工作。我们所说的 KTLO 目前大约占 30%，而我希望把它降到 5% 左右，对吧？我认为自己已经找到了一条实现路径，也许不是今天，但可能几个月后就能做到。我们发现，与生产环境和编码智能体协作的团队大致会经历一个四步成熟度模型。首先，他们会编写大量技能，把那些再也不想遇到的问题全部编码成 Cortex Code 可以使用的技能。其次，他们会采用事件驱动 AI，把它接入 PagerDuty、Slack 或类似的系统，这样它们现在就可以……第三，他们开始处理复杂工作流，并使用 LLM 对这种多步骤推理过程进行编码：去联系支持团队，让他们和客户一起完成这件事；再去做另一件事；然后在 Slack 上通知某个人。第四，也是我之前提到的，就是持续学习。因此，当你在事故处理或值班调查中发现新情况时，就把它重新编码进编码智能体所使用的技能中。到目前为止，效果相当不错。我们的愿景是让智能体承担主要值班工作，然后让人类负责二线和三线值班，或者反过来也可以。你可以让其中一个值班角色——分诊人员——由一个智能体担任，先于你处理问题，这会立刻减少实际工作量。我希望工程师们会说：“我喜欢值班，因为它很有趣。”而不是：“哦，这就像是某种我”——

Eira May：对。就像他们会很兴奋地投入问题处理。

Vivek Raghunathan：是的。而不是那种：“我只想每九周值一次班，因为那是我整个季度里最糟糕的一周。”对吧？

Vivek Raghunathan：这大致就是我们对外循环的理解。产品方面仍然处于不断完善之中。如果你看过 Snowflake CoCo 和 Snowflake CoWork，就会发现我们正在这些产品中尝试用完全不同的方式打造产品。我们发现，小型且被充分授权的团队运作得非常好。

Eira May：我正想问你这个，因为我知道你谈到过单个工程师的影响力，希望最大限度地提升团队中每个人的影响力；你还谈到过，有些人确实能够突破边界，真正深入地试验这些智能体。你觉得……我想问的是，你会如何提升单个工程师的影响力，同时又不让 AI 以某种方式抬高所有人的门槛，最后反而让每个人都处于同一个……

Vivek Raghunathan：是的。我的意思是，这是个非常好的问题，对吧？

Vivek Raghunathan：在我看来，每一次重大变革中都会有先驱者，就像 Lewis 和 Clark 那样的人，他们会出发探索。然后是定居者，也就是那些跟随探索者或先驱者进入新领域的人。

Eira May：是的。他们会在那里安顿下来，并把基础设施建设起来。

Vivek Raghunathan：然后还会有怀疑者，对吧？也就是抵制者。他们甚至可能不是在显性地抵制，而是在隐性地抵制，对吧？对我而言，非常重要的一点是，我们要根据每一类人当前所处的位置与他们交流。有人走进我的办公室对我说：“嘿，我今天经历了接受现实的七个阶段。”然后，他们一夜之间就从隐性的抵制者变成了先驱者，对吧？

Vivek Raghunathan：所以，我们会根据每个人当前所处的位置与他们交流。我认为，当下的现实之一是，我们中的很多人已经变得非常擅长某件事。我的意思是，如果你花了一辈子把某件事做到极致，然后突然遇到一个 DT，它和你一样出色，甚至比你更出色，那么你就难免要经历某种“悲伤的七个阶段”，如果可以这么说的话——

Eira May：是的。我觉得，你必须换一种方式思考自己的价值。没错。

Vivek Raghunathan：我认为，软件行业的很多人都正在经历这个过程，而我希望根据他们当前所处的位置与他们交流。我想带着他们一起踏上这段旅程。你之前问过我，在这样的世界中，领导者的角色是什么。此时此刻，我会说，领导者能做的最重要的事情就是身先士卒，向大家展示如何走上这段旅程：先直面并处理自己的情绪，确保自己已经站在先驱者的位置上，然后再带领团队一起前进。可以说，现在是轻骑兵冲锋的时刻，而不是躲在后方指挥，对吧？

Eira May：是的，是的。说得很好。

Vivek Raghunathan：所以，正如你所说，我们发现识别先驱者其实很容易，因为他们就像走进糖果店的孩子一样。他们会说：“嘿，我周末发现了这个东西，还用它做了这么多东西。我现在就需要占用你一个小时，向你介绍这一切。”然后我会问：“等等，这件事很紧急吗？”他们会说：“不，这件事极其紧急。”接着，他们就会向你展示自己正在做的事情。因此，他们很容易主动显现出来。他们的工作表现也会发生变化——突然之间，他们仿佛神奇地变成了过去一百倍那么高效。你很难注意不到他们，对吧？

Eira May：确实，确实如此。

Vivek Raghunathan：他们并不总是那些在编码智能体出现之前就被你认为是百倍工程师的人。现在被放大的是一套不同的能力：好奇心、适应能力，以及学习意愿。

Vivek Raghunathan：所以，他们很容易被识别出来。我也希望把那些我称为“95% 正在利用现有成果的人”一起带上。因此，我们不把这件事看成非此即彼的二元选择，而是把它视为一条连续的光谱。你遵循的那些我刚才提到的最佳实践越多，你在这条光谱上就走得越远。我们内部开玩笑地使用一套以 Steve Yegge 命名的 Yegge 量表：你是 Yegge 五级，还是 Yegge 七级？我甚至几乎直接对团队说：“我们需要让组织中的 Yegge 七级人数增加到原来的五倍，让更多人达到这个水平。”这并不是说我们会神奇地把这些人招聘进来，而是说，我们会帮助那些处于 Yegge 三级的人，让他们更接近 Yegge 七级。

Eira May：让他们完成转变。是的。顺着这个话题，我想到最近和许多节目嘉宾讨论过的一件事：智能体式编程和凭感觉编程所承诺的愿景，开始遭遇规模化的限制。我的意思是，从你的角度来看，考虑到 Snowflake 所面对的规模环境，你们是否发现两者之间确实存在很大的差距……对。

Vivek Raghunathan：不，我们没有发现这种差距。如果一定要说的话，我们看到的是，编码智能体到了合适的人手中，可以创造出惊人的成果。你昨天听到 Christian 谈过交互式编译器。他谈到重写我们的编译器。你可以把编译器称为任何查询引擎的大脑。人们会为它投入大量心血和汗水，查询引擎的大部分核心秘诀也都蕴含在其中。我们的编译器通常是我们实现最困难功能的地方。因此，当你看到类似 Iceberg 支持、动态表功能或 Unistore 功能这样的工作时，它们全都需要……或者说，这些功能都需要时间，因为编译器相关的工作必须谨慎而细致，有时甚至非常艰苦。

有时编译器本身就是很慢，而当你处理交互式工作负载时，这一点非常重要，比如你们的一些听众可能会使用 ClickHouse 处理的那类工作负载。像 Snowflake 这样的分析引擎无法开箱即用地很好处理这些工作负载，其中一部分原因就是编译时间可能相当长。因此，如果查询本身执行时间很短，但编译时间很长，那么在真正执行查询之前，就会先承担一大堆固定成本。

于是，负责这项编译器工作的技术负责人说：“嘿，我准备找三个人。我知道，如果必须重写这个编译器，我会做哪些事情；我们将使用编码智能体来重写它。参与者包括我、一组编码智能体和三名工程师。”但这些工程师全都是领域专家。他们所要说的……