基础设施即代码

你要解决的问题

Terraform 写到第十个环境时，通常会撞上几类反复出现的问题：main.tf 越堆越长，变量既没描述也没默认值，sensitive 标记被漏掉，状态锁冲突时没人知道该先查谁。更麻烦的是评审：一次 plan 输出几十页，审阅者很难判断这到底是不是预期变更。

这个技能把「写配置」和「写可交付的模块」区分开。它不会替你执行命令，而是给你一套结构化的产出和检查路径，让你一次对话后拿到可以直接进流水线的模块或环境配置。

它如何工作

核心能力

• 先做判断：诉求是跨环境复用的模块，还是仅某个环境独有的配置
• 生成模块骨架：main.tf、variables.tf、outputs.tf、versions.tf、README.md，并推荐提供可跑的 examples/
• 管理远程状态：S3 + DynamoDB 锁、状态加密、定期备份，用 terraform plan -detailed-exitcode 做漂移检测（返回 0 无变化、2 有漂移）
• 排障路径：状态锁、Provider 鉴权失败、资源已存在与依赖、模块源、Terragrunt 依赖环或 hook
• Terragrunt DRY：根 terragrunt.hcl 加环境目录，用 dependency 配合 mock_outputs 让 validate 和 plan 在依赖未就绪时也能跑

关键步骤

1. 判定复用边界，单职责模块配合理默认值
2. 产出文件清单与变量/输出描述，敏感项标记 sensitive=true
3. 检查后端类型、锁是否启用、是否检测到漂移
4. 输出两份结构化工件：IaCModule（文件、变量、输出、版本约束、CI 阶段）与 StateReport（后端、锁、漂移、资源数、建议）

IaCModule 可以直接交给 CI 流水线执行 plan、validate 和 checkov；StateReport 可以交给成本优化工具做资源标签分摊。落地说明里还会写清设计取舍、敏感项处理方式，以及你需要自己补的远端状态和云凭证。

适用边界

• 不执行 terraform 或 terragrunt 命令，只产出配置与操作步骤
• 具体云资源参数以对应云厂商文档为准，不替代文档查询
• 密钥绝不写入代码；敏感变量必须标 sensitive=true 并走密钥管理，CI 建议用 OIDC 取云凭证
• 提交前仍需人工过一遍清单：terraform fmt -recursive、terraform validate、tflint --module、checkov -d .，以及 terraform state rm、terraform state mv、terraform import 这类状态操作要在确认影响后执行