AI 开始写 Terraform 了：IaC 的下一站，是帮你少写代码还是让你多操一份心？

AI 开始写 Terraform 了IaC 的下一站是帮你少写代码还是让你多操一份心《AI视界——从资讯看技术》专栏 · 第二十八期当 AI 把触角从应用代码延伸到基础设施配置运维的工作内容正在发生一次静悄悄的重塑。你不再是那个写配置的人而是那个审配置的人。本系列专栏其他文章欢迎访问AI视界——从资讯看技术我的主页AOwhisky这里有更多运维系统性知识整理和其他有趣内容欢迎与我一起探讨学习~一、AI 的触角伸向了 IaCHashiCorp 近期在 Terraform Cloud 中集成了一项新功能AI 辅助配置生成。用大白话说就是你可以用自然语言描述你想要的基础设施AI 帮你生成对应的 Terraform 配置代码。比如你写“创建一个 AWS EC2 实例用 Ubuntu 镜像开放 443 端口”AI 会生成一段完整的main.tf包含 instance 资源定义、安全组规则、以及 provider 配置。这听起来像是一个提效工具。确实如果你的工作是大量重复地写类似的基础设施配置AI 可以帮你省下不少时间。但如果你读过本专栏的第一期和第十二期应该对这个场景有一种似曾相识的感觉。第一期我们聊过AI 写的应用代码可能有性能陷阱和安全风险。第十二期我们聊过Google 报告指出 85% 的云上安全漏洞来自配置错误。现在 AI 开始写基础设施配置了这意味着什么如果应用代码的 AI 生成需要审查那基础设施配置的 AI 生成需要更严格的审查。因为 IaC 的一个错误影响的不是单次 API 响应而是整个云资源栈的安全边界。二、AI 生成的 Terraform 配置和 AI 生成的应用代码有什么本质区别先搞清楚一个关键问题。AI 写 Python 和 AI 写 Terraform风险级别不同在哪。影响范围不同。一个 Python 函数的 bug可能导致单个接口报错或数据不一致。一个 Terraform 配置的错误可能导致整个生产环境的网络被暴露在公网或者数据库被意外删除。IaC 的错误是批量化的、不可逆的、影响全局的。修复成本不同。应用代码可以通过回滚版本来修复IaC 的错误修复往往需要重新 apply而 apply 过程本身就是有风险的。如果错误涉及资源销毁和重建你的业务可能在修复窗口里继续受损。可测试性不同。应用代码可以跑单元测试、集成测试、端到端测试AI 生成的代码经过测试能发现大部分问题。IaC 的测试依赖terraform plan但 plan 只能告诉你“将要做什么”不能告诉你“这样做是否安全”。一个 plan 完全正确的 Terraform 配置仍然可能在 apply 之后暴露安全漏洞。这意味着什么意味着 AI 生成 Terraform 配置这件事对运维来说不是“少写代码”而是“多了一个需要严格审核的来源”。三、实操让 AI 生成一段 Terraform 配置看看它会怎么做我们用最简示例来测试一下 AI 的 IaC 能力。假设给 AI 这样一个自然语言指令“创建一个 AWS 安全组允许来自任何 IP 的 SSH 和 HTTPS 访问。”AI 生成的 Terraform 配置可能是这样的resource aws_security_group web_sg { name web-sg description Security group for web server ingress { from_port 22 to_port 22 protocol tcp cidr_blocks [0.0.0.0/0] description SSH access } ingress { from_port 443 to_port 443 protocol tcp cidr_blocks [0.0.0.0/0] description HTTPS access } egress { from_port 0 to_port 0 protocol -1 cidr_blocks [0.0.0.0/0] description Allow all outbound traffic } }这段配置语法完全正确terraform validate会通过terraform plan也不会报错。但一个有经验的运维看到它会立刻皱眉。第一SSH 对所有 IP 开放。0.0.0.0/0意味着任何人、任何 IP 都可以尝试 SSH 连接你的服务器。AI 严格按照指令执行——你说了“来自任何 IP”它就真的写了任何 IP。它不知道你真正需要的是“仅办公网络的 IP 段”或者“仅跳板机”。它不理解安全最佳实践只理解你字面上的需求。第二出站流量完全放行。0.0.0.0/0的出站规则意味着如果服务器被入侵攻击者可以不受限制地向外部发送数据——窃取数据库、上传敏感文件、连接 CC 服务器。AI 生成这段配置时没有提示任何风险。第三缺少核心的安全约束。没有提到密钥管理没有提到日志审计没有提到最小权限原则。AI 只生成了你要求的部分不会主动建议“你还需要配置这些安全措施”。这正是我们第一期就讨论过的问题AI 在功能层面能完美执行指令但在安全层面完全无知。IaC 场景下这个缺陷被放大了。四、IaC 的 AI 化对运维意味着什么Terraform AI 配置生成功能的出现不是孤立的新闻。它是运维 AI 化大趋势中的一环。本专栏的第十五期和第二十一期我们聊过运维 AI 在故障排查和变更管理中的应用。第二十七期聊了 AI 代码审查。现在 AI 开始写基础设施配置了。把这几件事连起来看一条线就清晰了AI 正在覆盖运维工作流的每一个环节——从写配置到查故障到审代码。但它覆盖的方式是承担执行角色而不是决策角色。对于正在入行的运维人来说这个趋势释放了两个信号。信号一写配置的能力会逐渐贬值。当 AI 能根据自然语言生成 Terraform 代码手写 IaC 配置这项技能本身不再具有高溢价。类似十年前会手写 HTML 就能拿到高薪现在 AI 几秒钟就能生成一个完整页面。信号二审配置的能力会持续升值。AI 生成的配置能不能用、安不安全、符不符合企业规范——这些判断 AI 做不了。能做的是那些既懂 Terraform 语法、又懂云安全最佳实践、还理解公司内部架构规范的人。而这三样加在一起恰好是一个优秀运维的核心能力。一期一会 · 本期核心笔记Terraform Cloud 集成 AI 配置生成功能AI 开始从应用代码延伸到基础设施配置。这是运维 AI 化趋势的重要一步。AI 生成的 Terraform 配置在语法上正确在安全上无知。它严格遵循指令的字面含义不理解安全最佳实践不会主动建议加固措施。对运维来说IaC 的 AI 化意味着写配置的能力在贬值审配置的能力在升值。运维的核心价值从“生成配置”转移到“审核和兜底”。这一期我们聊了 AI 生成基础设施配置的风险是第一期话题在 IaC 领域的延伸。但 AI 对基础设施的影响不止于配置——K8s 的原生 Sidecar 特性也在云厂商层面陆续落地。下一期我们聊聊 AWS EKS 对 Sidecar 的支持把第二十三期的 API 讨论延续到生产环境中的实际应用。这是《AI视界——从资讯看技术》的第二十八期。专栏继续我们向前。如果这篇文章让你有所思考欢迎在评论区聊聊你敢让 AI 帮你写生产环境的 Terraform 配置吗如果它生成的配置通过了 plan你会逐行审查吗— Compiled and Authored by Whisky — Augest 6 th, 2026