terraform（Terraform/OpenTofu基础设施代码管理）Skill 是什么？如何安装？

Terraform/OpenTofu 基础设施代码管理 Skill：把云上架构变成可审查、可复用、可回滚的代码

• 它是什么：一个专注于 Terraform / OpenTofu 的基础设施即代码（IaC）技能，覆盖模块设计、状态管理、多环境策略、安全加固与故障排查全流程，并优先使用 Linux 基金会维护的开源分支 OpenTofu（tofu 命令）。
• 它能做什么：从零规划 VPC / EKS / RDS 架构，生成符合最佳实践的 HCL 配置，设计远程状态后端与锁定方案，处理状态迁移、资源导入、漂移检测等高风险操作。
• 它和普通对话式 AI 的区别：内置了模块目录结构、变量校验规则、生命周期规则、for_each 优于 count 等一整套工程约定，并具备读写文件与执行命令的能力，可以真正落地成仓库里的代码。
• 适合谁：需要落地云上架构的高级软件工程师、平台/基础设施工程师、以及正在从「控制台点击」迁移到「代码化管理」的团队。
• 使用前提：本地具备 OpenTofu 或 Terraform 命令行环境与云厂商凭证，具体安装与授权方式以官方说明为准。

该技能叫什么？如何下载安装 AI 技能提升开发效率？

基本信息

项目	内容
技能中文名	Terraform/OpenTofu基础设施代码管理 Skill
技能英文名	terraform
技能 ID	13477
核心定位	基础设施即代码（IaC）的架构规划、配置编写、状态治理与故障排查
首选工具	OpenTofu（tofu），与 Terraform 语法和配置完全兼容
可用工具权限	Read、Grep、Glob、Edit、Write、Bash

它解决什么问题

传统云资源交付有两种典型困境：一是在控制台上手动点击，环境之间无法复现，改错一个安全组就可能引发线上事故；二是直接用 Terraform 写配置，但缺少统一的模块规范与状态治理，几个月后仓库里堆满硬编码、状态文件散落本地、terraform apply 变成「谁都不敢按的按钮」。

这个技能把「资深工程师的 Terraform 经验」沉淀成可调用的能力：它会先帮你规划架构与模块边界，再产出带变量校验、版本约束、生命周期规则的标准配置，最后覆盖状态后端、多环境隔离、漂移检测这些真正容易翻车的地方。

一键安装的思路与步骤

AI 技能的安装本质上是「把一份技能说明挂载到你的 AI 助手上」，让它在你提问时自动加载对应的专业知识。具体入口与命令以官方说明为准，通用流程如下：

1. 确认安装前提：拥有该技能所在平台的账号；本地或运行环境已安装 OpenTofu 或 Terraform 命令行（版本建议满足 >= 1.6.0 一类约束，具体以官方说明为准）；已配置好云厂商访问凭证（如 AWS 的访问密钥或角色）。
2. 进入技能市场/技能库：在平台的技能（Skill）入口中搜索技能英文名 terraform 或技能 ID 13477。
3. 执行安装/启用：点击安装或启用按钮，按提示确认技能可使用的工具权限（该技能需要文件读写与命令执行能力）。若平台支持命令行安装，安装命令以官方说明为准。
4. 验证是否生效：新建会话，输入包含触发关键词的提问，例如「用 opentofu 帮我写一个带私有子网和 NAT 网关的 VPC 模块」。如果回复开始出现模块目录结构、variables.tf 校验规则、tofu plan 建议等专业内容，说明技能已生效。
5. 排查未生效：检查技能是否处于启用状态、当前会话是否绑定了该技能、提问中是否缺少 terraform / tofu / IaC / module / state 等触发词。

触发关键词：terraform、tf、opentofu、tofu、infrastructure、IaC、provision、cloud、aws、azure、gcp、kubernetes、k8s、module、provider、state、backend、plan、apply、workspace、resource、data source、output、variable、locals、import、taint、destroy。提问时带上其中任意一到两个词，几乎都能稳定唤起。

该技能的主要功能和特点

