2025 年 2 月，Andrej Karpathy 造出 "vibe coding" 一词：完全顺着感觉接受 AI 补全、"不读 diff、有报错就直接粘回去"。这个词半年内从玩笑变成产业现实——大量原型、内部工具乃至付费 SaaS 的第一版都这么写出来的。但"氛围"止步于演示：一旦有了真实用户，问题就从"能不能跑"变成"错一个赔偿多少"。
AI 代码的结构性弱点恰好撞上生产环境的雷区：密钥管理（模型爱把 API key 写进前端和环境变量硬编码）、权限边界（生成的接口常默认不做鉴权）、数据库操作（缺索引的全表扫描、无事务的写入）、异常路径（错误被静默吞掉，故障不可见）。这些都不是模型升级能自动解决的——它们是工程纪律问题，需要用流水线来强制。
| 质量指标 | AI 普及前（2020 左右） | 2024–2025 | 含义 |
|---|---|---|---|
| 两周 churn（提交后短期返工）占比 | 约 3.1%–3.3% | 5.7%（2024）→ 7.1%（2025） | 首版质量下降，返工成为常态 |
| 重复代码块（copy/paste） | 基线 | 约 4 倍；2024 年复制粘贴行数首次超过重构移动行 | 维护负担从"写"转向"读与删" |
| 错误掩盖型写法（空 catch、吞异常） | 基线 | 同比 +47%（GitClear 2026 跟进研究） | 故障被延迟暴露，爆炸半径更大 |
| 含缺陷/漏洞的生成方案比例 | — | 62%（CSA 抽查） | "能跑"不等于"能上线" |
注意口径：GitClear 基于对上亿行变更的静态分析，CSA 与 Escape.tech 是抽样审计，都不能直接推论"你的代码也这样"。但方向一致：AI 让代码变便宜的同时让变更变快，事故窗口变多。生产系统的可靠性不取决于代码写得多快，而取决于你多快能发现并撤销一次坏的变更。
安全厂商 Autonoma 汇总了七起有公开记录的 vibe-coded 应用生产事故，合计暴露约 150 万个 API key，其中多起的模式高度雷同：AI 生成的前端把第三方服务密钥直接打进客户端 bundle；另有应用出现"未鉴权用户可读取企业私有数据"的接口。另一边，Escape.tech 对 5,600 个 vibe-coded 应用的自动化扫描发现 2,000+ 个漏洞与 400+ 个暴露密钥（Ox Security 引述）。共同点不是"模型太笨"，而是没有任何一道人工或自动护栏挡在提交与部署之间。启示：密钥泄露与鉴权缺失是 AI 代码上生产的前两大死因，且都可用纯机械手段（密钥扫描、鉴权测试）拦住。
归纳成四类高频失败模式：①凭据外泄——密钥进前端/进镜像/进日志；②权限裸奔——生成的 CRUD 接口默认无鉴权或用客户端校验；③数据事故——无备份、无迁移回滚脚本，AI 一句 DROP 或全表更新毁掉生产库；④静默故障——空 catch 吞错，用户先于监控发现故障。四类都有对应的标准解法，见下两节。
一个低成本高杠杆的预防动作是上线前验尸（premortem）：在部署前花二十分钟，让 agent 扮演"事后调查员"，对着本次变更列出"最可能导致线上事故的五种方式"及各自证据（代码位置、配置、外部依赖），人再逐条裁决。因为输入就是本次 diff，AI 在这个任务上的表现远好于开放式代码审查；很多团队把它作为 AI 生成代码上生产前的最后一道人工闸门——比"再让另一个模型审一遍"有效，也比人肉通读 diff 现实。
AI 时代的部署哲学要倒过来想：默认每次部署都会出事，先设计怎么撤。个人/小团队可落地的最小架构：
还有一个容易被忽略的杠杆：发布节奏。AI 让分支产出速度暴涨后，长生命周期分支的合并冲突与"漂移"被放大，trunk-based + 小步提交 + feature flag 的组合成为 AI 时代的事实标准——每次变更越小，回滚越便宜，责任越可定位。反之，攒一周再合的大分支会让前面所有的护栏设计打折：出问题时你无法二分定位是哪次"氛围提交"引入的。
AI 代码的静默故障多，监控的最小集必须是：①错误追踪（Sentry 类，含 source map，空 catch 要在 code review 里当 bug 对待）；②核心业务指标告警（不只是 CPU/内存，而是"注册数、支付成功率"这类业务信号，异常波动 10 分钟内知道）；③日志与审计（谁/哪个 agent 在何时改了什么，git 提交与部署记录关联）；④预算熔断（AI 代码常引入意外的第三方 API 调用，云账单与 LLM 账单都要设上限告警）。
在"护栏"层面，2025 年后逐渐成为共识的分层是：提交前（IDE 内安全提示、secrets 扫描）→ CI 里（SAST 静态扫描、依赖漏洞、许可证合规、AI 代码审查工具）→ 运行时（WAF、速率限制、异常行为检测）。三层各拦不同问题，别指望任何单一工具兜底。对小团队，优先级是：密钥扫描 > 错误监控 > 依赖审计 > SAST——前两项成本几乎为零，却能挡住六成以上的典型事故。
最后补一块多数小团队缺失的拼图：事故复盘（postmortem）。每次事故后写一页纸：时间线、影响面、根因、AI 在其中扮演的角色（生成时引入？审查漏过？）、以及护栏为什么没拦住。季度回看这些复盘，你会发现 80% 的事故落在同两三个模式里——针对它们补一条自动化护栏，比泛泛地"加强测试"有效得多。把复盘也交给 agent 起草（从日志和 PR 记录生成时间线草稿），人负责根因判断，是 AI 在可靠性工程里最划算的用法。