“AI 写 Terraform，我是不是可以提前下班了？”

——用生成式 AI 辅助编写 IaC 的机会与风险

最近这半年，我在不少群里都看到类似的问题：

“Echo，AI 已经能直接写 Terraform 了，我们运维是不是要被替代了？”
“CloudFormation 模板让 AI 生成，靠谱吗？”
“以后是不是一句话，云环境就自己搭好了？”

说实话，第一次看到 AI 给我写出一个能 terraform apply 成功的 VPC 模板时，我心里也咯噔了一下。

但冷静下来后，我的结论反而越来越清晰：

生成式 AI，确实会重塑 IaC 的写法，但它替代不了真正懂系统的人。

今天这篇文章，我不唱赞歌，也不泼冷水，
就从一个一线运维的真实视角，聊聊：

• AI 写 IaC，到底爽在哪
• 又最容易在哪翻车
• 运维工程师，该怎么用它，而不是被它用

一、先说结论：AI 写 IaC，是“外挂”，不是“自动驾驶”

如果一句话概括我的态度，那就是：

AI 非常适合“起草、补全、重构 IaC”，但绝不适合“无脑全权托管”。

它像什么呢？

更像是一个：

• 记忆力超强
• 写代码不嫌烦
• 但不背责任的实习生

你用得好，它能帮你省 30%～50% 时间；
你用不好，它能在凌晨 3 点帮你制造一次事故。

二、机会：AI 在 IaC 场景，真的很香

先不谈风险，咱得承认现实：
AI 在 IaC 这件事上，天然就有优势。

1️⃣ 模板生成：从“空白恐惧”里解放出来

写 Terraform 的朋友都懂这种痛：

• 我知道我要建什么
• 但从 provider {} 开始写，真的很烦

比如你跟 AI 说一句：

“帮我写一个 AWS 上的 VPC，2 个公有子网，1 个 NAT Gateway”

它往往能直接给你一个结构完整、能跑的草稿：

provider "aws" {
  region = "ap-southeast-1"
}

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

这个阶段，AI 最大的价值不是“对不对”，而是“快”。

就像画画先打草稿，总比盯着白纸发呆强。

2️⃣ 模块化与重构：比你更有耐心

老 IaC 项目，最让人头疼的是什么？

• 重复资源
• 变量命名混乱
• 模块拆不动

而 AI 在这方面，反而很有优势。

你把一段 500 行的 Terraform 丢给它，说一句：

“帮我抽成 module，顺便规范下变量命名”

它往往能给你一个还算合理的拆分方案。

我自己的使用习惯是：

AI 负责“整理”，我负责“判断”。

3️⃣ 多云 / 多版本语法切换，AI 很擅长

比如：

• Terraform 0.12 → 1.x
• AWS → 阿里云 / 华为云
• Terraform → CloudFormation

这些事情人写很烦，AI 写很快。

CloudFormation 这种 YAML 地狱，AI 反而如鱼得水：

Resources:
  MyEC2:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: t3.micro

说句大实话：
这种“体力活 + 规则明确”的事，本来就该交给 AI。

三、风险：AI 最可怕的地方，不是写错，而是“看起来很对”

真正危险的，从来不是语法错误。

而是——
它写的东西，能跑、能建、还能上线。

1️⃣ 安全默认值，AI 经常“太乐观”

我见过 AI 生成的 IaC，常见问题包括：

• 安全组 0.0.0.0/0
• S3 默认 public
• IAM policy 直接 *:*

比如这样的 Terraform：

resource "aws_security_group" "sg" {
  ingress {
    from_port   = 0
    to_port     = 65535
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

你问它，它会说：

“这是为了方便测试。”

但问题是：
很多生产事故，就是从“先方便一下”开始的。

2️⃣ 业务上下文，AI 是“瞎子”

AI 不知道：

• 你这个 VPC 是生产还是测试
• 这个账号有没有 SCP
• 公司合规要求是不是必须打标签

它只是在“合理猜测”。

所以你会看到它生成：

• 没有 tag
• 没有 cost center
• 没有生命周期策略

而这些，恰恰是企业级 IaC 的灵魂。

3️⃣ 一旦出事，AI 不背锅

这是我最想强调的一点。

IaC = 基础设施即代码 = 基础设施即责任

当你执行：

terraform apply

出问题的时候：

• 不会有人接受“是 AI 生成的”这个理由
• 审计、追责、复盘，写名字的只有你

所以，IaC 的最终作者，永远是人。

四、正确姿势：把 AI 当“副驾驶”，而不是“自动驾驶”

结合我自己的使用经验，总结一套安全又高效的用法。

✅ 1. 只让 AI 写“第一版”

• 模板
• 结构
• 重复代码

但：

• 权限
• 网络
• 安全相关

一定要人工过一遍。

✅ 2. 强制走工具链校验

不管 AI 多自信，流程不能省：

terraform fmt
terraform validate
terraform plan

再配上：

• tflint
• checkov
• tfsec

让机器审机器，人审设计。

✅ 3. 把“组织经验”喂给 AI，而不是让它自由发挥

最靠谱的方式是：

• 给它你们公司的 IaC 示例
• 告诉它命名规范、安全基线

然后说：

“按这个风格生成”

这时候，AI 才真正像个“团队成员”。

五、写在最后：AI 不会干掉运维，但会淘汰“只会敲模板的运维”

我越来越强烈地感觉到：

未来的运维价值，不在“会不会写 Terraform”，而在“知不知道该不该这么写”。

AI 会让“写 IaC”这件事变得更简单，
但也会把设计能力、风险意识、系统理解的重要性无限放大。

如果你只是：

• 拿模板
• 改参数
• 照着敲

那确实危险。

但如果你能：

• 用 AI 提速
• 用经验兜底
• 用体系保证安全

那恭喜你，
你会比以前更强，而不是更弱。