• 架构规划先行：在写代码之前先梳理资源需求与依赖关系、网络拓扑（VPC、子网、路由）、模块边界与可复用性、多区域/多可用区高可用设计、灾难恢复与备份策略，以及 IAM、加密、网络隔离等安全要求。
• 标准化模块结构：默认采用 modules/ + environments/ 的分层目录，每个模块由 main.tf（资源定义）、variables.tf（输入变量）、outputs.tf（输出值）、versions.tf（提供程序版本约束）组成，配合 .terraform.lock.hcl 锁文件保证可重现。
• 模块接口带校验：生成变量时会附带 description、type 与 validation 规则，例如名称长度 1–32、环境枚举只允许 dev/staging/prod、子网数量至少 2 个以满足高可用。这比「随便传个字符串」的野生模块可靠得多。
• 远程状态与锁定治理：给出 S3 + DynamoDB、GCS、Azure Storage 等后端配置模板，强调加密、版本控制、锁表防并发修改，并说明 force-unlock 的正确使用前提。
• 多环境三种策略：工作区（terraform.workspace）、目录隔离、tfvars 文件，按团队隔离需求选择，并给出 tofu apply -var-file="environments/prod.tfvars" 这类可直接套用的调用方式。
• 安全最佳实践内置：最小权限 IAM 策略、Secrets Manager 密钥托管配合 random_password、KMS 密钥轮换、S3 服务端加密、安全组仅放通必要端口、sensitive = true 标记敏感输出。
• 提供程序版本与别名管理：用 ~> 5.0 这类悲观约束锁定主版本，用 alias 支持多区域/多账号部署，用 default_tags 统一打标便于成本分摊。
• 高级模式覆盖：dynamic 动态块批量生成安全组规则、for 表达式做映射转换与过滤、for_each 替代 count 获得稳定资源地址、lifecycle 的 prevent_destroy / ignore_changes / create_before_destroy、depends_on 显式依赖。
• 故障排查知识库：状态锁超时、提供程序插件缓存损坏、资源已存在需 import、循环依赖、状态中泄露敏感数据、资源漂移、模块源变更、计划输出过长、超时配置等高频问题都给出了对应处置方式。
• 测试与验证流程：tofu fmt -recursive 格式化、tofu validate 校验、tfsec 安全扫描、infracost 成本估算、terraform-compliance 策略检查，以及一份「计划审查清单」。

和普通工具比强在哪：普通编辑器只帮你补全语法，普通对话 AI 只给你一段能跑但不成体系的示例；这个技能的差异在于它输出的是「工程决策 + 完整目录 + 可维护约定」，并且会主动提醒你「先审查 plan 再 apply」「状态文件不要进版本库」这类真正决定成败的纪律。

如何使用该技能？

以下按典型工作流给出分步骤指南。

第 1 步：用自然语言描述目标，让技能产出架构方案

输入示例：

我要在 AWS 上搭一套生产环境：一个跨 3 个可用区的 VPC，公有子网放 ALB，私有子网放 EKS 和 RDS PostgreSQL 15.4，需要 NAT 网关出网，状态存到 S3 并用 DynamoDB 加锁。

输出说明：技能会先给出模块划分（vpc / eks / rds / app-service）、网络网段规划、可用区分布、安全组与网络 ACL 的隔离思路，以及状态后端方案，再进入具体代码。

第 2 步：生成模块代码并落地到仓库

技能会按标准结构写出文件，核心片段通常长这样：

# modules/vpc/main.tf
resource "aws_subnet" "private" {
  count             = length(var.availability_zones)
  vpc_id            = aws_vpc.main.id
  cidr_block        = cidrsubnet(var.cidr_block, 4, count.index + length(var.availability_zones))
  availability_zone = var.availability_zones[count.index]

  tags = merge(local.common_tags, {
    Name = "${var.name}-private-${var.availability_zones[count.index]}"
    Tier = "private"
  })
}

变量文件会同时生成校验规则：

variable "subnet_ids" {
  description = "资源放置的子网 ID 列表"
  type        = list(string)
  validation {
    condition     = length(var.subnet_ids) >= 2
    error_message = "高可用性需要至少 2 个子网。"
  }
}

第 3 步：组合模块与传参

在环境目录中组合模块，注意 source 用相对路径或带版本号的注册表地址，内部模块建议用 Git 标签锁定：

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0"
  # ...
}

module "database" {
  source = "../rds"

  name            = "${var.name}-db"
  engine          = "postgres"
  engine_version  = "15.4"
  vpc_id          = module.vpc.vpc_id
  subnet_ids      = module.vpc.private_subnet_ids
  security_groups = [module.vpc.database_security_group_id]
}

第 4 步：初始化、格式化、校验、预览

tofu fmt -recursive
tofu init
tofu validate
tofu plan -out=tfplan
tofu show tfplan

技能会提示你对照计划审查清单逐项确认：变更是否符合预期、有没有资源被意外标记删除、敏感数据是否出现在输出、标签是否覆盖全部资源、加密是否开启、IAM 是否遵循最小权限、安全组是否足够收敛。

第 5 步：应用变更

tofu apply tfplan

第 6 步：状态操作（高风险，务必谨慎）

tofu state list
tofu state show aws_vpc.main
tofu import aws_instance.example i-1234567890abcdef0
tofu state mv aws_instance.old aws_instance.new
tofu state rm aws_instance.temp
tofu init -migrate-state

