目录
"我让Claude Code'写一段用Terraform创建EC2实例的代码'，结果30秒就生成了IaC代码。这不就意味着基础设施工程师要失业了吗？"
有这种感受的人应该不在少数。事实上，AI编码工具的进化令人瞠目结舌，在基础设施领域，代码生成、配置文件编写、日志分析等工作都在高速化。OpenAI在2025年发布的Codex（编码Agent）同样擅长自动生成基础设施代码。
那么，基础设施工程师和网络工程师真的会被淘汰吗？
先说结论："取代"不会发生，但"角色变化"正在发生，这是比较现实的看法。本文将聚焦基础设施领域，梳理AI擅长与不擅长的事情，并具体讲解工程师应采取的策略。
1. 现在到底发生了什么——AI编码工具的进化
首先，让我们了解一下AI编码工具在基础设施领域已经能做什么。
主要AI工具及其基础设施能力
| 工具 | 提供方 | 基础设施领域的优势 |
|---|---|---|
| Claude Code | Anthropic | 生成Terraform、Docker、Ansible、K8s manifest等。擅长在理解整个项目后进行修改 |
| Codex（CLI） | OpenAI | 在沙箱环境中执行与验证代码。IaC自动生成与运行验证可一气呵成 |
| GitHub Copilot | GitHub/MS | 编辑器内的代码补全。可预测生成现有Terraform或YAML的后续部分 |
| Amazon Q Developer | AWS | 专注AWS。擅长生成CloudFormation、CDK、IAM策略 |
| Google Cloud Assist | 辅助GCP环境配置。与Vertex AI集成 |
值得关注的是，这些工具已经超越单纯的代码补全，开始作为"Agent"运作。Claude Code能读写文件、执行命令，Codex则能在沙箱中运行代码并验证结果。
能做的事情正在急速扩展
在2024年时AI还只停留在"生成Terraform模板"的水平，到了2025～2026年已经可以做到以下事情：
- 读取现有基础设施代码，指出其中的安全问题
- "我想把这个应用部署到AWS上"→整套提议VPC、子网、SG、ALB、ECS/EKS的结构
- 分析生产环境的错误日志，提出原因候选与对应方法
- 从零构建CI/CD流水线
- 生成或修改Kubernetes manifest与Helm chart
看到这种进化速度，会觉得"基础设施工程师好像不再需要了"也不难理解。但这只是"AI能做的事情"的一个侧面。
2. AI"能做"的基础设施工作
AI特别擅长的是"可用代码表达"、"存在模式"、"基于文本"的工作。
① Infrastructure as Code（IaC）的生成
Terraform、CloudFormation、Pulumi、Ansible、Chef——这些IaC工具的代码生成，是AI最擅长的领域。
| 任务 | AI精度 | 补充说明 |
|---|---|---|
| Terraform资源定义 | ◎ 高 | AWS/GCP/Azure的主要资源几乎都很准确 |
| Ansible Playbook | ◎ 高 | 常见的软件安装、配置变更都很擅长 |
| Docker / docker-compose | ◎ 高 | 多阶段构建、网络配置也可完成 |
| K8s manifest / Helm | ○ 中～高 | 基本结构准确。复杂的自定义资源仍需审核 |
| CI/CD流水线 | ○ 中～高 | 可生成GitHub Actions、GitLab CI等工作流 |
② 配置文件的生成与优化
nginx.conf、apache.conf、iptables/nftables规则、systemd unit文件——这些配置文件的生成AI同样擅长。只要说一句"帮我写一个这个Web应用用的nginx反向代理配置，支持SSL"，就能得到符合最佳实践的配置。
③ 日志分析与异常检测
从海量日志中找出模式，这是AI的主场。
- 总结syslog、journald、CloudWatch Logs等文本日志
- 错误模式的分类与频率分析
- 即时回答"最近一小时激增的错误是什么？"
- 根据日志推测原因并提出对策
④ 文档与操作手册的自动生成
AI可以读取现有基础设施代码，自动生成架构图说明、运维手册、故障应对手册的草稿。这是基础设施工程师最不愿意做（却最重要）的工作之一。
⑤ 安全检查
IAM策略的过度权限检查、安全组规则验证、Terraform代码对CIS Benchmark的合规检查等定型化的安全审查，AI也可以提供辅助。
3. AI"做不到"的基础设施工作
这里才是核心。如果不准确理解AI的局限，就可能导致"全都交给AI"→重大事故的最坏情况。
① 物理层的作业
理所当然，AI无法进行物理操作。
- 服务器机柜中的设备安装与布线
- 故障HDD/SSD的更换
- 网络设备（路由器、交换机、防火墙）的物理配置与更换
- 数据中心的出入管理与物理安全
也许有人会想"只要上云就不需要物理操作了吧？"但是，大约六成的日本企业仍在混合使用本地环境（据IDC Japan调查），物理基础设施在可预见的将来不会完全消失。
② 故障时的业务判断
生产环境出现故障时，最重要的是"优先处理什么"的业务判断。
- "数据库坏了。从备份恢复会丢失最近两小时的数据。是恢复还是尝试修复？"
- "服务A和服务B都宕机了。资源有限的情况下先恢复哪一个？"
- "怀疑遭到安全入侵。是停服调查还是边运行边调查？"
这些判断不仅需要技术知识，还需要综合考虑对业务的影响程度、对客户的承诺（SLA）、法律风险以及与管理层的协调，无法交给AI。AI可以"提供选项"，但无法"负责任地做出决定"。
③ 对未知故障模式的应对
AI对训练数据中包含的模式很在行，但对谁都没经历过的故障则比较弱。
- 云厂商端尚未公开的Bug
- 多系统复合故障（网络＋DNS＋应用同时异常）
- 硬件老化导致的间歇性故障
这种情况下，经验丰富工程师的"直觉"——也就是从过去类似事例中类推的能力——至关重要。
④ 安全的最终责任
即使AI说"这个配置是安全的"，那也只是说法，而非保证。一旦发生安全事件，法律与伦理责任由人类承担，而非AI。
- 个人信息泄露时向监管部门的报告与应对
- 实施取证调查与证据保全
- 制定再发防止对策并向管理层汇报
- 向客户通报并进行沟通
⑤ 供应商管理与谈判
云厂商、数据中心运营商、ISP、安全厂商——基础设施工程师的工作包含大量对外谈判。合同条款协商、SLA达成、故障时的协调等都是AI无法胜任、纯粹属于人类的领域。
4. 对网络工程师的影响
网络工程在基础设施中处于略为特殊的位置。让我们单独看看AI对它的影响。
AI可以自动化的网络业务
| 业务 | AI能力 | 具体示例 |
|---|---|---|
| ACL / 防火墙规则生成 | ◎ | 只要说明需求，就能自动生成iptables/nftables/SG规则 |
| VLAN / 子网设计建议 | ○ | 根据需求制作IP设计的初稿 |
| 网络设备配置生成 | ○ | Cisco IOS、Junos等配置生成（但需要人工验证） |
| 流量分析 | ◎ | NetFlow/sFlow数据的异常检测与模式分析 |
| BGP / OSPF配置 | △ | 基础配置可以，复杂的路由策略需要审核 |
AI难以胜任的网络业务
- 物理布线的设计与施工：楼层布局、线缆走向、配线箱的整理
- 无线信号勘测与无线LAN设计：需要物理现场勘察。墙体材质、干扰源识别
- 第一层故障的定位：需要物理确认线缆断裂、端口故障、光信号衰减等
- 与运营商的线路协调：新线路接入、带宽调整、冗余结构协调
- 大规模网络迁移：数百台设备的迁移计划与实施。为最小化停机时间的分阶段迁移
网络工程对物理层的依赖度较高，因此比服务器基础设施更难被AI完全取代。但在配置生成和故障排查的效率化方面，AI会带来巨大助力。
5. 实际现场会如何改变
让我们抛开理论，看看AI在实际现场是如何被使用的——这里列举几种典型模式。
模式1：加速IaC开发
在某家初创企业，基础设施工程师使用Claude Code生成Terraform代码。以前定义一个AWS资源需要30分钟到1小时的工作，通过向AI传达需求再审核修改，缩短到了5～10分钟。
但重要的一点是，绝不会直接把AI生成的代码应用到生产环境。必须由人类审核，并从安全配置和成本优化的角度加以修改。
模式2：故障应对的初期辅助
生产环境出现故障时，先让AI分析日志，筛选出原因候选，然后由人类做出最终判断并执行恢复作业——这是一种分工模式。
- 之前：人工查日志定位原因需要30分钟到1小时
- 之后：AI在5分钟内把原因候选缩小到3个→人类确认并处理
故障的MTTR（平均恢复时间）会缩短，但同时也产生了"轻信AI的分析结果而做出错误恢复操作"的新风险，所以最终判断仍需经验丰富的工程师来做。
模式3：加速初级工程师的成长
基础设施领域一直被认为"没经验就寸步难行"，但AI正大幅平缓学习曲线。
- "请解释这段Terraform代码的含义"→AI逐行解说
- "为什么这个安全组应该限制22端口？"→AI讲解背景与原因
- "我看不懂这份故障日志"→AI说明日志结构与关键点
这并不是"工程师不再需要"，而是"工程师成长速度加快"的效应。
模式4：实现"一人基础设施团队"
过去需要3～5人才能完成的基础设施运维，在AI的辅助下，出现了1～2人就能运转的情况。人数虽然减少，但留下来的人才会被要求更高的技能与判断力。
6. AI时代基础设施工程师的生存之道
接下来是具体战略。本节梳理不会被AI取代、反而因为AI而更具价值的技能组合。
① 掌握善用AI的能力
这是最重要、最见效的战略。能把AI当作"工具"而非"威胁"来使用的工程师，生产力会提升数倍。
- 在日常工作中融入Claude Code、Codex、Copilot等AI工具
- 掌握向AI下达合适提示（指令）的方法
- 保持能够正确验证与修正AI输出的技术水准
关于如何免费使用各种AI工具，可参考"免费使用AI的方法【2026最新版】"。
② 向"设计与架构"侧转移
AI擅长的是"写代码"，而不是决定"设计什么、怎么设计"。
- 云架构设计：平衡可用性、可扩展性与成本优化的设计能力
- 多云战略：理解AWS、GCP、Azure的特性，并合理分配使用的判断力
- DR（灾难恢复）设计：从RPO/RTO定义到恢复步骤制定
③ 深化安全专业
安全是"AI出错时影响最大"的领域。因此，具备安全专业能力的工程师需求，随着AI普及反而有可能增加。
- 零信任架构的设计与实施
- 安全事件应对技能
- 合规（ISMS、PCI DSS、GDPR等）适配能力
④ 具备SRE（Site Reliability Engineering）视角
Google提出的SRE思想——"把运维当作软件工程问题来处理"——在AI时代显得更加重要。
- SLI/SLO/SLA的设计与运营
- 基于Error Budget的决策
- 推进自动化（AI也是自动化的一种手段）
- 构建Postmortem（故障回顾）文化
⑤ 增加与业务的接触点
最难被AI取代的能力，是连接技术与业务的桥梁能力。
- 基础设施成本的优化建议与管理层报告
- 新业务的基础设施需求定义与预算估算
- 把技术风险翻译成业务风险进行解释的能力
7. 结论——不是"取代"而是"进化"
让我们再次总结本文的结论。
| 视角 | 结论 |
|---|---|
| AI会取代基础设施工程师吗？ | 完全取代=No。但"只会动手的工程师"需求一定会减少 |
| AI擅长的领域 | IaC代码生成、配置文件编写、日志分析、文档撰写等"可用代码表达的定型业务" |
| 需要人类的领域 | 物理作业、故障时的判断、安全责任、供应商谈判、架构设计 |
| 对人员数量的影响 | 团队规模很可能缩小。但留下的人才会被要求更高的技能 |
| 对网络工程师的影响 | 由于物理层依赖度高，比服务器基础设施更难被取代。配置生成的效率化仍将推进 |
最重要的信息是："善于驾驭AI的基础设施工程师"拥有最高的市场价值。AI承担定型工作之后，工程师可以把精力集中在更高阶的设计、判断与战略上。
这不是"威胁"，而是"进化的机会"。不是畏惧AI，而是把AI变成自己的武器——这就是AI时代基础设施工程师的生存战略。
关于IT整体图景的基础知识与AI辅助开发的入门方法，也请参考"零基础AI开发入门"。
常见问题
Q. 现在开始学习成为基础设施工程师，是不是不划算？
不，反而是机会。因为AI工具的出现，基础设施领域的学习门槛正在降低。但是，只会"在服务器上装Linux、跑nginx"是不够的。你需要云架构设计能力、安全知识，以及善用AI工具的本领。反过来说，具备这些技能的工程师，今后的需求依然很高。
Q. CCNA等网络认证的价值会下降吗？
认证本身的价值不会"消失"，但认证所证明的部分技能（比如配置命令的死记硬背）确实可以被AI替代。更重要的是，备考过程中所学到的对网络基本原理的理解（OSI参考模型、TCP/IP原理、路由协议概念），这些知识在AI时代依然很有价值。因为要判断AI输出是否正确，基础知识不可或缺。
Q. 如果因为AI引起生产故障，责任由谁承担？
目前，决定把AI生成的代码应用到生产环境的人（及其组织）承担责任。AI只是工具，不能成为法律上的责任主体。这就像用菜刀做菜失败了，责任也不归菜刀厂商一样。因此，必须由人类审核与验证AI生成的基础设施代码后再应用——这种运维方式是不可或缺的。
Q. 在本地环境下AI的影响会小一些吗？
在物理作业较多（设备安装、更换、布线）的本地环境中，AI的影响确实比云环境小一些。但配置管理（如用Ansible管理服务器）、监控配置、文档撰写等基于文本的工作，即便在本地环境中，AI也能发挥巨大作用。"物理交给人类、逻辑（配置与代码）由AI辅助"的分工会自然而然地推进。
Q. Claude Code和Codex该如何区分使用？
Claude Code在本地终端运行，擅长理解整个现有项目后生成与修改代码。另一方面，Codex可以在沙箱环境中执行与验证代码，更适合生成带有运行验证的新IaC代码。在实际工作中，对现有基础设施的修改与扩展用Claude Code，新建项目的原型制作用Codex，这样的分工较为高效。但工具进化很快，建议两者都试一下，选择最适合自己工作流的那个。
Q. 小型企业也应该引入AI基础设施管理吗？
是的，小企业受益反而更大。即便请不起专职基础设施工程师，有AI工具的辅助，开发者也能兼任基础设施管理。不过，像安全配置、备份等关键工作，不要盲信AI的输出，强烈建议由具备可靠知识的人进行审核。
