AI写完代码之后：Jed谈生产系统、故障调查与自治运维的边界

一、嘉宾背景

这期a16z / The Ben & Marc Show的标题是《Why AI Can Write Code But Can’t Keep It Running (Yet)》，元数据标注时长为3,537秒，约59分钟。嘉宾Jed在转录中也被写作Jad，被介绍为Grepper的CEO。所给材料没有提供他的姓氏，公司名称也按材料中的写法保留。他在访谈中讲述的系统工程经历，为理解其产品思路和AI开发实践提供了背景。

Jed曾参与OpenFlow相关工作，并为SHA-3候选方案制作硬件实现；之后在MIT做博士后期间，与Nikolay Zeldovich开展应用安全研究。他还谈到一次创业尝试：应用遭到漏洞利用后，回滚相关状态，再向修补后的应用重放，试图消除攻击影响。他坦言，这项技术在当时还太早，团队只是接近让它真正工作。采访者随即追问，现实运维中究竟能否划清需要恢复的状态边界。

此后，Jed曾在AppDynamics工作，也做过风险投资，后来担任首席产品官，建设产品与工程相关团队。这些经历使访谈同时涉及系统实现、团队组织和采购判断。早年的恢复方案也与本集的核心问题相呼应：修补应用之外，还需要知道应用与外部世界发生了哪些交互，以及相关状态延伸到了哪里。这个联系有助于理解讨论，但早期研究并未因此成为今天自治运维问题的答案。

二、本期主要内容

Jed从可观测性的成本谈起。他说，2023年与工程负责人交流时，反复听到削减基础设施和可观测性费用的需求。按这些访谈中的说法，可观测性开支约相当于基础设施开支的5%—20%，而客户最终追求的是可靠性和费用的可预测性。他判断，微服务和多层采集推高了遥测数据量，新增支出带来的可靠性收益却逐渐趋平。这一判断来自他的访谈和市场观察，不能作为所有企业的统一成本结构。

他的产品思路是在遥测流上游实时提取信号，减少下游处理负担，再将这些信号交给AI排障层。他宣称这能降低90%的成本，但节目没有提供成本基线、测量方法或独立验证。这套方案将两种价值连在一起：先通过数据处理节约开销，再利用提取的信息支持可靠性工作。两者仍需分别检验，费用下降本身不能证明排障效果。

谈到开发，Jed认为，熟练使用AI需要持续适应模型、工具框架、上下文管理和任务拆分方式。他声称，普通与优秀工程师之间的表现差距扩大了十倍，同时明确限定了这一观察的范围：这是他在小型分布式系统团队中的个人经验，尚未在百人团队中验证。按照他的解释，工程师需要理解任务的复杂性，才能将工作拆成代理可以执行的部分。

他的日常流程体现了这种拆分方式。他通常同时管理三四个会话窗口，再多就容易丢失上下文；持久的命令行代理会话则帮助延续工作。代理先起草设计和PR文档，再由技术负责人代理审查。Jed逐项检查算法、分工和PR依赖，随后展开并行实施。最终，各个分支要整合成一组可由人逐个审阅、按依赖排列的PR，审查也越来越侧重测试及其明确的预期结果。

主要案例是auto promotion，也称shredding：将半结构化日志中的字段提升为数据湖中的独立列，以便过滤和查询。这个功能涉及Parquet、Iceberg、元数据提交，以及多个写入方之间的协调。Jed说，借助AI，他用约十天交付了生产功能；他估计，过去由一个人完成可能需要六个月。采访者据此概括为十到二十倍的提升。这里包含实际交付时间、对旧流程耗时的估计，以及采访者的倍数概括，三者不能合并成普遍适用的生产率结论。

运维部分采用了另一套架构：独立的检测机制识别日志中的新模式和环境变化，再由生成式代理追查代码、查看历史并评估假设。Jed以每天PB级的日志说明输入规模，并举出连接耗尽、内存超限和资源缓冲区耗尽等早期消息。讨论由此转向运行证据：AI需要先获得哪些信息，才能支持下一步调查和行动。

