它会写资源代码，但不理解你公司的云环境、组织规则和变更风险。
AI 擅长生成 Terraform，企业需要的却是“在真实约束下安全落地基础设施变更”。

---

开头

如果你最近用过 AI 写 Terraform，大概率会有一种很强的错觉：

它真的很能写。

你让它建一个 VPC，它会。
让它配 ECS、ALB、RDS，它也会。
甚至你让它直接输出一整套 IaC 模板，看起来都像模像样。

于是很多人开始产生一个判断：

既然 AI 已经能写 Terraform，那它是不是很快就能接管基础设施交付了？

但只要你把这些代码放进企业真实环境，很快就会被现实教育：

• terraform validate 过了，plan 却不对
• plan 没问题，安全扫描不过
• 安全规则过了，又不符合组织规范
• 规范对了，依赖资源没配齐
• 代码终于能发了，生产环境又没人敢直接 apply

这时你会发现一个很残酷的事实：

AI 很擅长写 Terraform，但它并不真正擅长企业级 AWS Provisioning。

因为这两件事，表面相似，本质完全不同。

---

一句话结论

Terraform 生成是代码问题，企业级 AWS Provisioning 是约束、状态、治理和风险控制问题。

AI 解决的是“写出来”，
而企业真正关心的是：

• 写得对不对
• 符不符合公司规范
• 能不能在当前环境里落地
• 会不会带来安全风险
• 谁来审批
• 出问题怎么回滚

所以问题从来不是：

AI 会不会写 Terraform？

真正的问题是：

AI 能不能把自然语言需求，安全地转换成一份符合企业约束的 AWS 基础设施变更。

而这，恰恰是最难的部分。

---

为什么 AI 写 Terraform 看起来很强？

先说公平一点，AI 在 Terraform 上表现确实不错，因为 Terraform 天然适合大模型发挥。

1. Terraform 很“模板化”

Terraform 的资源块结构清晰、语法稳定、官方文档完备、社区示例极多。
对于大模型来说，这类任务很像“高级代码补全”。

2. 很多场景都有固定模式

比如：

• 创建 S3 Bucket
• 配置 Security Group
• 定义 ECS Service
• 编写 IAM Role
• 输出标准 VPC 结构

这些东西都存在大量公共样本，AI 非常容易学会。

3. “看起来合理”很容易做到

很多人判断 AI 代码质量时，标准其实很低：

• 语法对
• 结构像
• 字段齐
• 能解释

但这只是“像一份 Terraform”，
并不等于“像一份企业可用的变更”。

---

真正的难点：企业要的不是代码，而是可落地变更

企业级 AWS Provisioning 的重点从来不是“资源怎么写”，而是：

这份变更能不能在当前组织和云环境里安全执行。

它至少要同时满足四类约束：

AI 往往擅长第二步。
而企业真正困难的是后面四步。

---

为什么 AI 做不好企业级 AWS Provisioning？

1. 它能生成“局部正确”，但企业要求“全局正确”

AI 很容易写出一个“像样”的 RDS 或 ECS 配置。
但企业里真正的问题是：

• 放哪个 account？
• 哪个 region？
• 走公有子网还是私有子网？
• 是否必须加密？
• 是否必须 Multi-AZ？
• 是否必须挂 WAF？
• 是否必须接入 CloudTrail、Config、GuardDuty？
• 是否只能使用公司标准 module？

也就是说，AI 写出来的是“资源定义”，
企业需要的是“在当前环境中正确的资源定义”。

差别非常大。

---

2. 它没有你公司的真实上下文

AI 默认知道的是 AWS 文档和社区最佳实践，
但企业真正重要的信息，往往藏在内部系统里：

• AWS Organizations 结构
• Landing Zone 规范
• 共享 VPC 设计
• IAM permission boundary
• SCP 限制
• 内部 Terraform Module Registry
• 命名与 Tag 规则
• 成本中心映射
• 审批流程
• 合规要求

如果这些上下文没有接给 AI，它就只能“猜”。

而在基础设施领域，猜错一次，代价可能就是事故。

---

3. 它不真正理解组织规则

企业云环境不是“只要 AWS 支持就能建”。

很多限制来自组织本身，而不是云厂商：

• 生产资源必须部署在指定账号
• 某些 region 不允许使用
• 数据库不能暴露公网
• IAM 权限不能通配
• 所有存储必须开启加密
• 所有资源必须带成本标签
• 高风险变更必须双人审批

AI 可以学到“最佳实践”，
但企业要的不是建议，而是规则。

