AI能写代码却管不好系统？一线创业者拆解运维自动化的真实瓶颈

AI编程工具在过去两年里彻底改变了软件开发的节奏，从Copilot式的自动补全到Claude Code驱动的多智能体协作，写代码这件事的边际成本正在肉眼可见地下降。但当话题从"生成代码"转向"让系统稳定运行"时，叙事就完全不同了。Grepr CEO Jed与投资人Martin的这场深度对话，罕见地把"语法"和"语义"、"代码分布"和"真实世界分布"这两组区分讲透了：AI在代码世界里的成功，未必能平移到运维世界。

从自动补全到20个PR：AI编程的真实生产力

Jed的团队只有10个人，却在构建一条完整的可观测性数据管道。他描述自己最近的工作方式：使用Windows + WSL + Claude Code，同时开三到四个会话窗口，让主实现agent和"tech lead reviewer"agent通过命令行互相review PR，先产出PRD和设计文档，人工逐项确认算法与分工后，再并行派发子任务。他提到一个具体项目——数据湖中的auto promotion（自动提升/列式撕碎），把半结构化日志的每个字段变成可独立过滤的列，涉及元数据系统、提交协调、多写入者一致性等复杂机制，过去单人需要约六个月，他用大约十天完成，全部是生产代码而非demo。

这种提效并非均匀分布。Jed观察到的规律很直接：好工程师用AI变得更好，差工程师并没有因此变好。原因在于，模型无法替你承担分布式系统的复杂度——任务拆解、上下文管理、子任务编排，仍然依赖大脑能装下多少复杂度。他特别提到一个实践细节：用命令行子agent而非内置子agent，因为前者能保持持久会话、跨会话复用，上下文效率更高；同时要明确告诉模型"不要为简单调研拉起20个agent烧光token"。

Claude Code 是 Anthropic 推出的命令行 AI 编程代理，它不同于 IDE 内的自动补全，而是以独立进程运行，能读写文件、执行命令、运行测试并自主规划多步任务。其关键设计是持久会话：每个会话拥有独立的上下文窗口，可跨多次交互保留记忆，因此适合承担长时间运行的子任务。开发者可以同时开启多个会话，让不同代理分别负责实现、审查或调研，并通过命令行互相传递 PR 链接与反馈。这种“多会话+子代理”模式能显著提升上下文利用效率，但也要求使用者主动管理 token 消耗，避免为简单任务启动过多代理。

语法易学，语义难仿：为什么运维不是代码问题的简单延伸

对话中最有价值的理论框架，是嘉宾对"语法"与"语义"的区分。语法是你敲下的字符，语义是机器实际执行时发生的事。模型在语法层面的成功，本质是因为代码的训练分布和代码的解空间高度重合——人类写过的代码构成一个可管理的流形。但一个系统的运行状态空间随每个bit指数增长，很快超过宇宙原子数，这正是chaos engineering多年未能落地的根本原因：状态空间爆炸得太快。

更关键的是，很多语义无法从语法推导，必须实测。Jed举了query optimization的例子：模型生成的SQL对应代码"看起来没问题"，但它最初完全没有做任何优化，重复的conjunct被反复计算；只有当把性能基准和真实查询数据集摆到它面前，它才提出假设、逐条验证并修好。而问到"该给系统分配多少内存"时，模型毫无概念——这类问题只能靠生产环境实验回答。

混沌工程（Chaos Engineering） 旨在通过主动注入故障（如随机终止进程、模拟网络延迟）来验证系统在异常条件下的行为，从而提前发现隐患。其理论根基正是“状态空间爆炸”：一个分布式系统的可能状态随节点数、消息顺序、时序等因素呈指数增长，远超可穷举测试的范围。实践中，混沌工程通常限定在受控实验内，针对已知的故障模式设计假设，而非覆盖全部状态。这也解释了为何它难以成为日常运维的默认手段——实验设计本身依赖对系统语义的深刻理解，而语义往往无法仅从代码语法推导，必须结合生产环境中的真实观测。

反向定位：为什么AI SRE大多从错误的一端切入

