跨国深谈← 返回←Vibe debugging：代码生成之后，生产环境才是真正的硬仗

Vibe debugging：代码生成之后，生产环境才是真正的硬仗

关联

人物 Corinne Riley · Mayank · Roshan

公司 Resolve AI · OpenTelemetry · Splunk

概念 智能体 · 代码生成 · vibe coding · vibe debugging · 部落知识 · 知识图谱 · 护栏 · 评估

这一集是 Greylock 的「Change Agents」系列，聊的是智能体 AI 在复杂软件工程里的落地。两位主角：Mayank 是 Resolve AI 的联合创始人兼 CTO，职业生涯几乎全在做开发者工具和监控系统，参与创建了开源项目 OpenTelemetry（把遥测数据的插桩和路由方式标准化的项目），上一家公司被 Splunk 收购后他做到了所有监控产品的首席架构师；Roshan 是工程副总裁，做过 Apple Siri 的自然语言理解负责人，后在 Google 参与 Google Assistant、Bard、Gemini，其团队发布过 DeepResearch 和 Canvas。

抛出来的钩子是：整个行业都在为 AI 写代码欢呼，但 Resolve 认为真正的大问题在下游——代码生成得越快，生产环境的瓶颈就越大。

写代码只占工程师 10-20% 的时间

Mayank 在 Splunk 看到的现实是：随着团队变大，工程师可能只有 10%、20% 的时间在真正交付新功能，剩下的大部分时间花在运维生产、处理事故、填合规问卷、变更上线流程、优化成本上。Splunk 生产环境里的微服务数量比工程师还多——没有多少人端到端地了解整个系统 。

所以他的判断是：代码创建上的收益是真实且不可否认的（Resolve 自己团队用 Claude、GitHub Copilot、Cursor 这类工具产出代码快了大概 2、3 倍），但这只是「矛尖」。要实现软件工程的真正高生产力提升，得自动化那些需要跨工具、跨运营边界、依赖大量部落知识（没写下来、只存在人脑里的经验）的复杂活动，让「环境智能体」在后台完成复杂工作，人不必一直握着方向盘 。

Roshan 补了一个关键观察：用代码生成工具你确实能更快地产出代码，但团队实际发布到生产的速度并没有快那么多——那才是拼图里缺的一块 。AI 让代码更快涌出来，反而让下游更堵：理解软件生产行为的时间更少、在生产环境调试它的专业知识也更稀薄。这就是他们创办 Resolve 的理由：复杂性正在向生产环境转移，而源代码只是运营生产的众多工具之一，遥测系统、基础设施、Slack 和 runbook 里的部落知识同样重要，而且生产环境一直在变，知识还必须保持最新 。

衡量标准：多快发布到生产

对事故响应这个场景，指标是平均解决时间（MTTR）：多快响应、多快缓解、要动用多少人力——一次复杂事故可能把不同值班轮换里的很多工程师吵醒，事后还要写复盘 。但不止事故：日常还要登 VPN、跑 kubectl 命令、登日志工具看系统健康，这种「千刀万剐式」的小消耗也是 Resolve 在啃的场景。

现在连他们的销售都在 Slack 里问「这个子系统最近有没有变更」。Roshan 给的北极星更直白：你实际上能多快把东西发布到生产环境——搭原型和 V1 很容易，难点全在上线时冒出的意外；如果上线能简单到和搭 V1 一样，那就是阶跃式改进 。

Vibe debugging：给 vibe coding 补上后半程

Roshan 承认 vibe coding 名声不太好，但认为它的问题不是走错方向，而是走得不够远：你快速搭出了代码、部署了、出了问题，但你对自己构建的东西没有深入理解，得靠别人去修，学习也没法传递回来。Resolve 提出的对应概念是 vibe debugging——vibe coding 给你速度，vibe debugging 给你清晰度，两者合起来才能跨过那道坎 。

一个具体例子说明什么叫「理解生产」：回答「我的前端服务健康吗」是个非常复杂的问题——你得知道前端跑在哪、数据在哪、主要面板是什么、日志在哪、答案到底在哪。首先要弄清该操作哪个工具，再以正确的方式操作它 。

还有超越表面相关性、深入因果链：这些东西同时开始出问题，但事件链是什么、从哪开始、怎么传播的 。他提到一位客户每周要花两小时人工整理 SLO 预算的运维报告——查追踪、翻日志、总结事故——这种事没有理由不能交给 AI 。

为什么不能自己拿聊天机器人套一下

在静态知识上拖个聊天机器人远远不够，因为生产环境是不断变化的：每个环境有复杂的拓扑结构、有部落知识、有时序理解，还有你想要采取的动作——这是 V1 级 co-pilot 和真正自主系统之间的区别 。

难度有多大？Mayank 给了两个数据点：Resolve 正朝着每季度消耗一万亿 token 前进，大约相当于整个 Azure 的 1%，相当于每周从零开始完整重做两次 Stack Overflow 。

更本质的复杂性在于：调试最复杂的事故，连资深工程师都要花很久，事故拖得越久，越高阶的工程师和高管跳上电话会议， collective 的诀窍汇聚在一起才搞清楚发生了什么。而且这比用 AI 创建一个 PR 难得多——创建 PR 时你大致知道预期产出是什么，调试事故时你真的不知道发生了什么，既需要第一性原理推理，又需要肌肉记忆，还有大量没被写下来的部落知识；runbook 多半已经过时 。

