Jad Naous（Grepr 创始人兼 CEO）¶

来源：a16z / 为什么 AI 能写代码却还不能让它持续运行（本页全部时间戳均出自该期；它也是本库目前收录他的唯一一期）

现任：Grepr 创始人兼 CEO（2023 年起）——可观测性数据流上游的信号提取 + AI 排障
此前（均为自述，[00:01:00]–[00:07:05]）：
Applied Intuition 首席产品官（约 3 年，自述把团队从 15 人带到 90+，覆盖产品 / 工程 / infosec / 设计）。⚠️ 他说离开的原因是组织形态而不是业务："我手下每一块都有了一个负责人，而我基本就坐在那儿协调、整天开会，就想去做点别的。"
a16z 投资人（约两年）。⚠️ 是 Martin Casado 把他招进去的："来跟我一起做 VC 这件事" —— "我说：什么是 VC？我是个架构师，我做工程的东西" —— "他说：太好了，你知道得越少越好。" ✅ 他自己给的转行观察："从真正做事的世界转到 VC，需要大量重接脑回路。"
AppDynamics 约三年半（自述任内 200 人 → 2000 人，被 Cisco 收购，"我当了一天的 Cisco 员工"）。
学术：斯坦福（OpenFlow，并为论文做了最早一批被考虑采用的 SHA-3 硬件实现）；MIT 博士后（导师在稿中作 "Nikolai Zelda"，本库按 Nickolai Zeldovich 读）。⚠️ 与 Casado 是研究生同一个组的同学（Casado 早四年入学）。
⚠️ 一次失败的创业：基于合作者（稿中作 "Ramsh Chandra"）的博士工作——"如果你被攻击、被利用了，能不能通过把与那个应用相关的整个世界的状态回滚、再把它滚到一个打过补丁的版本上，来移除那个漏洞"。⚠️ 结论是技术太早，而他自己点出这与本期主题同源："它其实和我们在聊的东西挺相关的——即你到底能在多大程度上给运维系统的状态划定边界，而我会主张这非常难。"
⚠️ 一句关于兴趣的自述：他做完网络之后"决定其实我不喜欢网络，因为它就是把比特从一个地方搬到另一个地方"。Casado（Nicira 创始人）的回应是 "大多数人假设它不深，我认为它非常深"。

已收录：a16z / 为什么 AI 能写代码却还不能让它持续运行（2026-10-16，59 分钟，Martin Casado 主持）

⚠️⚠️ 必须前置的关系披露：他与主持人是研究生同组同学，而且 Casado 当年把他招进 a16z。⚠️ 本期没有说明 a16z 是否投资了 Grepr，频道通用免责声明称"a16z 及其关联方可能持有所讨论公司的投资"。✅ 本库按"旧友之间的技术对谈"收录——这个关系也正是本期质量高的原因（两人互相打断、互相不让步、有三处当场让步），但 Grepr 的全部业务数字与效果均为自述，本库一条未核实。

一、⚠️⚠️ 他的核心论证：可学习的对象不是状态空间，是排障步骤¶

来源：a16z / Grepr

✅ 本库认为这是他在本期贡献的最可迁移的一条，而且它是针对 Casado 那条"状态空间比宇宙原子还多"的直接反驳（[00:39:24]–[00:40:24]，由 Casado 复述、他连说两次"正是如此"确认）：

"宇宙是重尾的。能出的坏事的数量大概是个例外性的东西，但用来 debug 它的那组步骤是个可管理的东西。那才是你能教给这些模型的……因此如果你给它正确的信号，它就能走过若干步骤去把这个问题约束下来。"