市面上多数AI SRE产品采用"后视镜"路线：指标飙升或告警触发后，回溯复杂系统找根因。Jed认为这条路走不通，因为反向回溯根因本身在复杂系统中就极为困难。Grepr的做法相反：先假设系统此前运行正常，用大规模聚类在每天PB级日志中找出"从未见过的模式"——一个全新的日志模板、一次资源耗尽的前兆——再由预测模型把异常信号抛给AI，让AI去读代码、查历史、验证因果链假设。

他透露了几个真实案例：内部系统和两家客户环境中，AI给出的早期预警有几次被人工忽略，随后都演变成了生产事故。这构成了一种有趣的交叉验证——预警的有效性由"被忽略后确实出事"反向证明。对话双方在这里形成了一个重要共识：AI不需要预测所有可能，只需要接管人类运维工程师的调试工作流——读报错、顺藤摸瓜、提出假设、验证假设，这套步骤是有限且可学习的。

AI SRE 指利用人工智能辅助或替代站点可靠性工程师（SRE）的部分工作，典型场景包括异常检测、根因分析和自动修复。当前多数产品采用“告警后回溯”模式：当监控指标越过阈值时，AI 在历史日志、调用链和变更记录中搜索可能原因。这种方法的局限在于，复杂系统的根因往往涉及多层交互，回溯搜索空间巨大且容易陷入虚假关联。相反，从“正常基线”出发检测从未见过的模式，再让 AI 验证因果假设，更符合人类工程师的调试直觉——先注意到“哪里不对劲”，再顺藤摸瓜，而非在告警风暴中盲目猜测。

分布式集群交给AI？答案比想象中保守

当被问及"AI能否运行一个分布式集群"时，Jed的回答分层且谨慎：query optimization这类边界清晰、有基准可量化的任务，"非常接近"可交付；但完整接管分布式集群运维，"还不行"。分歧点在于对状态空间的判断。投资人Martin引用系统史的经验：从虚拟内存到路由，人类每次都放弃精巧算法转而超配资源，因为真实负载不可预测；运维面对的是重尾、异常驱动、幂律分布的世界，与代码的温和分布截然不同。

Jed的乐观建立在另一个前提上：如果把运维看作"在有限步骤内完成因果链搜索"，而不是"预测无限状态"，问题就变得可管理。他承认这需要模型能自主规划实验、主动获取信息，而不只是被动推理。两人最终收敛到一个判断：代码问题接近解决，运维问题会晚得多，而安全运维因为存在主动对抗的对手，还要更晚。

真实世界的分布，才是AI的下一道墙

对话尾声回到一个更宏观的框架：AI在解空间分布与训练分布一致的领域会继续野火式扩张——代码、图像、文本都属此列；而解空间由物理世界决定的领域，会慢得多。Martin用自动驾驶举例：DARPA Grand Challenge之后外界以为拐点将至，结果花了约20年和1700亿美元投资，单位经济性仍不如Uber。这不是技术不行，而是经济均衡点由真实世界的分布决定。

一个耐人寻味的商业细节印证了这一点：Grepr向客户同时推销"AI驱动的可靠性"和"节省90%可观测性账单"，客户几乎无一例外先买后者。代码工具的价值可以直接折算成工程人天，而运维AI的价值要挂在"避免一次事故"这种难以定价的账上——这或许比技术本身更能解释，为什么AI运维的商业化节奏远慢于AI编程。

重尾分布与幂律分布 是描述真实系统负载的常见统计特征：大多数事件较小，但极端事件的发生概率远高于正态分布的预测。例如，请求延迟、故障间隔、流量峰值往往呈现重尾，意味着“罕见”的超大值出现得比预期频繁得多。这类分布下的系统设计不能依赖平均情况，而必须为极端情况预留冗余。Martin 引用系统史指出，从虚拟内存到路由，人类反复放弃精巧算法转而超配资源，正是因为真实负载不可预测且重尾。AI 若要在运维中立足，必须理解并适应这种分布特性，而非假设一个温和、可建模的世界。