三、核心观点：推理、例子与边界

代码的语法、语义和性能特征，需要分别验证。采访者以SQL耗时受到schema和数据影响为例，说明仅凭阅读代码无法掌握系统的全部行为；Jed指出，这首先属于性能特征，配置决定NULL如何处理才是语义问题。双方随后为便于讨论，将代码之外的系统行为宽泛地称为semantics。这一区分关系到如何验收：结果是否正确、语义是否符合约定、在目标负载下是否足够快，需要各自的证据。

分布式系统进一步放大了这些差别。采访者谈到一致性、锁和缓存：是否允许短暂读到旧值、何时牺牲可用性、缓存能否带来收益，都取决于具体负载和访问模式。模型能够生成一种实现，并不意味着它已经掌握了选择这种实现所需的信息。问题因此延伸到算法之外：运行条件是否已被明确描述，成为可以检查的输入？

Jed的查询优化案例说明，明确的反馈可以缩小这一缺口。他提供查询数据集、性能基准和流处理器约束，让模型迭代代码。但模型起初没有识别出AND表达式中重复的合取项，直到他指出问题，才继续探索其他优化假设。反馈循环确实推动了优化，人的诊断也仍可能决定搜索方向。至于应该分配多少内存，Jed承认还要在生产环境中实验。基准能够回答特定问题，却未必覆盖容量配置和全部实际负载。

采访者在自己的分布式Gaussian splat渲染器上遇到了另一种情况。数百万个splat的换入换出与流式传输依赖系统的实际运行状态，他认为现有模型在这项任务上表现很差。这个案例不足以判断AI优化其他渲染器的能力，但说明反馈是否具有代表性会影响结果。两人的经验共同指向几个具体条件：哪些状态可见，哪些性能目标可测，还有哪些运行条件没有进入模型的上下文。

Jed的AI SRE设计也依赖这样的调查过程。检测层先识别变化，代理再判断变化的意义，生成式模型无需直接从全部日志中预测未来事故。它可以从资源耗尽消息追查到代码出处，比较历史记录，再提出候选解释。不过，新模式也可能源于正常的流量变化。发现差异、确认故障和查明根因是不同的步骤，这套架构能发挥多大作用，取决于后续验证能否将它们区分开。

采访提供的成效证据仍然有限。Jed说，系统已用于内部和少数客户环境，有几次被忽略的提示后来演变成了生产事故。这些案例支持继续试验，但没有给出全部提示和事故的统计：多少提示最终没有对应事故，多少事故没有得到提前提示，收到提示后采取行动能否阻止事故，都无法据此确定。Jed也明确区分了能力层级：他认为AI接替人工完成查询优化已经很接近，但还不能独立运行业务关键的分布式集群。

采访者的疑虑来自运维中的重尾异常和稀缺样本。他以增加RAM、预留容量、ECMP以及自适应路由可能出现的振荡为例，解释工程师为何有时选择增加余量，而不依赖更准确的预测。这是他的经验判断，不能据此断言所有自适应系统都会失败。双方也谈到，随机的外部负载、未通知的发布和多个条件共同触发的死锁，会与分散在人之间的知识交织。某位工程师偶然听说的一次部署，可能正是解释日志时缺失的信息。

双方较为一致的方向，是让代理学习调查程序。代理根据当前信号提出可能的因果链，再通过查询和实验逐步排除解释，无需预先记住所有故障。Jed也将这种方法用于安全调查，追查行为统计、实体和基数变化所触发的信号。采访者则提醒，安全场景中还有主动寻找罕见问题状态的对手。一个在普通运行异常中有效的调查流程，能否应对这种对抗，仍需单独验证。

