为什么 AI 搞不定基础设施配置（以及你该怎么做）

最近到处都在说：“让 AI 写代码吧。”
说实话，写业务逻辑的时候，AI 确实挺靠谱。路由、数据库查询、工具函数，这些它基本都能拿捏。但基础设施配置这块，AI 却经常翻车。

你一丢个 Terraform 文件给它，问题就来了。

基础设施配置的上下文难题

AI 写 HCL 语法其实没问题，能写出合法的代码。
真正麻烦的是：它不知道这些配置为什么要这么写。

举个例子，你让 AI 加一个新事件：订单创建事件，需要走 SNS，再进 SQS。AI 可能给你生成：

• SNS topic
• 带死信队列的 SQS
• 订阅关系
• 对应 IAM policy

看起来没毛病，但里面所有数字和范围都是 AI 自己“猜”的。
可见性超时到底是 60 秒还是 600 秒？IAM policy 该精确到 bucket，还是用通配符？消息保留时间是 14 天还是默认值？

AI 只能靠训练数据里的常见写法，完全不知道你实际的流量、团队习惯，以及上季度因为重放窗口太短导致的线上事故。

代码审查的隐形成本

更麻烦的是，AI 帮你写完后，审查工作量不但没减少，反而变大了。

审业务代码还算直观，主要是看逻辑和边界。
但审基础设施配置，就得交叉验证好几件事：

• HCL 语法是否符合 AWS IAM 的实际规则
• 新资源和现有流水线是否冲突
• 团队的那些“没写下来的约定”
• 消费服务的角色在这个账号里到底存不存在

审查人成了“人工编译器”，要把 AI 缺的上下文全补上。
一旦配置错了——超时、范围、保留策略——半夜三点响的不是 CI，而是你的 Pager。

根本问题：应用和基础设施分离

这其实不是工具问题。
就算你再加模块、再加策略校验器，也解决不了核心矛盾：应用代码和基础设施代码分在两个仓库，审查流程也完全独立。

AI 做基础设施决策时，看不到它真正要服务的业务逻辑，上下文天然缺失。
再多工具也只是给一个有问题的系统增加更多流程。

更好的做法：把基础设施当成编译时问题

那有没有办法，让基础设施不再是“单独的事”？

试想一下：你直接在带类型的应用代码里声明基础设施需求，框架自动完成后面的资源创建、IAM 范围、死信队列、订阅关系等。

一个 pub/sub topic 可能长这样：

export const orderCreated = new Topic<OrderCreatedEvent>("order-created", {
  deliveryGuarantee: "at-least-once",
});

没有单独的 HCL 文件，没有要人工审的 IAM policy，也没有猜超时值的烦恼。
框架能从代码里直接看出这个 topic 需要什么，危险的配置决策从“AI 瞎猜”变成了“框架根据类型自动算”。

你的 PR 也只需要改一个 TypeScript 文件，而不是再加一堆 Terraform 和 policy。

这对「Vibe Coding」意味着什么

这就是为什么“凭感觉写基础设施”和“凭感觉写业务代码”需要完全不同的架构。
业务逻辑可以安全交给 AI，因为它有类型、有测试、相对独立。
但基础设施决策需要的上下文，散落在系统的其他地方。

解决办法不是让 AI 提示词更聪明，而是彻底去掉应用和基础设施之间的缝隙。
当框架能从你的应用代码里直接编译出基础设施时，那些高风险的决定就不再需要 AI 瞎猜，也不需要 reviewer 半夜当编译器了。

这样，你才能真正放心地把基础设施也交给“感觉”。