他自己的表述是把目标改写：⚠️ "所以目标不是让模型就说'这就是发生的事'，而是'跑这个工作流，去确定发生了什么'。"
✅ 他给的历史接点："它真的是在接替人的角色。因为你记得整个 chaos engineering 那一波——它之所以没走到哪儿，是因为你很快就要去把一个'宇宙里原子那么多'的状态空间压成可管理的；而真正在做这件事的，一直是那个在实际 debug 时一步步走过去的人。"
⚠️ 他的第二个支点是数据，但当场被限定了：他说 "我的假设是我们有全部的数据"（新东西出现、例外涌现、工作负载变化，"在我的世界里这些都已经被采集、被流过去了"），⚠️⚠️ Casado 立刻打断："但模型没有在那种有依据的来源（grounded source）上训练过。" —— 他承认："没有，你没有。" ✅ 本库认为这是他全期最重要的一次让步：它把"我们有数据"与"模型用得上这些数据"分开了。
他的应对是改变用法：⚠️ "但这里的故事不是'嘿 Claude 先生，这是一堆日志，有什么事吗？'。它必须更能跑实验、深入进去，看看在现有的环境里，有哪些不同形状的可能因果链是吻合的。"
⚠️ 他的第三条论证是归纳而不是机制，本库标明："当我们开始做 AI 写代码的时候，它是自动补全。没人真的知道你能用 AI 造出多复杂的软件……然后它基本上突破了预期，因为我们能把系统里越来越多的复杂度建模进去。" → "如果我们能让它在代码上 work，我们就能一层一层继续加上去，直到能处理那些问题。"
✅ 一处标签互换值得记（[00:46:30]）：他自称 "也许我只是太宿命论、太悲观了，我把一切都想成在走某种概率路径"，⚠️ Casado 的回答是 "这不是宿命论，这是相反。大家会说这非常乐观。"

⚠️ 他自己给的、对"全部遥测"最诚实的一处削弱¶

（[00:33:24]–[00:34:24]）他先承认 "人类也是按 runbook 操作的"，然后主动给反例：

"生产里确实有很多事最终需要一个人去说'这太复杂了'。有些状态是隐藏的，而我知道它，是因为我前几天在饮水机旁跟另一个人聊过，他跟我说了他部署的那个东西。"

✅ 而他的回应是把它定成目标："但我会主张，我们需要做到的目标是：有足够的遥测、足够的理解，让一切都真的可见。" ⚠️ 本库标注这是目标陈述，不是现状描述。
⚠️ 他也承认运维难不只因为技术（[00:45:28]）："它涉及的人多得多，不只是一个写代码的人" —— Casado 接 "知识池也是分布式的" —— "正是如此。"

二、⚠️⚠️ 时间判断：同一分钟里的一个"是"和一个"否"¶

来源：a16z / Grepr（[00:36:24]）

问	答
AI 做掉人在 query optimization 上的那份活，还有多远？	⚠️⚠️ "我觉得非常近。"（被追问"真的？"——"是。"）
跑一个分布式集群呢？（Casado 具体化为"集群挂了公司就不工作"）	⚠️⚠️ "还没有。"

✅ 而他对前者的乐观有一手依据（[00:27:19]–[00:29:22]）：他最近的项目就是查询优化，做法是先把性能基准和系统应如何运行定义清楚，⚠️ 成立条件被他说得很明确："它之所以能做得还不错，是因为它能把这件事锚定在性能基准上——我说：这是查询的数据集、这是用户在问什么，去干吧。"
过程里的一处失败值得记："它起初根本没在做任何优化——'哦，这挺好啊，看起来没问题'。我说：你看，你这里做了这些 conjunct，而这个项是重复的，本该被去掉。" 然后它才去建立一堆优化假设。
⚠️⚠️ 而他给的明确"AI 做不到"在同一段："当问到'我该给这个系统多少内存'这类事——它完全不知道。那必须来自在生产里真正跑起来的实验。"
✅ 他认为当下模型做得好的恰恰是知道自己不知道："它知道'这个问题我大概答不了，让我想办法跑个实验、把那个信息拿出来'。"
⚠️ 但他自己紧接着限定："当然，生产系统不会按你期望的方式运行——而那归根结底就是为什么会出事故。"

三、产品路线：明确反向于"AI SRE"¶

来源：a16z / Grepr

⚠️⚠️ 他对现有路线的批评（[00:30:22]）¶

他指出的共同错误："很多那类系统基本上从一个滞后指标开始——这个 metric 尖刺了、这个告警触发了——然后回溯一个非常复杂的系统，试图确定为什么会发生。"
判断：⚠️⚠️ "那就是为什么那些不 work——因为回溯到根因其实非常有问题。" ⚠️ Casado 先给了外部印证："轶事性地说，我听到别人做这件事的反馈并不好。"

✅ 他们的做法：先找"什么变了"，而且检测层是确定性的¶

（[00:30:22]–[00:36:24]）✅ 这段架构是 Casado 三次追问逼出来的，本库认为是本期信息密度最高的一处：