关于“计算不可约性”的讨论进一步触及信息的边界。采访者认为，语言和代码都是对世界的压缩，有些问题必须实际运行或模拟才能得到答案。Jed提出，代理可以规划如何获取信息，编写实验代码并执行模拟。由此，模型的作用可以延伸到组织求证过程。但另一个问题仍未解决：代理能否发现原始描述中根本没有包含的维度？能够执行实验，并不等于知道描述遗漏了什么、还应调查什么。

四、学习与应用

从Jed的案例出发，工程团队可以先将AI任务说明写成可验证的约定。以查询转换为例，输入数据、NULL等语义规则、预期结果和性能条件都应明确，正确性与速度分别检查。查询基准需要保留能够代表实际请求的样本；模型提出优化后，既比较耗时，也核对结果。内存容量等依赖运行状态的决定，则需要另行设计实验。这些是由案例推导出的应用建议，并非节目报告的额外客户成果。

代理并行实施之前，也需要明确可供审查的工作依赖。可以先让代理提交设计和PR划分，由负责人确认算法、接口与合并顺序，再分配实现。审查测试时，还要检查预期结果的依据。如果实现和预期结果同时被改写，仅凭测试通过无法判断行为变化是否合理。Jed能同时管理三四个窗口，反映的是他个人能够维持的上下文范围；团队可以据此观察自身的调度成本，但这个数字并非通用标准。

评价提效时，应分别记录写码、设计判断和最终集成所需的时间。十天交付与“过去可能需要六个月”提供了比较线索，后者却仍是反事实估计。团队内部更有用的比较，是选择相近任务，保留验收范围和人工审查投入的记录，同时观察交付加快后是否增加返工。这样才能判断，这套流程能否持续复制，以及效果在多大程度上依赖工程师对特定系统的熟悉程度。

运维试点可以先将代理的职责限定为协助调查。检测机制提供新日志模式或资源异常，代理列出候选原因、已查证据和仍未解释的现象；缺少隐藏状态或部署信息时，再向了解系统的人求证。信号质量、调查效果和建议的可执行性应分别记录，否则检测、诊断和修复容易被混成一个成功率。采访没有给出总体统计，试点因此还需记录误报、漏报和没有结果的调查，才能评估命中案例在整体表现中的分量。

实验能力也需要明确适用条件。代理可以查询历史、编写复现代码或进行模拟，但模拟结果必须说明覆盖了哪些负载和状态。安全场景还要考虑对手可能主动改变行为，一组正常环境中的调查结果不足以证明长期有效性。同样，查询优化的局部进展，也不足以支持将业务关键集群的独立运行责任交给AI。

减少环境复杂性，是节目提出的另一条思路。双方以仓库和机器人作业环境为例，讨论通过改变环境来约束自动化任务、改善经济可行性。将这一思路延伸到软件运维，可以考虑让部署记录、配置变更和依赖信息更容易查询，减少必须通过口头交流才能补齐的背景。这样的投入是否划算，仍需比较整理环境的成本与调查收益。采访者预测，在解法与训练分布更一致的受限领域，进展会更快；他也认为现实应用面临更难的经济约束。这一预测可为选择试点提供思路，但尚非已确立的普遍结论。

采购评估则需要分别计算遥测账单、工程师时间和事故损失。Jed说，潜在客户更看重他承诺的Datadog账单节约，而非AI可靠性的推介。双方认为，工程生产率比SRE生产率或避免事故的价值更容易定价，运维AI也仍处于早期。客户的购买偏好说明明确账单更容易形成采购理由，却不能验证90%的节约比例。试点应约定处理量、保留数据、比较周期和新增费用，并检查成本下降后是否仍保留调查所需的信号。可靠性收益需要独立观察，避免事故的价值则需要谨慎归因。费用节约可以帮助产品进入实际环境，自治运维能力仍须在运行中取得证据。

来源

• 原始节目：Why AI Can Write Code But Can’t Keep It Running (Yet)