遇到状态锁卡住时，先确认没有其他流程在跑，再执行 tofu force-unlock <LOCK_ID>。

第 7 步：多环境切换

tofu workspace new staging
tofu workspace select prod
tofu apply -var-file="environments/prod.tfvars"

配置里可直接用 terraform.workspace 驱动差异化参数，例如 dev 1 台、staging 2 台、prod 5 台。

第 8 步：漂移巡检

tofu plan -refresh-only
tofu apply -refresh-only

前者只对比现实与状态，后者把状态刷新到与现实一致；若要强制回到代码定义，直接 tofu apply 覆盖漂移。

同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
本技能（terraform Skill，ID 13477）	专注 IaC 的 AI 技能助手	架构规划、模块设计、状态治理、安全加固、故障排查、命令执行	需平台账号 + 本地 CLI + 云凭证；安装入口以官方说明为准	从零搭建云架构、模块化重构、状态迁移、多环境治理	优势：工程约定完整、优先 OpenTofu、可读写文件并执行命令；不足：强依赖本地环境与凭证，最终仍需人工审查 plan
Terraform / OpenTofu 原生 CLI + 通用对话 AI	手工编排 + 通用问答	完整 IaC 能力，问答侧仅提供零散示例	需自行安装 CLI、自行设计目录与状态方案	简单资源、临时验证	优势：灵活、无额外依赖；不足：缺少体系化规范，通用 AI 容易给出硬编码、无状态后端、无版本约束的示例
Pulumi	用通用编程语言（TypeScript/Python/Go）写 IaC	编程语言表达力强、可复用现有软件工程实践	需掌握对应语言与 SDK	已有强编程团队、复杂逻辑编排	优势：抽象能力强、测试生态好；不足：学习曲线偏陡，HCL 生态的现成模块与资料更丰富
云厂商原生模板（CloudFormation / ARM / Bicep）	厂商托管的声明式 IaC	与云服务深度集成、托管状态	需学习厂商专有语法	单一云厂商、强合规场景	优势：无需自建状态后端、原生支持度高；不足：多云迁移成本高，跨云统一治理困难
云控制台手动操作	图形化点击	上手最快	几乎无门槛	一次性试验、紧急变更	优势：直观；不足：不可复现、不可审查、不可回滚，是环境漂移的主要来源

选型建议：如果你已经决定走「代码化管理云资源」这条路，且希望有人替你守住模块规范、状态安全与审查纪律，这个技能是最贴合的选择；如果团队以强编程能力为核心资产，Pulumi 也值得并行评估；如果严格限定单云厂商且追求托管省心，云原生模板仍有其位置。

该技能的典型应用场景与实际体验情况

场景一：平台工程师从零搭建一套生产级 VPC 与 EKS

角色：平台/基础设施工程师。痛点：网段规划、NAT 网关成本、私有子网路由表关联、EKS 节点组容量这些细节环环相扣，凭记忆写极易漏项。

使用方式：直接描述目标环境，让技能先输出架构方案与模块边界，再逐模块生成 vpc 与 eks 代码，最后按步骤跑 fmt / validate / plan。实际体验是「上手难度低、一次成型率高」，尤其是 cidrsubnet 自动切分子网、NAT 网关 depends_on 互联网网关这类容易翻车的细节会被自动补齐。注意事项：第三方注册表模块的版本号仍需你自己拍板，生产环境建议锁到次版本而非直接放行主版本。

场景二：高级工程师做模块化重构与状态迁移

角色：负责存量仓库治理的高级工程师。痛点：早期配置大量硬编码、count 导致资源地址不稳定、状态文件还躺在某位同事本地。

使用方式：让技能给出重构路径——先把资源抽成带 variables.tf 校验的模块，再把 count 改为 for_each 以获得稳定地址，最后把本地状态迁移到 S3 + DynamoDB。实际体验是「风险提示到位」，它会强调先 tofu state list 摸清现状、迁移时用 tofu init -migrate-state、并提醒 state push 属于危险操作。注意事项：状态迁移务必先备份，prevent_destroy 应在关键资源上开启。

场景三：多环境差异化交付（dev / staging / prod）

角色：需要同时维护三套环境的团队。痛点：环境之间配置靠复制粘贴，改一处忘两处。

使用方式：选择 tfvars 或工作区策略，让技能生成 us-west-2 三可用区、dev 用 t3.small 单实例、prod 用 m5.large 三实例的差异化参数，配合 -var-file 调用。实际体验是「结构清晰、切换成本低」，配合同一套模块即可复用。注意事项：若环境间需要强隔离（不同账号、不同权限），优先选目录隔离而非工作区，避免误操作波及生产。

场景四：线上故障排查与漂移巡检

角色：值班工程师。痛点：apply 报状态锁超时、报资源已存在、报提供程序插件异常，排查靠猜。