⚠️ Casado 的质疑："我从来不觉得这些生成式模型擅长预测，而你一直在讲预测建模……是我想错了吗？" —— "不，你没想错。因为目标其实不是让那个 agent 去预测，而是让它拿到一个'有东西变了'的信号。" —— Casado："哦，确定性地。我明白了。" —— 再确认 "所以是有一个单独的模型做预测那部分，然后它去提醒那个 AI？" —— "是的。"
流程："你给我们你每天一 PB 的日志，我们扫描全部。每次我们看到你的日志里浮现出一种新的模式、一个我们以前没见过的东西，我们就把它提给 AI。"
AI 那一层做推理不做检测："这条消息——让我去看代码、搞清楚它从哪来、理解这段代码做什么；让我看看它以前是不是发生过……它基本上跑所有这些假设和启发式。"
盯的信号是最早的那条消息：error connections ran out / memory exceeded / resource buffer is emptied 这类 "某种真的很早的预警"。
✅ 本库标注：这个"确定性检测 + LLM 推理"的分工，正是他第一节那条核心论证在产品上的实现。

⚠️ 唯一一条带结果的证据，形式是漏报代价¶

（[00:31:23]–[00:32:23]）"目前为止做得挺好。我们在自己的系统里跑，也在我们几个客户的环境里跑过" ——

⚠️⚠️ "有几次我们忽略了它。而那些变成了生产事故。"

✅ 本库认为这个证据形式值得单独标注：它报告的不是准确率或召回率，而是"我们没听它的那几次，代价是什么"。 ⚠️ 而代价也在这里：没有任何数量（几次、多少告警、误报率），且为自述。 ✅ 按"方向性证据"收录，不按效果收录。

⚠️ 他对可观测性市场的诊断（[00:07:05]–[00:09:05]）¶

支出量级（自述）：企业在可观测性上花的钱约为基础设施支出的 5%–20%。
⚠️⚠️ 诊断："他们真正想花钱买的是可靠性……所以他们是把钱投进可观测性，当作可靠性的一个代理（proxy）。" ⚠️ 注意 Casado 这里插了一次误解（"花费的可预测性"）并被他纠正为"可靠性"。
⚠️ 失效机制：微服务让单元更小更垂直整合 → 每一层的数据量膨胀 → "可观测性的成本开始增长得比你输出的功能单位更快，而每多花一美元换来的边际可靠性增量就是在变平"。✅ 他的结论是需求没变、回报塌了："人们仍然愿意为可靠性付那 5% 到 20%。"
⚠️ 他坦白的战略算盘："那时候有个叫 AI 的东西正在进入画面，我们就想：如果我们在数据流里、而且我们在提取信号，那我们就处在一个战略位置上，可以把它喂给未来会出现的任何东西。"

四、工程方法论：一份带硬限制的一手记录¶

来源：a16z / Grepr。⚠️ 全部为自述。

栈（[00:18:13]）：Windows + WSL + Claude Code + Opus 5.5。⚠️ 用 Windows 的理由："我就是从来不想去学那些键盘快捷键……我讨厌单键鼠标，我讨厌为了一个快捷键要按那么多修饰键。"
⚠️⚠️ 产出与 review（[00:19:14]–[00:20:16]）："过去两周我 ship 了这些巨大的、20 个 PR 的东西，直接丢给我的团队去 review。" ⚠️ Casado 挑明其组织含义（"新的汇报结构就是下面的人给 CEO review PR？"），✅ 回答比玩笑更有信息："不，所有人都在写同样的 PR……PR 到处乱飞。"
✅⚠️⚠️ review 重心的转移："在 review 周期里变了很多的是，我们开始更多地聚焦在测试上，以及做 golden expectations 这类事——它们是不是在以不同的方式漂移。" ✅ 即人工审查的对象从"这段代码对不对"挪到了"预期输出有没有漂移"。 ⚠️ 他没有给这条做法的失败模式。
⚠️ 一条与同日另一期方向相反的子 agent 技巧（[00:20:16]）："不要用（内建的）sub agents，而是告诉 Claude 去起命令行子 agent，因为那些能在时间上保持持久会话"，好处是 "在上下文方面高效得多"。⚠️⚠️ 而同一天 Latent Space 那期转述的 Codex 侧口径相反（子 agent 更好，因为缓存优化）。✅ 本库不裁决，但指出两边优化目标不同：那边是缓存命中与速度，这边是会话持久性与上下文效率（且他用的是 Claude Code）。
✅ 并行度的瓶颈是人，而且他给了数字（[00:21:17]）："我通常同时开三到四个会话窗口，因为超过这个数我就开始在不同事情之间丢失上下文——它们完成得更快，然后就得等着我。"
agent 协作结构（[00:21:17]–[00:22:18]）：不走 PR，直接走命令行；让实现 agent 配一个 "tech lead reviewer"，"它们一起在这些 PR 上迭代"，并共用一份 PR doc + design doc。✅ 他的人工把关点在最前面：先让 agent 写 PR doc、让 tech lead review，然后他自己逐块确认算法、分工、PR 之间的关系，再放它去并行实现。
⚠️⚠️ 而他给的硬限制必须与"20 个 PR"一起读："但最终你必须把它全部放回一个栈里，作为一个人类一个一个过——否则它就会变得又乱又枝节横生，你根本没法收拾。"
⚠️⚠️ 量化（[00:22:18]–[00:24:18]）：data lake 的 auto-promotion / shredding（把日志事件里每个字段提升成可独立过滤的列）——"大概花了 10 天。在以前的日子里，那大概要 6 个月"，"一个人，就是我自己"。✅ Casado 在听数字前先确认了"这是生产代码，不是 demo mockup"，并归纳为 "10 倍、20 倍的改进"。
✅ 本库的读法：⚠️ 他同时说过"没有哪个模型能真正想通我们做的事"，所以这个 10 倍不是来自模型替他想，而是来自他把想清楚的东西交给模型去实现——正对应他那个"人先过 PRD 与 design doc"的流程。

