terraform-engineer Skill 入门：让 AI 助手按企业级规范写 Terraform

terraform-engineer 是一个给 Claude Code 这类 AI 编程助手用的技能包（Skill）。它本身不是软件，而是一套写好的规范文档：装进 AI 助手之后，AI 在帮你写 Terraform 基础设施代码时，会照着里面的企业级标准来写——模块怎么拆、状态文件放在哪、密钥怎么存，都有现成的规矩。对使用者来说，用法只有两步：把文件夹放进 Claude Code 的技能目录，然后正常提需求，剩下的由 AI 自己判断什么时候调用。

先交代背景。Terraform 是 HashiCorp 出品的基础设施即代码（IaC，Infrastructure as Code）工具，用配置文件描述云上的服务器、网络、数据库，一条命令创建或销毁整套环境，是云计算运维的主流工具之一。写 Terraform 代码入门不难，难在写得规范：状态文件管理不善会导致团队协作冲突，密钥写死在代码里会造成泄露事故。这个 Skill 要解决的就是”规范”这一层。

装的是一位十年经验工程师的工作习惯

Skill 是 Claude Code 的扩展机制：一个文件夹里放一份 SKILL.md 主文件和若干参考文档，AI 根据任务内容自动判断要不要加载。对 Skill 机制还不熟的读者，可以先看find-skills 入门，那篇讲了技能的发现和安装；本站此前介绍过的 product-marketing-context 也是同类技能包，只是面向营销场景。

terraform-engineer 的 SKILL.md 给 AI 设定的角色，是一位有十年以上基础设施自动化经验的资深 DevOps 工程师，主攻 Terraform 1.5 以上版本和 AWS、Azure、GCP 三大云平台。触发条件覆盖六类任务：开发可复用模块、配置带锁的远程状态、配置三大云的 Provider、搭建多环境工作流、做基础设施测试，以及把存量资源迁移到 Terraform 管理。只要对话里出现这些主题，AI 就会按这套规范输出。

它给 AI 规定的工作流分五步：分析基础设施需求、设计带输入校验的可组合模块、配置带锁定和加密的远程状态后端、落实最小权限等安全策略、最后用 terraform plan 和自动化测试验证。每次输出方案时，AI 被要求给全五样东西：模块结构（main.tf、variables.tf、outputs.tf）、状态后端配置、带版本约束的 Provider 配置、tfvars 使用示例，以及一段设计决策说明，而不是只丢下一段代码。

包里有什么：1 份主文件加 5 份参考手册

整个包共 7 个文件、约 2300 行，全部是 Markdown 文档和一个元数据 JSON，没有任何可执行代码。主文件之外的五份参考手册按需加载，各管一摊：

• module-patterns.md：模块设计模式。给出标准模块目录结构（main/variables/outputs/versions 四件套加 examples 和 tests），变量一律带 validation 校验块，资源复制用 for_each 而不是 count，还有动态块、条件资源和模块版本锁定的完整 HCL 示例。
• state-management.md：状态管理，五份手册里内容最重的一份。S3 加 DynamoDB 锁、Azure Blob、GCS 三种远程后端的完整配置都有，连状态桶本身的加密、版本化、防公开访问怎么建都写了；后半部分是 workspace 用法、state mv/rm/import 等状态操作命令和迁移流程。
• providers.md：三大云的 Provider 配置，每家云各列了四种认证方式并注明适用场景——比如 AWS 推荐 CI/CD 用环境变量、EC2 上用 IAM 角色，GCP 生产环境明确不推荐服务账号密钥文件。Kubernetes 和 Helm 的 Provider 配置也顺带覆盖了。
• testing.md：测试策略，从 terraform validate、plan 审查，到 Terraform 1.6 新增的原生 test 框架、Go 语言的 Terratest、OPA/conftest 策略即代码检查、TFLint 静态检查和 pre-commit 钩子，整条测试工具链都有配置示例。
• best-practices.md：篇幅最大的一份，DRY 原则、snake_case 命名规范（布尔变量要写成疑问形式）、密钥分级处理（sensitive 变量起步、密钥管理服务更好）、资源标签和成本优化，文末附一张上线前检查清单。

