Skip to Content

19b - AI 辅助 IaC 生成

本文是《AI Agent 实战手册》第 19 章第 2 节。 上一节:AI 辅助部署自动化 | 下一节:AI 辅助 CI/CD 配置

概述

基础设施即代码(IaC)是现代云运维的基石,而 2025-2026 年 AI 正在深刻改变 IaC 的编写方式。从 Pulumi AI 的自然语言生成基础设施代码,到 AWS IaC MCP Server 让 AI 助手直接理解 CDK/CloudFormation,再到 Firefly AIaC 的开源命令行生成器——AI 将 IaC 的编写时间缩短了 60-70%。本节覆盖 Terraform/OpenTofu、Pulumi、AWS CDK 三大 IaC 工具的 AI 辅助生成、IaC 管理平台(Spacelift、env0)、状态管理与漂移检测策略,以及 IaC 安全扫描工具链。


1. IaC 工具全景(Terraform, Pulumi, CDK, OpenTofu)

2025-2026 IaC 格局变化

IaC 领域在 2023-2025 年经历了重大变革:

  1. Terraform 许可证变更:HashiCorp 于 2023 年将 Terraform 从 MPL 2.0 改为 BSL 许可证,引发社区分裂
  2. OpenTofu 崛起:Linux 基金会托管的开源分支,提供状态加密、早期变量求值等增强功能
  3. Pulumi AI 原生集成:Pulumi 率先推出 AI 助手和 Neo 平台工程工具,支持自然语言生成 IaC
  4. AWS IaC MCP Server:AWS 发布 MCP Server,让 AI 编码助手直接理解和生成 CDK/CloudFormation 代码

工具推荐

工具类型语言支持价格AI 辅助能力适用场景
Terraform声明式 HCLHCL免费(BSL)/ Cloud: $0.10/资源/月起Copilot 辅助、AIaC 生成多云、成熟生态
OpenTofu声明式 HCLHCL免费开源(MPL 2.0)Copilot 辅助、AIaC 生成需要开源许可的团队
Pulumi编程式TS/Python/Go/C#/Java免费 / Team $50/月起Pulumi AI、Neo 平台开发者友好、复杂逻辑
AWS CDK编程式TS/Python/Java/C#/Go免费(仅付 AWS 资源费)AWS IaC MCP Server、Q DeveloperAWS 深度用户
Crossplane声明式 K8sYAML/Compositions免费开源Copilot 辅助K8s 原生基础设施

IaC 管理平台

平台用途支持工具价格核心能力
SpaceliftIaC 编排与治理Terraform/OpenTofu/Pulumi/CloudFormation/Ansible免费层可用 / Pro $399/月起策略即代码、漂移检测、审批流
env0IaC 自动化Terraform/OpenTofu/Terragrunt/Pulumi/K8sPro $349/月起(10 用户)成本管理、自助服务、合规
Terraform Cloud官方托管Terraform免费层 / Essentials $0.10/资源/月远程状态、Sentinel 策略
ScalrIaC 管理Terraform/OpenTofu免费层可用 / 按用量层级配置、OPA 策略

IaC 工具选择决策树

你的团队背景是什么? ├── 运维/DevOps 背景,熟悉声明式配置 │ ├── 需要开源许可? → OpenTofu │ ├── 需要成熟生态和社区? → Terraform │ └── 已在用 K8s,想统一管理? → Crossplane ├── 开发者背景,偏好编程语言 │ ├── 多云 / 120+ Provider? → Pulumi │ └── 纯 AWS 环境? → AWS CDK └── 不确定 └── → Terraform(最大社区)或 Pulumi(最佳 AI 体验)

2. AI 辅助 Terraform 模块生成

操作步骤

步骤 1:使用 AI 编码助手生成 Terraform 模块

在 Claude Code、Cursor 或 Kiro 中,利用上下文工程提供项目信息:

# CLAUDE.md 或 Steering 规则中添加 IaC 上下文 ## 基础设施规范 - 云提供商:AWS - 区域:ap-northeast-1(东京) - 环境:dev / staging / prod - 命名规范:{project}-{env}-{resource} - 标签策略:Environment, Project, ManagedBy=terraform - 状态后端:S3 + DynamoDB 锁