⚠️⚠️ "AI 开始训练他们"，以及"差距乘了 10 倍"¶

（[00:11:06]–[00:14:07]）

✅ 方向被他反过来说："真正好的工程师能以某种方式把它放进自己的工作流，而在那种方式里，AI 开始训练他们"——训练的是 "怎么跟它说话、怎么从它那里拿到最好的东西"。
harness 也是要学的对象：他试过 OpenCode、Codex、Claude Code，"不同的 harness 在管理上下文、思考问题、何时起合适的子 agent 上做法不同"。✅ 具体例子："用 Claude Code，如果我不告诉它'别为了做基础研究起 20 个 Fable agent'，它就会去起 20 个，把你的 token 全烧掉。"
⚠️⚠️ 断言（[00:13:07]）：团队变大后 "还行的工程师和真正好的工程师之间的差距，就是乘了 10 倍"。⚠️ 被 Casado 精确追问"是好工程师变更好，还是差工程师突然变好" —— "不是。如果你是个好工程师，你只是变成一个更好的好工程师。" 机制："你脑子能处理的复杂度越高，你就越能把任务拆开、分派出去。"
✅⚠️⚠️ 而本库认为必须连带引用他自己加的两条限定：① "我的团队还小，我们没有在 100 个人身上做过"；② "对我们做的事情是这样的，因为我们造分布式系统和分布式算法，而你的脑子必须处理那个复杂度——因为 AI 不做这件事" → "对我们解决的问题，没有哪个模型能真正想通我们做的事。" ✅ 即这条"10 倍差距"被锁在"模型还想不通的问题域"里，而本期后半的全部辩论就是在问这个域会不会缩小。 详见 AI 与就业。

五、他承认的两处难点与一处商业冷水¶

⚠️ 他 100% 同意运维更难（[00:44:28]）：Casado 说"做运维的公司日子很难过，这是个难得多的问题"，他的回答是 "我 100% 同意。它是个难得多的问题。" 并补上非技术的那半：外部随机负载、"有人刚 ship 了个新东西推到生产但没告诉任何人"、"这件事发生、那件事发生，然后你进了死锁"，以及涉及的人多得多。
⚠️⚠️ 而本库认为最该记在他名下的商业观察是那个冷水故事（[00:56:39]）：他们带着 AI 可靠性产品去见客户，"他们说：等等等等，往回倒。你刚说你能省我们 90% 的 Datadog 账单？那才是我想买的东西。" —— "但那个 AI 的东西呢？" —— "不不不不。那（降本）才是我们现在想买的。"
✅ Casado 的概括："代码这块人们就是懂……而在运维侧，很难理解它的实际价值、很难给它标一个美元数、很难让人付钱出门。" —— 他："100%。"
⚠️ 他尝试给运维找对应的科目但没说服自己："你也可以把它想成 SRE 生产力，或者是你的业务宕掉——也许你能救下一次事故，那个成本是多少。" 然后自己接 "我不知道。这很怪。" ✅ 本库照录这处没说完的论证，详见 AI 商业与价值捕获。
✅ 他对自己所处阶段的定性（[00:57:39]）：Casado 说运维这块 "现在还很早"，他的回应是 "还很早。"