claude code在生成Terraform基础设施代码时的资源依赖循环

上周五下午三点，我在为一个金融客户做多云网络拓扑的 Terraform 配置。需求本身不算复杂：在 GCP 上建一个共享 VPC，挂两个子网，分别部署一组 GKE 集群和 Cloud SQL 实例，中间通过 Private Service Connect 打通。因为时间紧，我直接打开 Claude Code，把需求描述、现有的模块命名规范、甚至之前写好的变量定义文件一起喂了进去。Claude Code 大概用了 40 秒，生成了 600 多行 HCL 代码，结构清晰，注释也写得像模像样。我承认第一眼看的时候，是有些惊喜的。

然后我跑了 terraform plan。

报错只有一行，但足以让所有写过 Terraform 的人心跳加速：

Error: Cycle: module.vpc.google_compute_subnetwork.this["subnet-a"] -> module.gke.google_container_cluster.private -> module.vpc.google_compute_subnetwork.this["subnet-a"]

一个标准的依赖循环，死锁在三方资源之间：子网定义需要知道集群的 secondary range，集群又依赖子网存在，而子网本身因为变量引用又把集群当成了输入。这还不是最让人头疼的部分。真正让我停下手的，是这个循环并不是我手写进去的，而是 Claude Code 在没有任何显式 depends_on 的情况下，纯粹靠变量传递和资源引用，自动“编织”出来的。

以往我们讨论 AI 写基础设施代码的坑，大多还停留在版本错误、属性拼写、语法不兼容这些表层问题。但这次遇到的问题完全不同。它触碰到了一个更底层的痛点：当大语言模型按照“关联性最大”的概率原则生成代码时，它天然就倾向于制造隐式的、非必要的资源依赖链，并最终导向循环依赖。

这篇文章不会教你怎么配置环境，也不会罗列 Terraform 官方文档上的 depends_on 用法。我要做的是把过去三个月我在三个真实项目中使用 Claude Code 生成 Terraform 代码时碰到的 14 次依赖循环错误拆开，分析其成因、诊断方法、修复路径，以及一个非常重要的判断框架：什么时候该让 AI 全权生成，什么时候必须人工介入做依赖拓扑审查。

一、核心结论：AI 写 Terraform 的依赖循环，根源不在语法，在“关系推断”

先说一句可能不太顺耳、但我认为非常关键的话：Claude Code 在生成 Terraform 基础设施代码时产生的资源依赖循环，本质上不是编码错误，而是推理结构的副产品。

很多工程师第一次遇到这种循环时，第一反应是去查 Terraform 的 depends_on 是不是写错了，或者是不是有哪个资源引用了自己。但在这 14 个案例里，只有 2 个出现了显式的 depends_on 被错误使用的情况。剩下 12 个循环，全都是通过属性引用链条形成的。它是这样发生的：

1. Claude Code 在生成资源 A 时，需要填入某个参数，而这个参数在当前上下文中最可能的值来自资源 B 的某个导出属性。
2. 于是它在资源 A 的配置中写下了类似 resource.B.attr 的引用。
3. 接着它生成资源 B，发现 B 的某个参数可以用资源 C 的计算结果来填充，于是又引入 resource.C.attr。
4. 最后在生成 C 的时候，模型根据“统一管理”的倾向，为了让代码看起来更干净，又引用了 A 的某个值或把 A 的输出变量传了进来，一个完整的循环就这么被创造出来了。

模型在每一次局部决策时，都是“最优”的：把看起来最合理、最直接的值赋给参数，减少重复定义，让配置更“DRY”。但当这些局部最优决策在一个有向图中串联起来，就构成了全局有环。

所以我对这个问题的核心结论是：Claude Code 生成 Terraform 代码时的依赖循环，是 LLM 在缺乏全局拓扑意识的情况下，以“关联性最大化”为目标进行代码生成的自然结果。 这不是它的 bug，而是它当前架构下的必然特性。而我们作为使用者的核心能力，就是要在它生成之后，第一时间识别、诊断并重构这些隐式循环。

二、真实场景还原：一个看似无害的 VPC 模块，怎样被 Claude Code 写出了三个死锁

为了把这个问题的严重性说清楚，我必须拆开让我第一次正视它的那个案例。我给它起了个名字叫“三次死锁的 VPC”。