步骤 2:生成模块的 AI 工作流

1. 描述需求 → AI 生成模块骨架 2. 审查变量和输出定义 3. AI 补充 README 和 examples/ 4. 运行 terraform validate + tfsec 扫描 5. 人工审查安全配置(IAM、安全组、加密)

提示词模板

模板 1:VPC 网络模块生成

请为 AWS 生成一个生产级 Terraform VPC 模块,要求: 基础设施需求: - VPC CIDR: [10.0.0.0/16] - 可用区数量: [3] - 子网类型: 公有子网、私有子网(应用层)、私有子网(数据层) - NAT Gateway: [每个 AZ 一个 / 共享一个] - VPC Flow Logs: 启用,发送到 CloudWatch 模块规范: - 使用 Terraform 1.5+ 语法 - 所有资源添加标签(通过 default_tags) - 输出 VPC ID、子网 ID 列表、NAT Gateway IP - 包含 variables.tf(带描述和验证规则) - 包含 outputs.tf - 包含 README.md(使用说明和示例) 安全要求: - 默认安全组拒绝所有入站流量 - 启用 DNS 支持和 DNS 主机名 - 私有子网不分配公网 IP

模板 2:通用 Terraform 模块生成

请生成一个 Terraform 模块,用于部署 [资源类型]。 环境信息: - 云提供商:[AWS/Azure/GCP] - Terraform 版本:[>= 1.5] - Provider 版本约束:[~> 5.0] 功能需求: - [具体功能描述] - [高可用要求] - [备份策略] 输出要求: - main.tf:核心资源定义 - variables.tf:所有变量带 description 和 type - outputs.tf:关键输出值 - versions.tf:版本约束 - 使用 locals 减少重复 - 遵循 [命名规范]

模板 3:AI 辅助模块重构

请审查并重构以下 Terraform 代码: [粘贴现有代码] 重构目标: 1. 提取可复用模块(识别重复模式) 2. 添加缺失的变量验证规则 3. 改进命名一致性 4. 添加 lifecycle 规则防止意外删除 5. 优化 for_each 和 dynamic blocks 的使用 6. 确保符合 tfsec 安全规则

3. AI 辅助 Pulumi/CDK 代码生成

Pulumi AI:自然语言生成基础设施

Pulumi AI 是目前 IaC 领域最成熟的 AI 原生体验。用户可以用自然语言描述基础设施需求,AI 直接生成可部署的 Pulumi 代码。

Pulumi AI 使用方式

方式说明适用场景
pulumi.com/ai  网页版在线对话式生成快速原型、学习新 Provider
Pulumi Neo平台工程 AI 助手企业级基础设施管理
Copilot/Claude + Pulumi SDK在 IDE 中生成日常开发、模块编写

操作步骤:用 Pulumi AI 生成基础设施

