a16z：AI能写代码，为何还难以运维生产系统
点播放，字幕跟着声音走
Subtitles follow the audio
逐句文字稿
点任意一句，从那里开始听
正在加载字幕…
-
AI所处的世界全是数字化的，而这是真实世界，这两者并不一定是一回事。
-
我们刚开始做AI编程的时候，那还只是自动补全。
-
当时没人真正知道，用AI到底能构建多复杂的软件。
-
后来它基本上超出了所有人的预期，因为我们能在系统里建模越来越复杂的逻辑。
-
我只是不确定运维是不是也受同样的限制。
-
甚至说，数据在哪儿？怎么学会去构建一个能理解所有运维环节的系统？
-
我的假设是，数据我们都有。
-
我觉得问题可能在于复杂度。
-
还有就是，你描述的那些运维上的东西，到底能在多大程度上转化成AI可以推理的形式？
-
很长一段时间里，跑分布式集群的肮脏秘密就是靠人来管。
-
你觉得我们现在到了能用AI来跑这类服务的阶段了吗？
-
我觉得已经足够了，能够……
-
好了，Jed，感谢你来参加播客。
-
不认识的朋友说一下，Jed是Grepr的CEO，而且我们研究生是在同一个组。
-
我第一次见到你的时候，组里来了个新生，我走进办公室，看到一个摩托车头盔和一包万宝路。
-
我心想，这家伙肯定酷得不得了。
-
所以我的问题是，你的酷劲儿都去哪儿了？
-
第一个问题。
-
也许先给大家简单介绍一下你的背景。
-
跟听众说一下，Jed是我认识的最厉害的系统思考者之一，我特别喜欢跟他聊天。
-
我们打算深入聊聊从系统的角度看工程，以及AI正在怎么影响我们。
-
我们尤其会聊到运维这类事情，不过为了打好基础，也许先简单说说你的背景。好。
-
所以，你是在我最酷的那段巅峰时期认识我的。是啊，你当时特别酷。
-
摩托车，还有万宝路香烟。
-
我记得当时心里想，哇，香烟这东西居然合法？
-
感觉特别违和。
-
我记得有一天Nick看见我在Gates楼外面抽烟，他看着我的表情就像……
-
Nick McKeown是我们的导师。
-
Gates是那栋楼。对。
-
其实我最喜欢的一件事，你还记得Balaji Prabhakar教授吗？当然记得。
-
我最喜欢他的一点是他抽烟。
-
他好像是唯一一个抽烟的教授。
-
我就觉得特别棒。
-
先说清楚，我现在不抽烟了。
-
不行了，太老了，这把年纪不适合了。
-
不过话说回来，我是跟你一起在斯坦福的。
-
你一直是我仰望、崇拜的那个人，我心里想，嘿，我长大了就想成为这样的人，因为我比你早入学四年。
-
对，所以你比我高四届，比我早毕业好一阵子，你去创办了Nicira，我留下来继续待着，更多做OpenFlow方面的工作，在硬件那边从安全角度参与搭建了不少东西。
-
其实我在那儿做过的最有意思的项目之一，是我做了第一批SHA-3实现，当时大家在考虑用哪些方案。
-
我把它们做成了硬件，用来展示它们到底行不行之类的，那是我论文里的一个项目。挺有意思的。
-
后来我决定，其实我不喜欢网络，因为它无非就是把比特从一个地方搬到另一个地方。
-
这能有多难呢？
-
他要么在理念上认同这件事很深刻，要么就不认同。大多数人觉得它不深刻。我觉得它非常深刻。
-
我是说，这里面确实有点意思，但对我来说，最终还是……对，它打动不了你。对，对。
-
后来我真的去了MIT，跟Nikolaj Zeldovich做博士后，他也特别有深度、特别聪明。对，他非常厉害。
-
那时候我做了一些应用安全方面的工作，还基于我在那边跟Ramesh Chandra一起做的一些研究创办了一家公司，他当时还是个博士生。
-
但最终这项技术太超前了。那是什么技术？
-
我们做的是，嗯，你知道，最终很多工作其实都是Ramesh做的。
-
他的博士研究是关于，嘿，如果你被攻击了、被利用了，但你能不能恢复过来，把跟那个应用相关的整个世界的状态回滚，然后再把它叠加到打过补丁的应用版本上，从而消除那个漏洞利用？
-
于是我们开始在真实世界里做这件事，然后我们就想，唉。
-
听起来真的很难。
-
这其实跟我们正在聊的话题挺相关的，就是你能在多大程度上真正界定运行系统的状态，我觉得这非常难。
-
不过对，我们差点就让它跑起来了，就差一点。
-
我觉得对所有长尾学科来说，这就是为什么聪明人会陷进去。
-
就是你看到了一点进展，但你其实是在渐近线附近徘徊。不过算了，我跑题了。咱们继续。
-
咱们继续聊你的，呃，然后我就加入了AppDynamics。
-
我在那儿待了大概三年半。
-
公司从大约200人发展到2000人，然后被Cisco收购了。
-
我当了一天Cisco员工。
-
然后我就看到，接着你就说，Jad，你来跟我干吧。
-
来跟我一起做VC这摊事吧。
-
我说，什么鬼……VC是什么？我可是个架构师啊。
-
我干的是工程方面的活儿。他怎么说？他说，太好了，你知道得越少越好。真的，就是你原话。确实是这样。
-
然后我来这儿上班第一天，你就说，慢点来。
-
其实从实际做运营转到VC，这需要大脑做很多重新调整。是啊，是啊。
-
就像从读博士转到做运营一样，顺便说一句，我觉得你得先把脑子里的损伤修复过来。
-
真实世界就是这样。
-
然后，嗯，我在这儿待了几年，跟你做了不少工作，那段时间真的很有意思。
-
跟很多很棒的人共事，比如Jennifer、Mark和Ben。
-
Satish，嗯，我第一次来的时候Matt也在这儿，差不多是我快走的时候了。是啊。
-
后来我加入了Apply做首席产品官，帮他们搭建工程和产品团队，从大概15个人扩展到90多人，涵盖产品、工程、信息安全和设计。
-
大概三年之后，我负责的每一块都有了自己的负责人，我就基本是坐在那儿协调、整天开会，就想去做点别的事了。
-
所以就离开了，然后开始跟很多工程负责人聊他们面临的问题和想做的事。
-
当时所有人，那是23年，所有人都在说，嘿，我们想削减开支。
-
那你问他们，钱都花在哪儿了？
-
大家都会说，可观测性。
-
而且，你知道，其实一开始是基础设施，然后才是可观测性。
-
所以我开始研究这个问题，想搞清楚，为什么大家觉得它太贵了？
-
结果发现有几个原因。
-
首先，人们在可观测性上的花费大概是基础设施花费的5%到20%，但说到底，他们真正想花钱买的是可靠性。
-
他们想买的是可靠性，还有——是支出的可预测性吗？
-
是他们基础设施和应用的可靠性。我明白了，明白了，明白了。
-
所以他们把钱投在可观测性上，把它当作可靠性的替代指标。
-
在当时，你花的钱越多，得到的可靠性就越高。
-
但随着架构发生变化，变成了小得多的微服务，垂直整合程度也高得多，每一层收集的数据量都在膨胀，
-
可观测性的市场渗透率大大加深了，而你收集的数据量和可观测性的成本，实际上开始比你产出的功能单元增长得更快。
-
而且，嗯，你在可观测性上每多花一美元所带来的可靠性边际增长，也就是边际增长率，正在趋于平缓。
-
嗯，所以这就是为什么大家觉得它贵，但人们仍然愿意把5%到20%的钱花在可靠性上。
-
所以问题就是，我们能不能真正解决这个问题，把那种可靠性的提升、那种边际可靠性的提升找回来，不一定是靠多花钱在可观测性上，而是靠别的办法。
-
所以当时的想法就是，好，太好了。
-
如果我们能搞清楚什么是信号、什么是噪声呢？
-
我们能不能把你正在收集的可观测性数据——这些数据现在大多是冗余信息，大多只是买个保险——真正做一次上游的信息提取，在上游该做什么就做什么，最终能够大幅降低下游可观测性的成本。
-
如果你能在上游实时提取出那个信号，那么第一，你可以降低成本。
-
第二，你现在可以把它喂给其他系统，用来驱动后续的可靠性运维。
-
而当时，有个叫AI的东西开始进入视野。我们就想，太好了。
-
如果我们处在数据流当中，而且在提取信号，那我们就处在一个战略位置上，可以把它喂给未来出现的任何东西，因为那将是必需的。所以这就是我们做出来的东西。
-
嗯，所以Grepr帮公司，你知道，我们一开始是帮他们大幅降低遥测方面的支出，你把我们放进数据流里，即插即用，让数据流经我们，成本降低90%。
-
嗯，现在我们正在构建第二层，把这些信号喂进AI层，AI层现在正进入故障排查，判断哪里出了问题并修复它们。
-
我很想聊聊你在AI如何改变开发这件事上的经验，这个问题很多人都能问，很多人也能答，但我总觉得，工程师就是工程师。
-
你当过架构师，管过产品，也带过工程团队。
-
你们公司现在多大了？有多少人？我们10个人。对。
-
所以你们是用一个相对精简的团队在做大量的软件。
-
那也许可以先大致勾勒一下，比如，像你这样有架构经验的资深工程师，你觉得大家能看到什么样的收益，也许可以讲讲你是怎么用AI的，你实际看到了哪些收益，技术栈是什么，你的流程是什么，
-
你是怎么考虑这些的。
-
那也许我可以给你一个历史视角，讲讲在带团队这些方面都发生了什么。
-
我们最开始用AI的时候，还基本只是自动补全。
-
我记得当时我们在IntelliJ里用Copilot，我们说，天哪，你看，它把这些测试自动补全了。
-
我们说，是啊，但它只是自动补全而已。
-
然后很快，事情就开始演变了。
-
我注意到的是，真正优秀的工程师能够以某种方式把它融入自己的工作流，让AI反过来开始训练他们。
-
哦，有意思，比如怎么跟它对话，怎么从它那里得到最好的结果。
-
顺便问一下，你觉得这是跟具体模型相关的吗？
-
就是说，你是学会了怎么用AI，从大面上说，还是说你会对某个特定模型变得很熟练？
-
我觉得不同模型确实带来一些细微差别。
-
嗯，你肯定也在看你的推文，嗯，是有一些细微差别，但跟AI协作是有方法的，而且我觉得跟不同的工具框架协作也是有方法的。
-
我觉得，你知道，我们试过比如用open code或者不同的框架，或者用codex对比Claude，比如Claude Code，不同的工具有不同的方式管理上下文、思考问题、什么时候启动合适的子代理、该告诉它什么，
-
比如提示词的类型。
-
比如用Claude Code，我发现如果我不告诉它别启动20个子代理去做基础调研，它就会去启动20个子代理做调研，把你的token全烧光。
-
所以很多这些东西，你开始了解这个框架、这些模型，以及它们之间怎么互动，然后它们怎么跟外部世界互动。
-
但我跑题了，我就先。
-
在我看来，我一开始注意到的就是，有些人能适应、能学习，用这种方式去做，而另一些人就没那么强的适应力。
-
后来随着我们往团队里招更多人，普通工程师和真正优秀的工程师之间的差距就直接放大了十倍。你能预测谁会、能预测谁会成为好工程师吗？
-
是那种好工程师变得更好、差工程师没变好吗？
-
还是说其实还行？对。
-
所以就是说，如果你是个好工程师，你只会变成更好的好工程师。
-
并不是说有什么差工程师突然就变成好工程师了。
-
不不不，归根结底，你必须真正理解整个架构，因为你的大脑能处理的复杂度越高，你就越能把任务拆解开来，而且我觉得这其实可能是个，呃，算是非共识的观点吧，
-
呃，我是说，我有时候确实会听到这种说法，就是好工程师要好得多，这种人更少，而你发现这基本上是普遍成立的。
-
我是说，你看，我的团队还很小。
-
我们还没在上百人的规模上验证过，但就我的经验而言，对于我们做的这些事情，情况确实如此，因为我们做的是分布式系统和分布式算法。
-
你的大脑必须能处理这种复杂度，因为AI处理不了。对。
-
所以对于我们解决的问题，没有任何一个模型能真正想清楚我们做的那些事情。
-
比如有很多，我们有一个查询翻译层。
-
我们刚才就在聊查询优化。
-
所以你必须真正理解查询的语义，理解怎么得到查询的语义，然后把它解释给模型，再让模型去构建这个翻译层，比如说。对。
-
那么对于可能不太深入了解计算机科学的听众来说，你说的语义是什么意思？
-
语义其实就是事物的含义。
-
比如“狗”这个词的语义，就是那种四条腿走路、会汪汪叫的动物。
-
而语法就是它只是一个三个字母的词，由三个不同的字母组成。
-
这个词的形状是不一样的，而且不同单词的形状也可以不同。
-
但不同的词其实也可能表达同一个意思。
-
所以它们可能语义相同，但语法不同。
-
所以 dog 和 puppy 的语义可能略有不同。
-
它们指的是……但它们太接近了。
-
所以在计算机科学里，我用很简单的方式描述就是，语法就是你敲进去的那些字符，而语义就是机器实际做了什么，对吧？
-
所以它就像是系统实际的运行时特性，所以你看，计算机科学……我学的是电气工程。
-
你成了计算机科学家，而我成了风投，所以这就是我看到的问题所在。
-
总之，我只是想让正在听的人明白，有实际的语法，也就是写代码，你知道，我们聊语法的时候，说的就是代码本身。
-
然后你聊到语义的时候，你 literally 说的是你有一台机器来解释那段代码，不管它是不是编译过的，然后那台机器做了某些事，语义就是机器实际做了什么。
-
而这些东西，你知道，显然是非常不同的，对吧？
-
比如说，有些语义你光看语法根本推不出来。
-
你不知道机器会做什么，因为……反正你就是得测试它。你得测试它。
-
而且你测试的时候，它可能走向各种不同的结果。
-
一个非常经典的例子就是 SQL。
-
你可以写一条 SQL 查询，但它实际怎么执行、执行多久，完全取决于比如 schema 长什么样，或者数据库里的数据长什么样，等等。
-
但那个，我不会把它叫作语义。
-
我会把它叫作性能特征。哦，当然。对。
-
我觉得那更像是……我会说那里面语义的部分是，取决于数据的形状或者配置，你最后可能会得到不同的语义，因为就像你说的，你希望 null 被当作 false 处理。
-
而除非你也知道系统的配置等等，否则你是不会知道的。好。好。
-
所以为了这次对话的目的，我觉得我们就这么说吧：有你实际在写的代码，有系统怎么运行，我们把第二个叫作语义，这样我们才能聊下去。
-
那你想怎么称呼它们？
-
我们需要深入探讨一下这里的语义，确保它们清晰明确。
-
因为有很多——我知道。好。好。我们就保持在高层面上聊。好。
-
那我们回到正题。
-
其实在开始录播客之前，你我就在随便闲聊。
-
你当时说到，现在你能做一些产品、项目，一周就能搞定，而过去需要一个团队花好几个月，你能不能给我们大致讲讲，你个人是怎么做项目的，以及你看到的收益。
-
就是稍微讲讲你的流程？
-
我用的是 Cloud Code。
-
我要说一件挺有意思的事，我用的是 Windows。什么？
-
那是这家公司微软做的吗？
-
而且我用 WSL。
-
所以，我所有东西都用 Linux，比如开发之类的。
-
它没有图形界面之类的。
-
我就用命令行。
-
但你怎么会用 Windows 呢？
-
因为我就一直没真想过去学那些键盘快捷键。你是游戏玩家吗？
-
就像你切到 Counter-Strike 之类的。
-
不然还能为什么？
-
我不是在吐槽 Windows。
-
我是说，你知道，我 90 年代用过它。
-
真的，唯一的原因就是我一直不想去学那些快捷键。
-
我讨厌那个单键鼠标。
-
我讨厌那种只有一个键的东西。
-
我讨厌那么多修饰键。
-
你得敲键盘才能用快捷键什么的。
-
我就是，我就是一直没，我就想，为什么，为什么，为什么要浪费时间？
-
所以我就想，行吧，我用 Windows。对。
-
嗯，然后 WSL，我用 cloud code。WSL 是什么？
-
那是 Windows 的 Linux 子系统。
-
所以它其实是，他们把 Linux 内核跑在 Windows 里的一个虚拟机管理程序里，然后给你访问权限。特别好。他们做得非常棒。很棒。
-
Windows、WSL 和 cloud code。
-
然后我最近，最近在做的就是我用 Opus 5.5。
-
我跟它说，这真是个很好的模型。是个很厉害的模型。真的很好。
-
然后，过去两周我提交了这些超大的、20 个 PR 的东西，我直接扔给我团队去审。
-
他们就说，我就说，别担心。听起来挺吓人的。
-
就像新的汇报结构一样，下面的人给 CEO 审 PR。
-
我们已经变成这样了吗？
-
不是，大家都是在写同样的东西。大家都在写。
-
对，我审我手下人的 PR。
-
然后大家就是 PR 满天飞。低头皱眉看 PR。对。
-
不过，评审流程里变化最大的一点是，我们现在更关注测试，更关注像黄金预期这类东西，还有它们是不是在以不同的方式发生变化，等等。
-
但 Opus 5，还有我最近学到的一个技巧是，你不用子代理，而是直接让 Claude 启动命令行子代理，因为那些子代理会一直保持它们的助手会话。
-
所以你可以让它把这些代理分别启动起来。
-
你实际上可以从其他会话里运行它们，等等。
-
这样一来，从上下文的角度来说，你的效率就高多了。你同时跑多少个代理？
-
多少个，多少个，多少个代理，代理？
-
通常我同时开三四个会话窗口，因为我发现再多的话，我在不同的事情之间就开始丢上下文了。因为它们会更快地完成，然后我就，然后它们就在等。
-
那它们是通过 PR 来交互的吗？子代理之间是怎么协作的？
-
不是，它们直接通过命令行交互。哦，哇。好。对。
-
所以我会让主调用，也就是负责实现的那个主代理，配一个技术负责人来做评审，它们基本上就是互相提问。这个说得通吗？
-
这个说不通吗？
-
评审一下我的 PR，等等。
-
然后它们就一起在这些 PR 上迭代。
-
然后它们会有一份 PR 文档，基本上就是一份设计文档，里面什么都有，它们一起在上面工作。
-
我做的第一件事就是让那个代理去做，让技术负责人去评审这份 PR 文档。
-
我会过一遍 PRD，过一遍设计文档，确认它说得通。
-
然后详细地过一遍每一部分，确认所有算法都能跑通，所有部分都能跑通，分工是合理的，PR 之间的划分以及它们之间的关系也是合理的。
-
然后我就告诉它，直接开始做吧。
-
看看有没有可以并行处理的地方，然后启动其他代理去实际执行。
-
但最终你还是得把所有东西放回一个整体里，能够作为人一个一个地过一遍，因为否则就会变得又乱又杂，你根本没法处理。
-
那大概要花多少时间，你能不能举个例子，说说你现在做的一个项目和，我也不知道，六年前相比，时间上差多少？
-
我最近交付的那个项目大概是……
-
顺便说清楚，这可不是闹着玩的，这是生产代码。对，这是生产代码。
-
你接下来要说的，就是你在交付产品上获得的那些提升。
-
那我给你举个例子，就说我最近做的那个，最近那个 PR，或者说最近那一组 PR，是我们所谓的自动提升和数据湖。
-
在数据湖里，你存储所有数据，通常数据是列式存储的，parquet 文件、iceberg 之类的。
-
而当你从日志里拿到数据时，它们是非结构化的，列是任意的，所以为了获得最佳的数据布局，能够高效快速地查询，你基本上得……
-
理想的情况是，日志事件里的每个字段都变成一个列，你可以独立于其他行对它进行过滤。
-
我们把这叫做自动提升或者拆列。
-
做这样的事情极其复杂，对吧？
-
比如你得去搞清楚元数据系统是怎么工作的？
-
元数据系统的提交是怎么工作的？
-
你怎么在不同的写入者之间做协调，等等。
-
嗯，那大概花了 10 天，而以前的话，一个人大概要花六个月。哇。就你一个人做的？
-
就我一个人。太疯狂了。
-
是啊。
-
所以对于新产品的生产代码来说，我们大概是 10 倍、20 倍的提升。是的。
-
你知道，我总有一个疑问，就是我很能理解，这些模型是在有史以来写过的所有代码上训练出来的，可以这么说，对吧？
-
所以我能理解为什么它们能生成代码，那是语法层面的东西。
-
但接下来，比如你在做核心基础设施，假设是分布式算法，那些属性，比如它在运行时如何自我处理，是非常非常不同的。
-
很多时候，你光看那些语法，根本看不出会发生什么，对吧？
-
比如说，很多时候，假设你在写某个分布式系统。
-
然后它的表现方式，比如可用性，甚至正确性，都会取决于工作负载长什么样，你知道，比如访问模式是什么，流量是什么样的？
-
你是在说它的性能方面吗？
-
还是说语义方面？
-
嗯，我觉得可用性方面，你可能得加锁，所以它在一段时间内就不可用了。
-
我说的是正确性，比如你可能决定做最终一致性。
-
所以如果你做一次读，它不会是一致的，因为没有锁。
-
然后是性能，你知道，也许你做缓存，也许你不做缓存。
-
所以这些都是设计空间里的各种权衡，对吧？是的。
-
除非你知道访问模式，否则你不会知道它在这些方面会表现如何。
-
所以我就在想，好，我有一个 AI。
-
我能理解它会怎么为一个通用的分布式数据存储写代码，比如说。
-
但我不理解它怎么会知道去做那些必要的权衡，因为它连访问模式是什么都不知道。
-
而且这些东西也不是说就能……
-
甚至哪里有数据能学着去构建一个理解所有操作的系统呢，对吧？
-
就像今天，我们依赖人来管理集群，来优化数据库等等。所以你能不能谈谈你是怎么看待这个问题的，比如，我理解写代码这部分，但你面对的是这些深度的运维系统，你怎么把 AI 应用到那个问题上？
-
还有，嘿，我们到底有没有取得任何进展？
-
还是说这仍然是个没解决的问题？
-
我觉得这个问题也许跟复杂性有关。
-
那么，你在多大程度上能把你描述的那些运维层面、生产环境里发生的事情，转化成 AI 能够推理的东西？
-
具体来说，AI 到底怎么对系统进行推理？
-
好，首先，你觉得它在写代码的时候，能在多大程度上真正预测会发生什么？
-
它在这方面做得有多好？
-
第二个问题是，好，那我们怎么让它对这件事进行推理？
-
那我们先问第一个，比如，如果我用你的方法，用 JAD 方法写代码，然后构建了一个大型分布式系统，它实际上能把它做到性能正确的频率有多高？
-
它实际上在运维层面做到相当合理的频率有多高？顺便说一句，我最近就在搞这个分布式高斯泼溅，我得说它很烂，简直糟透了，因为，
-
你知道，你有数百万个高斯泼溅点，需要换页进出、流式处理，这完全取决于运行中的系统，所以是的，没有一个模型能做好。所以在我们的领域里，
-
我发现的是，我们基本上把性能基准长什么样、系统应该怎么运行、以及在我们这个流处理器里构建时要满足什么约束才能达到正确性能，都定义得非常清楚，
-
但偶尔它也会出问题，比如我最近的项目全是关于查询优化和查询性能的。
-
所以我就说，嘿，这是个典型的例子，我们基本上是在生成对应 SQL 的代码，想把它放到流水线里跑，然后我们说，好，你生成的代码很烂，修一下。
-
然后它就开始过一遍，但它一开始没意识到的是，它其实根本没对代码做任何优化。它就像，哦，这没问题啊。
-
看起来有什么问题呢。
-
我说，你看，这边有这些合取条件，你在做这些，然后这个特定的项重复了，本来应该被消掉的。
-
然后它就说，啊，好，让我来搞清楚这个，等等。
-
然后它基本上就沿着一条线索去弄清楚所有……它围绕“有哪些东西可以优化来让它更好”建立了一堆假设。
-
并且能够把这些建立在性能基准之上。
-
我就说，你看，这里有一组查询的数据集，还有用户在问什么等等，去处理吧。
-
所以它基本上用这种方式能做得相当不错。
-
但一说到比如“我该给系统多少内存”这种问题，是的，它完全没概念。
-
而这必须来自在生产环境中实际跑过的实验。
-
所以我觉得，这些系统目前在运维方面做得比较好的一点是，它知道自己大概回答不了这个问题。
-
它会想办法跑个实验，把那个信息弄出来。
-
但当然了，一说到运维，生产系统可不会按你预期的方式运行。
-
说到底这就是为什么——那你们有没有发现，你们在做那种AISRE的事情吗，就是真的有一个在跑的系统、有日志，然后你把它喂给AI，让它帮你调优之类的？有的。
-
那效果怎么样？
-
我们就是说——因为从个例来看，我了解到的别人做这个的体验并不太好。
-
我听到的那些反馈，从个例上来说，都不太好。
-
所以有这么几点，第一是我们运维和安全两方面都在做这个，但我们切入的方式跟别人从AISRE角度做的不一样。
-
很多这类系统基本上是从一个滞后指标开始的。
-
比如，“嘿，这个指标飙了”或者“这个告警响了”。
-
然后倒回去翻一个非常复杂的系统，试图搞清楚为什么会这样。对吧，是啊，当然。
-
这就是为什么那些东西不管用。
-
因为倒推根因其实问题很大。
-
所以我们反过来做，就是能不能先从判断你的环境里有没有什么东西发生了变化入手？
-
比如，我们能不能做大规模的聚类，大规模地在一堆东西里找出那个不一样的点，找出那根针？
-
然后——哦，所以你是假设它之前一直好好的，现在不行了，那就是有什么东西变了？
-
但也可能只是正常流量模式的变化，对吧？那也没问题，那也没问题。
-
所以我们关注的是，出问题的时候，系统通常会以某种方式告诉你出问题了。对，没错。
-
如果它运行正常、按正常速度扩容，那就什么都不会发生，但有时候你会看到某条消息说“错误：连接用完了”。对。
-
或者是内存超了，或者资源缓冲区空了，或者某种特别早期的预警，就是有事情发生了，而那条消息正是我们想抓住的，然后从那儿往下查，看看这是不是个真问题、需不需要我们去调查处理。那它做得怎么样？
-
到目前为止，它做得还挺不错的。
-
我是说，我们正在自己的系统里内部跑它。
-
我们在几个客户的环境里也跑过。
-
其中有几次我们忽略了它的提示，结果那些都变成了生产事故。真的吗？哇。
-
单从直觉上讲，我能理解这些模型是怎么理解语法的。
-
因为就像我说的，它们是在有史以来写过的所有代码上训练出来的，而事实证明这覆盖了很多有用的场景。
-
我其实很难想象软件的实际运行状态空间能有个边界，对吧？
-
我是说，这话听起来挺荒唐的，但它其实某种程度上是真的。
-
就好比程序每多一个比特，它们运行上能做的事的状态空间就翻一倍。
-
所以你很快就到了，你知道，状态数比宇宙里的原子还多。
-
可以说，这就是为什么，这就是为什么那种产品化的运维方法从来就没真正奏效过，对吧？
-
像混沌工程那套东西从来就没真正管用，我们一直都得靠，你知道，其实长期以来运行分布式集群的肮脏秘密就是靠人来管。
-
所以我就在想，然后，你知道，然后为了甚至训练一个 AI 来做这件事，你得有足够的数据、足够的配置，所以我有点好奇，你觉得我们现在是不是到了一个，
-
一个可以用 AI 来运行分布式集群或者运行这类服务的阶段，还是你觉得那还早着呢？
-
我觉得现有的东西已经足够让它把这个循环跑起来了。
-
我是说，归根结底，我同意你的看法，空间是无限的，有太多不同的情况，但归根结底人类也是照着操作手册来干的。
-
而且，当然，生产环境里有很多事情最终需要某个人去处理，比如，“嘿，这太复杂了。”
-
比如有些隐藏的状态我是知道的，因为我前几天在饮水机旁边跟另一个人聊过，他跟我讲了他部署的某个东西。
-
有很多东西可能并不体现在系统的状态里，但我要说，我们需要能做到的目标，就是获得足够的遥测数据和足够的理解，让一切都变得真正可见，从“嘿，
-
这就是系统现在的样子。这是它运行的方式。诸如此类的。
-
然后我觉得，最终真正在运维中暴露出来的大多数问题，假设你的系统之前运行正常，都是因为某种变更导致的。
-
如果你能专注于找出变更是什么、是什么样的变更，然后顺着这个思路走——我能就这一点问个傻问题吗，就是我从来不觉得这些擅长预测的生成模型……
-
听起来你讲的很像是预测建模？
-
比如，你预测一个变更，或者建立基线然后检测异常？我是不是想错了？
-
不，你没想错。
-
因为目标其实不是让智能体去预测，而是让它拿到一个确定性的信号，知道有东西变了。
-
这个我能看到。我明白了。对。等等，等等。
-
所以是有一个单独的模型来做预测类的事情。
-
然后它会去提醒AI。对。好。明白了。
-
所以，我们做的事情基本上就是，你把每天PB级的日志给我们。对。
-
然后我们把它们全部扫描一遍。
-
每当我们看到日志里出现一种新的模式、或者我们之前没见过的东西，我们就把它提取出来交给AI。
-
所以那是一个预测模型，它做的正是预测模型擅长的事，就是判断出异常的东西之类的。
-
然后它把结果交给AI，AI再去弄清楚到底该怎么做，所以AI基本上就能推理并把它推进下去，我可以说哦这条消息，让我实际看看代码，弄清楚它是从哪来的，理解这段代码是干什么的，让我看看它以前是不是真的发生过
-
让我看看，所以它基本上就是跑所有这些假设和启发式规则，试图理解这有没有道理、在某种意义上是不是有意义的，然后它就能决定怎么处理它。那你觉得我们离——还是回到查询优化，不是日志之类的——我们离
-
让AI基本上干人类以前在核心优化方面干的活，还有多远？我觉得非常近了。真的吗？是的。哇。我觉得……
-
运行一个分布式集群。
-
我就想到，好吧，你有像James Cowling这样的人，MIT博士，负责运行一个分布式集群。
-
而且如果集群挂了，公司就没法运转了。
-
然后只要它还在运行，就算跑起来了。我也不确定。
-
就是说，我们是不是已经到了你会说AI能干这活的地步了？不，还没有。好吧。
-
我觉得，我觉得，我是说，你看，非常非常简单地说，我们刚开始搞AI写代码的时候，那就是个自动补全。对。
-
而且没人真正知道你到底能用AI把复杂软件做到什么程度。
-
当时我们看这事儿的时候就想，唉，AI永远不可能做出X或者Y或者Z之类的。
-
结果它基本上超出了预期，因为我们能在系统里建模越来越复杂的東西。
-
我就是觉得，我在这事儿上想得很简单。
-
对我来说，这些模型就是输入分布、输出分布。
-
而事实证明，你确实可以拿有史以来所有的代码来训练。
-
而且那个流形其实还挺好驾驭的。
-
我就是不确定运维是不是也受同样的约束。
-
对我来说，那感觉更像是宇宙，重尾分布、基于异常、幂律，还有所有这些对这些模型来说很难搞的东西。但我不知道。我是说，你才是干这行的人。所以也许不是这样。也许这些也是能驾驭的。
-
但我跟你说，系统的历史，你也知道，就是你总想造一个聪明的算法，做高效的事，聪明的虚拟内存管理、聪明的拥塞控制、聪明的路由。
-
结果我们每次实际都怎么做？
-
我们造一个更复杂的东西。
-
不，我们每次都超额配置，真的是每次。
-
每次都是，记得那个交换内存吗，就是往磁盘上换页那个？哥们，你要是那么干了，你就完蛋了。就这样，你的电脑就死了。
-
所以，我们真的是超额配置内存，还有路由。
-
你知道有多少自适应路由算法吗，就是那种会根据流量来响应的。但会有振荡。去他的吧。我们超额配置。我们就用ECMP。
-
你知道吧，所以我就觉得，系统的历史就是你不去预测，你超额配置，因为你预测不了。
-
我觉得吧，你知道，在运维这一块，要么我们一开始就把系统建好、超额配置，这样就不用去做那些复杂的运维操作。
-
要么也许AI能像人一样去做，但我觉得这跟写代码很不一样，因为你要处理各种异常情况，数据又不多，等等。
-
我就是觉得这是另一个领域，不过我也不知道，我就是个做风投的。
-
我之所以在这方面更乐观，是因为我所在的领域，我们做的事其实就是跟可观测的世界打交道。
-
我正想说，你才是这方面的真正专家。
-
所以我问你这些问题都显得挺傻的。不不，完全不会。
-
因为在我的世界里，我的假设是我们拥有全部数据。
-
就是我们能确切知道什么时候有新情况发生，或者出现了异常，或者负载变了，或者别的什么。
-
在我的世界里，这些全都已经被采集下来、流式传输过来了。
-
然后呢，对，但是，但是那个模型并没有基于这些东西的真实来源数据训练过啊。不不，你没有。那会非常难。
-
但，但这里说的可不是那种，嘿，Claude先生，这儿有一堆日志，出什么事了，对吧？
-
它得更有能力去做实验、深入进去看，比如，有哪些不同的可能因果链形态，是真正符合现有环境的。我明白了。所以对，这就是你之前说的。现在我明白你的意思了。
-
你是说，这个宇宙是重尾分布的，可能发生的坏事数量大概是个异常级别的事。
-
但是，用来调试它的那套步骤集合，是可控的。
-
这就是你能教给这类模型的东西。完全正确。
-
所以，如果你给它正确的信号，它就能走完一系列步骤，真正把这个问题的范围约束住。完全正确。有意思。完全正确。
-
所以它真的就是在扮演那个角色，因为记得吗，记得那整波混沌工程的热潮吗，它之所以没搞出什么名堂，就是因为，你很快就会想着去，你知道，把一个状态空间缩小，那空间本来跟宇宙里的原子数一样大，你就想超快地，
-
真正把它变得可控。
-
而当时就是靠人去走这些步骤，在实际调试中做到这一点。
-
而你现在说的就是，AI会来做这件事。对。没错。
-
所以目标并不是让模型直接说，事情就是这样。
-
而是，嘿，走一遍这个工作流程，去弄清楚到底发生了什么。
-
而且，我们也在安全领域尝试类似的做法，比如说，嘿，在安全方面，你的统计数据里出现了某些不一样的变化，比如某些实体的存在方式出现了行为差异，各种东西的基数发生了变化。
-
于是这就成了那个什么，那个宇宙里的一个扰动。
-
然后我们把这个信号拿过来，喂给AI，跟它说，嘿，AI，想出一堆可能的因果链，然后去逐一验证，看有没有哪条符合我们实际看到的数据模式。
-
于是这就变成了一个更像是，嘿，这就像是，我也不知道，就像把这个方块塞进去，找到那个钉子，或者找到能插进这个钉子的那个孔。
-
我是说，这在我看来甚至更难，因为运维那个，论点是系统会进入某种坏掉的状态，那种状态非常罕见，而且这种罕见状态还特别多。对。
-
所以这就不是你能直接拿个模型去训练的东西，因为它可能进入的糟糕罕见状态太多了。
-
所以也许你可以通过走这些步骤来减少这种情况。
-
安全那个看起来更难，因为这不只是自然规律下的罕见状态，你实际上面对的是一个对手，他在刻意寻找罕见状态，刻意去找你搞不定的东西。
-
所以情况可能是，写代码这件事会被解决，运维要多花一点时间，而做某件事则要花长得多的时间。
-
对，但你也想想，我是说，我也不知道，对我来说，整个世界在某种程度上是量子化的。普朗克长度。
-
物理学家是这么说的吗？对，我也不知道。我不是物理学家。
-
我觉得好像有，我其实，我现在真的是在胡说八道，但我真的觉得，那个，那个，那个时空是离散化成普朗克长度的。
-
但是，但是对，我是说，我同意，你刚才说的在某种程度上是对的，但对于运维和系统总体来说，可能的状态以及它们之间可能的路径，确实存在一种离散化。对。没错。
-
我只是觉得，当你面对的是，可能数量非常多，可能数量非常多。
-
我跟你说件事，还记得我们研究生组里的Sundar吗？对。Sundar Iyer？Iyer，对对对。
-
我记得他有次来找我，看起来特别难过，他说，Martin，我刚有一个特别难过的领悟，你知道，你随便拿一个MP3，还记得MP3吗，对我们来说就是音乐？
-
他说MP3的大小是有限的，比如说，你知道，四分钟，大概就是四兆，对吧？
-
那就意味着，宇宙里的歌曲数量是有限的。
-
那不行，因为，你知道，因为这一切都是由比特组成的，对吧？而且就是四兆。
-
那就意味着你可以把每一个概念都列举出来。
-
所以我特别难过，就是这种音乐有限性的想法，对吧？
-
而且说真的，我们聊这个的时候正走在盘子上。
-
我就想，你这家伙，你知道宇宙里的原子数你多快就跨过去了吗，你连个零头都还没到呢，对吧？
-
就像二的两倍的两倍的两倍。
-
你在说什么呢？
-
对二的两倍感到高兴吧，四兆。
-
状态那么多，高兴点吧。
-
那实际上就是无限的，对吧？
-
我们在说什么呢？
-
所以我确实觉得，在某种程度上，我们低估了系统能进入的状态数量，而且，也许，我从一个看这些公司的风投的角度告诉你，那些试图解决运维问题的公司日子很难过。
-
这看起来比那些解决代码问题的公司要难得多得多。
-
因为我觉得这是个难得多的题。我百分之百同意。
-
这是个难得多的题。
-
而且，这不仅仅是因为系统本身，你知道，有随机的、突然落到你头上的外部负载，或者，你知道，有人刚发布了个新东西，推到了生产环境，没告诉任何人，或者，呃，
-
有些状态是当这件事发生、那件事发生时才真正出现的，然后你就陷入了死锁。
-
呃，还因为它涉及的人多得多，不只是写代码的那一个人。
-
它实际上还涉及知识池是分散的，正是如此。
-
就像要连接它们、把它们组合起来需要什么，这些之间的互动，但最终，我是说，我想到AI现在的位置，以及可能的未来，还有所有这些东西的深度和前瞻能力，对我来说，我觉得代码只是，
-
这就像是一个缩影，也许我只是太宿命论了。
-
也许我只是对世界的运作方式太悲观了，我把一切都看成是在遵循某种概率路径。
-
所以对我来说，如果我们能在代码上做到这一点，我们就能一点一点地继续扩展那种复杂度的层次，一层一层地叠加，直到我们能处理那些运维问题。
-
很多人说这不是宿命论，恰恰相反，这非常乐观。
-
有人会说，对我来说，我不认为宇宙会那么轻易地交出它的秘密，但咱们走着瞧吧。
-
我是说，这算是个大问题。
-
我得说，到目前为止，这还不是一个已经有答案的问题。
-
不不，但我知道有很多东西，我们人类认为是随机的或者不可能解决的。是的。
-
而这就是我们在编程上看到的情况。
-
你知道，一开始人们觉得，你能用代码实现的所有这些东西，可能的世界是有限的，你没法让一个系统真正理解人脑所需的全部复杂性。
-
我觉得随着时间推移，这一切都会实现。
-
太有意思了，我居然在跟你说这些，而你可是那个展望未来的风投，还在说，不，我是说，我跟你讲讲我的看法。
-
我的看法是，对这些模型的研究就是，你用数据训练，要么就是这样。
-
你用数据训练，而数据代表一个分布，这个分布有用或者没用。
-
所以，当你用语言来训练时，它之所以有用，对我来说恰恰说明人类太了不起了，因为他们观察了宇宙这个非常高维的系统，然后把它降维成一个对模型来说真正有用的流形，对吧？是的。
-
对，但那和宇宙本身不一样。
-
从这种高维到语言的降维，维度要低得多。
-
而我认为代码是把一台机器的所有运行状态降维成让它运转起来的那些结构。
-
所以对我来说，指令或者说描述，与宇宙的实际运行、与系统的实际运行之间，仍然存在脱节，我觉得我们可以朝着这个方向取得进展。
-
但我要说的是，你有点在往模拟这个方向靠拢了。
-
有些东西在计算上是不可约的。
-
你必须实际跑一遍才能得到答案。
-
你没法直接预测出来。
-
所以也许我们正处在一个事件视界上，模型能解决任何不需要真正模拟就能得到答案的问题。但为什么呢？
-
为什么你非得从“它现在就得回答这个问题”这个角度去想，而不是它能模拟、抱歉，是能规划自己的执行过程，去获取它需要的信息，从而能够——对。
-
不，也许我们正在往那个方向走。对。对。
-
这差不多就是我的——有道理。对。
-
而且我觉得——存在一个更低维的空间，就是你会采取的那些步骤，我们可以用 AI 大幅缩减，然后那些它做不到的步骤，它可以写代码去做，或者模拟去做。
-
不过你指出的点是，模型没法真的去弄清楚这个世界额外的维度，那些我们需要去找出来、才能把宇宙建模进它的世界里的维度。
-
这大概是真的。
-
但它能不能充分模拟一个科学家，从而走到那一步呢？也许吧。好。我能问你个问题吗？
-
你觉得 VC 的工作里，有多少是 AI 能驱动的？
-
我对 VC 的理解是，它非常依赖关系。我觉得，所以还好。
-
我就是相信市场其实相当有效，你知道，所以关键不在于找到那家别人都找不到的公司。
-
我觉得大家都能找到对的公司。我觉得市场是有效的。
-
然后我对 VC 还有一个理解，就是，你知道，科技是正向的，我对所有科技都挺乐观，我不担心 TAM。
-
所以我觉得关键在于触达，比如募资，是触达，是拿下交易的能力，以及之后创造价值的能力。
-
而这里面很多东西，是创业公司天然做不到的，比如，你知道，招人，招高管，或者在这方面帮忙。
-
所以我对风投的看法是，这活儿你基本上得是个人才能干。
-
因为，你知道，那才是这份工作真正的内容。
-
所以这一点上，我不觉得AI能做到，比如说你给AI一个模拟宇宙，让它随便怎么搞奖励黑客、建立信任关系，行吧。
-
但我觉得那得是……话虽如此，我得说，我见过AI做的分析，跟我共事过的任何初级分析师比，一样好甚至更好。
-
所以单说分析这块，它们很棒。
-
但我觉得这更多是在说风投的分析能力不行，而不是模型有多强大。
-
我就觉得那整套都是装腔作势、胡说八道。
-
我就觉得好的风投是那种，你知道，相信科技是净正向的，科技浪潮总会带来价值，那就找最好的公司投进去。
-
市场是非常非常有效的。
-
所以我觉得这个问题的答案几乎有点……我的答案几乎算是个技术性细节。
-
那比如说，你知道，我来这儿，有件事我一直想问你，就是这个问题，我们一开始专门聊的是运维，但对我来说，存在一个AI写代码的世界，那有点像它生活的这个抽象的模拟世界。
-
然后还有世界的其余部分。对，没错。
-
整个讨论就是这个，就好像有AI，有AI生活的那个世界，全是数字的，管它是什么，训练数据、分布内世界，然后还有真实世界，这些东西不一定是一回事。
-
而且经常不是一回事。
-
所以问题就是，你得在多大程度上训练AI，让它能在一个世界里生存下来？
-
还有它真正需要什么，我不想回答那个问题，就是你需要训练什么？
-
但我好奇的是那些空白地带。
-
我们聊了一点运维。
-
你说，哦，我不知道这能不能解决。
-
我就想，是啊，Martin，这会被解决的。
-
在我脑子里，还有很多别的东西。
-
比如自动驾驶汽车，很长一段时间我们都觉得那不会实现，但很明显它真的会被做成，而且一定会实现。
-
只是需要时间，因为有很多不同的因素。
-
那你觉得，接下来还有哪些阶段、哪些领域，是紧跟在代码之后排上队的？
-
我的感觉是，AI会继续像野火一样蔓延，但仅限于那些解空间受限的领域，也就是解空间的分布和训练集的分布一致的领域。
-
代码语法的分布和训练集的分布是一样的。
-
生成图像的分布和训练集的分布也是一样的。
-
在这些领域，我觉得它会继续像野火一样蔓延。
-
而那些解的分布是现实世界的领域，我觉得会难得多、耗时更长，经济上的等效性也会困难得多。自动驾驶就是个很好的例子。
-
我记得我在斯坦福的时候，Sebastian Thrun赢得了DARPA大挑战赛。还记得吗？
-
我们当时就想，太棒了。
-
自动驾驶汽车马上就要来了。说真的。
-
结果花了20年、1700亿美元的投资，最后单位经济模型还不如Uber，对吧？
-
所以你看，我觉得，解决真正的问题，那些你必须应对真实世界分布的，就是要难得多得多。
-
所以我把AI看作一个通用工具，它是个非常有效的工具，你有数据的分布，然后希望你能把它应用到，你知道，
-
一些问题上，我们会把它应用到很多东西上，我觉得经济均衡会决定什么行得通、什么行不通，因为我觉得它是个非常非常通用的工具，就像一个通用函数逼近器，最终结果如何，我的意思是，还是那句话，你知道，我之前说过的一点
-
就是AI是如何训练人类去使用它的，我经常想到，你知道，有些问题看起来无解，是因为世界本身就是那样，然后我们试图让AI或者我们正在构建的工具去适应这个世界的现状，但在某些情况下，
-
我们其实倾向于改变世界，让它去适应我们从数字化、从自动化数据仓库能做到的事情。
-
所以我脑子里总会冒出这个问题，比如当我们看这些数据仓库之类的，唯一行得通的那个就是，你知道，干脆把整个东西都自动化。
-
我就在想，随着我们不断改进或改变我们的方式，或者说扩展我们想用AI工具解决的范围等等，
-
我们是不是其实开始对世界建模，或者改变世界、改变那些实际能发生的事情，去迎合AI需要的样子。
-
是啊，我的意思是，我觉得现在，很多AI只是在数字世界里运作。
-
而对此，说白了，解集和训练集的分布是一样的，对吧，某种意义上说，所以那没问题。
-
我觉得，再说一次，在均衡的情况下，我觉得当你面对真实世界时，你可以解决任何你想解决的问题。
-
无非就是算力和钱的问题。
-
而均衡点会是一个经济上的均衡点。
-
我觉得影响你求均衡的那个函数的一种方式，就是约束系统、约束环境，就是约束系统。
-
所以我觉得我们将会，就像我们现在处在这个元经济均衡的飞轮里，我们在优化这个超级通用但非常低效的过程，而它的解集是人们所看重的。
-
我觉得我们会有30年的这个，会创造大量的价值。
-
你想听个好玩的事吗？好啊。
-
你知道，我们做了这个AI的东西，然后我们跟人聊。
-
我们去联系客户。
-
我们说，嘿，我们做了这个AI的东西。
-
你知道，我们在帮客户变得更可靠。这是我们正在做的事。
-
他们说，太好了，我们想跟你们聊聊。
-
然后我们上了电话会，我们说，嘿，我们做的是这个。
-
你知道，我们做了这个系统，帮你优化你的数据。
-
它帮你降低成本，然后帮你变得更可靠，因为现在我们能找到这些问题，在它们变成事故之前就解决掉。
-
他们说，等等等等等等。倒回去。
-
你说你能省掉我们90%的Datadog账单？对。那才是我要买的。
-
我们说，但是那个AI的东西，他们说，不不不不。而且挺有意思的，很多这些，呃，比如对代码来说，你知道，我总是这么想，哦，对代码来说，人们一下就能明白。
-
他们说，我去，它真能用。对。
-
而在运维这边，或者说超出这个范围的任何事情，还是要理解实际价值，把它换算成美元金额，然后掏钱买单，不，百分之百。
-
所以，我也觉得从编程的角度来看，这 literally 就是工程生产力，而工程生产力是这些项目里最高的支出项之一。所以就很直接。没错。
-
但你也可以稍微换个角度想，你知道，这是 SRE 的生产力，或者说你的业务宕机了。
-
也许你能挽回一次事故，那成本是多少。我不知道。这挺，挺奇怪的。
-
我觉得就是人们在这个之外是怎么想的。
-
对，我也，我也只是觉得，这段代码太神奇了，因为它太好了，没人想到这能发生。
-
我觉得现在运维这块还是，还挺早期的，还挺早期的。所以，对。好吧。
-
行，聊得真好。谢谢你，Chad。谢谢你来。谢谢。