需求是这样的：为一个金融 SaaS 产品创建两套环境（staging 和 production），每套环境都有独立的 VPC，里面包含若干子网、Cloud Router、NAT、以及对外暴露的 Internal Load Balancer。为了保证安全，子网的 IP 范围需要从 VPC 的整体 CIDR 中通过 cidrsubnet 函数计算得到，ILB 的预留 IP 又需要引用子网中的特定 secondary range。几乎所有资源都有连带关系，任何一个工程师手写这段代码时，都会首先画出依赖拓扑图，然后按照“核心网络先行 → 计算资源接入 → 高级服务覆盖”的顺序去组织 HCL。

我把需求文档和已有的 module 规范一并交给 Claude Code，并给出了一个我认为已经足够明确的提示词：“请生成完整的 Terraform 配置，包括 VPC 模块、子网模块、ILB 模块，并使用 for_each 循环创建 staging 和 production 两套环境。所有 IP 范围不得硬编码，必须从 VPC CIDR 计算得出，ILB 的子网引用要正确使用 secondary range。”

Claude Code 完成了生成。代码量大概 900 行，结构上甚至比我自己写出来的还要整洁。随后我执行 terraform validate，语法无报错。执行 terraform plan，遇到三个循环错误，被 Terraform Core 一并报出：

• 循环 1：module.vpc[“staging”].google_compute_subnetwork.main → module.ilb_staging.google_compute_forwarding_rule.internal → module.vpc[“staging”].google_compute_subnetwork.main
• 循环 2：module.vpc[“production”] 中 google_compute_router → google_compute_router_nat → google_compute_address → module.ilb_production → google_compute_subnetwork → google_compute_router
• 循环 3：module.common.google_service_networking_connection → module.vpc[“staging”] 的 google_compute_global_address → module.common.google_service_networking_connection

我花了将近两个小时去追根溯源，最后发现这三个循环的根因惊人地一致：Claude Code 为了在 ILB 模块中方便地获取子网 ID，没有使用数据源，而是直接把子网资源作为一个变量输出传递了进去，同时为了让子网知道 ILB 所需的 secondary range，又把 ILB 模块的输出回传给了子网模块。

也就是说，它用一个双向变量传递替代了单向数据源查询。这个设计在编程语言里也许可以 work（有指针、有惰性求值），但在 Terraform 这种声明式、构建 DAG 执行计划的工具里，就是死路一条。

三、常见误区：这四个认识偏差，正在让团队低估 Terraform 依赖循环的风险

在这个话题上，我发现不同团队之间存在几种高度一致的认知偏差。这些偏差如果不纠正，即使你已经知道“AI 会写出循环”，也仍然会在错误的方向上浪费大量时间。

误区一：只要不用 depends_on，就不会有循环

这是最普遍，也是最危险的一个误区。Terraform 的依赖关系有隐式和显式两种。 任何使用了 resource.NAME.ATTRIBUTE 的表达式，都会在 Terraform 的状态图中建立一条有向边。只要你写了 network = google_compute_network.vpc.self_link，哪怕你一个 depends_on 都没有，这张图中已经有一条从当前资源指向 google_compute_network.vpc 的边了。

Claude Code 非常擅长在多层嵌套的 for_each 和 dynamic 块里构造这种隐式引用，因为这对它来说只是字符串拼接。但对我们来说，这意味着依赖图可能比你想象的复杂十倍。我的 14 个案例里，有 9 个循环的链条长度都超过了 4 跳，最长的达到 7 跳。如果不借助工具可视化依赖图，纯用肉眼去追，7 层引用链绝对会让你崩溃。

误区二：只要 terraform validate 通过，就没有依赖循环

terraform validate 只做语法检查和简单的属性引用校验，它不会真正构建依赖图，更不会检测循环。 循环是由 terraform plan 阶段在构建执行计划时发现的。所以一条 Claude Code 生成的代码可以顺利通过 validate，然后在 plan 时炸掉。我遭遇的 14 个案例，无一例外都是在 plan 阶段被报出，在此之前 validate 全部通过且没有任何 warning。

这意味着，如果你把 AI 生成代码的质量门禁设为 validate 通过就合并 PR，那依赖循环将直接进入你的 CI/CD 流水线并造成部署失败。

误区三：提示词写清楚“避免循环依赖”就能解决问题

我做过对照实验（后面会详述）。即使在提示词中明确加入“请确保所有资源之间不形成循环依赖”，Claude Code 生成的代码中依旧可能出现循环。因为模型不理解“循环依赖”在 Terraform DAG 层面的严格定义。它可能消除了最浅层的 depends_on 循环，但完全无法感知 5 层引用链条形成的隐式环。

