AI与基础设施工程

# AI 与基础设施工程 来源: https://omegion.dev/2026/08/ai-and-infrastructure-engineering/ 2026年8月23日 · 阅读时长 6 分钟 ## 引言 当下正有一股风潮，推动整个公司全面拥抱AI——将所有上下文信息都喂给它，在每个代码仓库里编写`AGENTS.md`或`INSTRUCTIONS.md`，这样任何项目不仅能被人类发现和贡献，也能被一个智能体（agent）做到。细想之下颇为有趣：我从未见过哪位人类队友真正读过README，而现在我们却都在编写比以往更完善的文档，只不过目标受众从人类变成了机器人。随之而来的问题显而易见：这会让工程师变得多余吗？一旦关于技术栈及其基础设施的所有上下文都被写在某个智能体可读的地方，我们是否就是下一个被淘汰的？ 我不认为这完全是个正确的问题，因为我们已经经历过一个类似的版本。 ## 我们曾经历过类似变革 Kubernetes杀死了Ansible吗？某种程度上是的。我已经多年没写过Ansible playbook了——如果现在有人递给我一份，我会像第一次见一样费力辨认其模块语法——这并非因为配置管理不再重要，而是因为Kubernetes让服务器管理变得足够简单，以至于我们完全停止构建自己的节点镜像——我们直接使用云服务商提供的任何东西，一个为我们构建的AWS AMI，毫不质疑。上次我通过SSH登录节点调试是什么时候？几乎从来没有。如果一个节点出问题，我就直接干掉它，指望替换的节点不会有同样的问题。再上一层也走了同样的路：在ECS Fargate、Lambda或Cloudflare Containers上运行一个容器，我真的不知道也不关心它落在了哪个节点上——但这不代表没人负责编排它，而是意味着我当初就决定了这个工作负载应该是一个容器，它运行什么镜像，可以与什么通信，如何扩展，失败时怎么办。Kubernetes和无服务器容器并没有移除那一层决策，它们只是将工作单元从“机器”提升到了“工作负载”，而那层之下的所有事情都被悄悄地自动化掉了。 没人会说Kubernetes、Fargate或Cloudflare的容器平台取代了基础设施工程师。每一个都取代了一个特定的手工操作层——手工构建镜像、手工修补系统、获知一个工作负载落到了哪个节点——而工程师们每次都向上移动到了更高的层级。我认为AI正在以同样的方式再次发生，只是位置更高了一层。 ## 日常工作的变化 我每天使用Claude来生成Helm图表和编写Terraform模块。它真正从我日常工作中移除的并非思考——而是查证工作。我不再需要阅读AWS提供商的更新日志来搞清楚v5和v6之间到底改了什么；我描述我想要什么，以我希望模块或图表最终呈现的任何形态，Claude就会生成一个版本。需要反复迭代才能使其达到我真正可以上线的状态，但一旦完成，它就成了下次的范例——尤其是在代码仓库中存在一个指向它的`AGENTS.md`时。 同样的事情早些时候在下一层也发生了：我不会手工编写原始的Kubernetes YAML，就像我不会手工编写Ansible模块一样——那就是Helm图表的用途。渐渐地，我甚至不再手工编写Helm图表了。我指示它应该做什么，然后Claude来编写。 ## 没有改变的部分 我仍然需要知道一个优秀的Terraform模块或结构良好的Helm图表是什么样子。当真正出现问题，而直接干掉Pod不是选项时，我仍然需要能够通过SSH登录到一个节点——上一层不会移除下一层，它只是改变了你必须亲自介入的频率。而且，我仍然是那个决定事物实际形态的人：模块的最终版本是什么样子、一年后是否易于维护、图表应如何部署和版本化。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\[\.\.\.\]`调用层层叠加，只是为了展平一个子网映射的映射的映射。现在Claude几秒钟就能写出等效的代码，如果今天让我从头写出这个，我真心需要坐下来思考一下。我通过SSH调试一个故障节点的反应速度，比那曾是我唯一会用的方法时要慢一些。这不是假想的成本——我能实时感受到它正在发生，就像许多在Kubernetes之后成长起来的工程师从未真正学会手工制作服务器镜像，但他们也没问题，因为他们从来不需要。 ## 接下来会怎样 我不太确定的部分在于，“我仍然提供方向”这个说法能持续多久。现在，我是那个决定技术栈长期形态的人，因为我有上下文而智能体没有——真的没有，超不出写在一个仓库`AGENTS.md`里的内容。但这正是那些全公司范围AI推广试图弥合的差距：给智能体*全部*上下文，而不仅仅是一个仓库的。如果这真的奏效，一个真正拥有整个基础设施长期视角的智能体——不仅仅是这个Terraform模块，而是多年来跨越每个仓库做出的每一个决策——可能最终会比我规划得更好，就像我无法在调试速度上胜过一个读过我所用每个提供商所有更新日志的工具一样。 Kubernetes没有取代基础设施工程师，它取代了他们的一层工作，并将他们向上提升了一层。我认为AI也不会取代工程。我认为它仍在忙于吞噬“提供方向”之下的那一层——而我并不完全确信，那就是它吞噬的最后一层。