2025 年 2 月，Andrej Karpathy 造出"vibe coding"一词：完全顺着感觉让 AI 写代码、"忘记代码的存在"。这个词能火，是因为它诚实描述了数百万人的真实工作方式——只看效果不看实现。但软件工程的第一性原理没有变：你看不见的代码，终将以故障的形式让你看见。
AI 代码的质量问题分三层：功能缺陷（逻辑错误、边界条件遗漏——测试能抓住）；结构性技术债（重复代码、死代码、被放弃的半成品、没人理解的逻辑——测试抓不住，慢性毒药）；安全漏洞（注入、硬编码密钥、权限缺失——出事就是事故）。传统技术债靠"人读代码"兜底，AI 把生成速度提高了数倍而人的审查时间没有增加，剪刀差就是这么产生的——这是理解全部数据的钥匙。
规模背景：GitHub CEO 在 2024 年 10 月公开表示平台上约 41% 的新增代码由 AI 生成，谷歌也称其内部超过 30% 的新代码由 AI 完成。到 2026 年，主流开发场景中 AI 参与率只会更高——质量治理已经不是"要不要"的问题。
四组关键证据按时间线看：其一，GitClear 代码考古。对 2020-2024 年累计 1.53 亿-2.11 亿行（不同版本样本）真实仓库代码的纵向分析发现：代码翻新率（churn，写入后两周内被修改或回滚的比例）从 3.1% 升至 5.7%；复制粘贴行占比从 8.3% 起持续攀升；2024 年 5 行以上重复代码块数量是 2023 年的 8 倍，而"移动代码"（重构的健康形态）占比在下降。翻译成人话：AI 时代的第一直觉是复制，而不是抽象。
其二，安全面。Veracode 2025 年 GenAI 代码安全报告调查约 2000 名安全从业者，45% 表示所在团队的 AI 生成代码引入过安全漏洞。更早的学术研究（Stanford 的 Perry 等，2021 实验、CCS 发表）已证明：用 AI 助手写安全敏感任务的参与者，产出漏洞率显著更高，且更自信地认为自己写得安全——过度自信是独立于代码本身的第二重风险。
其三，工程效能面。Google DORA 2024 年报告估算，AI 采纳度每提高 25%，交付吞吐量约降 1.5%、交付稳定性约降 7.2%（2025 版报告对"AI 与稳定性"的结论有所回调，方向仍有争议，属弹性估算）。METR 的随机对照实验（2025-07）则显示资深开发者在熟悉代码库上用 AI 反而慢 19%。这些研究与"体感变快"并不矛盾：AI 在陌生领域、一次性脚本、原型开发上确实快，而在成熟代码库里，理解与审查成本会反噬。
| 质量指标 | AI 普及前（约 2020-2023） | AI 普及后（2024-2025） | 来源/说明 |
|---|---|---|---|
| 两周内代码翻新率 | 3.1% | 5.7% | GitClear 2025 报告 |
| 5 行以上重复块增幅 | 基线 | 约 8 倍 | GitClear（2024 vs 2023） |
| AI 代码含漏洞经历 | — | 45% 企业 | Veracode 调查（2025） |
| AI 助手用户代码漏洞率 | 基线 | 显著更高 | Perry 等 Stanford 实验（定性） |
| 交付稳定性弹性 | — | AI 采纳 +25% → 稳定性约 -7.2% | DORA 2024（估算） |
2025 年中，安全研究者对部署在外的 AI 生成应用（多为 Next.js + Firebase/Supabase 技术栈的独立开发产品）进行大规模扫描，发现上千个应用把 API 密钥、数据库凭据、服务账号私钥直接硬编码进前端 bundle 或公开仓库——因为"让 AI 帮我连数据库"最顺手的写法就是把密钥写进环境变量文件再被一并提交。涉及的 Firebase 项目被确认可读取甚至写入真实用户数据。这不是模型不会写安全代码（所有主流模型被正确提示时都会提醒你用服务端代理），而是 vibe coding 工作流里没有任何环节强制检查凭据暴露。
启示：AI 代码的安全下限由工作流决定，不由模型决定。一个 gitleaks 预提交钩子（10 分钟配置）就能挡住这类事故的绝大多数——多数受害者连这 10 分钟都没花。
反面也要说：AI 代码的质量分布是"双峰"而不是单纯变差。在有完整测试、清晰规格、严格 review 的项目里，AI 生成代码的缺陷密度可以做到不高于人工基线（微软、Google 的部分内部数据与 Google 内部"AI 代码需同等审查"政策可作旁证）。质量塌方集中在"没有验收体系"的场景——这恰好是个人独立开发者最常见的工作方式。
原则先行：不要试图人肉审完 AI 的产出，要让机器审机器，人只裁决。可落地的四道防线：
| 防线 | 工具（免费/开源优先） | 拦截什么 | 接入点 |
|---|---|---|---|
| 密钥与配置审计 | Gitleaks、TruffleHog | 硬编码密钥、.env 泄露 | git pre-commit + CI |
| 静态安全扫描（SAST） | Semgrep、CodeQL、SonarQube 社区版 | 注入、反序列化、权限缺陷 | CI 每次 PR |
| 依赖与镜像扫描（SCA） | Dependabot、Trivy、OSV-Scanner | 带漏洞依赖、投毒包 | 每日定时 |
| AI 代码评审 | CodeRabbit、Copilot Code Review、Claude Code 审查提示词 | 逻辑不一致、缺测试、坏味道 | PR 触发 |
测试策略上，AI 时代的关键变化是测试必须先于或伴随生成：让 AI 按 spec 先写验收测试（含边界与异常路径），再让实现代码过测试——测试由人生成意图、AI 生成用例，可避免"AI 写实现、AI 写测试、两者共享同一个错误假设"的合谋问题。对已有代码库，覆盖率工具（coverage.py / istanbul）用来定位"AI 改过但无测试保护"的高危区域。
重构层面，2026 年的最佳实践是"AI 辅助的债务清偿循环"：(1) 用 SonarQube/自定义脚本量化重复块与复杂度热点；(2) 让 Agent 按指令做提取函数、消灭重复的机械重构（这是 Agent 最擅长的任务类型之一）；(3) 用特征开关或小 PR 控制爆炸半径。社区经验是：把 GitClear 式的重复膨胀问题交给 AI 处理，比人肉重构快一个数量级——制造问题的工具恰好也是解决问题的工具，前提是你建立了度量。
审查疲劳与责任真空。产出速度提高 5 倍、审查带宽不变，人就会开始"扫一眼就合"——形式化 review 比不 review 更危险，因为它给了虚假保证。解法只有减少需要人看的量（机器预审）。
依赖投毒面扩大。AI 会"幻觉"出不存在的包名（slopsquatting），也会无差别引入高下载量的劣质依赖；2024-2025 年 npm/PyPI 多起投毒事件均利用了这一点。锁文件 + SCA + 最小依赖原则是基本卫生。
知识债最难还。代码能跑，但没有人（包括作者）理解它。一旦需求变化或需要排障，重写成本高于当初节省的成本。对策是把"重要设计决策"写在 spec/ADR 文档里而不是聊天记录里——聊天记录是 vibe coding 时代最大的单点故障。
gitleaks pre-commit 钩子 + GitHub Actions 里跑 Semgrep 与 Trivy（各 15 分钟，官方文档均有模板），历史仓库先跑一次全量扫描补漏。AGENTS.md、docs/decisions/），聊天记录不算档案。