Cursor写90%代码后，我们生产环境挂了90分钟

去年12月，我们的AI代码占比从15%飙到89%。三个月后，一个"无害的"自动补全建议，让结账系统在黑色星期五宕机了90分钟。

从"不用AI就落后"到"AI写的代码不敢碰"

事情开始得很美好。我们团队8个工程师，用Cursor（AI代码编辑器）和Claude（Anthropic的AI助手）接管了几乎所有编码工作。需求文档进去，完整功能出来，人类只负责点击"接受"。

速度提升是真实的。以前两周的feature，现在三天上线。代码审查？我们取消了。AI生成的代码看起来太"正确"了——变量命名规范、注释齐全、甚至带单元测试。

问题是我们混淆了"看起来正确"和"实际正确"。

转折点发生在11月29日。Cursor在优化结账流程时，自动把一段支付验证逻辑改成了"更简洁"的版本。改动只有12行，人类工程师扫了一眼就部署了。

两小时后，客服系统爆炸。用户支付成功但订单未创建，钱扣了，货没发。我们损失了47笔交易，平均客单价$340，还有三个大客户直接取消年度合同。

复盘：AI的"过度优化"陷阱

事后看，那个改动是个经典案例。原代码有一行看似冗余的锁机制，防止并发请求重复创建订单。AI认为这行"影响性能"，删了。

人类工程师后来承认：他确实看到了这行删除，但Cursor的注释写着"移除不必要的同步开销"，他就没多想。

「我们太信任AI的自信了。」技术负责人在内部复盘会上说，「它写代码的语气像个资深架构师，我们忘了它其实不理解业务上下文。」

更隐蔽的是测试环节。AI生成的单元测试覆盖了99%的代码行，但全是"正常路径"。并发冲突、网络超时、支付网关返回脏数据——这些真实世界的麻烦，测试里一个都没有。

AI学会了写"能通过测试"的代码，但没学会写"能在生产环境存活"的代码。

现在我们的新规矩

事故后，团队改了工作流。AI仍然写90%的代码，但有三条硬红线：

第一，任何涉及资金、用户数据、核心流程的改动，必须人工逐行审查，不接受AI的"优化建议"直接部署。

第二，强制引入混沌测试。每周随机杀掉一个服务、注入网络延迟，逼AI生成的代码暴露脆弱性。

第三，保留"人类兜底时间"。每天下午4点后禁止AI辅助提交，工程师手写代码——不是为了效率，是为了保持"代码直觉"不退化。

效果？AI代码占比从89%降到67%，但生产事故归零。部署频率从每天12次降到8次，MTTR（平均修复时间）从47分钟降到9分钟。

有个意外发现：让工程师手写那33%的代码后，他们审查AI代码时更能挑出问题了。就像司机偶尔要手动换挡，才不会忘记怎么判断路况。

行业正在重复我们的错误

GitHub最新报告显示，2024年全球AI生成代码占比已达41%。但配套的安全实践几乎没跟上——只有12%的团队有AI代码的专项审查流程。

我们接触的三家创业公司，都在用类似我们的"全AI"模式。其中一家上周刚经历数据库误删，原因是Cursor建议的"清理旧数据"脚本没加WHERE条件。

「AI不会故意害你，」那家公司的CTO告诉我，「但它对'旧数据'的理解和你完全不同。」

大厂也在踩坑。某头部云厂商的工程师私下透露，他们的AI辅助代码审查工具，曾把关键的安全检查标记为"低优先级建议"——因为训练数据里这类检查被跳过的频率太高。

算法学会了人类的坏习惯，还放大了它们。

现在我们的代码库里有条特殊注释：「// AI-REVIEW: 此处有并发风险，人类必须确认」。这是那90分钟事故留下的疤痕，也是我们的免疫系统。

2026年的开发者大概不会自己写多少代码了。但问题是：当AI成为主要作者，谁来当那个质疑它的读者？