我每天都在用 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。
METR 的发现不是孤例。开发者信任数据讲了一个类似的故事：84% 的开发者在使用或计划使用 AI 编程工具，但信任度已降至 29%，低于 2024 年的 40%。只有 3% 报告高度信任。Stack Overflow 的一项随机对照试验在任务层面发现了同样的感知偏差——使用 AI 的开发者实际上比不用 AI 的慢 19%，尽管他们自认为快了 20%。当人们相信一个工具让自己更快时，即使证据指向相反，他们也会继续使用。
这背后有原因。一个有经验的开发者在熟悉的代码库上工作时，脑中携带的上下文是任何自动补全都无法匹敌的。他们知道哪些抽象层是漏的，哪些测试是不稳定的，哪个模块是两年前离职的人写的。AI 没有这些上下文。于是开发者陷入了一个闭环：写提示词、等待、阅读建议、发现遗漏、修改、重新提示。这个闭环感觉很高效，因为屏幕上一直在变。但挂钟说的是另一回事。
一项关于 Cursor 使用情况的双重差分研究在更长的时间跨度上发现了同样的模式。初期速度确实提升了。然后代码复杂度悄悄上升，静态分析告警不断累积，长期速度反而下降了。第一个 sprint 看起来很棒，到第六个 sprint 就开始还债了。
这不意味着 AI 编程工具没用。GitHub 衡量的是孤立任务上的完成速度。METR 衡量的是有经验的开发者在真实代码库上的表现。两个发现可以同时成立。AI 在你不擅长的领域、不熟悉的代码、或机械性任务上确实有帮助。但当你本来就知道该怎么做的时候，它反而会拖慢你。
模式匹配不是推理
Anthropic 的 AI 可靠性工程负责人 Alex Palcuie 在 QCon London 上把技术工作拆成四个阶段：观察、定位、决策、行动。他说 AI 在观察阶段「棒极了」——「以 I/O 的速度读日志，不会厌烦。」搜索代码库、关联信号、在没人有时间读完的文件里拉线索。但在定位和决策——理解你的系统里的因果关系——它弱得多。
他讲了两个直接映射到编程的故事。跨年夜，Claude 通过不知疲倦的模式匹配找到了一次生产故障：它把 HTTP 500 追踪到 200 个可疑账户，继续深挖，发现 4000 个同时创建的休眠账户，把调查方向转向了人类本可能当成普通 bug 的欺诈行为。这是 AI 最好的状态：在你永远读不完的数据里不知疲倦地搜索。
然后讲了相反的故事。每次缓存故障引发请求峰值，Claude 都诊断「容量问题——加服务器」。峰值是症状，不是原因。Claude 把模式匹配到过去的容量事件，无法追问这次峰值是否意味着别的东西。「就像团队里的新人，」Palcuie 说，「他们会想『哦，是容量问题』，实际上是你丢了缓存。」
在代码库里，同样的失败模式不断出现。AI 建议 Stack Overflow 上的答案——加重试循环、扩大连接池、加熔断器——却不知道你的服务失败是因为两年前离职的人写的模块在特定负载下泄漏。一项覆盖 ChatGPT、Claude 和 Gemini 的研究发现，分析生产事故时技术细节的幻觉率高达 23%。在编程里，你可以在 PR 里迭代修正错误。在 live incident 中，一个自信但错误的诊断对 Global 2000 公司每分钟成本 9000 美元。在多步 agent 工作流里，上游一个错误的服务名或 API 假设会污染下游每一步推理。
Palcuie 还谈到事后分析：「它给出一个 80 分的故事，漂亮、可读、有说服力，但在根因上真的很差。」Claude 不知道你系统的历史——尤其如果你的系统已经运行了十年。这同样映射到 code review：AI 的 PR 看起来合理，直到熟悉系统的人问了模型答不出的那个问题。
代码质量问题
2025 年 12 月的一项 CodeRabbit 研究分析了 470 个开源 PR——320 个有 AI 参与编写，150 个纯人工编写。AI 生成的 PR 缺陷率高出 1.7 倍：逻辑错误多 75%，安全漏洞最多多出一倍，过度 I/O 问题多出近八倍。PR 接受率：AI 代码 32.7%，人类代码 84.4%。
这个差距就是我所说的「70% 问题」的代价。AI 能快速完成大部分工作。剩下的 30%——错误处理、边缘案例、生产环境加固——才是真正的工程所在。这部分花的时间和从前一样多。「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 产出、捕捉它引入的缺陷、向 QA 解释为什么一个函数在 null 输入时悄无声息地失败的人。
管理层和一线之间的分裂在运维数据里非常清楚。Catchpoint SRE 报告用同一套方法论追踪 toil（琐碎劳动）已有八年，发现 2026 年中位数 reported toil 从 20% 跳到 34%——逆转了多年的下降趋势。被问及 AI 是否减少了 toil 时，49% 说 yes，35% 说没变化，16% 说反而增加了。评论很直接：「AI 不会自动消除 toil，它重新分配 toil。」新的类别包括：维护 AI 工具、审查 AI 建议、调整提示词、检查 AI 操作是否正确、向别人解释 AI 做了什么。
管理层接触的是 AI 的产出：更干净的报告、更快的 demo、更短的会议。所以他们报告 toil 减少。一线接触的是 AI 的过程：验证它的结论、捕捉它的错误、在它基于错误数据行动后收拾残局。自动化把 IC 的工作从「做」变成了「查」。两种视角同时成立。只有 13% 的团队表示对监控 AI 驱动组件的能力「非常」或「极其」有信心。当你看不清 AI 为什么做出某个决定，时间就从执行转向了验证。报告的说法是：「从外面看，toil 似乎还在；从里面看，往往感觉像是谨慎。」
一位 DevOps 工程师在 Reddit 发帖：「我们不断加『AIOps』和『Autonomous』工具来减少 toil，但感觉 toil 只是在转移。以前修代码，现在修 AI agent 为什么把 503 当成『自愈』机会重启了错误的服务。」一条高赞回复：「以前直接 debug pipeline 或 infra，现在在 debug 本该 debug 东西的自动化。」在编程里，平行关系很明显：管理层看到更干净的报告和更快的总结；一线看到更多需要审查的代码、更多生产事故、更大的维护面。
在 METR 的 2026 年 2 月更新中，30-50% 的开发者拒绝在没有 AI 的情况下参与实验。他们已经依赖上了一个被实验证明会拖慢他们的工具。这件事值得我们警惕。
当 AI agent 搞崩生产环境
信任问题不是理论上的。有生产权限的 AI agent 已经造成了真实损害。
2025 年 12 月，Amazon 的 Kiro AI agent 自主删除了整个 AWS 生产环境，造成 13 小时 downtime。agent 拥有 operator 级权限，没有强制 peer review。它被要求修复 AWS Cost Explorer 的小问题，却决定删除并重建整个环境。此后 Amazon Q Developer 也发生了几乎相同的事故。
AI agent 事故汇编中的其他案例：LangChain agent 陷入无限对话循环 11 天，产生 47000 美元 token 账单。一个 agent 在周末产生了 230 万次非预期 API 调用。Claude Code 误读 Terraform state 文件，运行 terraform destroy，删除了 2.5 年的生产数据。Replit AI agent 在 code freeze 期间删除了生产数据库，销毁 1200 多条高管记录，又伪造 4000 条假数据填补空缺。
所有案例的共同模式：自主行动却没有执行时治理、审批关卡或审计追踪。没有权限边界。破坏性操作没有强制审查。没有预算上限。88% 的组织在过去一年报告过 AI agent 安全事件。64% 的十亿美元公司在 AI 故障上损失超过 100 万美元。
这些不是 reckless 实验的边缘案例。它们是 coding agent 拿到生产钥匙、却没有「伤疤组织」来知道哪些操作不可逆时会发生的事。一个下午 scaffold 微服务的初级工程师，和误读 state 文件运行 terraform destroy 的 agent，是同一个故事：有速度，没有理解。
Jevons 是对的
1865 年，经济学家 William Stanley Jevons 观察到，当 James Watt 让蒸汽机变得更省煤之后，英国的煤炭消耗量并没有减少，反而增加了。更便宜的能源解锁了此前不经济的用途。原本用不起蒸汽动力的工厂突然用得起了。总需求增长了，因为单位成本下降了。
Anthropic 的 AI 可靠性工程负责人 Alex Palcuie 在 QCon London 上称之为「AI 行业最受欢迎的悖论」。他当时讲的是运维，但同样的逻辑适用于开发。AI 降低了代码的生产成本，组织就生产更多代码。更多代码意味着更多集成点、更多故障模式、更多需要监控、测试和维护的东西。「工具层面的所有改进都会被不断增长的复杂性所抵消。」
证据在不断积累。GitHub commit 同比增长 25%。新应用的构建速度在三年前是不可想象的。但 MTTR 自 2021 年以来逐年恶化：
- 2021：47% 的组织需要超过一小时才能恢复
- 2022：64%
- 2023：74%
- 2024：82%
这发生在 observability 和 AIOps 工具空前投资的同一时期。更多工具，更慢的恢复。2024 年，只有 18% 的组织在一小时内恢复。11% 需要超过一天。2% 需要数周。
AI 编程工具以团队从未有过的速度生成代码。大量代码在没有人完整读过的情况下就上线了。系统变得更复杂，但运维它的人并没有获得与之匹配的理解。出问题时，工程师在 debug 自己没写过、也不了解的代码。
与此同时，根据 Uptime Institute 2025 分析，整体 outage 频率实际上在下降。但发生的 outage 更严重、代价更高。2024 年 CrowdStrike 事件 导致全球 850 万台 Windows 系统崩溃，Fortune 500 公司损失超过 50 亿美元。医疗 19.4 亿，银行 11.5 亿。一次跳过质量检查的 faulty 配置更新。AI 让系统变大的速度，快于它让故障变便宜的速度。
这就是 Jevons 悖论在实时上演。AI 降低了写代码的成本，而世界的回应是要求更多的软件。不是多一点点，而是多得多。美国劳工统计局预测到 2034 年开发者就业将增长 15-18%，即使 AI 承担了越来越多的键入工作。
这件事有乐观的版本：AI 使得一条软件长尾成为可能——那些以前不具备经济可行性的软件。小企业可以有定制工具，小众问题可以有专门的解决方案，更多人可以参与构建，而不仅仅是专业工程师。
也有不那么令人舒服的版本。如果 AI 接管了初级工程师曾经借以成长的任务——写模板代码、修缺陷、写测试——那么培养高级工程师的通道就断了。今天的 Staff Engineer 是靠多年写糟糕的代码、凌晨两点调试、在亲眼看着错误处理失败中学会它的含义而成长起来的。如果这种学徒期消失了，我们将面临经验丰富但无法被替代的老一代工程师，以及从未得到足够锻炼的新一代。
随着 AI 处理更多例行工作，工程师自己动手的练习越来越少。Palcuie 把只有被 burn 过才积累的直觉叫做「伤疤组织（scar tissue）」。如果 AI 处理了大部分简单的脚手架工作，伤疤组织就会萎缩。当 AI 最终失败——它会的——本该接手的工程师已经好几个月没手动做过这些事了。Palcuie 把它比作 on-call：「曾经熟悉每个犄角旮旯的值班，现在多了一个有时比你找问题还快、有时又像过度自信 junior 的大语言模型。」
这不是新问题。1983 年，认知心理学家 Lisanne Bainbridge 发表了《自动化的讽刺》，被引用超过 1800 次。她的核心发现：当你自动化大部分工作后，人类操作员对剩余任务的练习变少，而剩余任务恰恰是自动化失败时需要执行的任务。她指出了两个讽刺：第一，设计者因为觉得操作员不可靠而自动化，但设计者自己的错误成了主要失败来源；第二，自动化处理简单任务，把难的留给操作员，但操作员因为从不练习这些难任务而变得更差。
航空业证明了她说得对。法航 447 于 2009 年坠毁，228 人遇难。自动驾驶断开时，飞行员不得不在夜间湍流中手动飞行。他们做不到。一项对 30 名 airline pilot 的研究发现，所有人基本仪表操作都低于认证标准。43% 报告转向自动化驾驶舱后手动飞行技能下降。FAA 和 EASA 现在强制要求 recurrent 手动飞行练习。不是可选，是强制。
Google 在运维上很早就理解了这一点。自 2006 年运行的 DiRT 项目故意向生产系统注入故障，让工程师在非紧急状态下练习 incident response。Netflix 的 Chaos Monkey 做同样的事。原则与航空业相同：等到自动化失败才让团队练习手动干预，已经太晚了。Palcuie 的结论：继续培养工程师。你仍然需要他们——尤其是「从没发生过这种事」的时刻，那是模式匹配处理不了的。
DORA 报告对这种张力做了很好的总结：「AI 不能修复团队，它会放大已有的优势和劣势。」AI 是一个乘数，而乘数对它所乘的东西毫不挑剔。
什么真正有效
一项 2025 年 Stanford-CMU 研究让 48 名专业人士在 16 个 realistic 任务上对比四个 AI agent 框架。人类主导、AI 辅助的工作流比完全自主 agent 表现好 68.7%。完全自动化在纸面上快 88%、便宜 90%，但成功率低 32-50%。算上验证和 debug 时间，完全自动化实际上慢 17.7%。
Google 的 SRE 现在用 Gemini CLI 做 incident response，但有分层安全控制。Gemini 分类症状、选择缓解 playbook，但人类在 fix 运行前验证。「在一个 context 安全的操作，在另一个 context 可能不安全。」他们关注 MTTM（平均缓解时间）而非完全自主。这在编程里同样适用：AI 做观察和脚手架，人类做影响生产的判断。
Palcuie 尽管说 AI 作为完整替代「不行」，仍然会在打开 dashboard 前先找 Claude。关键是他用它做什么：观察，不是自主行动。读日志、关联信号、捕捉人类凌晨三点会错过的模式。判断权留在工程师手里。打开 Cursor 时同理：让它搜索和 scaffold；不要让它在没有理解系统的人 sign off 的情况下 ship。
我真正的看法
过去两年里，我从两个角度观察着这一切——既是一个每天用 AI 写代码的人，也是一个管理着同样在这样做的团队的人。
AI 在做真正的工作。这一点没有争议。但行业在衡量错误的东西。生成的行数、完成的任务、sprint 速度——这些衡量的是产出。它们衡量不了理解。而理解才是让软件在生产环境中持续运行数月、数年的关键。
METR 的发现——有经验的开发者使用 AI 后变慢了，但自认为变快了——应该比现在更让我们担忧。我们正在一个感知偏差之上构建组织战略。公司在根据并未在对照实验中兑现的生产力提升来裁员。他们在耗尽最积极采用 AI 的人。他们积累代码的速度，远远超过了积累维护这些代码所需判断力的速度。
Jevons 告诉我们，这个问题不会通过减少代码产出来解决。历史上从来都不会。当某样东西变得更便宜，你只会得到更多。出路在于认识到：代码从来不是瓶颈，判断力才是。现在仍然是。
做对这件事的公司会像优秀飞行员使用自动驾驶一样使用 AI：把它当作杠杆，把人类的注意力释放到机器无法做出的决策上——同时把它当作需要更多刻意练习、而非更少练习的工具。做错的公司则会学到 METR 研究早已揭示的教训——你无法准确感知的速度，也是你无法管理的速度。Bainbridge 在 1983 年就预言，自动化会创造出「同时更被需要、却更没准备」的操作员。四十年后，我们在软件里正在构建完全相同的场景。