步骤 1:在 pulumi.com/ai 描述需求 "Create an AWS ECS Fargate service with an ALB, running a Docker container on port 8080, with auto-scaling from 2 to 10 tasks based on CPU utilization" 步骤 2:选择语言(TypeScript/Python/Go/C#/Java) 步骤 3:AI 生成完整代码,包含: - VPC 和子网配置 - ALB + Target Group + Listener - ECS Cluster + Task Definition + Service - Auto Scaling Policy - IAM 角色和策略 步骤 4:复制到项目,运行 pulumi preview 审查 步骤 5:人工审查安全配置后 pulumi up 部署

Pulumi TypeScript 示例(AI 生成后人工审查)

import * as pulumi from "@pulumi/pulumi"; import * as aws from "@pulumi/aws"; // AI 生成的 ECS Fargate 服务骨架 const cluster = new aws.ecs.Cluster("app-cluster"); const taskDefinition = new aws.ecs.TaskDefinition("app-task", { family: "app", cpu: "256", memory: "512", networkMode: "awsvpc", requiresCompatibilities: ["FARGATE"], executionRoleArn: executionRole.arn, containerDefinitions: JSON.stringify([{ name: "app", image: "your-registry/your-app:latest", portMappings: [{ containerPort: 8080 }], // ⚠️ 人工审查点:确认日志配置 logConfiguration: { logDriver: "awslogs", options: { "awslogs-group": "/ecs/app", "awslogs-region": "ap-northeast-1", "awslogs-stream-prefix": "ecs", }, }, }]), }); // ⚠️ 人工审查点:确认安全组规则最小权限 const serviceSecurityGroup = new aws.ec2.SecurityGroup("svc-sg", { vpcId: vpc.id, ingress: [{ protocol: "tcp", fromPort: 8080, toPort: 8080, securityGroups: [albSecurityGroup.id], // 仅允许 ALB 访问 }], egress: [{ protocol: "-1", fromPort: 0, toPort: 0, cidrBlocks: ["0.0.0.0/0"], }], });

AWS CDK + AI:MCP Server 集成

2025 年 AWS 发布了 IaC MCP Server,让 Claude Code、Kiro 等 AI 编码助手能够直接理解 CDK 构造库并生成符合最佳实践的代码。

AWS IaC MCP Server 配置

// .mcp.json 或 Claude Code MCP 配置 { "mcpServers": { "aws-iac": { "command": "uvx", "args": ["awslabs.aws-iac-mcp-server@latest"], "env": { "AWS_REGION": "ap-northeast-1" } } } }

CDK 生成提示词模板

使用 AWS CDK (TypeScript) 生成以下基础设施: 需求: - 一个 S3 存储桶用于静态网站托管 - CloudFront 分发(HTTPS only,自定义域名) - Route 53 DNS 记录 - ACM 证书(自动验证) - WAF 规则(速率限制 + SQL 注入防护) CDK 规范: - 使用 CDK v2(aws-cdk-lib) - 使用 L2/L3 构造(不要用 Cfn 前缀的 L1) - 添加 cdk-nag 规则检查 - 输出 CloudFront 域名和分发 ID - 遵循 AWS Well-Architected 最佳实践

Firefly AIaC:开源命令行生成器

AIaC  是 Firefly 开源的 AI IaC 生成器,支持通过命令行用自然语言生成 Terraform、Pulumi、CloudFormation、Helm Chart 等代码。

# 安装 go install github.com/gofireflyio/aiac/v5@latest # 生成 Terraform 代码 aiac get terraform for "an AWS S3 bucket with versioning, \ encryption using KMS, and lifecycle rules to transition \ objects to Glacier after 90 days" # 生成 Pulumi 代码 aiac get pulumi python for "a GCP Cloud Run service \ with a custom domain and minimum 2 instances" # 生成 Helm Chart aiac get helm for "a Redis cluster with 3 replicas \ and persistent storage"

4. 状态管理与漂移检测

状态管理最佳实践

IaC 状态文件是基础设施的”记忆”,管理不当会导致资源孤立、配置冲突甚至数据丢失。

Terraform/OpenTofu 远程状态配置

# backend.tf — AI 可生成,但必须人工审查加密和锁配置 terraform { backend "s3" { bucket = "myproject-terraform-state" key = "prod/terraform.tfstate" region = "ap-northeast-1" encrypt = true # ⚠️ 必须启用 dynamodb_table = "terraform-state-lock" # ⚠️ 必须配置锁 kms_key_id = "alias/terraform-state" # 推荐使用 CMK } }

状态管理策略对比

策略适用场景优点风险
单一状态文件小项目(<50 资源)简单爆炸半径大
按环境分离中型项目环境隔离跨环境引用复杂
按服务/组件分离大型项目最小爆炸半径、并行执行依赖管理复杂
Workspace多环境相同配置代码复用状态隔离不够强

AI 辅助状态管理提示词

请为以下项目设计 Terraform 状态管理策略: 项目规模:[资源数量] 环境数量:[dev/staging/prod] 团队规模:[人数] 云提供商:[AWS/Azure/GCP] 请输出: 1. 状态文件分割方案(按什么维度拆分) 2. 后端配置模板(S3/GCS/Azure Blob) 3. 状态锁配置 4. 跨状态引用方案(data source / remote state) 5. 状态备份和恢复策略

漂移检测

基础设施漂移(Drift)是指实际云资源状态与 IaC 代码定义不一致的情况。常见原因包括手动控制台操作、其他工具修改、自动扩缩等。

漂移检测方法

方法命令/工具频率建议自动化程度
terraform planterraform plan -detailed-exitcode每日 CI 运行高(CI/CD 集成)
Spacelift 漂移检测内置定时检测 + 通知可配置(每小时/每日)高(自动修复可选)
env0 漂移检测内置检测 + 合规报告可配置
driftctl(开源)driftctl scan按需
AWS Config Rules原生服务持续高(AWS 环境)

CI/CD 中的漂移检测(GitHub Actions 示例)

# .github/workflows/drift-detection.yml name: IaC Drift Detection on: schedule: - cron: '0 8 * * *' # 每天早上 8 点检测 jobs: detect-drift: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Setup Terraform uses: hashicorp/setup-terraform@v3 - name: Terraform Init run: terraform init working-directory: infra/prod - name: Detect Drift id: plan run: | terraform plan -detailed-exitcode -out=plan.out 2>&1 | tee plan.log echo "exitcode=$?" >> $GITHUB_OUTPUT working-directory: infra/prod continue-on-error: true - name: Notify on Drift if: steps.plan.outputs.exitcode == '2' uses: slackapi/slack-github-action@v2 with: webhook: ${{ secrets.SLACK_WEBHOOK }} payload: | { "text": "⚠️ 基础设施漂移检测到!请查看:${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}" }

AI 辅助漂移分析提示词

以下是 terraform plan 的输出,显示了基础设施漂移: [粘贴 plan 输出] 请分析: 1. 哪些资源发生了漂移? 2. 漂移的可能原因是什么?(手动修改/自动扩缩/其他工具) 3. 每个漂移项的风险等级(高/中/低) 4. 建议的修复方案: - 接受漂移(更新代码匹配实际状态) - 回滚漂移(terraform apply 恢复到代码定义) - 导入资源(terraform import) 5. 如何防止此类漂移再次发生

5. IaC 安全扫描(tfsec, Checkov, Snyk IaC)

AI 生成的 IaC 代码可能包含安全隐患——宽松的安全组规则、未加密的存储、过度授权的 IAM 策略等。安全扫描是 AI 辅助 IaC 工作流中不可或缺的一环。

安全扫描工具对比

工具维护方支持格式内置规则数价格特色
CheckovPrisma Cloud (Palo Alto)Terraform/CF/K8s/Helm/ARM/Dockerfile1000+免费开源多格式支持、自定义策略、CI 集成
tfsecAqua SecurityTerraform/CloudFormation300+免费开源快速、Terraform 专精、IDE 插件
TerrascanTenableTerraform/K8s/Helm/Dockerfile500+免费开源OPA 策略引擎、远程仓库扫描
Snyk IaCSnykTerraform/CF/K8s/ARM400+免费层(有限)/ Team $25/用户/月修复建议、开发者体验、SaaS 平台
TrivyAqua SecurityTerraform/CF/K8s/Dockerfile/依赖多源免费开源多用途(IaC + 容器 + 依赖)
KICSCheckmarx多格式2000+免费开源规则最多、查询语言灵活

操作步骤:集成安全扫描到 AI IaC 工作流

步骤 1:本地开发时扫描

# Checkov — 推荐首选,覆盖面最广 pip install checkov checkov -d ./infra --framework terraform --quiet # tfsec — Terraform 专精,速度快 brew install tfsec # 或 go install github.com/aquasecurity/tfsec/cmd/tfsec@latest tfsec ./infra # Trivy — 多用途扫描器 brew install trivy trivy config ./infra

步骤 2:CI/CD 中自动扫描

# GitHub Actions 中集成 Checkov - name: Run Checkov uses: bridgecrewio/checkov-action@v12 with: directory: infra/ framework: terraform quiet: true soft_fail: false # 发现高危问题时阻断流水线 output_format: sarif output_file_path: results.sarif # 上传结果到 GitHub Security - name: Upload SARIF uses: github/codeql-action/upload-sarif@v3 with: sarif_file: results.sarif

步骤 3:AI 辅助修复安全问题

Checkov 扫描发现以下安全问题: [粘贴 Checkov 输出] 请为每个问题提供: 1. 风险说明(为什么这是安全问题) 2. 修复后的 Terraform 代码 3. 是否可以安全地添加 checkov:skip 注释(如果是误报) 4. 相关的合规标准(CIS Benchmark、SOC 2 等)

推荐扫描策略

开发阶段(本地): └── tfsec(快速反馈)或 Trivy(多用途) PR 审查(CI): └── Checkov(全面扫描)+ SARIF 上传到 GitHub Security 部署前(CD): └── Checkov + 自定义策略(组织特定规则) 定期审计: └── Snyk IaC(SaaS 仪表板)或 KICS(深度扫描)

实战案例:从零构建 AI 辅助 IaC 工作流

场景:一人公司的 AWS 基础设施

一个 Solo Founder 需要为 SaaS 产品搭建 AWS 基础设施,包含 VPC、ECS Fargate、RDS、S3、CloudFront。

工作流

第 1 步:在 CLAUDE.md 中定义基础设施上下文 - 云提供商、区域、环境、命名规范、安全要求 第 2 步:用 AI 生成模块骨架 - "生成 VPC 模块,3 AZ,公有/私有/数据子网" - "生成 ECS Fargate 模块,支持蓝绿部署" - "生成 RDS PostgreSQL 模块,多 AZ,自动备份" 第 3 步:安全扫描 $ checkov -d ./modules --framework terraform → 发现 5 个问题(安全组过宽、未启用日志等) 第 4 步:AI 辅助修复 - 将 Checkov 输出粘贴给 AI - AI 生成修复代码 + 解释 第 5 步:状态管理配置 - S3 后端 + DynamoDB 锁 - 按环境分离状态文件 第 6 步:漂移检测 CI - GitHub Actions 每日运行 terraform plan - Slack 通知漂移 第 7 步:部署 $ terraform plan → 人工审查 → terraform apply

关键决策

决策点选择理由
IaC 工具Terraform最大社区、最多 Provider
AI 辅助Claude Code + AIaC灵活、支持多种输出
安全扫描Checkov免费、规则全面
状态管理S3 + DynamoDBAWS 原生、成本低
漂移检测GitHub Actions 定时 plan零额外成本

避坑指南

❌ 常见错误

  1. AI 生成的安全组规则过于宽松

    • 问题:AI 倾向于生成 0.0.0.0/0 的入站规则以确保”能用”,但这在生产环境中是严重安全隐患
    • 正确做法:始终在 AI 生成后运行安全扫描,明确指定 CIDR 范围和端口
  2. 直接 apply AI 生成的代码而不 plan

    • 问题:AI 可能生成会删除或替换现有资源的配置,导致数据丢失
    • 正确做法:永远先 terraform plan,仔细审查变更,特别关注 destroyreplace 操作
  3. 状态文件存储在本地或 Git 仓库中

    • 问题:状态文件包含敏感信息(密码、密钥),且本地存储无法团队协作
    • 正确做法:使用远程后端(S3/GCS/Azure Blob)+ 加密 + 状态锁
  4. 忽略漂移不处理

    • 问题:漂移积累会导致 IaC 代码与实际环境严重脱节,最终无法安全执行 apply
    • 正确做法:设置定期漂移检测,发现后立即分析并决定接受或回滚
  5. AI 生成的 IAM 策略权限过大

    • 问题:AI 常生成 "Action": "*""Resource": "*" 的策略
    • 正确做法:要求 AI 遵循最小权限原则,使用具体的 Action 和 Resource ARN
  6. 不锁定 Provider 版本

    • 问题:AI 生成的代码可能不包含版本约束,导致不同环境使用不同版本
    • 正确做法:在 versions.tf 中明确锁定 Provider 版本(使用 ~> 约束)

✅ 最佳实践

  1. 将安全扫描作为 CI 的必经门禁,AI 生成的代码必须通过扫描才能合并
  2. 在 Steering 规则中明确 IaC 安全要求,让 AI 从一开始就生成合规代码
  3. 使用模块化设计,AI 生成的模块经过审查后可在多个项目中复用
  4. 状态文件按环境和服务分离,减小爆炸半径
  5. 定期运行 terraform plan 检测漂移,保持代码与实际环境同步

相关资源与延伸阅读


参考来源

Content was rephrased for compliance with licensing restrictions.


📖 返回 总览与导航 | 上一节:AI 辅助部署自动化 | 下一节:AI 辅助 CI/CD 配置

Last updated on