我每天都在用 AI 编程工具。作为一家 YC 支持的创业公司的 CTO，过去两年里我亲眼看着团队逐步采用 Cursor、Copilot 和 Claude。我见过一个初级工程师在一个下午搭好了一整个微服务。我也见过同一个服务在三周后引发了一次生产事故——因为没有人真正理解它在干什么。
行业叙事很简单：AI 写代码更快，开发者更高效，公司需要更少的工程师。但数据讲了一个更诡异的故事。AI 写的代码比以往任何时候都多。开发者觉得自己变快了。但他们实际上并没有。公司在根据 AI「将会」做到什么来裁员，而不是根据 AI 实际做到了什么。留下来的工程师在加班，而不是早下班。
我想搞清楚为什么。
数据是真的
GitHub Copilot 在启用它的文件中生成了 46% 的代码，在 Java 项目中高达 61%。超过两千万开发者在使用它。财富 100 强企业中有九成已经部署。截至 2026 年 2 月，所有开发者中 AI 生成的生产代码占比达到 26.9%，上一季度还是 22%。
自主 Agent 也在快速发展。Cognition 的 Devin 在投入生产 18 个月后发布了 2025 年度绩效报告。它的 PR 合并率从 34% 翻倍到 67%。在安全补丁这类边界明确的任务上，它比人类快 20 倍；在测试生成上快 10 到 14 倍。包括 Goldman Sachs 和 Nubank 在内的数千家公司已经在用它。但它在面对模糊需求时表现很差（25% 成功率），在全新架构面前更是如此（15%）。这个区别很重要。
GitHub 的平台数据展示了产出端的故事：2025 年 PR 合并量同比增长 23%，commit 数量增长 25%。新 iOS 应用增加了 50%，新网站增加了 40%。我们正在生产比以往任何时候都多的软件。
这些数字是真实的。AI 在做真正的工作。但原始产出是一个具有误导性的生产力指标，表面之下发生的事情让这个故事变得复杂得多。
没人预料到的研究
2025 年 7 月，非营利 AI 研究机构 METR 发表了一项随机对照实验，在行业中引起了巨大震动。十六位经验丰富的开源开发者在他们熟悉的代码库上完成了 246 项任务——其中一些人已经贡献了五年以上。任务被随机分配为「允许使用 AI」或「禁止使用 AI」。开发者使用 Cursor Pro 搭配 Claude 3.5 和 3.7 Sonnet。时薪 150 美元。
结果是：使用 AI 的开发者慢了 19%。
实验前，这些开发者预测 AI 会让他们快 24%。经历了实际的减速之后，他们仍然相信自己快了 20%。感知与现实之间差了 39 个百分点。而且 69% 的人说他们还是会继续用 AI。
这背后有原因。一个有经验的开发者在熟悉的代码库上工作时，脑中携带的上下文是任何自动补全都无法匹敌的。他们知道哪些抽象层是漏的，哪些测试是不稳定的，哪个模块是两年前离职的人写的。AI 没有这些上下文。于是开发者陷入了一个循环：写 prompt、等待、阅读建议、发现遗漏、修改、重新 prompt。这个循环感觉很高效，因为屏幕上一直在变。但挂钟说的是另一回事。
一项关于 Cursor 使用情况的双重差分研究在更长的时间跨度上发现了同样的模式。初期速度确实提升了。然后代码复杂度悄悄上升，静态分析告警不断累积，长期速度反而下降了。第一个 sprint 看起来很棒，到第六个 sprint 就开始还债了。
这不意味着 AI 编程工具没用。GitHub 衡量的是孤立任务上的完成速度。METR 衡量的是有经验的开发者在真实代码库上的表现。两个发现可以同时成立。AI 在你不擅长的领域、不熟悉的代码、或机械性任务上确实有帮助。但当你本来就知道该怎么做的时候，它反而会拖慢你。
代码质量问题
2025 年 12 月的一项 CodeRabbit 研究分析了 470 个开源 PR——320 个有 AI 参与编写，150 个纯人工编写。AI 生成的 PR 缺陷率高出 1.7 倍：逻辑错误多 75%，安全漏洞最多多出一倍，过度 I/O 问题多出近八倍。PR 接受率：AI 代码 32.7%，人类代码 84.4%。
这个差距就是我所说的「70% 问题」的代价。AI 能快速完成大部分工作。剩下的 30%——错误处理、边界情况、生产环境加固——才是真正的工程所在。这部分花的时间和从前一样多。
Google 的 DORA 2025 报告在组织层面证实了这一点：90% 的开发者使用 AI，超过 80% 认为 AI 提高了他们的生产力，但 AI 的采用与软件交付稳定性呈负相关。团队发布得更快，也崩得更多。报告的核心发现是：「AI 不能修复团队，它会放大已有的优势和劣势。」
裁员基于预测，而非事实
自 2022 年以来，超过五十万科技从业者被裁。2025 年，美国约有 127,000 人失业。其中约 70,000 次裁员与 AI 的采用直接相关。
但总数掩盖了一个关键细节：60% 的高管是基于对 AI 未来影响的预期来缩减人员的。只有 2% 的大规模裁员是因为 AI 已经切实替代了相应的工作。公司裁员不是因为 AI 证明了它能胜任，而是因为他们赌它将来可以。
METR 研究中发现的感知偏差——开发者认为自己的生产力比实际高出 39 个百分点——可能会向上传导。如果工程师觉得 AI 让他们快了很多，管理层看到 demo 出来得更快，那么传递到高管那里的信号在到达之前就已经失真了。
被裁的工程师去了哪里？LinkedIn 跟踪了 500 多名被裁员工：42% 去了其他科技公司（金融科技、AI、健康科技），28% 转入非科技行业，15% 加入了初创公司。一个数字特别突出——2026 年 63% 的被裁科技人员表示自己开始创业了。
再就业速度因专业方向差异极大。AI/ML 工程师平均 1.4 个月找到新工作。前端工程师需要 4.2 个月。产品经理需要 4.8 个月。市场在告诉你，哪些技能它认为可以被 AI 替代，哪些它认为与 AI 互补。
初级工程师的招聘量下降了 30%。整体开发者就业预计到 2034 年增长 15-18%。市场没有在缩小，而是在掏空中间层。
为什么所有人都更忙了
这是一直困扰我的部分。如果 AI 让我们更高效了，我们应该有更多空闲时间才对。但所有证据都指向相反的方向。
UC Berkeley 的研究团队在一家科技公司驻扎了九个月，为 Harvard Business Review 追踪了 40 名员工。他们发现：员工「以更快的节奏工作，承担了更广泛的任务，并将工作延伸到一天中更多的时段——往往没有人要求他们这样做。」他们用额外的工作填满了休息时间、晚上和清晨。没有人逼他们。工具让这一切成为可能，他们就这么做了。
2026 年 3 月的 Harness 报告量化了这一现象。在高频使用 AI 编程工具的开发者中，96% 每月多次在晚上或周末加班，而偶尔使用的只有 66%。高频用户的事故恢复时间也更长：7.6 小时对比 6.3 小时。最积极拥抱 AI 的人反而最先倦怠。TechCrunch 在二月发了一篇报道，标题是：「最先出现倦怠迹象的，是那些最积极拥抱 AI 的人。」
这背后的机制很好预测。一个原本需要两周的功能现在四天就能搞定。但 sprint 不会因此变轻松——三个新功能立刻填上了空缺。新的速度成为了基线，没人会往下调整期望。管理层看到 demo 出来得更快了。而一线开发者才是那些审查 AI 产出、捕捉它引入的 bug、向 QA 解释为什么一个函数在 null 输入时悄无声息地失败的人。
我在关于 AI SRE 的文章中写过同样的动态：管理层看到的是更干净的报告和更快的总结；一线看到的是更多需要审查的代码、更多生产事故、更大的维护面。双方说的都是事实，只是在看系统的不同部分。
在 METR 的 2026 年 2 月更新中，30-50% 的开发者拒绝在没有 AI 的情况下参与实验。他们已经依赖上了一个被实验证明会拖慢他们的工具。这件事值得我们警惕。
Jevons 是对的
1865 年，经济学家 William Stanley Jevons 观察到，当 James Watt 让蒸汽机变得更省煤之后，英国的煤炭消耗量并没有减少，反而增加了。更便宜的能源解锁了此前不经济的用途。原本用不起蒸汽动力的工厂突然用得起了。总需求增长了，因为单位成本下降了。
Anthropic 的 AI 可靠性工程负责人 Alex Palcuie 在 QCon London 上称之为「AI 行业最受欢迎的悖论」。他当时讲的是运维，但同样的逻辑适用于开发。AI 降低了代码的生产成本，组织就生产更多代码。更多代码意味着更多集成点、更多故障模式、更多需要监控、测试和维护的东西。「工具层面的所有改进都会被不断增长的复杂性所抵消。」
证据在不断积累。GitHub commit 同比增长 25%。新应用的构建速度在三年前是不可想象的。但 MTTR 自 2021 年以来逐年恶化。需要超过一小时才能恢复的组织比例从 47% 上升到了 82%。
这就是 Jevons 悖论在实时上演。AI 降低了写代码的成本，而世界的回应是要求更多的软件。不是多一点点，而是多得多。美国劳工统计局预测到 2034 年开发者就业将增长 15-18%，即使 AI 承担了越来越多的键入工作。
这件事有乐观的版本：AI 使得一条软件长尾成为可能——那些以前不具备经济可行性的软件。小企业可以有定制工具，小众问题可以有专门的解决方案，更多人可以参与构建，而不仅仅是专业工程师。
也有不那么令人舒服的版本。如果 AI 接管了初级工程师曾经借以成长的任务——写模板代码、修 bug、写测试——那么培养高级工程师的通道就断了。今天的 Staff Engineer 是靠多年写糟糕的代码、凌晨两点调试、在亲眼看着错误处理失败中学会它的含义而成长起来的。如果这种学徒期消失了，我们将面临经验丰富但无法被替代的老一代工程师，以及从未得到足够锻炼的新一代。Lisanne Bainbridge 在 1983 年就精确预言了这一点：把训练性的任务自动化掉，你就在削弱系统在自动化失效时所依赖的人类能力。
DORA 报告对这种张力做了很好的总结：「AI 不能修复团队，它会放大已有的优势和劣势。」AI 是一个乘数，而乘数对它所乘的东西毫不挑剔。
我真正的看法
过去两年里，我从两个角度观察着这一切——既是一个每天用 AI 写代码的人，也是一个管理着同样在这样做的团队的人。
AI 在做真正的工作。这一点没有争议。但行业在衡量错误的东西。生成的行数、完成的任务、sprint 速度——这些衡量的是产出。它们衡量不了理解。而理解才是让软件在生产环境中持续运行数月、数年的关键。
METR 的发现——有经验的开发者使用 AI 后变慢了，但自认为变快了——应该比现在更让我们担忧。我们正在一个感知偏差之上构建组织战略。公司在根据并未在对照实验中兑现的生产力提升来裁员。他们在耗尽最积极采用 AI 的人。他们积累代码的速度，远远超过了积累维护这些代码所需判断力的速度。
Jevons 告诉我们，这个问题不会通过减少代码产出来解决。历史上从来都不会。当某样东西变得更便宜，你只会得到更多。出路在于认识到：代码从来不是瓶颈，判断力才是。现在仍然是。
做对这件事的公司会像优秀飞行员使用自动驾驶一样使用 AI：把它当作杠杆，把人类的注意力释放到机器无法做出的决策上。做错的公司则会学到 METR 研究早已揭示的教训——你无法准确感知的速度，也是你无法管理的速度。