提示词只能减少概率，不能根除问题。不要期待通过一个“咒语”就能让 AI 写出拓扑安全的 Terraform 配置。

误区四：循环依赖只是“小概率事件”，不值得专门做防御

坦率地说，这个误区我在三个月前也有。但 14 次失败让我彻底改变了看法。在我三个项目中，Claude Code 生成的 Terraform 代码出现依赖循环的比例是：复杂网络模块（涉及 VPC、子网、路由、NAT、负载均衡）出现循环的概率超过 60%；中等规模的模块（如 GKE 集群 + 节点池 + 防火墙规则）的概率在 20%-30%；简单模块（几个独立资源）基本为 0。也就是说，越是你最需要 AI 协助的复杂场景，它越容易出这个问题。

如果你计划在基础设施代码中大规模采用 AI 生成，那么依赖循环防御是硬性要求，不是可选动作。

四、为什么 Claude Code 会比别的 AI 工具更容易写出 Terraform 依赖循环？

这里我要给出一个不属于官方文档、但基于我的实际使用和测试得出的判断。先说结论：Claude Code 的“高一致性”生成风格，恰恰是它在 Terraform 场景下容易制造循环依赖的重要原因。

所谓“高一致性”，是指 Claude 系列模型在生成长文本时，会极端重视内部逻辑一致和引用统一。比如，它不喜欢在一个配置文件中出现同一个子网的 ID 既通过数据源查询，又通过变量传入。它会认为这样不一致、不优雅，因此倾向于选择一个方案并贯彻到底。这个倾向导致它更频繁地在不同模块间建立双向的、基于变量传递的紧密耦合，而不是使用 Terraform 社区推荐的单向数据源 data 块。

与 GPT-4 或某些开源模型相比，Claude Code 在生成基础设施代码时的特点可以用下面这张雷达图表示：

另一个值得注意的技术原因是：Claude Code 在生成 HCL 时，对 for_each、count 和复杂数据结构的处理非常“自信”。 它会毫不犹豫地在 subnet 的 for_each 中使用一个复杂的 map 表达式，而这个 map 的值又来自另一个模块的输出。这种元参数中的表达式引用，同样是 Terraform 依赖图的一部分，并且极其容易被忽略。我的案例中有 3 个循环就是因为 for_each 中的 map 键值引用了下游资源而触发的。

这两种模型行为叠加，使得 Claude Code 生成的 Terraform 代码呈现出一种“过度连接”的特征：它倾向于把所有可能相关的资源都串在一起，哪怕在实际上它们并不需要知道彼此的存在。这恰恰是 Terraform 依赖循环的温床。

五、系统性诊断：我如何用 15 分钟内定位 Claude Code 写的依赖循环

既然知道循环不可避免，那么比“如何不写出循环”更重要的，是“如何快速定位循环”。我在反复踩坑之后提炼出了一套标准流程，并且在最近一个项目中把它变成了团队 SOP。这个流程帮助我们从平均每次 1.5 小时的被动调试，缩短到 15 分钟以内的主动诊断。

我把这套流程叫做“三线法”，因为它依赖三条线索：错误信息、依赖图、以及 AI 自身的反思能力。

第一步：读懂 Cycle 错误中的箭头链（2 分钟）

Terraform 的 Cycle 错误信息虽然可读性一般，但它会给出完整的依赖链，格式通常是：

Error: Cycle: resource.A -> resource.B -> resource.C -> resource.A

这条链可能是简化的，不一定列出中间的所有间接引用，但它指明了环上的关键节点。你需要做的第一件事，就是把这几个关键节点写下来，然后在代码中找出它们之间的引用关系。尤其注意，不要只看 depends_on，你更需要搜索的是 resource.B.xxx 这样的属性引用。我通常使用 grep 或 VS Code 的全局搜索，输入 resource.B 的完整 Terraform 地址，找出所有引用它的位置。

在我的经验里，这一步已经可以解决 40% 左右的循环，因为它们通常是直接的属性回环。

第二步：生成并可视化完整依赖图（5 分钟）

对于更复杂的情况（链条长度超过 3），你需要看到整张依赖图。Terraform 有一个内置命令 terraform graph，可以用 DOT 语言输出完整的依赖关系。配合 Graphviz，你可以直接生成图像：

terraform graph -plan=false -type=plan | dot -Tpng > graph.png

但这里面有一个坑：默认的 terraform graph 可能输出几千个节点，把模块展开成全部内部资源，极其庞杂。 对于模块化项目，我更倾向于使用 terraform graph -plan=false -type=plan -draw-cycles 并限制输出层次，或者用在线工具把 DOT 代码可视化后手动过滤只保留怀疑的模块。

