我用AI写了3个月生产代码，发现7个没人提的坑

3个月前，我把AI从写玩具脚本推进到生产环境。现在代码还在跑，但我多了几页笔记——全是"这方法在生产里会炸"的警告。

这不是vibe coding教程，是事故记录。

从"能跑就行"到"炸了谁背锅"

早期用AI写代码很爽。 greenfield脚本（全新脚本），原型，用完即弃的功能——AI生成、我扫一眼、扔服务器上，第二天忘了它存在。

生产环境不一样。代码要维护、要监控、凌晨3点出问题要有人能看懂。我最初没意识到这个断层：AI写的代码在隔离环境里完美运行，放进真实基础设施就像把家猫扔进雨林。

第一个教训来得很快。AI生成的数据库迁移脚本，本地测试通过，预发布环境通过，生产环境锁表10分钟。没有恶意代码，只是AI不知道我们的主库有读写分离，选错了执行节点。

问题不是AI能力，是上下文。AI看不见你的基础设施拓扑、看不见历史事故、看不见那个"千万别在周二下午部署"的潜规则。

我试过的7种生产适配方法

方法1：把基础设施写成文档喂给AI

最直觉的做法。我把架构图、部署流程、监控规则整理成markdown，塞进上下文窗口。

效果：AI开始生成"符合我们规范"的代码，但规范是静态的。上周刚改的告警阈值，文档没更新，AI按旧规则写，新代码一上线就误报。

维护文档比维护代码还累。我放弃了这条路线。

方法2：让AI只写"被框死的代码"

限制AI的发挥空间。只让它填函数体，不准碰接口定义、不准碰配置、不准碰任何可能连锁反应的地方。

这确实减少了事故，但也阉割了AI的价值。变成高级自动补全，而不是agent（智能体）。

更麻烦的是，边界在哪？一次我以为安全的"纯计算函数"，AI内部调了个缓存——它从训练数据里"知道"这种场景该用缓存，但不知道我们的缓存有双活架构，选错了实例。

方法3：强制AI生成"可审查的代码"

要求每段AI代码附带解释：这行为什么这样写、依赖什么假设、什么情况下会失效。

执行起来像让程序员写注释，AI会编造理由。更危险的是，我发现自己开始信任这些解释——"它都说了这里会处理空指针"，结果没处理。

解释成了安慰剂。

方法4：人机结对，AI写我审

回到最保守的模式。AI生成，我逐行阅读、测试、签字。

瓶颈立刻显现：AI的速度是秒级，我的审查是小时级。3个月的实践里，这种模式只适用于最关键的路径代码，占比不到20%。

剩下的80%怎么办？我需要在"完全信任"和"完全人工"之间找到中间态。

方法5：用测试当安全网

加强测试覆盖，让AI代码在测试里暴露问题。听起来合理，但AI写的测试也在vibe——它测试的是"我认为正确的行为"，不是"生产实际的行为"。

一次AI为某个API生成了20个测试用例，全部通过。上线后发现漏了跨时区场景——训练数据里没这个corner case（边界情况），它想不到要测。

测试的盲点，就是AI的盲点。

方法6：小流量灰度+自动回滚

把AI代码当成可疑代码对待。1%流量、自动监控、异常自动回滚。

这是目前我依赖最深的机制。但它解决的是"出问题怎么办"，不是"怎么减少问题"。而且灰度本身有成本：需要基础设施支持、需要维护分流逻辑、需要有人盯着监控。

小团队玩不起。我算过账，维护这套灰度系统的工时，超过它帮我省下的编码时间。

方法7：让AI只读不写，当超级搜索

最极端的保守策略。AI不生成新代码，只帮我理解旧代码、找bug、写文档。

意外地好用。生产代码的复杂性往往不在逻辑，而在历史包袱——为什么这里有个看似多余的try-catch？AI能从git历史里找到3年前的那次事故报告。

但这已经偏离了vibe coding的初心。我想让AI写代码，不是当考古学家。

那些文章没告诉你的

网上教你vibe coding的帖子，场景多是：新side project（业余项目）、内部工具、原型验证。共同点是低 stakes（低风险）——炸了重写，没人受伤。

生产环境的高 stakes 改变了所有计算。不是AI能不能写对，而是写错了我能不能发现。

我现在的实践是混合策略：新模块用方法6（灰度），旧代码改动用方法7（只读），关键路径用方法4（人工审查）。没有银弹，只有持续的上下文工程。

一个具体例子：我让AI生成了一段处理用户上传的代码，本地测试完美。但我额外加了一步——把这段代码和过去12个月的on-call记录（值班记录）一起喂给AI，问"这段代码可能触发哪些历史问题？"它指出了2个我之前没考虑的race condition（竞态条件）。

这不是AI变聪明了，是我学会了喂对饲料。

还在跑的那部分

3个月过去，我仓库里大概有15%的代码是AI生成后直接进生产的。它们运行稳定，但我记得每一块的"出生证明"：哪段灰度过、哪段我逐行审过、哪段后来补了监控。

更诚实的数据是：有8%的AI生成代码被完全重写，不是因为逻辑错误，是因为没人能看懂AI为什么那样设计。维护成本超过了重写成本。

还有一个数字我没法量化——我花在"教AI理解我们系统"上的时间。写prompt、整理上下文、事后复盘，这些隐性成本很少被讨论。

现在我的待办列表里有一项：测试一个假设。如果我把过去3个月的所有AI交互记录喂给新的agent，让它总结"这个团队的生产代码有什么模式"，下次生成的代码会不会更靠谱？

这需要再花3个月验证。而3个月后，模型可能又换代了。