借助 AI 将 Terraform 大文件拆成模块

一份约 1600 行、包含 45 个资源的 Terraform 配置，如何借助 AI 拆成七个模块，同时保持线上资源不变？dev.to 作者展示了一套结合 HashiCorp Agent Skills、Terraform MCP Server 和 moved blocks 的流程。重点是让代码结构调整与状态地址迁移保持一致。

目前能确认什么

作者接手的是已经纳入 Terraform state 的配置，但资源名称仍带着导入时的编号，大量 ID 和 ARN 被硬编码，资源旁还留着 45 个 import blocks，也无法直接复用于第二套环境。

硬编码字符串即使指向正确资源，也未必能让 Terraform 识别资源之间的依赖。改用资源引用，才能把这种关系表达在配置里。

作者先让 AI 盘点资源，再提交模块划分和完整的新旧地址映射表，人工批准后才生成代码。Agent Skills 提供模块设计与命名规范，MCP Server 则帮助查询锁定版本的 Provider 文档。

moved blocks 用来声明资源地址的迁移关系，避免 Terraform 将地址变化误判为删除旧资源、创建新资源。作者给出的验收条件是：

plan 必须为 0 to add、0 to change、0 to destroy，仅包含地址迁移。

工作区还配置了 Sentinel 策略，检查删除、替换和原地更新。作者明确说明，这是在 HashiCorp 工作期间构建的演示，并非生产就绪方案。

我的判断

对维护存量基础设施的程序员，最有参考价值的是先审地址映射表，再审生成代码。模块边界和资源归属在表格里更容易核对，也能提前发现遗漏。

AI 可以协助整理配置，但是否改动真实资源，应由实际 state 对应的 plan 和策略检查来判断。

现有节选尚未完整展示迁移执行、最终验证及 CloudFormation 退役过程。因此，可以确认作者设置了严格的重构验收条件，还不能据此认定完整流程已被证明适用于生产环境。