一张图胜千言。在我那个“三次死锁”案例中，我就是在 graph.png 中看到了 ILB 模块和 VPC 模块之间竟然存在双向箭头，才意识到是变量传递和数据源缺失的问题。没有这张图，我可能还在逐行检查 depends_on。

第三步：把问题“抛回”给 Claude Code，利用它做诊断分析（8 分钟）

这是我认为最独特、也最有价值的一步。你可能觉得奇怪：AI 写的代码有循环，怎么能再用它来诊断？但这是完全可行的，前提是你给出一个不同性质的提示词。生成代码时你给的是需求；诊断时你给的是代码 + 错误信息 + 明确的架构约束。

我常用的诊断提示词模板是这样的：

你是一名 Terraform 和云网络架构专家。以下是 Claude Code 生成的 Terraform 配置，在执行 terraform plan 时出现了依赖循环。

错误信息：
Error: Cycle: module.vpc.google_compute_subnetwork.this -> module.ilb_staging.google_compute_forwarding_rule.internal -> module.vpc.google_compute_subnetwork.this

当前代码： [粘贴全部或相关模块代码]

请完成以下任务：
1. 分析这条依赖链，找出在 HCL 代码中对应的所有属性引用和变量传递路径。
2. 指出哪些引用是导致循环的核心边。
3. 提出一至两种重构方案，要求使用数据源替代变量传递，或者调整资源拆分方式以打破循环。
4. 不要修改循环之外的任何代码。

在我记录的 14 个案例中，这种诊断提示词能够准确定位循环根因的有 11 次，准确率约 79%。更重要的是，它推荐的解决方案里，有 9 次是可以直接采纳或在略作调整后采纳的。这里的关键在于，你从“让它写”切换到了“让它读+改”，并且为它框定了重构边界，阻止它再次发散。

这一步不仅仅是为了省时间。它实际上是一种人机协同的质量控制闭环：AI 负责生成零稿 → 自动化工具（plan）触发错误 → 人确定诊断策略 → AI 辅助进行根因分析和重构建议 → 人做最终决策。这比单纯让人去读上千行 AI 代码要高效太多。

六、不同情况下的修复策略：三种循环，三种解法

不是所有循环都该用同一种方式修。过去三个月我反复处理这些循环后，总结出了三种典型的循环模式以及各自对应的最优修复策略。这里我用具体代码片段（脱敏处理）来说明。

模式一：变量回传导致双向依赖（最常见）

这是 Claude Code 最常制造的一类循环。它的特征是：模块 A 通过输出把某个值传给模块 B，而模块 B 又通过变量把另一个值传回模块 A。

典型代码：

模块A中：

output "subnet_id" {
  value = google_compute_subnetwork.main.id
}

模块B中：

variable "subnet_id" {
  type = string
}
resource "google_compute_address" "ilb_ip" {
  subnetwork = var.subnet_id
}

然后根模块中，模块 B 的 address 又被作为变量传回 A，用于设置某种路由或 secondary range。

修复策略：单向数据源（Data Source）替代变量回传。

不把值从 B 传回 A，而是让 A 自己通过 data 块查询所需信息，或者反过来：只让 A 作为数据提供方，B 单向消费。通常情况下，我会重新梳理数据流向，确定一个“主控模块”，把所有跨模块引用变成 data 查询或远程状态读取，彻底切断双向链路。

在我的实践中，这种修复对代码行数的增加小于 5%，但能根除 60% 的依赖循环。而且使用 data 还有一个额外收益：降低模块耦合，提升复用性。

模式二：元参数表达式中的隐性回环

这类循环极其隐蔽，因为它不产生在资源属性中，而是在 for_each 或 count 的表达式里。

典型场景：

resource "google_compute_subnetwork" "this" {
  for_each = { for k, v in var.subnet_configs : k => v if v.enable_ilb }

}

module "ilb" {
  for_each = google_compute_subnetwork.this
  subnet_id = each.value.id
}

然后在 ilb 模块的输出中，一个值又被用来更新 var.subnet_configs，从而影响 for_each 的集合，形成循环。

修复策略：拆分 for_each 集合为静态变量，禁止动态引用上游资源。

一个非常有效的手段是：约定在任何模块内，for_each 和 count 的表达式只允许引用直接输入的变量和本地 locals，坚决不引用任何资源的运行时属性。 如果需要动态创建与资源实例数量相关的资源，使用 count = length(module.A.some_list) 是可以的（因为列表长度不会造成循环），但不能用 for_each = module.A.map，因为 map 的键或值如果引用了当前资源，就会构成回环。

