AI 写的代码，在生产环境能跑多久

之前写过一篇《我用 AI 提效了多少》，讲的是哪些环节交给 AI 真有用。那篇偏“怎么用”。

这篇讲另一件事：AI 写的代码，放到生产环境里，能跑多久。

先说结论：代码能不能长期跑，跟它是不是 AI 写的没关系，跟这段代码有没有隐性约束、出错后能不能被发现有关系。 有的 AI 代码能一直跑下去，有的当天就出事 —— 区别在这里。

生产里的坑，长什么样

先说一个我见过的、很典型的场景。

给一个后台加“批量导出”接口。需求是“管理员能把列表数据导出成 Excel”。AI 生成的版本跑得通、命名规范、注释齐全，读一遍完全没问题，就上线了。

问题不在代码，在验收方式：我用管理员账号测的，一切正常。上线几天后才发现，这个接口只在前端按角色隐藏了入口，服务端本身根本没有校验权限。 换一个低权限账号直接调接口，能导出全部数据。

代码没有错。它只是“按我说的做了” —— 而我没说过权限。

这类坑有个共同特征：不报错、测试也通过、看起来完全正确。 它的问题只在你没想到要提的那一点上。而这恰恰是 AI 代码最危险的失败模式 —— 语法错误一眼能看出来，这种“安静地做错”不能。

什么样的 AI 代码能一直跑

反过来说，有几类代码我用了很久，从来没出过事。

边界清晰、验收标准明确的代码

正则、日期格式转换、数据清洗脚本、格式转换工具。这类代码的特点是：对就是对，错就是错，跑一次就知道。 它的正确性不依赖任何业务上下文，也就没有“隐性约束”可言。

这类活交给 AI，产出可以直接用，而且能一直用下去 —— 因为需求不会变，正确答案只有一个。

模板化的、不含判断的代码

增删改查、配置骨架、接口定义、测试用例的分支铺陈。这类代码的价值不在“写得漂亮”，而在“别写错”，而它的每一行都是可以被对照验证的。

只要你能验证，它能跑多久，取决于你的验证做得有多细，不取决于它是不是 AI 写的。

无状态、不改数据的逻辑

纯计算、纯转换、纯读取。这类代码即使有 bug，影响范围也在当次请求内，重启或者修掉就恢复了，不会留下“半年前写错的数据”。

什么样的 AI 代码，早晚会坏

真正会出事的，是下面这几类。它们的共同点是：错误不会立刻暴露，而会沉进数据或状态里。

涉及权限和身份的代码

就像开头那个例子。AI 默认不知道你的权限模型 —— 谁能做什么、哪个接口要对哪个角色校验，这些都不在需求描述里。它没写，不是它偷懒，是它不知道。

权限是必须自己过一遍的地方，不能交给 AI 定。

涉及并发和状态流转的代码

两个人同时提交、同一个订单被重复处理、支付回调和用户操作撞在一起 —— 这类问题的触发条件很具体，往往在压测和日常测试里都碰不到。

AI 生成的状态流转，通常是“理想路径”：从 A 到 B 到 C，每一步都对。但真实系统里还有“卡在 B 的时候又回来了一次”“C 失败后要回滚到哪”这类分支。这些分支它不会主动补，因为你没提。

涉及幂等和重复提交的代码

接口被调用两次会怎样？这个“如果重复调用会发生什么”，是 AI 最容易忽略的一类问题。原因很简单：绝大多数“写出来能跑”的代码，默认每个请求只来一次。

数据迁移和批量处理

这类代码最危险，因为它直接改数据，而且往往只跑一次。跑错一次就没有“再跑一遍”的机会，可能要把整个表回滚。

对这类代码，我的要求是：先在副本上跑，先跑小批量，先验证结果再全量。 这三步一步都不能省，也一步都不该交给 AI 自己判断。

异常恢复和容错处理

出错了怎么办、外部接口超时怎么办、消息处理失败要不要重试、重试几次、重试的顺序是什么 —— 这些问题的答案取决于你的业务，不取决于代码本身。

AI 会给你一套看起来合理的容错，但“合理”和“符合你这个业务”是两回事。默认的重试策略可能把一个临时故障放大成一次雪崩。

一个简单的判断方法

上面这些讲完，其实可以收成两个问题。拿到一段 AI 生成的代码，问：

1. 这段代码里，有多少是“必须知道我的业务”才能写对的？
2. 它写错了，我要多久才能发现？

第一个问题问的是约束。约束越少，AI 越可靠；约束越多，越要自己把关。

第二个问题问的是暴露速度。错了立刻报错、立刻能看到，风险就低；错了要等几天、等数据积累到一定程度才暴露，风险就高。

两个问题的答案连起来看：约束少、暴露快的代码，交给 AI；约束多、暴露慢的代码，自己写或者自己疯狂核对。 权限、并发、状态机、数据迁移，全都落在“约束多、暴露慢”这一格里。

我现在的检查清单

具体到合入之前，我固定过几项。不追求快，追求“别把静默的错误带进生产”。

第一步，看 diff，不看它的自我描述。 它说“已经处理了边界情况”没有用，看它实际改了哪几行、有没有顺手动到任务范围外的文件。

第二步，跑一遍它没测过的地方。 它通过的那条路径，往往是你写进需求的那条。换个角色、换个权限、换个输入再走一遍。

第三步，对权限。 每个涉及数据读写的接口，都问一遍“低权限的人能不能直接调”。前端隐藏入口不算校验。

第四步，对异常输入。 空值、超长字符串、重复提交、并发点击，各试一次。这类问题在正常数据下永远测不出来。

第五步，想一次回滚。 如果这段代码上线后发现问题，怎么退回去？数据能不能还原？想不清怎么做回滚的改动，先别合。

第六步，看日志和监控。 这段代码跑起来之后，出问题你能不能从日志和监控里发现？如果它出错了既不报错也没告警，等于没有防护。

这六步都不难，难的是每次都做。而“每次都做”正是AI 时代的核心技能 —— 写代码变快了，验证变成了主要成本。

边界：别把 AI 一棍子打死，也别全信

最后说两个极端，都不可取。

“AI 写的代码不能用” —— 不对。边界清晰、能立刻验证的代码，AI 写得又快又稳，而且是长期的提效。

“AI 写的代码没问题，我测过了” —— 也不对。测试通过只能证明“你想测的那条路径是对的”，证明不了“你想不到的那些约束是对的”。

更准确的说法是：AI 抬高了产出速度，也抬高了验证的权重。 省下来的时间不该全用来写更多代码，该分一部分到验证上。

小结

AI 写的代码能跑多久，取决于两件事：这段代码里有多少“必须懂业务才能写对”的约束，以及它出错后多久会被发现。

约束少、暴露快的，放心交；约束多、暴露慢的（权限、并发、状态流转、幂等、数据迁移、异常恢复），自己写或者重点核对。

把这两条判断清楚，比纠结“要不要用 AI”有用得多。