AI 写完代码测试全过，上线后却接连冒出 100 多个 bug

开发者 @UkrainianVapeM1 原本计划两周前发布自己的新 Chrome 扩展，代码由 AI 生成，测试环节全部通过。但部署到生产环境后，他已经修复了超过 100 个 bug，至今仍未收尾。每次 AI 跑完几百次测试后，他手动复测还能再找出 20 到 30 个新 bug，修复后上传新版本，问题依然存在。

他认为这种落差是当前 AI 编码最让人挫败的地方：AI 从项目一开始就知道代码最终要部署到生产环境，也能访问代码仓库，测试全部通过，可一上线就冒出开发阶段从未出现过的报错。

同一个代码仓库，不代表运行环境完全一致。本地开发时的 Node 版本、依赖包、环境变量、构建配置，都可能和生产环境不同；开发服务器的运行逻辑，也和生产构建版本有差异。API 请求可能因为跨域限制、网络规则、凭证缺失直接失败。

测试数据库通常只有少量干净的测试数据，生产环境却存着成千上万条历史数据，包含空值和复杂关联关系。在测试数据上秒回的查询，放到生产环境可能慢到无法使用。

权限差异同样容易被忽略。AI 在本地开发时往往拥有宽泛的访问权限，生产环境的服务账号权限受限，文件系统访问规则、密钥处理方式也完全不同。代码本身没有改动，只是运行它的周边条件变了。

知道代码要部署到哪里，和真实验证它能在那里正常运行，是两件完全不同的事。AI 可以读取部署配置、预判潜在问题，但只要没有实际校验真实运行时、构建流程、权限规则、外部服务连通性、代表性生产数据，很多判断就只是看起来合理的假设——而 AI 恰恰非常擅长用这类合理假设填补信息缺口。

他认为 AI 编码的工作流必须调整：生产环境的约束要在写代码之前就纳入考量，而不是等部署失败后再补救。需要提前明确代码最终由哪个运行时执行、生产构建的表现是否和本地一致、需要哪些权限、存量数据会带来什么影响、外部服务是否能正常连通。

校验环节不能只停留在本地跑通，必须包含真实生产构建，以及接近生产环境的集成测试。不同类型的产品有各自的特殊校验点：CRM 系统要验证数据结构、权限规则、后台任务；电商项目要覆盖支付流程、订单链路；加密货币项目要测试钱包连接、链配置、外部集成。他正在开发的 Chrome 扩展就是最典型的例子：本地开发的代码，和打包后装进 Chrome 的扩展，表现并不总是一致。权限规则、内容脚本、后台服务工作线程、存储机制、浏览器限制，都会暴露本地测试没发现的问题。

哪怕是预发布的 staging 环境，也没法完全复刻生产环境的真实流量、第三方集成和底层基础设施。部署环节本身也需要配套校验：日志、监控能力、快速回滚机制，和发布前的测试同等重要。

人类开发者同样会遇到这类环境差异问题，但 AI 让生成能跑的代码变得太容易，却完全没有同步校验代码实际运行的真实条件。在修复了 100 多个 bug 之后，他不再轻易相信 AI 给出的测试通过结果，除非自己能在真实环境复现同样的表现。

他的结论是：生产就绪是一项独立的任务，不是写完功能、跑通测试就自动达成的结果。AI 不应该只知道代码要部署到哪里，更要帮忙证明代码真的能在那个环境里正常运行。在测试环境跑通，只能证明代码在你实际测试过的条件下可用，不代表它能适配你所有预设的运行场景。