文章探讨 AI 在 SRE、监控、自动化运维等基础设施场景中的具体应用方式与工程收益。
眼下所有公司都在一股脑地全面拥抱 AI——把所有上下文都喂进去,在每个仓库里写一份 AGENTS.md 或 INSTRUCTIONS.md,让任何项目都能被 AI Agent 发现和贡献,而不只是人类。说起来有点好笑:我的队友从来没真正读过 README,而现在我们写的文档比以往任何时候都好,只不过读者换成了机器人。随之而来的问题显而易见:工程这件事是不是要失业了?一旦关于一套技术栈及其基础设施的所有上下文都被写进了某个 AI 能读取的地方,我们是不是就要被替代了?
我觉得这个问题本身问得不太对,因为我们其实已经经历过一次类似的事了。
Kubernetes 有没有干掉 Ansible?算是吧。我已经好几年没手写过 Ansible playbook 了——要是现在给我一个,我得眯着眼睛看模块语法,就像从没见过的似的。配置管理并没有变得不重要。Kubernetes 只是让服务器管理变得足够简单,以至于我们彻底不再构建自己的节点镜像了——直接用云厂商给我们的东西,用 AWS 帮我们建好的 AMI,不问为什么。上次 SSH 登录到节点上调试是什么时候?基本没有了。如果某个节点出了状况,我就把它干掉,希望替换上来的那个不会有同样的问题。再往上一层也是一样:用 ECS Fargate、Lambda 或者 Cloudflare Containers 运行一个容器,我根本不知道、也不关心它跑在哪台节点上——但这不代表没有人来做编排工作,而是代表我仍然在决定这个工作负载应该是一个容器,用什么镜像运行,它可以访问什么,如何扩展,出问题时怎么办。Kubernetes 和无服务器容器并没有移除那一层决策,只是把工作的单位从"机器"提升到了"工作负载",而那层以下的所有东西都悄无声息地自动化掉了。
没有人会说 Kubernetes、Fargate 或者 Cloudflare 的容器平台取代了基础设施工程师。每一个都只是取代了某一层手动工作——手动构建镜像、手动打补丁、知道某个工作负载跑在哪台节点上——而工程师每一次都会往上一层迁移。我认为 AI 正在做同样的事,只不过再往上一层。
我每天用 Claude 生成 Helm chart 和写 Terraform 模块。它真正从我的日常工作中抹掉的不是思考环节,而是查资料的工作。我不再通读 AWS provider 的 changelog 来搞清楚 v5 和 v6 之间有什么变化;我只需要描述我想要什么,告诉我希望这个模块或 chart 最终成什么样子,Claude 就会给我生成一个版本。要把它打磨成我真正能交付的样子需要几轮迭代,但一旦成型,它就成了下一次的参考——尤其是仓库里有 AGENTS.md 指向它的时候。
往下一层的情况也类似:我不再手写原始 Kubernetes YAML 了,就像我不再手写 Ansible 模块一样——那本来就是 Helm chart 干的事。现在越来越连 Helm chart 我也不手写了——我现在跑的"chart-as-a-dependency"模式,就是我描述给 Claude 然后让它先起草的那种东西。我来指挥它应该做什么,Claude 来写。
我仍然需要知道一个好的 Terraform 模块或者结构良好的 Helm chart 长什么样。当真的出了大问题、不能简单杀掉节点了事时,我仍然需要能 SSH 进去——上一层并不会移除下一层,只是降低了你触达它的频率。我仍然是决定最终形态的那个人:模块最终长什么样,一年以后还能不能维护,chart 应该如何部署和版本化。AI 做的是耗时的那部分。我来给方向。
诚实的权衡:我现在构建和调试东西的速度比两年前快了很多,但我也明显比那时候更生疏了底层基础。我的 HCL 语法记忆已经不如从前。四年前我手写过一个嵌套 for 循环——四层嵌套,在另一个 AWS 账户里给跨区域和可用区的子网打标签——光是把语法写对就花了我大约一个小时:
locals {
subnet_tags = merge([
for account, regions in var.accounts : merge([
for region, azs in regions : merge([
for az, subnets in azs : {
for subnet_id, tags in subnets :
"${account}/${region}/${az}/${subnet_id}" => tags
}
]...)
]...)
]...)
}
四层 merge([...]...) 叠在一起,只是为了把一个 map 的 map 的 map 的子网展平。Claude 现在几秒钟就能写出等价的代码,如果现在让我从头写一个,我真得坐下来想一会儿。我在 SSH 上调试故障节点的反应速度比以前慢了一点——那时候那是我唯一知道的方法。我能感觉到这件事正在实时发生,就像很多在 Kubernetes 出现之后成长起来的工程师从来没有真正学过手动制作节点操作系统镜像一样,这也没什么,因为根本不需要。
我不太确定的是"我来给方向"这件事能维持多久。现在是我来决定一个技术栈的长期形态,因为我有上下文而 AI 没有——真的没有,最多就是写在某个仓库的 AGENTS.md 里的一点东西。但这恰恰是那些公司级 AI 推广计划试图弥合的差距:给 AI 完整的上下文,而不只是单个仓库的。如果这真的可行,一个对整个基础设施有真正长期视角的 AI——不只是这个 Terraform 模块,而是多年以来在每个仓库里做出的每一个决策——最终可能比我规划得更好,就像我没法比一个读过我用过的每个 provider 的每个 changelog 的工具更会调试一样。
我认为 AI 还在消化"给方向"之下的那一层。我不完全相信这就是最后一层。五年后再来问我,"我来给方向"到底是全部的故事,还是只是我写这篇文章时恰好站的位置。