人工智能与基础设施工程2026年8月23日 阅读时长6分钟引言当下企业界大力推动全面采用人工智能将所有上下文信息输入其中在每个代码仓库编写AGENTS.md或INSTRUCTIONS.md文件让智能代理也能参与项目。这有点滑稽我从没让人类队友认真读README文件现在却更用心为机器人编写文档。问题来了这会让工程师变得多余吗一旦技术栈及其基础设施的上下文信息都被智能代理读取我们会被淘汰吗我认为这不是恰当的问题因为我们经历过类似情况。似曾相识的场景Kubernetes在某种程度上取代了Ansible。我多年没编写过Ansible剧本现在看到可能都不认识模块语法。这不是配置管理不重要而是Kubernetes让服务器管理变简单我们直接用云提供商构建的镜像如AWS的AMI。我很少SSH登录节点调试节点出问题就销毁寄希望于替换节点不出问题。在ECS Fargate、Lambda或Cloudflare Containers上运行容器时我不在乎运行节点但这不意味着没人编排而是我决定了工作负载的运行形式、镜像、通信服务、扩展方式和故障处理。Kubernetes和无服务器容器没消除决策层只是将工作单元从“机器”提升到“工作负载”下层工作实现自动化。没人说Kubernetes、Fargate或Cloudflare的容器平台取代了基础设施工程师它们只是取代特定层面的手动工作工程师会向更高层面迈进。我认为人工智能正在重演这一过程只是在更高层面。日常工作的改变我每天用Claude生成Helm图表和编写Terraform模块它节省的是查找资料的时间。我不用通读AWS提供商更新日志了解版本变化只需描述需求Claude就生成版本虽需调整但完成后可作范例尤其是代码仓库有AGENTS.md文件指向它时。类似情况之前也有我不再手动编写原始Kubernetes YAML文件就像不再手动编写Ansible模块这是Helm图表的作用。现在我也越来越少手动编写Helm图表只需指明功能Claude就完成编写。未改变的部分我仍需知道优秀的Terraform模块或结构良好的Helm图表是什么样。出现问题无法销毁Pod解决时我仍需SSH登录节点排查。更高层面技术不会消除较低层面需求只是减少处理频率。最终决策仍由我做如模块形态、维护性、图表部署和版本控制等。人工智能负责耗时部分我负责指明方向。被舍弃的技能现在我构建和调试速度比两年前快但对基础知识掌握不如以前。我的HCL语法记忆变差四年前我手动编写四层嵌套for循环标记子网花一小时才写对语法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文件。但企业推动人工智能应用就是要填补这一差距让智能代理掌握完整上下文信息。如果实现一个对整个基础设施有长远规划的智能代理可能比我做出更好的规划就像我调试不如读过所有提供商更新日志的工具。Kubernetes没取代基础设施工程师而是取代部分工作将他们推向更高层面。我认为人工智能也不会取代工程领域它目前在蚕食“指明方向”之下的工作而我不确定这是否是最后一层。