代码之雾

Source: Dev.to

Introduction

It starts with a simple question about a single Terraform variable. Soon, you’re chasing configurations across dozens of browser tabs and scattered IDE folders, desperately trying to understand the reality of your infrastructure. You are flying blind in the Multi‑Repo Verse, and just when you think you’ve found a lifeline, you realize your AI copilot is confidently feeding you the wrong information.

This post is Part 1 of the “Making Invisible Infrastructure Visible” series. Over the next four posts, I will explore the complexity of managing large single‑or multi‑repo Terraform‑coded infrastructure, the limitations of current tooling, and how I built Infra‑Graph, a local‑first, AI‑powered mapping tool, to bridge the gap between static code and its hidden semantic meaning. If you manage Terraform across multiple repositories, this series is for you.

多仓库宇宙

我们都有过这样的经历。打开 IDE，准备做一个本应很简单的改动——比如在 AWS 安全组上调整一条入口规则。但在现代基础设施中，任何东西都不是孤立存在的。

你找到了资源块，却发现安全组 ID 是通过变量传递的。你追踪这个变量到 terraform.tfvars 文件，结果发现实际值是从一个完全不同仓库中定义的 remote‑state 数据块中获取的。这就是 多仓库宇宙 的现实。它是一种旨在强制边界的架构模式，但实际操作却像迷宫一样。

十分钟之内，你的屏幕已经被浏览器标签、GitHub 搜索结果以及交叉的 VS Code 工作区所淹没。这种现象不仅仅是“上下文切换”；它是 标签疲劳——在短期记忆中试图保持整个碎片化基础设施状态所带来的精神耗竭。在这种疲惫之下，还潜藏着更深层的职业焦虑：对 蝴蝶效应 的恐惧。

每次运行 terraform apply 时，你都要做好心理准备：如果我在这里更改了这个输出，会在另一个仓库的下游服务中导致什么破坏？ 版本控制让我们形成了提交文化，却把基础设施的语义现实隐藏在分布式文本文件的墙后。你是一名架构师，理应设计出具备弹性的系统，但在日常工作中，你却常常盲目前行。

AI 副驾驶的陷阱

于是，你像所有现代开发者一样：去使用 AI 副驾驶。你把 .tf 文件的片段粘贴到提示框中，或者使用拥有仓库全局可见性的高级副驾驶，询问：“删除 80 端口安全吗？”

AI 立即回应，语法完美，信心十足。它解释了为何此更改是安全的，分析了它能够访问的代码。短短一瞬间，你感到松了一口气。

随后是 现实检查。

你意识到 AI 并没有——也不可能——了解在另一个 AWS 账户的仓库中定义的、依赖该端口的未文档化的遗留负载均衡器。AI 并没有帮助你；它在幻觉。它在告诉你一个美丽却危险的谎言，因为它缺少基础设施中最关键的东西：基于事实的真相。

大型语言模型是强大的推理引擎，但当只喂入碎片化的文本文件时，它们只是富有创意的猜测者。

“它们懂得语法，但不懂得意义。”

它们并不知道，一个开放的端口隐含地连接了两个不同的资源。

语义地图的需求

那是转折点。我意识到，如果我想停止盲目操作——并且如果我真的想在不危及生产的风险下利用 AI——我不需要更好的提示。我需要一张更好的地图。我需要一种方式，将 AI 和我自己扎根于基础设施的真实情况。

简而言之，我需要一个 semantic map。

接下来

在下一篇文章中，我将向你展示那张地图到底长什么样，以及它为何会改变一切。

下一篇（第 2 部分）: 我是如何绘制 Terraform 基础设施领土的，或者我曾这么认为……

第 1 部分：代码的迷雾