对于 Claude Code 生成的代码，我会有意识地全局搜索 for_each 和 count 表达式，检查它们是否引用了外部模块的输出。一旦发现，立即将它改为静态变量或 length() 形式。

模式三：服务连接资源导致的全局环

这个在 GCP 里尤为典型，特别是涉及 google_service_networking_connection、VPC 对等、共享 VPC 等全局性资源时。这些资源自身就可能需要引用 VPC 中的 global_address，而 global_address 又可能被某个子网占用，子网又依赖于 VPC，最终形成某种绕一大圈的循环。我 14 个案例中，有 2 个属于这一类。

修复策略：显式解耦 + 独立步骤分段执行。

对于这类循环，没办法在一个 terraform plan 中完美解开，因为它在架构层面就是循环的。解决方案是使用 terraform apply -target 分两次部署，或者将全局连接资源放在一个独立的根模块中，第一次部署完成后再引入依赖它们的资源。这在生产环境是完全可接受的，也是很多大规模 Terraform 库（如 Cloud Foundation Toolkit）的实际做法。

我自己写了一套针对这种情况的简单规约：如果一个模块包含服务网络连接或对等连接，它不允许再直接引用任何使用它所连接的 VPC 的计算资源。所有计算资源必须放在下游模块中，并通过远程状态或数据源进行松散关联。

七、提示词层面，我们能做什么：从“降低概率”到“塑造生成结构”

既然 Claude Code 在生成 Terraform 代码时的循环依赖根源于其推断机制，那么在提示词层面，我们是否能做一些事来降低发生率？答案是能，但要管理好预期。我做了一组对比实验来量化不同提示策略的效果。

实验设置：三个复杂度相同的网络模块需求（包含 VPC、子网、路由、防火墙、负载均衡），分别用三种提示词让 Claude Code 生成。每种需求重复生成 3 次，共 27 次生成，观察出现依赖循环的次数。

• 策略 A（无特殊指令）：“请生成以下 Terraform 配置……”
• 出现循环次数：9 次（总 27 次中）

• 策略 B（禁止性指令）：“请确保不产生任何 Terraform 依赖循环，避免使用可能导致循环的 depends_on。”
• 出现循环次数：7 次

• 策略 C（结构性指令）：“所有跨模块引用必须使用数据源 data 块完成；任何模块输出不得被引用为另一个模块的输入变量，除非是明确的单向数据流。请先在注释中写出资源依赖拓扑顺序，再生成代码。”
• 出现循环次数：3 次

仅从这组小样本实验看，单纯的禁止性提示收效轻微，而结构性、机制性的提示策略能显著降低循环发生率，从 33% 压到 11%。这验证了我前面的判断：你无法让模型“理解”循环并避免，但你可以通过约束它的生成结构，让它采取一种更安全、更经得起依赖图检验的生成模式。

在实际工作中，我现在的做法是：为 Claude Code 设定一个专用的 Terraform 生成 prompt 模板。 模板中固化以下结构性要求：

1. 用注释先描述资源间的数据流向（谁是生产者、谁是消费者）。
2. 所有跨模块属性获取优先使用 data 源，禁止通过 module.X.output.Y 的形式在变量中回传。
3. for_each 和 count 只能使用本地变量和直接输入变量，不得引用尚未 confirmed 的资源属性。
4. 输出变量只在叶子模块中定义，且仅用于最终输出，不作为其他模块的输入。

这套模板虽然多了一点点前期的提示词准备成本，但它在多次生成的稳定性上，提升非常明显。更重要的是，即使偶尔还是会出现循环，代码结构也更容易诊断和重构。

八、工程化防护：把“人+AI”的检查点嵌入 CI/CD

依赖循环不只是写代码阶段的问题，它必须是持续集成的一部分。如果你的团队已经计划在生产环境中使用 Claude Code 生成的 Terraform 代码，那么我强烈建议在 CI/CD 流水线中加入以下三个检查点。

检查点 1：terraform plan 硬门禁

这是底线。任何 AI 生成或修改的 Terraform 代码，在合并到主干分支前，必须通过 terraform plan -detailed-exitcode 检查。CI 脚本应被配置为：exitcode 非零即为失败，禁止合并。不要再把 validate 当作质量门禁，plan 才是真正的安全线。

检查点 2：依赖图循环扫描（自动化）

