物界前沿把AI生成的代码丢进生产，第三天我就后悔了
最近看了Honeycomb CTO Charity Majors那个访谈，她说非确定性系统需要更多纪律而不是更少，每个想吃AI甜点的CEO都得先吃蔬菜。这话我第一反应是鸡汤，直到我自己上手跑了一周，才明白她说的蔬菜是什么。
第一天：新鲜感盖过警惕
我拿AI生成的一段数据管道代码直接接进了测试环境，预测逻辑跑得挺顺，我就加了监控字段部署了。当时还想，这比我自己写快三倍，省下的时间够我摸鱼了。
结果第三天，线上有个查询延迟毛刺，我打开追踪面板，发现有个分支逻辑在某个特定输入下多跑了两次重试。我查了整整一下午，最后发现是AI生成的代码里有个非确定性的超时重试策略，它自己“学”出来的，代码注释里完全没提。
这就是Majors说的那个问题，AI生成的代码把风险从IDE推到了生产环境。以前我写代码，脑子里有完整逻辑链，出了问题我能顺着思路排查。现在这代码不是我写的，它为什么这么写，边界在哪，我根本不知道。可观测性工具告诉我哪里错了，但没法告诉我为什么错。
一周后：纪律比效率重要
我后来把AI生成代码的接入流程改了，强制要求每条AI生成的逻辑都必须带可观测性埋点，关键分支必须有人工review签字。代价是效率掉了大概三成，但至少出了事我能定位。
Majors在访谈里说了一句我特别认同的话，她说现在的AI生成代码就像当年从手写服务器转向不可变基础设施，看起来是解放，实际上是要求更高的工程纪律。我这边测下来的结论是，她说的没错，而且我怀疑大多数人还没意识到这个转变有多深。
结论：看情况推荐
说白了这个工具本身没什么问题，问题在于使用方式。
适合谁：团队有成熟的可观测性体系，有代码review文化，能把AI当成加速器而不是替代品。不适合谁：小团队想靠AI省人力成本，觉得“反正代码能跑就行”，这种多半会在生产环境翻车。
推荐给有工程纪律的团队，不推荐给想靠AI偷懒的团队。 至于那些想让AI背锅的，趁早死了这条心，代码是它写的，锅最后还是你的。
如果你想试，我建议第一天先别急着接生产，拿周末时间把可观测性埋点补上，再让AI跑。这顿蔬菜，早晚都得吃，早吃早省事。
本文编译自 Hacker News，原文：Charity Majors on AI, Determinism, Instrumentation, & Eating Your Broccoli – RedMonk
版权归原作者所有，本文为基于公开报道的编译与独立分析。