Resolve 的核心组件叫**知识图谱**：为任何环境的复杂性建模——每个环境都有自己的工具、约定、模式和数据，知识图谱让 Resolve 自动学习任何新环境、开始表现得像经验丰富的工程师，并且自我学习、自我更新，成为运行时智能体调查事故时可用的现成知识 。具体怎么捕获部落知识？就像初级工程师一样：通过参加事故电话会议和事故频道来跟随资深工程师学习，或者被人类指导着去验证某个假设，下次它就会记得主动去查那类假设 。

那能不能直接扩展 Cursor 这类工具来解决生产问题？Roshan 的答案是：代码生成工具是为「代码这个可寻址的宇宙」设计的，而生产系统像一只活生生的、会呼吸的动物——是代码、基础设施、部署、流量行为、部落知识相互作用产生的涌现行为，且每个环境都不同，这对通用编码智能体来说是严重超出分布范围的 。

Mayank 补了个真实案例：客户用 Resolve 排查事故后，进一步让它在理解代码、日志和追踪的基础上提出一个防止问题复发的单元测试——用户说那是他们自己想不出来的。没有对生产实际状况的深刻理解，编码智能体不可能做到这一点 。

团队、评估与失败模式

要构建能导航生产系统的智能体，你需要 AI 和生产系统两边都是世界级的人。大多数 AI 团队懂模型但对生产复杂性没直觉，大多数基础设施团队泡在生产里但对构建智能体编排没感觉——两者在一线深度嵌合才是魔法的关键 。Resolve 的使命不止做助手，而是构建能自主采取行动修复事故的闭环修复系统，这需要达到足够高的准确度 。

评估是最难的部分。代码生成进步快，一个重要原因是它能构建可验证、可评估的环境；生产调试没有现成数据集，光是拿到数据集就非常非常难，所以别指望基础模型在这些任务上自动持续变好——它们根本接触不到这类数据 。他们在沙箱里模拟大量事故，也探索把模型本身用作操作员、调整到与专家级人类工作者的做法高度相关，这个范式大有可为 。

面对「模型经常自信地犯错」的提问，Roshan 说这里存在持续的张力：护栏放多了能保证结果有依据，但会损失模型的涌现式推理；挑战在于了解模型现在在哪、走向何方，找到恰到好处的护栏——让幻觉足够少，同时模型还能像专家工程师那样提出可行假设并缩小范围 。而从用户交互中学习成长，在他们的架构里是一等公民 。

有观众问生产系统会不会演变得更兼容 AI 智能体。Mayank 的回答很务实：数据孤岛确实是个挑战（指标散落在 CloudWatch、Datadog、Grafana 里，常常同属一家公司），遵循 OpenTelemetry 这类最佳实践会让工具更好用，但 AI 真正的机会在于不需要你遵守一条黄金路径、不需要预先做大量改造才能开始产生价值 。

本集带走

• 别只盯代码生成:工程师只有 10-20% 时间在写新功能，AI 让代码更快涌出反而加大生产环境的排查与运维瓶颈——下一个大杠杆在生产侧。
• 上线速度才是北极星：衡量 AI 对工程效率的贡献，看「从 V1 到真正发布到生产」能压缩多少，而不是代码产出行数。
• 生产系统 ≠ 代码:它是代码、基础设施、部署、流量、部落知识的涌现行为，每个环境都独特且持续变化，套个静态聊天机器人不够，通用编码智能体也严重超出其分布范围。
• 最难的不是写提示词，是数据和评估：生产调试没有现成数据集、且极难创建，这既是护城河也是基础模型无法自然进步的原因。
• 护栏与推理要找平衡：护栏太多会压掉模型的涌现式推理，太少会幻觉；正确姿势是跟着模型能力演进调整，并让系统从用户交互中持续学习。
• 捕部落知识学初级工程师：让智能体参加事故会议、被人类指导验证假设、记住下次主动去查——这是让系统随时间像资深工程师的方向。

是的，我觉得这里的北极星指标就是，你实际上能多快地发布到生产环境，对吧？
Yeah, I think the North Star here is like how much faster can you actually ship to prod, right?
—— Roshan · [12:17]

在 Resolve，我们现在正朝着每季度消耗一万亿 token 的方向前进。
So, here at Resolve, we are now on track to consume one trillion tokens per quarter.
—— Roshan · [17:34]

这相当于每周从零开始完整重做两次 Stack Overflow。
This is the equivalent of doing Stack Overflow completely from scratch twice every week.
—— Roshan · [17:51]

我认为这里的论点是：如果你行动得不够快、没有变得 AI 优先，在我看来你就面临巨大的风险，会被其他这么做的公司颠覆。
I think the sort of the thesis over here is that if you don’t move fast enough to sort of become AI first, you are at a huge risk in my opinion of being disrupted by somebody else who does.
—— Roshan · [26:11]

所以并不是基础模型就会在这些类型的任务上不断变得更好，因为它们根本没有这些数据集的访问权限。
So it’s not like the foundation models are just going to keep getting better at these kind of tasks because they just don’t have access to these data sets.
—— Mayank · [32:24]

但我认为真正的机会在于，AI 不需要你遵守一条黄金路径。
But I think that really the opportunity is that AI need not require you to abide to a golden path.
—— Mayank · [28:18]