为什么 AI 会写代码，却还无法让代码持续运行（目前）
摘要
- AI 编程已从自动补全迈入工业级杠杆阶段，但收益明显更多落在本就理解复杂系统的工程师身上。 Martin Casado 说，他独自用 10 天就交付了数据湖“自动提升”功能的生产代码，而过去大约需要 6 个月。Jad Naous 称这是“10 至 20 倍的提升”。但他也明确指出，团队规模很小，不能代表 100 人样本；“这并不是说一些糟糕的工程师突然就变成了好工程师。”
- 瓶颈已从编写语法转向架构设计和行为验证。 Jad 同时运行 3 到 4 个 Claude Code 会话，让代理审阅设计文档和 PR 文档、并行实现，再由他亲自“逐点”整合成果。他说自己用 Windows 和 WSL，提到 Opus 4.5，之后又介绍了一个使用 Opus 5 的技巧。大型 PR 越来越容易生成，测试、基准测试、算法、职责边界和人工审查的重要性也随之上升。
- 代码和运维所处的可学习分布，可能有着根本差异。 Martin 认为，语言和代码能把高维世界压缩成易于处理的表征；而生产系统面临罕见状态、不断变化的工作负载、隐藏上下文，以及“长尾、例外、幂律”。系统发展史也印证了这种难度：运维人员往往不追求完美预测，而是反复选择“超额配置”资源。
- AI 运维需要信号和调查能力，而不只是原始日志或滞后的告警。 Martin 说，应该寻找环境变化和早期预警信号，而不是等指标飙升后再试图推断根因。Jad 随后介绍，他们每天扫描多达 1PB 的日志寻找新模式，再将异常信号交给 AI 代理；代理会检查代码、搜索历史、提出因果假设并运行实验。
- 早期运维成效令人鼓舞，但距离自主管理集群仍有很大差距。 Martin 说，这套系统已在内部和少数客户环境中运行；有些团队忽视的信号，后来确实演变成生产事故。Jad 认为 AI “已经非常接近”取代人工查询优化，但被问到 AI 能否独立运行一个一旦故障就会拖垮公司的分布式集群时，他的回答是“还不行”。
- 最清晰的商业切入口是可量化的成本节省，而不是抽象的 AI 可靠性承诺。 公司曾将基础设施成本的 5%–20% 用于可观测性，但可靠性提升的边际收益不断下降；Jad 说，Grepr 会先把遥测成本削减 90%，再利用提取出的信号排查问题。客户会先听可靠性方案，随后还是回到眼前的预算：“你说能帮我们省掉 Datadog 账单的 90%？……我想买的就是这个。”
- AI 能否拓展到数字领域之外，取决于能否约束环境并找到经济上的平衡点。 Jad 认为，模型可以开展实验、应对现实世界的复杂性；Martin 则保持谨慎：自动驾驶用了 20 年、投入 1,700 亿美元，最后的“单位经济效益还不如 Uber”。Martin 认为未来几十年仍会创造大量价值，但运维 AI 必须证明，它能以足够低的成本驾驭现实工作流，才能真正部署。
精读
1. 可观测性成本曲线先失控，AI 替代方案随后才出现
Jad 的公司最初面对的是 2023 年的成本问题：工程负责人想削减开支，而基础设施之后，可观测性总会被列为下一个成本目标。公司把基础设施成本的 5%–20% 花在遥测上，本质上买的是可靠性和成本可预测性。
随着架构拆分为规模更小、垂直整合程度更高的微服务，这笔账越来越不划算。遥测覆盖了更多层，增长速度也超过了被监控的业务单元；“可观测性每多花 1 美元带来的可靠性增益，已经趋于停滞。”可观测性越来越像昂贵的噪声和保险。
Jad 的应对方式是在数据摄入时提取有效信号，而不是把所有内容都留到下游处理：将系统接入数据流，把遥测成本降低 90%，再把保留下来的信号送入 AI 层，用于诊断和补救。真正的战略资产不只是更便宜的存储，而是实时流动、对运维有意义的事件。
2. AI 放大的是系统判断力，而不只是打字速度
Jad 亲眼看到编程 AI 迅速从 Copilot 自动补全——“看，它把这些测试自动补出来了”——演进为一套工作流，教会有能力的工程师如何与 AI 协作。不同模型和工具保留上下文的方式不同，挑选代理的方式不同，所需的提示习惯也不同；如果不加约束，Claude Code 可能会为了普通调查“启动 20 个代理”。
工程师之间的表现差距不但没有缩小，反而扩大了。根据 Jad 的有限经验，优秀工程师变得更强，弱一些的工程师却不会突然变成强者：“你的大脑能把握的复杂度越高，就越能把任务拆分并分配出去。”他明确说明，这个判断来自一个规模很小、从事分布式系统和算法开发的团队，并非针对 100 人进行的普遍性测试。
Jad 使用 Windows、WSL 和 Claude Code。他说自己用的是 Opus 4.5，之后又提到一个使用 Opus 5 的技巧。他通常同时使用 3 到 4 个会话窗口；会话更多反而适得其反，因为产出快到他来不及保留上下文。常驻命令行的代理可以担任实现者和技术负责人，互相质询、审查 PR，并围绕共享的设计文档反复迭代。
人类的工作向前端和后端转移。Jad 会先审阅 PRD、设计、算法、职责边界和依赖关系图，再让代理动手；之后，他会“像人一样逐点”重组成果。现在的验证周期更强调测试、执行和基准测试变化，因为生成超大型 PR 已经很容易。
3. 10 天完成开发，不代表代码与实际行为之间的差距消失
Martin 最有说服力的效率案例，是数据湖“自动提升”功能的生产代码：把半结构化日志中的任意字段转成可独立筛选的列，格式包括 Parquet 或 Iceberg。工作涉及元数据处理、提交语义，以及协调不同作者。Martin 说他独自用了约 10 天完成；按他的估算，以前大约需要 6 个月。Jad 称这是 10 至 20 倍的提升。
Martin 指出，生成出来的语法并不能决定代码运行时的表现。可用性、正确性、一致性、缓存、锁和性能，都取决于负载、访问模式、模式、配置和实时数据。Jad 举了自己开发的 Gaussian-splat 分布式渲染器为例：AI 生成的结果“简直一塌糊涂”，因为数百万个 splat 如何加载、卸载和流式传输，取决于具体系统。
Martin 发现，只要能把行为转化为可衡量的反馈，模型就很有效。在查询优化中，模型一开始看不出重复的合取条件有什么问题，生成的代码也很差；但当它拿到具体查询数据、用户工作负载和性能指标后，就能提出假设并改进实现。可如果只问“我应该分配多少内存？”，没有真实实验的话，“它完全不知道”。
4. 有效的 AI-SRE 将异常检测与因果推理拆开
Martin 描述了一种不同于许多 AI-SRE 产品的做法。那些产品从滞后指标入手——比如指标飙升或告警触发——再试图在复杂系统中推断根因。他认为这就是它们效果不佳的原因：事后追溯根因很棘手。相反，他主张寻找环境变化和早期信号，再倒查这些信号是否预示着真实问题。
Jad 随后介绍，他们每天会扫描 1PB 日志，寻找新模式。预测模型检测到异常后，会把信号交给 AI 代理；代理可以检查产生相关消息的代码、搜索过去是否出现过类似情况、测试假设，并决定下一步行动。目标不是让代理预测未来，而是给它一个“有变化发生了”的信号。
Martin 说，这套系统已在内部和少数客户环境中运行；有些情况下，团队忽视的信号后来演变成了生产事故。
5. 状态空间可能极其庞大，排查流程却仍可控
Martin 怀疑运维问题是否也像代码一样，存在易于处理的分布。程序每增加 1 bit，可能的运行状态就翻一倍；数量很快便会超过“宇宙中的原子数”。罕见故障、幂律长尾、不断变化的工作负载和隐藏状态——可能只是因为“茶水间有同事提了一句”才有人知道某次部署——使长期运行的集群离不开人工介入。
系统发展史也让他保持谨慎。设计者曾反复尝试实现智能虚拟内存管理、拥塞控制和自适应路由，但生产实践最终往往选择预留更多容量：“我们一直都在超额配置”（“We overprovision all the time”）。一旦发生磁盘交换，电脑就等于瘫痪；运维人员宁愿多买 RAM，也不追求完美预测需求。
Jad 认同运维“难得多”，因为它涉及外部负载、未提前通知的部署、连续发生的故障状态、多人协作和分散的信息。但他认为，大多数事故都发生在某次变更之后；只要遥测足够完整，即使训练数据中从未出现过最终的故障状态，系统也能观测到导致变化的那次变更。
两人的部分共识是，故障空间可能近乎无限，但调查流程的维度要低得多。AI 不必记住每一种坏状态；它可以提出假设、索要证据、编写实验，并模拟那些无法省略的步骤。Martin 认为，模型或许能走到一个“事件视界”，解决所有无需实际执行的部分。
6. 现实世界中的 AI，最终考验的是经济性
安全问题会进一步增加难度，因为罕见状态并非偶然出现：对手会主动寻找防御者无法预料的行为。Jad 仍然沿用同一套流程——检测统计或行为上的扰动，让 AI 提出可能的因果结构，再测试哪种结构最符合观测数据——而不是指望某个模型从原始日志中直觉判断出攻击。
Martin 预计，在解决方案与训练数据分布重叠的领域，进展会最快，比如代码、图像和其他边界明确的数字领域。现实世界系统需要更长时间，成本也更高。他用自动驾驶作为警示：从 Stanford 的 DARPA Grand Challenge 点燃乐观预期，到真正部署花了 20 年、投入 1,700 亿美元，结果“单位经济效益还不如 Uber”（“worse unit economics than Uber”）。
Jad 反驳说，人们可以改变环境来适应自动化，就像仓库那样，而不是逼 AI 掌握一个不受约束的世界。Martin 认同，约束系统会改变经济平衡：只要投入足够多的算力和资金，几乎任何问题都可能解决，但只有一部分方案能实现有吸引力的单位经济效益。
买家已经表明了这种平衡点在哪里。Jad 推销主动式可靠性方案，客户却会打断他，追问能省多少钱：“你说能帮我们省掉 Datadog 账单的 90%？”（“You said you could save 90% of our Datadog bill?”）编程工具容易卖，因为开发者效率直接对应一个主要成本中心；运维 AI 仍处于早期，价值更难衡量，商业上最有力的切入点仍是立竿见影的预算削减。