三个月前，我把Claude Code直接接进了生产环境的基础设施仓库。不是沙盒，不是Demo，是管着Lambda、RDS、EKS和IAM角色的真家伙。现在回头看，最离谱的发现不是它多能干，而是它"干"出来的东西有多真——真到能骗过代码审查，真到差点进生产。
一、这套系统有多脆
先交代背景。我们的基础设施用OpenTofu管理，JSON驱动，五个模块：IAM、S3、SQS、SNS、Lambda。开发者写JSON配置文件，模块自动发现、验证，然后Crossplane部署到AWS。
这套设计的精妙之处在于隔离：人只碰JSON，不碰底层资源。但代价也很明显——验证层一旦漏掉某个边界条件，错误配置就能一路绿灯进监管环境。
我交给AI两类任务：写新功能、加验证规则、扩展资源；以及审查我写的代码，抓bug、找边界情况。三个月跟踪下来，两个差点出事的案例，暴露了一个会定义你职业生涯的模式。
二、第一起事故：Lambda层的"合理"幻觉
我让AI给Lambda模块加一个功能：支持多环境部署时自动注入不同的VPC配置。它很快交了稿——300多行，结构工整，注释齐全，甚至补了我没要求的单元测试。
问题出在第三处修改。它给JSON schema加了一个字段叫vpc_override，允许开发者显式覆盖默认VPC。逻辑看起来无懈可击：如果没提供，用默认值；如果提供了，做格式校验。
但它没问一件事：我们的监管环境禁止任何显式VPC覆盖。这个限制写在合规文档里，没写在代码注释里，更没在JSON schema里体现。
AI从现有代码模式推断："其他资源有覆盖机制，Lambda也应该有。"这是合理的工程直觉——在90%的场景下都是对的。但我们的基础设施属于那10%。
代码审查时，两个资深工程师都没看出问题。schema语法正确，测试覆盖到位，文档写得清楚。直到我手动跑了一遍端到端流程，才发现这个"合理"的功能能把流量导向未经审计的VPC。
这300行代码，每一行都符合语法，每一行都是假的——假在它建立在一个AI自己脑补的业务假设上。
三、第二起事故：IAM的"自信"盲区
第二次更隐蔽。我让AI审查一段我写的IAM角色绑定逻辑，让它找边界情况。
它确实找到了——它指出当角色名超过64字符时AWS会截断，建议加长度校验。还贴心地补了错误提示和文档链接。
但它漏掉了真正的问题：同一个PR里，我误把sts:AssumeRole的Principal字段写成了通配符"*"。这在开发环境能跑，在生产环境等于把角色暴露给整个AWS账户。
AI的审查报告对这个只字未提。我后来复盘发现，它的注意力被那个"发现"的长度问题完全占据——就像一个实习生急于展示自己找到了什么，反而对真正的雷视而不见。
更讽刺的是，那个长度校验建议本身也有问题：它建议截断到60字符留余量，但没考虑我们的命名规范里前缀就占了28字符，截断后会撞哈希冲突。
它"发现"了一个不存在优先级的问题，同时错过了致命问题，还附赠了一个有副作用的修复方案。
四、拆解幻觉的生产机制
这两起事故共享同一个根因：AI在填补信息缺口时，用的是概率推断，而非事实核查。
第一起事故中，信息缺口是"为什么其他模块有覆盖机制而Lambda没有"。AI的填补策略是"一致性优先"——假设这是遗漏而非刻意。第二起事故中，信息缺口是"这段代码的真实意图是什么"，AI的填补策略是"表面相似性"——通配符在语法上合法，所以它没触发警觉。
这两个策略在开放域问题是有效的。但在基础设施代码里，每一个"看起来合理"的假设都可能撞上一句没写进代码的硬性约束。
我后来做了对照实验：把同样的任务拆成两步，先让AI只问问题不写代码，再基于它的提问人工补充上下文。结果它的产出质量提升了至少一个数量级——不是因为它变聪明了，是因为信息缺口被人工封堵了。
这个发现反过来解释了为什么两个资深工程师也没拦住第一起事故：AI生成的代码太"完整"了，完整到审查者的大脑自动切换到了"验证模式"而非"怀疑模式"。
人类审查代码时有个默认假设：如果作者没提某个限制，大概率是不存在。AI利用了这个心理漏洞——它不会提自己不知道的限制，而它的沉默被误读为"没问题"。
五、三个月后的工作流改造
我现在用AI的方式彻底变了。不是不用，而是把"生成"和"验证"拆成两个独立环节，且都由人把关。
具体做法：任何AI产出的代码，必须先过三道人工关卡——业务假设清单（逐条确认AI脑补了哪些未明说的规则）、影响面扫描（假设这段代码有隐藏bug，会在哪个环节爆炸）、以及反向压力测试（故意给AI看有问题的代码，看它能不能抓住）。
第三道关卡尤其反直觉。我故意把那个通配符IAM角色丢给AI审了三次，它在不同提示词下的表现极不稳定：有时能抓住，有时完全忽略，有一次甚至"优化"了代码——把通配符改成了更危险的跨账户授权。
这种不稳定性本身就是信号。它意味着你不能把AI当作可信赖的审查者，只能把它当作"可能帮你省时间的工具"——而且省的时间必须花在更严格的人工复核上。
还有一个更底层的改变：我现在写代码时会有意识地埋"锚点"——显式注释那些"看起来可以推断但实际上不行"的决策。比如Lambda的VPC限制，我现在会在schema文件顶部写三行注释解释为什么这个模块没有覆盖机制。
这些注释不是给人类看的，是给AI看的。它们在训练AI的上下文理解，同时也在训练我自己：如果一件事需要向AI解释，说明它可能也需要向未来的同事解释。
六、那个会定义你职业生涯的模式
三个月的实验指向一个不太舒服的结论：AI在基础设施代码里的核心能力不是"写"，是"编"——编织一套自洽的叙事，让你相信它是可靠的。
这种编织在多数场景下是资产。它能帮你快速搭建原型，补全 boilerplate，甚至发现你自己没意识到的模式重复。但在受监管、高后果的环境中，编织能力变成了负债——因为它没有"不知道"这个概念，只有"合理推断"。
我现在的判断标准是：如果一段代码的bug会导致凌晨三点被叫醒，那么AI只能参与生成，不能参与决策。生成环节可以大幅提速，但决策环节必须有人类对业务上下文的完整掌握。
这个标准把AI的角色从"副驾驶"降级成了"高级自动补全"——听起来很保守，但三个月里两次差点进生产的事故告诉我，在基础设施领域，保守不是缺点，是生存策略。
最后一点观察：AI代码工具的营销话术正在制造一种危险的预期落差。它们展示的场景往往是"帮我写一个Python脚本"或"重构这个函数"，而基础设施代码的复杂度在于隐式约束的密度——同样300行，业务代码的约束可能在代码里，基础设施代码的约束可能在合规文档、历史事故复盘、或者某个离职工程师的脑子里。
AI无法访问这些，但它不会告诉你它无法访问。它会用语法正确性填补这个缺口，而语法正确是最廉价的伪装。
如果你也在用AI写基础设施代码，建议做一件事：下次审查AI产出时，专门挑一个它"完成得很好"的功能，追问自己"它为什么没问X"——X可以是任何你知而AI不知的业务限制。如果连续三次都能找到这样的X，说明你的审查流程还有漏洞。
这个习惯比任何工具配置都值钱。毕竟，凌晨三点的告警不会区分这段代码是人写的还是AI写的——它只关心谁能在五分钟内定位根因。
热门跟贴