夜雨聆风先看一组挺唬人的数字
腾讯公司90%的工程师日常在用AI编程，新增代码 50% 由 AI 生成小米、荣耀超万人在用，AI 生成新代码占 40%招商银行超8千人在用AI编程，AI 生成新代码占35%；中国太平36%……
银行和保险是国内软件工程最保守的一档，一行改动背后是一串审批流。它们都做到了三成五以上。
工程师看到这里的第一反应通常是：那我呢？
一、两篇论文，把结论掰了个方向
METR 在 2025 年 7 月放出一篇随机对照实验[1]。16 位资深开源开发者，在自己维护了平均五年的百万行级仓库里干活，246 个真实 issue 随机分配：一半允许用 AI，一半不许，全程录屏。
开工前开发者预测能省 24% 的时间，经济学和机器学习领域的专家预测能省 38% 到 39%。实际结果是：用了 AI 的任务，完成时间多了 19%。
更有意思的是，做完之后他们仍然认为 AI 帮自己提速了 20%。体感和秒表差了近 40 个百分点。
第二篇是 2025 年 10 月的 arXiv 论文[2]，用双重差分看 Copilot 上线前后 2755 个开源项目的活动数据。项目整体产出涨了，但涨幅主要来自外围的、经验较浅的贡献者；Copilot 之后的代码需要更多返工才能达到仓库标准。关键是返工落在谁头上——核心开发者 review 量增加 6.5%，自己原创代码的产出掉了 19%。
两个 19%，一个来自随机对照实验，一个来自面板回归，方法完全不搭，指向同一件事：AI 让新手更快地生产代码，让老手更慢地生产代码。
旁证还有。Google 2024 DORA 报告：AI 采用度每提升 25%，交付稳定性下降约 7.2%[3]。GitClear 分析 2.11 亿行代码变更：复制粘贴的代码行从 8.3% 涨到 12.3%，代表重构复用的"移动"代码行从 24.1% 掉到 9.5%[4]。
代码在变多，结构在变差。
二、不是 AI 不好用，是用错了地方
招行八千个工程师不会集体自欺欺人，METR 那 16 个人的秒表也不是坏的。两边都真，说明它们量的不是同一件事。
“写代码”至少是三种活：往白纸上填东西；在一个规矩清楚的新系统里加东西；在一个跑了八年、没人敢碰的老系统里改东西。METR 找的人恰好落在最难那一档。
1. vibe coding：本来就是 AI 的主场
Karpathy 造这个词时说的是"完全交给感觉，忘掉代码的存在"[5]。听着不负责任，放在特定场景里完全成立。
2025 年 3 月，YC 的 Garry Tan 和 Jared Friedman 披露，W25 那批公司里约四分之一的团队，代码有 95% 由 LLM 生成；这批公司整体每周增长 10%，是 YC 史上最快的一批[6]。
为什么这里 AI 特别管用？因为验收标准只有一条：跑起来，能演示。没有历史包袱，架构好不好无所谓，下周可能整个推倒重来。产品经理拿个想法要看效果，以前得画原型、对齐、排期、等一周；现在当场描述，二十分钟出一个能点的页面，一个下午试完过去两个月的方案量。这些代码的价值不在代码本身，而在它帮你排除了多少错误方向，用完就扔才是正常结局。
但边界越过去就要付账。2025 年 7 月，SaaStr 创始人 Jason Lemkin 用 Replit 连续 vibe coding 九天做一个高管联系人库。他明确下了“代码冻结”指令，第二天回来发现 AI agent 把生产数据库清空了，1206 条高管记录、1196 多家公司资料。Agent 先试图掩盖，声称数据无法恢复，追问之下承认“我在看到数据库看起来是空的时候慌了”。根子并不玄学：开发测试和线上客户数据用的是同一个库[7]。
教训不是“AI 不能信”，而是项目从“即用即抛”变成“有真实数据、有真实用户”的那一刻，规则换了，而 vibe coding 的习惯不会自己跟着换。
2. AI native：第二个主场
第二类适合 AI 的，是从第一天起就按“AI 要来读这份代码”的假设建起来的系统：模块边界清楚，改动落在一两个文件里；测试覆盖到能当规格说明用；类型够强，错误在编译期被拦住；仓库里有 AGENTS.md 或 rules，把约定写成 AI 能读的形式——哪些库不许用、日志里不许出现什么。
这些在 AI 之前就是好实践，以前的收益是“新同事上手快”，现在多了一项“AI 上手快”。所以 AI native 不是“让 AI 写代码”，而是“把系统建成 AI 能安全操作的样子”——前者是使用习惯，后者是工程投资。
3. 遗留系统（legacy System）：AI 最容易翻车的地方
一个跑了八年的核心系统，两百万行代码，四任架构师，文档最后更新于三年前，作者已经离职。为什么不适合大面积交给 AI？
第一层：AI 不知道你知道什么
1987 年金融行业经典电影《华尔街》里，Gordon Gekko 对着刚入行、拼命想表现的查理·辛说：Tell me something I don't know.
这句台词把甲方的傲慢演得很准，但它是个死结：我怎么知道你不知道什么？你和 AI 之间也是这个死结，只是方向反过来——你不知道 AI 缺哪块知识，所以不知道要补什么。
缺的分两种。一种是业务领域知识，比如这张表的“客户状态”有个值叫 7，文档没写，但所有人都知道它代表“渠道代理过户中”。这种可以补。
另一种要命，是隐性知识——你自己都写不出来的知识。
有个模块的数据访问层用的是一套明显过时的手写 SQL 封装，公司标准早就换成另一套 ORM 了，任何有经验的工程师看到都会想“这该重构”。但当年为什么没换？三年前评估过一次，换的话要停两周迭代，那两周正好压着一个业务的关键节点。技术负责人和业务老板会后单独聊了十分钟，结论是业务压力更大，架构先不动。这个结论没有进任何邮件、任何一条 commit message，它存在于两个人的记忆里，其中一个已经换了部门。
现在让 AI 去改。它手里只有代码和训练时学到的“行业最佳实践”，于是会非常自信地把手写 SQL 换成 ORM，顺手改掉七十个调用点，并在 PR 里写“统一了数据访问方式，提升了可维护性”。从代码质量看它做得对；从这个组织的实际约束看，它刚刚点了一个雷。它就是那个在荒野里看见一道莫名其妙的栅栏、不问为什么就想拆掉的人[8]。
你可以用硬约束的 rule 部分缓解，比如写死“data 层不许动”。但有些约束你自己都讲不清楚——“这块代码碰的时候要小心”，为什么小心？你说不上来，你只是被它咬过。这种感觉写不成规则。
第二层：你验收的是“我要的”，不是“我不要的”
vibe coding 也好，spec driven coding 也好，最后都要验收，而绝大多数人的验收方式是：我要的功能实现了吗？点一下，实现了，通过。
盲区在这：你不想要的那些东西呢？功能是显式的、可枚举的；安全、性能、并发、日志合规是隐式的，需要主动去找才能发现。验收清单上没有“这段代码不能泄露隐私”这一条，因为这是常识。
有家公司做面向个人用户的应用，出了一次隐私泄露。排查很顺：泄露来自手机端上传的日志，定位到 app 里哪段代码打的，再从 git 记录找到提交人。那个工程师一开始完全懵——哪些字段不能打日志、有些连存都不能存，这属于入职第一周就该知道的常识。后来他想起来了，那段代码是 AI 生成的。
它躲过了所有人的眼睛，是因为全程没有出现任何敏感字段的名字：它把一个数据结构整体序列化，然后写进日志。logger.debug(JSON.stringify(userContext)) 这类写法在 review 里几乎不会被拦，看起来只是一条调试日志，而那个结构里恰好有几个字段是从上游透传下来的用户身份信息。敏感信息从头到尾没有以字面量的形式出现过一次。
工程师 review 的时候在看什么？在看功能对不对。功能是对的。
Veracode 测了 100 多个大模型、80 个补全任务，45% 的样本引入了 OWASP Top 10 漏洞；Java 最惨，安全失败率 72%；跨站脚本 86%，日志注入 88%[9]。
日志，88%。给一个可以安全实现也可以不安全实现的选择，这一代模型相当稳定地选后者，因为后者在训练数据里更常见、更短、更“自然”。
第三层：模型学的是时间切片，不是演化过程
用 GitHub 的代码训练大模型，会用哪些分支？当然是 release、master、打了 tag 的版本分支，稳定且编译得过。但这些分支是代码演化过程中的一组时间切片。
一段代码真正的信息，有很大一部分不在最终形态里，而在它怎么走到这个形态的过程里。这个函数为什么加了个看起来多余的空值判断？半年前有过一次线上事故。这类信息在 diff、issue 讨论、事故复盘里，而用稳定分支训练的模型看到的是结果，看不到过程。
于是模型学到的是形状。它可以依葫芦画瓢地复制出结构相似、语法正确的代码，但不理解这段代码为什么长这样，也不知道它接下来该往哪长。
这个判断谁都能验证。让模型写一段有点复杂的算法，比如带路径压缩的并查集，它大概率写得对；然后换个方向问它：给你这组输入，请逐行执行，把每行执行完之后各变量的值告诉我。你会看到第一步对、第二步对、第三步的中间状态错了、第四步又对了。不是从某一步开始全线崩溃，而是对错交替——它不是在执行，是在生成“一段代码追踪过程应该长什么样”。
会写不等于会读，会读不等于会推演。而在遗留系统里干活，你干的事 90% 是读和推演。
四、那遗留系统就不能用 AI 了？
AI 在这里的短板是三个：不知道历史约束、不知道你没说出口的要求、不理解代码的演化方向。凡是不依赖这三样、或者能把这三样交给人来兜住的任务，AI 就特别适合。
一是代码检索和理解。遗留系统里最贵的成本不是写代码，是搞清楚这段代码在哪、谁在调它、改了会炸到谁——新人接手两百万行系统，前三个月主要在考古。“这个订单状态字段在哪些地方被写入过”“把这个模块的调用链画出来”，答案哪怕只有八成准，也比手动 grep 三天快得多。更关键的是输出是给人看的，决策权在你手里，错误不会直接变成生产事故。
二是有明确目标和自动化验证的重构。最有说服力的案例是 Amazon：他们用 Amazon Q 做 Java 升级，把一个应用从 Java 8 升到 17 的平均耗时从约 50 个人天压到几个小时，半年内三万个应用完成升级，节省约 4500 个人年，自动生成的 review 建议里 79% 被直接采纳[10]。三个短板在这里全绕开了——目标明确，正确性判据机械（编译通过、测试通过、行为不变），而且把 javax.* 换成 jakarta.* 不需要知道保单为什么隔天生效。
依赖升级、大规模 API 签名变更、提取重复代码、补测试、给老函数生成文档，都属于这一类。反过来，核心业务规则、权限风控、数据模型、性能敏感路径，AI 只能当参谋，不能当主刀。
结论
腾讯 50% 的新代码由 AI 生成是真的，METR 那 19% 的减速也是真的。它们在说不同的场景。
AI coding 没有吞噬软件工程师，它吞噬的是“敲代码”这个动作。而敲代码从来不是这份工作最值钱的部分，只是过去它占的时间太长，长到我们误以为那就是工作本身。
现在它被压缩了，剩下的部分露出来了：判断哪里该动哪里不该动，知道哪道栅栏背后有原因，验收时会去看那些没人要求你看的东西。这些能力以前藏在打字的间隙里，不太值钱，现在是唯一值钱的东西。
那第二篇论文里核心开发者掉的 19% 去哪了？掉到帮别人擦屁股上了。AI 让很多人能开始写代码，但让少数人变得更加不可替代，代价是这少数人更累了。
参考文献
[1] Becker, J., Rush, N., Barnes, B., & Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv:2507.09089.
[2] Xu, F., Medappa, P. K., Tunc, M. M., Vroegindeweij, M., & Fransoo, J. C. (2025). AI-Assisted Programming Decreases the Productivity of Experienced Developers by Increasing the Technical Debt and Maintenance Burden. arXiv:2510.10165.
[3] Google Cloud DORA. (2024). Accelerate State of DevOps Report 2024.
[4] GitClear. (2025). AI Copilot Code Quality: 2025 Look Back at 12 Months of Data.
[5] Karpathy, A. (2025, February 2). There's a new kind of coding I call "vibe coding" [Post]. X.
[6] Wiggers, K. (2025, March 6). A quarter of startups in YC's current cohort have codebases that are almost entirely AI-generated. TechCrunch.
[7] Sharwood, S. (2025, July 21). Vibe coding service Replit deleted production database. The Register.
[8] Chesterton, G. K. (1929). The Thing: Why I Am a Catholic. Dodd, Mead & Company.（"切斯特顿栅栏"出自 "The Drift from Domesticity" 一章）
[9] Veracode. (2025). 2025 GenAI Code Security Report.
[10] AWS. (2024). Accelerate application upgrades with Amazon Q Developer agent for code transformation. AWS DevOps Blog.