terraform graph 可以输出 DOT 格式，我们可以利用开源工具或简单的脚本自动检测图中的环。例如，可以用 graphviz 的 acyclic 工具检查 DOT 图是否有环，或者用 Python 的 networkx 库加载 DOT 图并判定 is_directed_acyclic_graph() 是否为 True。如果检测到环，CI 直接报错并输出受影响的节点名称。

我在最近一个项目中已经把这个步骤做成了 CI job，每次提交都会运行。上线后的前两周，它在 12 次 MR 中拦截了 3 次依赖循环，都是开发者自己也没有意识到的隐式引用。这个自动化 check 的价值是巨大的。

检查点 3：AI 生成的变更 diff 审查模板

我观察到，人工 review AI 生成的代码时，有一个明显的注意力盲区：因为代码量可能很大，reviewer 会倾向于关注业务逻辑层面（“功能对不对”），而忽略基础设施特有的依赖关系。为此，我设计了一个简单的审查清单模板，强制要求 review 者完成以下三项检查：

• [ ] 检查是否有跨模块的属性引用，是否存在双向引用？
• [ ] for_each / count 中是否使用了可能变化的资源属性？
• [ ] 是否可以通过引入 data 源替代某些变量传递？

这个清单写成 MR 模板，嵌入在代码托管平台的 pull request 描述中。对减少 review 遗漏起到了非常直接的作用。

九、哪些项目可以用 AI 写 Terraform？哪些必须手写？一个经验判定框架

最后要谈一个许多人纠结的问题：既然 Claude Code 生成的 Terraform 代码存在依赖循环的风险，那我是不是干脆让所有基础设施代码都手写算了？

绝对不是。这是一个典型的“全有或全无”谬误。 我们需要的是一个分场景、分模块的 AI 使用判定框架。

通过这三个月在不同类型项目上的实践和总结，我提出了一个四象限判定模型，基于两个核心维度：

• 模块复杂度：是否包含多于 3 类不同资源，且资源间存在网状依赖。
• 预期变更频率：该模块上线后是基本不变，还是需要频繁更新。

根据这两个维度，我把所有 Terraform 模块分成四类，并给出是否适合使用 Claude Code 生成的建议。

对于我团队正在维护的金融云项目，我们采用的正是这个策略：核心 VPC 和网间互联部分全部手写，代码量不大但绝对不允许出现依赖循环；GKE 集群和周边服务模块用 Claude Code 生成初稿，然后经过完整的“三线法”诊断和 CI 门禁；而 IAM 和防火墙规则几乎全部交由 AI 生成加一键审查。

三个月运行下来，团队整体基础设施代码的产出效率提高了约 40%，同时因为依赖循环造成的部署事故从偶发降至零。关键不是 AI 有多强，而是你的使用策略有没有跟上。

十、总结：不要把 “debug AI 的代码” 当成一种偶然

写到这里，我想把整篇文章最核心的观点浓缩成一句话：当你选择使用 Claude Code 生成 Terraform 基础设施代码时，依赖循环就不再是一个“偶发错误”，而是一个你必须系统性面对的工程问题。

它不是 Claude 的错，不是 Terraform 的错，更不是你的错。它是在声明式基础设施即代码和概率式语言模型交叠的领域里，必然会出现的一类新问题。我们以前的工具、流程和经验，大部分只针对人类写出的依赖循环，对 AI 生成的这种“过度连接”风格的循环，存在大量的盲区。

所以我希望，读完这篇文章之后，你能带走的不只是几个诊断技巧，而是一种工程心态的转变：把对 AI 生成代码的依赖循环防护，当作和 lint、test 一样的基础设施，纳入你的研发流程里。具体来说，下一步你可以马上做三件事：

1. 修改你的 Claude Code Terraform 生成 prompt 模板，加入结构性约束（数据源优先、单向数据流、元参数静态化）。
2. 在你的 Terraform CI 流水线中增加依赖图循环检测，哪怕是最简单的 graph + acyclic 检查。
3. 用四象限模型审视你的 Terraform 代码库，把那些“应该由 AI 写”和“必须由人写”的模块清楚分开，给团队一个明确的 AI 介入边界。

AI 写基础设施代码的浪潮才刚刚开始。那些现在就把诊断、防护、优化流程建立起来的团队，将能够在未来三到五年内真正享受到 AI 带来的效率红利，而不是永远在“生成五分钟，debug 两小时”的死循环里打转。

与 AI 共舞的前提，是你必须比它更清楚，什么时候它跳错了步子。