使用方式：把报错直接贴给技能，它会给出针对性的处置路径——锁超时先验证无并发再 force-unlock；资源已存在用 tofu import 纳管或从代码移除；插件缓存损坏则清理 .terraform/ 与锁文件后重新 init；怀疑漂移就 plan -refresh-only。实际体验是「定位快、方案具体」，比翻文档快得多。注意事项：force-unlock、state rm、state push 都属于不可逆或高风险操作，执行前必须二次确认。

该技能能为用户带来的价值

效率提升：把「查文档—规划—写配置—调错」的循环压缩成一次描述加几轮确认。原本需要半天到一天才能搭好的 VPC + EKS + RDS 组合，借助标准模块与校验规则可以显著缩短到小时级；故障排查从「翻 issue 猜原因」变成「按清单逐条排除」。

门槛降低：cidrsubnet 网段切分、for_each 与 count 的取舍、远程状态锁定、lifecycle 规则、sensitive 输出标记这些「知道的人觉得简单、不知道的人反复踩坑」的知识点被内置成默认输出，中级工程师也能产出接近高级工程师水准的配置。

风险收敛：强制「先 plan 后 apply」「状态文件永不入库」「加密与最小权限默认开启」「关键资源加 prevent_destroy」，把最容易造成生产事故的几个动作变成流程中的固定关卡。同时通过 tofu plan -refresh-only 定期巡检，把环境漂移从「事后发现」变成「例行检查」。

长期价值：产出的不是一次性脚本，而是带版本约束、带变量校验、带输出文档的可复用模块资产。模块被复用得越多，团队交付新环境、新区域的边际成本越低；配合统一打标，还能为成本分摊与账单归因提供数据基础。

常见问题 FAQ

Q1：这个技能怎么安装？装完怎么确认生效？

在平台的技能入口搜索英文名 terraform 或技能 ID 13477，按提示启用并授予文件读写与命令执行权限即可，具体安装命令与入口以官方说明为准。验证方式：新建会话提问「用 opentofu 写一个带私有子网的 VPC 模块」，若回复中出现模块目录结构、变量校验规则与 tofu plan 建议，即说明已生效。使用前请确保本地已有 OpenTofu/Terraform 命令行环境和云厂商凭证。

Q2：这个技能收费吗？

技能本身是否收费取决于所在平台的定价策略，本技能说明中未包含价格信息，请以官方说明为准。需要额外注意的是，技能生成的配置在 apply 后会真实创建云资源，云厂商侧产生的费用由你的账号承担，建议先用 infracost breakdown --path . 做成本估算。

Q3：它用的是 Terraform 还是 OpenTofu？两者能混用吗？

技能首选 OpenTofu（tofu 命令），它是 Linux 基金会维护的 Terraform 开源分支，语法和配置完全兼容。命令层面是一一对应的：terraform init ↔ tofu init、terraform plan ↔ tofu plan、terraform apply ↔ tofu apply、terraform state ↔ tofu state、terraform import ↔ tofu import、terraform workspace ↔ tofu workspace。迁移提供程序地址时可用 tofu state replace-provider 替换注册表来源。建议同一仓库内统一用一种命令，避免锁文件与缓存混乱。

Q4：适合谁用？我是刚接触云的新手可以吗？

技能的主要用户定位是高级软件工程师，内容深度偏向架构与治理，因此更适合已有一定云基础、需要落地生产架构的工程师。新手也能用——它会给出可运行的完整目录和详细注释，但建议严格遵循「先 plan 后 apply」、先在 dev 环境验证、不要在不懂的配置上直接 apply。另外请注意，本技能不替代对 tofu destroy 这类破坏性命令的判断，执行前务必看清计划输出。

Q5：状态文件能不能提交到 Git？本地状态怎么迁移到远程？

不能。状态文件中会包含明文形式的敏感数据（如密码、密钥），必须使用带加密的远程状态后端，并配合锁表防止并发修改。迁移方式：先在 backend.tf 中配好远程后端（如 S3 + DynamoDB，开启 encrypt = true 与版本控制），再执行 tofu init -migrate-state 完成迁移；跨后端迁移时用 tofu init -migrate-state -backend-config="bucket=新桶名"。迁移前请务必备份现有状态。

Q6：它和直接用 Terraform 命令、或者问通用 AI 有什么区别？

直接用命令解决的是「执行」，通用 AI 解决的是「给个示例」，而这个技能解决的是「怎么组织一整套可持续维护的 IaC 工程」：模块边界怎么切、变量怎么校验、状态怎么隔离、加密与最小权限怎么落地、出了问题按什么顺序排查。它还会主动提醒你做计划审查与漂移巡检——这些流程性约束，恰恰是 IaC 项目成败的关键。