这也是为什么 AI 经常给出一个“技术上可行”的方案，
但在公司里根本过不了审核。

---

4. 它对依赖关系的理解不稳定

一个 ECS 服务上线，背后通常不是一个资源，而是一串依赖：

AI 往往能把单个节点写得不错，
但一旦进入多资源依赖、共享资源复用、跨账户访问、网络和权限联动，就很容易出问题：

• 少一个依赖
• 依赖顺序错
• 资源引用不稳
• 默认配置不适合生产

它能生成“资源”，但不总能生成“系统”。

---

5. 它不了解当前环境状态

企业云环境不是一张白纸，而是一堆历史系统叠加出来的结果：

• Terraform state 不完整
• 有些资源被控制台手改过
• 多团队共享资源边界不清
• 某些 Stack 已经 drift
• 有些资源平台统一托管，不能重复创建

所以真正的 Provisioning 不是：

帮我生成目标配置

而是：

在当前状态上做出一组正确的增量变更

如果 AI 只看 Git 仓库，不看真实 AWS 环境，它理解的往往只是“理想世界”，不是“现实世界”。

---

6. 它最容易犯的是“工程上危险，但语法没错”的错误

基础设施领域最危险的从来不是语法错误，而是这类错误：

• S3 没关公共访问
• Security Group 开了 0.0.0.0/0
• RDS 直接暴露公网
• IAM 给了 *
• Secret 写成明文变量
• 日志和审计没接入

这些配置很多时候都能 apply 成功。
但成功，不等于安全。

AI 往往更关注“能跑”，
企业更关注“可控”。

---

真正的企业链路，远不止“AI 生成 Terraform”

很多人想象中的流程是：

需求 -> AI -> Terraform -> Apply

但企业真实流程通常是这样：

你会发现：

AI 只覆盖了“生成草案”这一步。

真正决定能不能进生产的，是后面的验证、审批、执行、审计和回滚能力。

---

所以，AI 在这个场景里到底该怎么用？

正确姿势不是让 AI “自由生成基础设施”，
而是让它在约束里工作。

更合理的模式是：

1. 基于 Golden Path 和标准模块生成
2. 接入企业上下文做 RAG 检索
3. 把安全和合规规则变成 Policy as Code
4. AI 负责生成、解释、分析和辅助决策
5. 高风险执行必须保留人工审批

一个更靠谱的架构应该是：

在这里，AI 不是“自治工程师”，
而是“受约束的基础设施助手”。

---

企业真正应该先做什么？

如果你想在 AWS Provisioning 里真正用好 AI，优先级不是“换更强的模型”，而是先补这几件事：

1. 建立标准模块和黄金路径

不要让 AI 从 0 写，
而是让它调用公司已经沉淀好的：

• VPC 模块
• ECS 模块
• RDS 模块
• S3 模块
• IAM 模块

2. 显式化规则

把口头规范变成可校验规则：

• OPA / Sentinel
• tfsec / checkov
• Tag 校验
• IAM 边界校验
• 网络暴露校验

3. 接入真实上下文

至少打通：

• Git
• Terraform state
• AWS Config
• CMDB
• 文档系统
• 变更系统
• Module Catalog

4. 给 AI 设边界

建议按成熟度分层：

• L1：问答与解释
• L2：生成 Terraform 草案
• L3：自动生成 PR
• L4：自动做风险分析和 Plan 解读
• L5：仅低风险环境自动执行
• L6：生产环境始终保留审批

---

结尾

所以，为什么 AI 能写 Terraform，却做不好企业级 AWS Provisioning？

答案很简单：

因为 Terraform 是代码，Provisioning 是变更。

代码生成解决的是表达问题，
企业落地解决的是上下文、规则、依赖、状态、审批和风险问题。

AI 当然有价值。
但它真正适合的位置，不是脱离约束直接管理云环境，而是：

• 帮你生成标准化草案
• 帮你理解已有 IaC
• 帮你发现风险
• 帮你补全变更说明
• 帮你提升基础设施交付效率

如果一定要把这篇文章压缩成一句话，我会这样说：

AI 能写 Terraform，因为它擅长模式生成；但做不好企业级 AWS Provisioning，因为企业需要的不是“能生成”，而是“在约束中正确生成，并且可验证、可治理、可回滚”。

---

如果这篇文章对你有帮助，欢迎点赞、分享！

本文是《AI Agent实战系列》的系列文章，后续还会更新AI Agent进阶玩法。关注公众号【架构之旅】，第一时间解锁全套实战教程，错过不再补～