它立下的规矩：8 条必须做、8 条不许做

SKILL.md 里最有分量的部分是两张硬性约束清单，AI 输出的每份方案都要过这道筛子。必须做的 8 条：模块用语义化版本号、启用带锁定的远程状态、输入变量带校验块、命名规范统一、所有资源打成本追踪标签、模块接口写文档、Provider 版本固定、跑 terraform fmt 和 validate。

禁止做的 8 条：明文存密钥、生产环境用本地状态、跳过状态锁定、硬编码环境相关的值、混用无约束的 Provider 版本、制造模块循环依赖、跳过输入校验、把 .terraform 目录提交进代码库。

这 16 条里分量最重的是状态和密钥两组。团队协作中两个人同时执行 apply 导致状态损坏、密钥随代码库泄露，是 Terraform 生产事故里最常见的两类，清单把它们全部前置拦截。以远程状态为例，手册里给的 S3 后端配置是这样的：

terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "production/vpc/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-state-lock"
  }
}

加密、独立的锁表一个不少，这份配置可以直接拿去改名使用。

安装与使用

Skill 可以在 CocoLoop 商店的 terraform-engineer 页面下载 zip 包（免费），也可以用该平台客户端的”快速安装”。手动安装解压到 Claude Code 的技能目录即可：

mkdir -p ~/.claude/skills/terraform-engineer
unzip terraform-engineer.zip -d ~/.claude/skills/terraform-engineer

有个实测发现的小坑：这个 zip 包里参考文档的路径用了 Windows 风格的反斜杠，在 Linux 和 macOS 下解压会得到名为 references\module-patterns.md 这类的文件，而不是 references 子目录。需要手动修复，否则 SKILL.md 里的引用路径对不上：

cd ~/.claude/skills/terraform-engineer
mkdir -p references
for f in references\\*.md; do mv "$f" "references/${f#references\\}"; done

装好之后不需要任何配置。在 Claude Code 里提出与 Terraform 相关的需求，比如”给这套 VPC 写一个可复用模块，状态放 S3″，AI 会自动加载这个 Skill，按上面那套规范输出代码。SKILL.md 文末还列出云架构、CI/CD、安全合规、Kubernetes 四个相关技能方向，作为团队分工时的配合建议。搭配 Claude Code 本身的命令执行能力，plan 和 apply 也可以让它代跑——Skill 管的是”写得规范”，执行环节靠助手本体。对 Claude Code 用法还不熟的读者，可以参考本站的 Claude Code 32 个实用技巧。

适用边界与几点提醒

这个 Skill 更适合两类人：已经在用 Terraform、想让 AI 生成的代码直接达到团队规范水位的工程师；以及有一定基础、想按企业标准系统补课的进阶学习者。完全没接触过 Terraform 的初学者，建议先把官方教程的 plan/apply 基础流程走一遍再来用它，否则 AI 输出的模块化方案反而会增加理解负担。

有几点事实需要交代清楚。第一，它是纯文档型技能，通过了 CocoLoop 平台自家的 CLS 安全扫描（据该平台标注为 S+ 级，无可执行代码），但文档本身不会验证配置正确性，所有代码在进生产环境前仍要自己跑 plan 和测试。第二，作者 veeramanikandanr48 是个人开发者，当前版本 v0.1.0 没有历史版本，也没有声明开源许可证；元数据里标注的上游 GitHub 仓库 clawdbot/skills 在本文写作时（2026 年 9 月）已经打不开，分发目前依赖 CocoLoop 的镜像。拿不准的技术细节，以 HashiCorp 官方文档为准。

国内使用还有两点。Terraform 官网和 Registry 国内可以直接访问，但 Provider 插件下载速度不稳定，必要时可配置国内镜像源。手册里的示例全部基于 AWS、Azure、GCP，用阿里云、腾讯云的团队要把资源类型换成对应的官方 Provider（alicloud、tencentcloud），不过模块拆分、远程状态、输入校验这些规范是通用的；HashiCorp 2023 年变更许可证后社区分叉出的 OpenTofu，同样适用这套文档的绝大部分内容。