AI Can Write the Code. Can It Run the System? | Grepr CEO Jad Naous｜深度中文详解
- 日期：2026-10-16
- 时长：3602 秒（约 60 分 02 秒）
- 嘉宾：Jad Naous，Grepr CEO
- 音频：收听本集
- YouTube：观看本集
- Episode：节目页面
- 英文来源：YouTube 字幕（youtube-captions）
Jad Naous 的经历横跨系统研究、应用安全、可观测性产品、工程管理和投资。他从斯坦福时期的 OpenFlow 与硬件安全工作谈起，随后经历 MIT 的应用安全研究、AppDynamics 的规模化阶段，以及创办 Grepr 前对工程团队成本的调研。这使本集的问题相当具体：一家处理遥测数据的公司，既用 AI 开发自己的基础设施，也试图用 AI 帮客户排查基础设施故障；前者取得的速度，能否直接迁移到后者？
这里的“可观测性”主要指通过日志等遥测数据理解系统状态；“运维”则进一步要求判断异常、寻找原因，必要时采取行动。两者之间的距离，正是整场对话的焦点。
本集从一个看似矛盾的现象展开：Grepr 创办的切入口是降低可观测性成本，但 Jad 认为客户真正想购买的是可靠性。微服务让遥测数据持续膨胀，更多数据却不必然带来相称的可靠性收益。因此，Grepr 先把自己放进数据流，在上游提取信号、减少下游存储与分析费用，再尝试把信号交给 AI 排查问题。
对话的另一条线索是 AI 编程。Jad 描述了以设计文档、并行智能体（Agent）、测试和人工审查组织开发的工作流，并举出自己约十天完成一项过去估计需单人六个月的数据湖功能的案例。但他也承认：模型可以根据明确的基准改进查询代码，却不能凭空知道生产环境该分配多少内存。代码的写法、系统运行时的表现，以及特定负载下是否可靠，是不同层次的问题。
双方真正的分歧不在于 AI 能否帮忙排障，而在于这种能力能走多远。Jad 主张先从海量日志中找出新变化，再让智能体查看代码、历史与数据，逐步验证可能的因果链；主持人则担心生产事故具有长尾性，安全事件还存在主动寻找盲点的对手。Jad 对查询优化接近自动化较乐观，却明确表示 AI 尚不能独立接管关键分布式集群。结尾的客户故事又给讨论加上一层商业约束：即使长期目标是自动化可靠性，眼下最容易被采购和验证的，仍是账单能否立刻下降。
- 开场：代码世界不等于运行中的世界 — 00:00 🎧 · ▶️
- 从斯坦福到 Grepr：一个系统工程师的路径 — 00:54 🎧 · ▶️
- 可观测性为何昂贵：客户买的是可靠性 — 07:23 🎧 · ▶️
- AI 放大工程能力，也放大能力差距 — 10:15 🎧 · ▶️
- Jad 的工具栈：先审设计，再并行实现 — 18:25 🎧 · ▶️
- 十天完成的数据湖功能：惊人的速度，有限的外推 — 22:55 🎧 · ▶️
- 会生成代码，不等于懂运行时取舍 — 24:55 🎧 · ▶️
- Grepr 的排障路径：先找变化，再追问原因 — 30:10 🎧 · ▶️
- 安全为何更难：异常之外还有对手 — 42:16 🎧 · ▶️
- 写代码之后：能力边界与购买理由 — 53:33 🎧 · ▶️
💬 他们说了什么：开场剪辑先摆出核心疑问：AI 编程从自动补全发展到构建复杂软件，是否意味着它也能管理分布式服务？主持人强调，模型所处的数字与训练数据世界，不一定等同于服务实际运行的世界；Jad 则追问，能否把生产环境发生的事转成 AI 可以推理的材料。
💡 为什么重要：这为全场划出两个能力层次：生成实现，以及面对真实负载、故障和未知状态持续作出判断。前一层的进步不能自动证明后一层已经解决。
⚡ 争议点：生产环境究竟是缺少可供模型学习的数据，还是已有大量数据、但尚缺有效的筛选和验证流程？双方随后分别从这两个方向展开。
💬 Jad 回顾自己在斯坦福从事 OpenFlow、硬件安全与 SHA-3 实现工作，之后在 MIT 做应用安全研究。他曾参与探索遭入侵后如何回滚应用相关状态、再将其迁移到修补过的程序上；这个想法在真实环境中极难落地。此后他加入 AppDynamics，经历团队从约 200 人增长到约 2,000 人及被 Cisco 收购的阶段，又先后从事投资与产品管理。离开上一份工作后，他于 2023 年访谈工程负责人，逐渐把注意力转向基础设施和可观测性支出。
💡 早年的“回滚整个相关世界”研究，预演了本集的难题：真实系统究竟有多少状态可被完整识别与控制？他的创业判断也不是单从模型能力出发，而是先听客户抱怨成本。
⚡ 研究中“几乎可行”的系统，与企业愿意部署、愿意承担风险的产品之间仍有巨大距离。访谈获得的共同痛点是创业线索，但不等同于已验证的普遍市场需求。
💬 Jad 称，受访企业的可观测性开支约相当于基础设施支出的 5%—20%。他的解释是，企业原本把遥测支出当作购买可靠性的替代方式；但随着微服务拆分、采集层次增加，数据量与费用增长得比产出的功能单位更快，额外投入换来的可靠性改善却趋于平缓。Grepr 因而在数据进入下游工具前提取信号、削减噪声。Jad 称其接入数据流后可将相关费用降低 90%，并计划进一步把信号用于 AI 排障。
💡 产品逻辑从“多收集数据，事后再找答案”，转为“尽早识别有用信息，同时控制数据成本”。如果上游提取可靠，同一份信号还能成为后续自动化排障的入口。
⚡ 大幅降费是嘉宾对产品效果的陈述，不是本集提供了独立基准测试。真正需要检验的是：削减后的数据是否仍足以复盘罕见事故，以及不同客户的节省幅度能否一致。
💬 Jad 说，团队早期使用的 AI 更像测试代码自动补全；能力提升后，优秀工程师开始学会与模型及其智能体工具配合，把复杂任务拆开，并明确说明算法与查询的真实含义。他观察到团队中较强与一般工程师的产出差距被放大，形容为约 10 倍，同时承认样本是自己的小团队，未在百人规模验证。两人还反复区分代码“写了什么”与系统“实际做了什么”；对于 SQL，他们进一步辨析结果语义和运行性能不能混为一谈。
💡 AI 缩短了实现时间，却把理解约束、界定正确性、审查结果的责任推向更上游。能提出可检验任务的工程师，往往比只会要求“生成代码”的人获得更多收益。
⚡ “强者更强”是 Jad 在特定分布式系统团队中的观察，不应推成所有岗位的定律。对于边界清楚、验证便宜的任务，经验较少的开发者也可能获得不同程度的提升。
💬 Jad 使用 Windows、WSL 和命令行开发环境，并描述以编码智能体、可保持会话的命令行智能体协作开发。他通常同时跟进 3—4 个会话窗口；再多就难以保持人的上下文。他会让负责实现的智能体与“技术负责人式”的审查智能体讨论，先检查产品需求、设计文档、算法、任务划分及 PR 之间的依赖，再允许并行执行。最终仍要把工作收束成人能逐项检查的提交；团队代码审查也更重视测试与预期结果。
💡 速度来自有结构的分工，而不是无限增加智能体数量。设计先行、测试约束与最终人工审查，为并行生成的代码提供共同标准。
⚡ 智能体之间互审可能发现疏漏，也可能共同接受同一个错误前提。大量 PR 同时涌入时，人的审查能力是否会成为新的瓶颈，不能只看代码生成速度判断。
💬 Jad 举例说明一项用于数据湖的“自动提升”功能：把半结构化日志中的字段整理成可单独过滤的列，以改善查询布局与速度。它不仅涉及文件格式，还要处理元数据提交、多写入方协调等问题。他说自己约 10 天完成了相关生产代码；按过去的做法，单人可能需要约 6 个月。主持人据此概括为约 10—20 倍的速度提升。
💡 这不是展示页面或一次性原型，而是包含数据组织与协调问题的生产功能案例，因此比“AI 很快写出一段代码”更能说明工程工作流的变化。
⚡ 六个月是对历史所需工时的回顾性估计，十天也不是长期维护成本。上线后的性能、异常输入、回归风险与后续维护投入，才决定整体效率是否保持同样倍数。
💬 主持人追问：分布式系统的正确性、可用性与性能取决于负载、访问模式及锁、缓存、一致性等设计取舍，模型如何仅凭代码作决定？Jad 以查询优化回应：模型起初没有发现生成代码中的重复条件；在人指出问题，并提供性能基准、真实查询样本后，它才能提出和验证优化假设。若问题变成“该给系统多少内存”，Jad 说模型并不知道，必须依赖实际实验，尤其是生产环境中的观测。
💡 这一段给出可操作的界线：能明确给出数据集、目标和测试方法的问题，适合让 AI 反复优化；结果高度依赖真实负载的问题，则要让测量进入决策循环。
⚡ 在生产环境做实验并非没有代价。如何控制影响范围、判断测量是否代表未来流量，以及在性能、成本和可靠性间选择目标，仍需要工程制度和人来负责。
💬 Jad 不赞成只等指标飙升或警报触发，再要求 AI 沿复杂链路倒查根因。他描述的做法是先扫描日志，识别以往未见的模式，例如连接耗尽、内存越界或资源缓冲异常，把这些早期变化交给 AI。智能体再查对应代码、历史记录与上下文，提出并检验可能的解释。他称，系统已在内部及少数客户环境运行，曾有被忽略的提示随后演变成生产事故；他也以企业每天可能产生 PB 级日志来说明先筛选信号的必要性。谈到自动化边界时，他认为 AI 接手查询优化已“非常接近”，但尚不能独立承担关键分布式集群的运行。
💡 这里不是让生成式模型直接吞下全部日志并猜答案，而是把“变化检测”与“基于证据的调查”分工：先缩小需要注意的范围，再沿可检查的步骤推理。
⚡ 新模式不一定是故障，旧模式也可能在新负载下造成故障；两次被忽略后出事的经历具有提示性，却不足以证明总体准确率。误报、漏报和提前量仍需系统测量。
💬 主持人指出，运维事故已包含大量罕见状态，安全事件还多了主动寻找盲点的攻击者。Jad 同意安全更难，但认为可以先发现实体行为、数量关系等方面的变化，再让 AI 提出数条可能的因果链，逐一与数据核对。双方进一步谈到生产环境的隐藏状态：突发外部负载、未被告知的部署、团队成员才知道的背景，都可能左右判断。主持人提出，有些结果必须实际运行才能得知；Jad 则认为 AI 可以规划实验，而非被迫立即给出答案。
💡 这把“智能”从一次回答，改写为提出假设、获取信息、验证并修正的过程。对安全而言，流程本身还必须面对刻意规避检测的行为。
⚡ 状态空间虽有限，却可能大到无法穷举；把排查步骤标准化，也不能保证关键信息已被记录。允许智能体主动实验时，还必须界定权限，避免调查动作本身扩大事故或安全风险。
💬 主持人判断，训练数据与目标结果分布接近的领域——如代码和图像生成——更容易快速推进；涉及真实世界的领域则更难，最终还要过经济账。Jad 补充，人也可能改变流程与环境，让问题更适合自动化。临近结尾，他分享销售经历：客户听完 Grepr 关于可靠性和 AI 的介绍后，最先追问的仍是能否节省 90% 的 Datadog 账单；相较尚在早期的自动排障，立即可见的成本下降更容易成为采购理由。
💡 技术路线与商业路线并不必同步。降低费用既能提供当下价值，也可能为未来更可靠的自动化积累数据入口；但后者必须靠事故预防效果，而不只是愿景，赢得信任。
⚡ 把环境改造成“适合 AI”可能提升可控性，也可能增加迁移成本或制造新依赖。客户愿意为节省账单付款，并不能反过来证明自动运行系统的能力已经成熟。
- Jad Naous：本集嘉宾、Grepr CEO；曾从事系统与安全研究、可观测性相关工程、投资和产品管理。
- Grepr：Jad 创办的公司。本集中将其产品描述为接入遥测数据流，先削减费用、提取信号，再将信号用于 AI 辅助排障。
- 主持人：Jad 在斯坦福时期的同组旧识；持续从分布式系统的状态空间、真实负载及模型训练分布出发，质疑 AI 独立运维的可行性。
- AppDynamics：Jad 曾任职的公司；他以其规模化经历说明自己的工程与组织背景。
- Datadog：结尾客户故事中用来说明可观测性账单的产品名称；节目并未提供与之相关的独立价格对比。
“客户投入可观测性，真正想买的是可靠性。”
——据 Jad 关于产品切入口的表述意译
“模型不知道该给系统多少内存；答案必须来自实际实验。”
——据查询优化与生产测量段落意译
“目标不是让模型宣布发生了什么，而是让它沿着流程查清发生了什么。”
——据双方关于 AI 排障的讨论意译
“AI 所在的数字世界，与系统实际运行的世界，不一定是同一个世界。”
——据开场与结尾讨论意译
- “可观测”不等于“可诊断”：日志能留下现象，却未必记录一次部署的动机、跨团队约定或外部依赖的变化。因此，提高采集覆盖率之外，还需要把变更记录、服务关系和人的决策纳入调查流程。
- 验证成本决定自动化边界：若结果可通过测试集或性能基准快速判定，智能体容易形成有效迭代；若答案要等待真实流量或罕见事故，验证就更慢、更贵，也更需要风险控制。
- 信号压缩存在双重目标：减少遥测量可以节省费用，但排障往往依赖平时看来无用的上下文。好的压缩策略既要计算眼前账单，也要考虑未来复盘时丢失证据的代价。
- 智能体的下一步未必是“更会预测”：本集更有启发性的设想，是让智能体知道自己缺什么信息，并提出受控的查询、比较或实验来取得它；这与直接要求一次性给出根因不同。
- 节省 90% 的适用范围：需核实计费口径、接入前后的数据保留与查询能力、客户工作负载，以及长期运行成本。
- 十天对六个月的效率比较：需区分功能开发、测试、上线、维护各阶段；节目中的历史工时是估计，不是对照实验。
- 事故预警效果：应以足够长周期评估误报率、漏报率、预警提前量，以及收到提示后可采取的具体行动。
- “强工程师收益更大”：目前是 Jad 对小团队、特定系统工作的观察；不同团队与任务类型可能出现不同结果。
- AI 独立运维的时间表：嘉宾的乐观预期与主持人的长尾风险判断都属于观点；本集没有给出足以证明关键集群可无人值守运行的证据。
- 自动驾驶投资与单位经济的比较：主持人引用了约 20 年、1700 亿美元等说法作为类比；其统计范围与比较口径未在节目中展开，应另行核实，不宜直接用作行业结论。
- 先选可验证任务：从查询优化、测试补全、重复性排障步骤入手，为智能体提供真实样本、性能基准和明确的成功条件。
- 建立变化到调查的链路：让日志模式检测先提出候选信号，再关联部署记录、代码和历史事件；不要把原始海量日志直接交给模型猜根因。
- 为生产实验设护栏：限定智能体的读取与操作权限，规定实验影响范围、回滚条件和人工批准节点。
- 分别衡量成本与可靠性：既记录遥测费用变化，也记录事故发现提前量、处理耗时和复盘时可用的证据，避免只优化一张账单。
- 把人工审查留在关键路径上：智能体可以并行写实现和提出审查意见，但设计取舍、正确性标准及高风险上线仍应由负责的工程师确认。
