Presentation: The Ladder Is Missing Rungs: Engineering Progression When AI Ate the Middle

梯子缺失了横档：当AI吞噬了中层时的工程职业发展 - InfoQ

InfoQ 首页 演讲 梯子缺失了横档：当AI吞噬了中层时的工程职业发展

文化与方法

QCon AI 波士顿（2027年7月8-9日）：AI原型已经成功。生产环境会发生什么？

梯子缺失了横档：当AI吞噬了中层时的工程职业发展

点赞

新下拉阅读列表

• 阅读列表

查看演讲

• 垂直

• 水平

• 全屏

速度：

• 1x

• 1.25x

• 1.5x

• 2x

50:30

概述

Alasdair Allan讨论了来自METR和Anthropic的关于AI编码采用的实证研究。他解释了"监督悖论"，即对AI工具的依赖会破坏初级技能发展，导致机构背景流失，并威胁到有效监督自主系统的长期工程人才管道。

作者简介

Alasdair Allan是Negroni Venture Studios的首席技术官，也是Evaro的临时首席技术官，他处于开源硬件、机器学习和新兴技术的交汇点。这位前天体物理学家研究员和Raspberry Pi前文档负责人，曾撰写八本书籍和超过一百篇学术论文。

关于会议

软件正在改变世界。QCon伦敦通过促进开发者社区中的知识和创新传播，赋能软件开发。作为以实践为导向的会议，QCon专为技术团队负责人、架构师、工程总监和项目经理设计，这些人群在团队中影响着创新。

INFOQ 事件

• 2026年11月19日，美国东部时间中午12点 扩展OpenTelemetry：管理收集器、配置和成本 演讲者：David Iparraguirre - Datadog高级产品市场经理，Jessica Yang - Datadog产品经理

演讲实录

Alasdair Allan：不是五年前，而是12个月前，几乎就在同一天，另一个人在纽约完全不同的会议上站起来说："在12个月内，AI将写出几乎所有代码。"我预计在座的各位中，仍有人在编写代码，或者至少有些人领导的团队仍在用手写代码，像野蛮人一样。说这话的是Dario Amodei，RLHF（强化学习人类反馈）的共同发明者，这一训练技术是几乎所有现代AI的基础，同时也是Anthropic的联合创始人。他说，在3到6个月内，AI将写出90%的所有代码，而在12个月内，几乎全部代码都将由AI写出。在6个月时，Amodei声称自己的预测得到了验证，称90%这个数字在Anthropic内部是完全准确的。12个月后，几乎就在同一天，但事情并没有完全按照他说的那样发生，对吗？

红木研究（Redwood Research）的一项详细分析得出结论，他引用的90%这个数字具有误导性。如果你只计算提交到代码库的代码，这个比例更接近50%，至少对我来说，这个数字仍然非常令人震惊。只有当你包含一次性脚本、单次探索以及所有曾经短暂有用过的AI生成文本时，这个数字才会膨胀到90%。与此同时，谷歌报告称其内部代码中只有刚超过25%是由AI生成的。微软报告约为30%。GitHub Copilot显示企业采纳率约为30%。这些数据在过去六个月中几乎没有变化，而这个比例离"几乎所有"还有很大差距。

AI正在编写大量代码。开发者的角色和工作内容已经发生了巨大变化，这一点我们都可以认同。Amodei并未夸大其词，Anthropic的内部数据显示，工程师每天有59%的工作时间使用Claude，且自报效率提升了50%。目前约有4%的GitHub提交记录是由Claude Code完成的。这些工具是真实存在的，在特定场景下确实能提升效率。但问题在于，编写代码从来就不是我们职业的核心目标。这可能会让一些人感到意外。目前大多数人讨论的话题是AI如何编写代码，而我们真正应该讨论、并且已经开始讨论的话题是：当软件工程师不再需要编写代码时，软件工程会变成什么样子。这次演讲既不涉及上述任何一场讨论，而是关注双方争论中被忽视的问题。

这背后存在一个结构性问题。如果AI承担了曾经用于训练工程师的工作，那么下一代工程师将从何而来？Amodei去年对自身观点的补充说明正印证了这一点。他表示，程序员仍然需要指定整体设计、代码协作方式以及设计的安全性。他将“编写代码”与“工程实践”进行了区分。在大约三到六个月之前，编写代码还是人们学习工程实践的方式。去年七月，路透社的一篇标题“AI使一些经验丰富的软件开发人员变慢，研究发现”被发布到了全球几乎所有工程团队的Slack频道中。作为一名前记者，我认为这个标题并不够吸引人，但它确实引起了所有人的关注。这项研究背后的METR实验是一项严谨的随机对照试验，而非厂商调查，结果显示，使用AI工具的资深开发者完成任务所需时间增加了19%。在实验开始前，他们预测AI会使他们快24%；实验结束后，他们仍然认为自己快了20%。感知与现实之间的差距高达43个百分点。仅凭这个标题就足以挑战关于AI的叙事。真正重要的是接下来会发生什么。

为了明确起见，过去四到五个月在编码工具的可用性方面取得了我认为具有突破性的进展。其中很大一部分得益于围绕模型的工具和架构改进。代理循环（Agentic loops）、代码检查器（linters）和测试运行器（test runners）的结构化反馈机制，以及从迭代而非单次生成的角度进行改进的能力。AI公司通过有针对性的训练使模型性能有所提升，而围绕模型的支撑架构也得到了显著优化。我们过去四到五个月看到的大部分进展（这些进展非常显著），主要来自于更紧密的反馈循环和架构改进，而非单纯的智能提升。

第二幕 - 数据

过去一年，我担任一家快速成长公司的临时首席技术官（CTO），这是我们的投资组合公司之一。我参与了大量招聘工作。任何做过一年以上招聘工作的人一定都了解其中的痛苦。没做过招聘的人，建议你不要轻易尝试。现在正在招聘的人一定也见识过这种现象：一些候选人表面上令人印象深刻的简历在深入提问时却漏洞百出。更糟糕的是，有些人明显在面试过程中依赖AI辅助。我构建的系统现在意味着我需要主动提示系统。但并非总是如此，有些人确实是通过真正学习来掌握技能的。信号非常嘈杂，现在越来越难以判断谁真正理解了自己产出的内容。这正是让我开始真正担忧现状的原因，尤其是关于职业发展阶梯的问题。我开始寻找数据，而不是厂商调查、博客文章，更不是LinkedIn上的热门观点。我需要的是具有统计显著性的实际研究结果。

你可能认为这些数据很难找到，或者可能认为它们并不像你想象的那么难以获取。实际上，从事这项研究的人比你想象的要少得多。METR再次进行了相关研究，他们评估了一个他们称之为“50%任务完成时间范围”的指标，即人类校准任务的长度，AI代理能够以50%的可靠性完成该任务。他们的主要发现是：AI能够完全自主完成（无需任何干预、单次生成）的任务长度，自2019年以来每七个月翻一番，自2024年以来加速至每四个月翻一番。此处的Y轴是按对数刻度显示的成功率。正是这个成功率指标标志着职业发展阶梯的断裂点。这里我们看到Claude Sonnet模型的成功概率与人类任务持续时间的对比曲线。S型曲线在约一小时后急剧下降。对于初级开发人员在第一年完成的任务，成功率接近100%；而对于需要多年初级经验积累才能做出判断的任务，成功率却接近0%。

对于需要人类花费不到四分钟完成的任务（如小的错误修复、模板代码编写、简单实现等），AI现在可以以接近100%的成功率完成。将这些任务交给人类已无意义，AI能更快、更可靠地自主完成。然而，对于需要人类约一小时完成的任务，AI的成功率约为50%；对于需要四小时以上才能完成的任务，成功率则低于10%。需要指出的是，这些基准测试结果严重高估了AI在实际场景中的能力。METR自己的可合并性研究发现，约50%通过自动化测试的AI生成的拉取请求（PR）最终不会被大多数仓库维护者合并。在针对18个成熟开源项目的实际任务测试中，Claude 3.7 Sonnet虽然通过了测试用例，但在15次审查中38%的时间未能生成任何可合并的PR。每个PR至少存在三类质量问题：缺少文档、测试覆盖率不足、代码规范违规或代码质量缺陷。维护者将AI生成的PR修复到可合并状态平均耗时约42分钟，仅为人类独立完成该任务所需时间的三分之一。AI可以实现核心功能，但始终无法在工艺层面（即中层工程师应具备的技能）达到要求。

在继续之前，我需要再次提醒你注意METR研究的结果：使用AI工具的资深开发者完成任务所需时间反而增加了19%。任务开始前，他们预测AI会使自己效率提升24%；任务结束后，他们仍认为自己比实际效率快20%。与Anthropic进行的随机对照试验形成鲜明对比：该试验中52名主要为初级软件工程师学习新的Python库Trio（该库自称是面向异步并发和I/O的友好型Python库），使用AI与不使用AI完成该任务的时间在统计学上没有显著差异（p值为0.391）。AI组仅快了约两分钟，这在统计噪声范围内。使用AI的小组在学习该库的效率上并未获得任何实质性的提升。Anthropic的论文明确指出，AI助手在此任务中的生产力提升未能达到统计显著性。

尽管右侧误差条存在轻微重叠，但他们在后续掌握度测试中得分存在统计学差异（p值为0.01，远低于0.05的阈值）。AI辅助组在库特定技能、概念理解、代码阅读和调试方面出现显著下降。使用AI助手的小组在掌握度测试中得分低17%（50% vs 67%）。差距最大的是调试问题，而调试正是验证AI输出结果所需的核心技能。AI组在未显著加快任务完成速度的情况下，学习成果显著减少。他们并未用速度换取学习，而是用学习换取了零收益。这并非权衡，而是纯粹的损失。低分参与者存在三种主要失败模式：完全依赖AI。他们甚至没有尝试，从一开始就完全依赖AI。

渐进式AI依赖。他们尝试了一小段时间后便放弃了，之后完全依赖AI完成剩余所有工作。有趣的是，他们采用了迭代式AI调试方式。他们使用AI来调试AI的输出结果，而不是试图理解AI的运作方式。所有陷入这三个群体并表现出这些行为的开发者得分均低于40%，而未使用AI的对照组得分则为67%。Anthropic明确指出这是一个悖论。如果初级工程师因过度使用AI而阻碍了技能发展，那么生产力提升可能需要付出验证AI编写代码所需技能的代价。他们称之为“监督悖论”。实际上，使用AI需要监督，而监督本身需要那些因过度依赖AI而逐渐退化的编码技能。

第三幕——人力成本

数据并不能说明一切。我看到一位拥有25年行业经验的资深工程师在LinkedIn上发帖。对我而言，这篇帖子准确捕捉到了数据无法体现的内容。对于目前正带领工程师团队并抵制AI工具的管理者，请思考他们世界中正在发生的事情。他们的整个职业身份建立在一项正迅速失去市场价值的技能之上。当90%的个人经验都变成了所谓“不再需要”的东西时，“你仍然会被需要来设计和架构一切，不用担心”这类标准安慰便显得毫无说服力。仅凭几句关于架构的空话，根本无法弥补这种落差。然而，这些资深程序员所具备的模式识别能力——系统应该如何构建、复杂性隐藏在何处、什么因素会导致系统规模失效——已无法通过传统方式获得。初级工程师不会再花数年时间研读遗留代码库，也不会在凌晨3点调试生产环境事故。

我们都经历过这种场景。他们只会将AI代理指向代码并要求其生成摘要。对软件在现实世界中实际行为的深刻直觉正变得越来越难以获得。或许这种能力如今已仅存于一小群人中，这群人所处的时代可能会被后人怀念为“手工艺时代”。实证数据支持这一情感叙事。Faros AI的《生产力悖论》报告分析了来自1200个团队约10000名开发者的遥测数据，发现AI采用率高的团队完成的任务数量增加了21%，合并的拉取请求（PR）数量增加了98%。PR审查时间增加了91%。每位开发者的错误数量上升了9%。平均PR规模膨胀了154%。瓶颈并未消失，而是向上游迁移至代码审查环节——这正是所有资深判断力集中之处。据传闻，我们已看到多个知名开源项目直接禁止AI生成的PR。我并不怪他们，但我也认为这种状况无法永远持续下去。低质量AI生成内容的激增，目前对开源社区构成了重大挑战。

DX此次发布的报告基于约20,000名开发者的调研，该报告发布于去年第三季度，因此是在AI编码工具质量近期显著提升之前。报告显示，AI工具的采用率更倾向于资历较浅的工程师，即初级工程师。尽管高级工程师的AI工具使用率最低，但那些每天使用AI的高级工程师反而节省了最多的时间。你可能立刻会感到困惑：这和我之前提到的METR研究结果似乎存在矛盾？DX调研了20,000名开发者，发现高级工程师报告节省的时间最多；而METR在受控环境下观察了16名经验丰富的开发者，发现AI使他们工作效率降低了19%，而他们自己却认为效率提升了20%。这两项研究结果可以同时成立，而这一事实本身就是一个真正的难题。如果我们连工具是否真正帮助了开发者都无法衡量，又如何判断使用这些工具的人是否在学习成长？

METR研究的对象是那些对代码库非常熟悉的资深开发者。这些开发者的技能组合已经高度适配他们所处的代码库。而DX研究的数据覆盖了开发者整个工作周内更广泛的场景：从全新的项目、陌生的代码库、模板代码到文档编写等各类任务。AI确实在这些工作中节省了时间，其中很多都是METR自身时间跨度研究显示AI擅长处理的短小且明确的任务。虽然METR引人注目的RCT报告聚焦于AI帮助最小的极端案例——即在熟悉领域处理复杂代码库的专家，但如果跳出这个极端场景，我们会发现一个规律：AI对已有技能的开发者帮助最大，而对新手则可能产生缺乏理解的输出。那些最需要刻意练习的人，反而最可能跳过这个过程。这或许并不令人意外。

Anthropic的工程师们实时描述了这一现象。一位高级工程师表示，他们主要在明确知道答案或至少能模糊判断结果形态时使用AI。他指出自己通过传统方式艰苦学习软件工程，才培养出这种能力。如果他职业生涯更早阶段，培养这些能力需要刻意努力，以避免盲目接受模型输出。另一位Anthropic的高级工程师将AI输出描述为"以危险方式表现出的高智商"，这种输出可能类似于一位非常有才华的初级工程师提出的方案，只有拥有深厚经验的人才能识别其中的问题。Anthropic的工程师报告称，他们向Claude提出的问题有80%到90%原本会问同事。一位高级工程师表示，现在初级工程师很少向他们请教问题，这令人感到遗憾。尽管如此，他们的问题确实得到了更有效、更礼貌的解答。

对于长期从事该领域的人来说，最令人惊讶的可能是资深工程师实际上喜欢与人合作，当同事离开时他们会感到失落。来自人际互动的偶然学习——通过与导师一起调试系统来理解其运作方式——在AI直接给出答案而跳过探索过程时被绕过了。

第四幕 - 案例研究

我向你们展示了很多图表，但我认为最近发生的问题为我们提供了一个非常优雅的案例研究，说明事情出了什么问题，即亚马逊的事故。谁听说过亚马逊目前发生的事情？是的，这很有趣。2025年12月中旬，AWS工程师允许亚马逊的Kiro AI编码工具对AWS Cost Explorer进行更改。这个AI代理被授予与人类工程师相当的操作员级权限，它认为最佳方法是删除并重新创建整个环境，而不是进行有针对性的更改。AWS花了13个小时在一个中国区域中恢复Cost Explorer。亚马逊将其归咎于用户错误，具体来说，是访问控制配置错误。后来有四个消息来源告诉《金融时报》，Kiro自主做出了这个决定。人们希望，一个人类工程师会知道，删除并重新创建整个生产运营环境并不是对配置更改的合理回应。这种知识来自于目睹过事情出错，来自于经历过生产事故，来自于吸收了隐含的规则：在面向客户的生产环境中，不要清除状态。

AI拥有权限，但缺乏实战经验。有趣的是，随后亚马逊零售网站发生了一系列中断。3月5日大约六小时的中断期间，有超过22,000人报告了问题。《金融时报》和CNBC都报道了内部简报文件将生成式AI辅助的更改列为促成因素。随着一系列特征为高影响范围的事故趋势，生成式AI的使用方式尚无明确的最佳实践和安全措施。五天后，3月10日，副总裁戴夫·特雷德韦尔（Dave Treadwell）将通常可选的“本周门店技术”（TWiST）会议变为强制性。他的电子邮件似乎以“各位，你们可能已经知道，网站和相关基础设施的可用性最近一直不太好。”开头。多家新闻机构随后报道，亚马逊引入了新的审批要求。初级和中级工程师现在必须获得高级工程师对AI辅助的生产更改的批准。

就像那项METR研究一样，这个故事几乎传播到了世界各地的每个工程Slack频道，你们中的一些人可能已经见过。然而，有趣的是，在过去的几天里，亚马逊对此叙述提出了强烈反对。在一份公开声明中，他们表示《金融时报》的报道存在不准确之处。他们的说法是，最近的零售事故中，只有一个是与AI工具以任何方式相关的。该事故并非由AI编写的代码引起，而是由一名工程师遵循AI工具从过时的内部维基推断出的不准确建议导致的。其他中断是独立的、与AI无关的操作问题。没有为使用AI工具的工程师引入新的审批要求。亚马逊将涉及AI的事故归因于人为错误，而非AI故障。亚马逊表示，这些中断中的大多数与AI无关。也许他们是对的。我非常愿意相信他们。

仔细观察亚马逊确认的内容。一个AI工具读取了过时的内部维基页面，它从陈旧的文档中推断出建议，工程师遵循了这些建议，导致网站宕机。这不是关于AI编写坏代码的故事，而是关于上下文的故事。AI无法区分当前维基页面和过时页面，无法判断其合成的建议是否仍适用于今天存在的系统。由于这些工具的特性，它对上下文窗口中的所有内容赋予了同等权重。遵循建议的工程师要么缺乏质疑的资历，要么信任了工具的自信，而我们都知道这些模型的自信程度往往远超其不确定性。

正如我在演讲开始时所说，问题从来不是编写代码本身，而是代码周围的环境。设计决策、系统上下文、对现状成因的积累理解。过时的维基页面是机构记忆缺失的体现，而遵循其建议却未加质疑的工程师则是判断力缺失的体现。这两种失败直接对应着缺失的环节：对AI的依赖取代了自身判断。上个月的一篇arXiv论文追踪了团队如何管理AI上下文。一个项目最终演变为26,000行编码化的上下文，指令数量远超实际代码量。与此同时，GitClear对2.11亿行代码的分析显示，AI工具的采用使代码量增加了10%，但质量指标却大幅下降，重构量减少60%。复制粘贴代码量上升48%，代码变更率激增44%。这些模型在编写代码时对现有系统的理解反而更少。

这正是提示工程（prompt engineering）与上下文工程（context engineering）之间的区别。前者关注如何提问，而后者关注模型开始工作时所看到的内容。那些正确理解这一点的团队，会将上下文视为基础设施，将其组织成类似入职文档的文件，构建带有逐步披露的记忆层次结构，并记录架构决策背后的推理过程。那26,000行的上下文架构并非负担，而是曾经存在于人们头脑中的机构知识的显性化表达，使AI也能使用这些知识。新工程师可以从其中学习，因为大多数工程并非绿地（greenfield），而是棕地（brownfield）或一些人开始称为黑地（blackfield）的系统。这些系统承载着高负载，所有人都同意其淘汰路径，但没人有时间执行。我亲身经历过这种场景。功能仍在不断被添加，因为业务无法等待。在黑地系统中，规格说明从未被编写过，或者即使编写过，也被数十年未记录的决策彻底使过时。

业务规则被编码在已超出所有理解者的条件中。AI代理可以阅读代码、测试和文档，但无法阅读生产环境。它们无法查看数年的请求模式，也无法理解哪些代码路径在代码本身未揭示的情况下承载着负载。它们无法区分一个死掉的边缘案例和一个仅占0.1%用户使用但一旦消失就会立即引发投诉的案例。

亚马逊过时的维基百科只是这个问题最显而易见的表现形式。每个代码库都充斥着未被记录的隐性知识，或者更糟糕的是，这些知识虽然曾经被记录过，却从未更新过。AI可以读取现有内容，但无法知道缺失或过时的部分。只有真正与系统共处过的人才能做到这一点。对于非全新系统而言，诚实的流程并不是先写规范、生成代码、运行测试。而是先观察生产环境，提取行为契约，编码系统测试，用这些内容作为规范，然后再引入代理。实现这一目标的工具已经存在，包括特征化测试、契约测试、流量影子分析和金丝雀分析。这些绝非新概念，它们是人工智能出现之前软件工程师就已经总结出的经验。AI对话需要继承这些方法，而不是假装通过更好的提示就能解决问题。无论你相信《金融时报》的版本还是亚马逊的版本，结构性问题的本质是相同的。

AWS Kiro事件中出现的“删除并重新创建”操作，是当AI代理拥有权限却缺乏判断力时会发生的情况。这种判断力来自于多年的生产经验。已确认的零售事件和过时的维基百科，是当上下文未被精心管理时会发生的问题。上下文管理正是缺失环节本应构建的机构知识。争议本身揭示了组织如何抗拒将这些问题视为结构性问题。亚马逊将其归咎于用户错误和常规操作审查。在工程领域，根据过时文档中的错误AI建议行事，绝不是一次性的失误。这是一套模式，会在AI工具部署到存在机构记忆空白的系统时反复出现，而几乎所有大型企业系统都存在这种空白。问题的关键不在于亚马逊的宕机是否由AI造成，而在于当AI工具被部署到那些所需上下文（生产知识、机构记忆、对现状成因的理解）都储存在那些从未真正做过AI现在处理的工作的人头脑中的环境中时，这些上下文又从何而来？当那些本应构建这些上下文的人一开始就从未做过相关工作时，这些上下文又从何而来？

第五幕 - 注意空白

我不会试图给出部分答案。作为整个行业，我们正面临一个根本性的结构性问题。梯子缺少了横档。当然，有趣的是，我们以前就曾经历过类似的情况。在20世纪80年代，家用电脑革命培养了一代通过实践学习的工程师，也就是我们这代人。我们是在BBC Micro、Commodore 64、ZX Spectrum、Trash-80等机器上成长起来的，这些机器启动时会显示一个基本提示符或CPM（如果你足够幸运的话）。孩子们编写游戏、工具、实验，大多是垃圾代码，但我们从中学习。到了2000年代初，计算机变成了封闭的设备。台式机启动进入Windows，而不是提示符。游戏通过磁盘或互联网下载，它们肯定不再附带源代码。Xbox在大多数家庭中取代了BBC Micro。孩子们在家里的卧室编写游戏或应用程序的能力，已无法与专业软件公司出品的相媲美。

这在20世纪80年代曾频繁发生。当时许多像我这样的孩子购买的磁带游戏，都是其他孩子在卧室里编写完成的。这种现象如今已不复存在。到了2000年代中期，计算机科学系开始注意到，新入学的学生在进入大学前从未编写过任何代码。他们一生都在使用计算机，却从未真正编程过，也不了解计算机的工作原理。这在学术界和工业界引发了大规模恐慌。为解决这一问题，出现了大量相关举措。其中最引人注目的就是Raspberry Pi。Raspberry Pi的推出是明确的回应，旨在重现可接触的动手实践。问题并非"我们需要一台廉价计算机"，而是"如何让孩子们拥有可以完全掌控的机器，即使损坏也无妨？"这台机器需要能启动到提示符界面，并配备GPIO引脚，让他们能够触碰物理世界。

这一举措取得了成功。数百万台设备问世，让整整一代人重新接触动手实践。这并非解决该问题的唯一方案，但却是最显著的解决方案之一。物理计算，比如让LED灯闪烁，成为了新时代的"编写自己的视频游戏"。尤其在2010年代中期，至少在一段时间内，大学生甚至年轻成年人可以在自己的卧室或宿舍里构建或原型设计物联网设备，其水平几乎可以与我们这些专业人士相媲美。这一解决方案的诞生经历了数年的思考，而它的成功正是因为诊断准确。

当前的人工智能革命正是同样的动态，只不过这次发生在专业人士层面，而非孩子们进入大学之前。过去支撑工程团队的基础工作，如调试、模板代码、胶合代码、文档编写等，现在在初级工程师看到之前就已经完成。Anthropic的内部数据量化了工程工作的新形态。工程师报告称，他们现在有59%的日常工作使用Claude，较一年前的28%显著增加，自报的生产力提升了50%（但请注意我之前提到的研究）。超过一半的工程师表示，他们只能将约20%的工作量完全委托给AI。有工程师估计，他们的角色已从70%的代码编写转变为70%的代码审查与修订。去年2月至8月间，Claude Code的自主操作次数从9.8次翻倍至21.2次，而每份文档的人工操作次数则从6.2次降至4.1次。剩余的工作日益偏向监督、架构设计和需要判断力的领域。

现在有证据表明，这条管道不仅未能培养判断力，甚至未能雇佣那些本可以构建它的人。本月月初，Anthropic 发布了自己的劳动力市场分析报告《人工智能对劳动力市场的影响：一种新度量及初步证据》。该论文引入了一种名为“观察到的暴露度”（observed exposure）的新度量指标，该指标结合了理论上的大语言模型（LLM）能力与 Claude 实际使用数据，并更强调自动化和工作相关用途的权重。这份报告内容引人深思。计算机程序员是暴露度最高的职业，达到 74.5%，这意味着我们程序员日常任务中四分之三现在在现实世界的专业场景中出现了显著的自动化应用。在另一端，30%的劳动者没有任何覆盖，包括厨师、机械师、救生员和酒保。我父母曾告诫我不要成为救生员。至少目前，物理世界仍未受到冲击。尽管我不确定，但若能在 20 世纪 90 年代末互联网泡沫初期的热潮中发表评论，我可能会预测到 Uber 的出现。考虑到互联网和 iPhone 确实彻底改变了世界，这对出租车司机的影响是显而易见的。

人工智能距离理论上的能力仍有很大差距。大语言模型（LLM）理论上能够实现的功能与实际应用场景之间仍存在显著鸿沟。计算机和数学相关职业的理论暴露度高达 94%，但实际使用覆盖率仅为 33%。在所有职业类别中，实际使用（红色区域）的规模都远小于理论能力（蓝色区域）。从演讲开始时的精确测量来看，这一差距相对温和。美国劳工统计局（BLS）预测，到 2034 年，暴露度越高的职业增长幅度越小。人工智能任务覆盖率每增加 10 个百分点，政府的增长预测就会下降 0.6 个百分点。劳动力市场分析已经将岗位替代纳入了考量。然而，目前高暴露度劳动者并未出现系统性失业。自 ChatGPT 发布以来，人工智能相关职业的失业率并未偏离基准线。这一点非常重要。

天空并未坠落。目前，那些预测末日的人是错误的。在暴露度较高的职业中，年轻员工的招聘速度已经放缓。从 2024 年开始，人工智能相关职业中 22 至 25 岁年轻人的新职位统计数据明显低于未暴露职业。平均估计显示，与 ChatGPT 问世前的水平相比，暴露职业的职位寻找率下降了 14%，而非广告数量减少。25 岁以上劳动者的就业机会并未减少。这仅针对刚进入行业的初级开发人员。这一结果在统计学上几乎不显著，但它与另一份基于 ADP 工资单数据的报告独立发现相呼应。该调查显示，22 至 25 岁劳动者在暴露职业中的就业率下降了 6% 至 16%，同样主要由招聘放缓而非离职率上升驱动。人们并没有被解雇，只是根本就没有被雇佣。这是在劳动力市场实时数据中体现的“缺失的阶梯”理论。

梯子的横档不仅失去了其教育功能，工作本身也在萎缩。企业并没有解雇有经验的员工，而是不再招聘新一代的劳动力。人才管道在入口处被切断，而非出口处。再次由Anthropic发布这一发现。这家开发Claude的公司正在记录证据，证明Claude的采用与最易受冲击职业中年轻员工招聘减少存在相关性。同一家公司发布的三项研究显示：AI阻碍技能形成、AI将工作转化为监督，现在AI又在初级岗位招聘上放慢了速度。无论你对这些情绪化表述持什么看法，他们表现出的学术诚实度都令人印象深刻。

所有来源，包括Anthropic自己的内部研究，都对此达成一致。该组织正竞相采用AI编码工具，而这些工具同时正在破坏培养能够监督这些工具的人才的管道。能够为AI构建良好上下文的人，是那些通过多年实践在脑海中形成上下文的人。培养这些人的管道正在断裂。如果你期待我在这里给出一个答案，我真的很抱歉要让你失望，因为我没有答案。目前没有简单的答案，因为我现在还没有一个能完美契合AI形状的Raspberry Pi形状的零件。在找到答案之前，我们仍有一些事情可以做。建立结构化的学习路径，有意识地轮岗从事基础工作，即使AI能更快完成，比如医学住院医师培训。你必须做这些琐碎的工作，因为这是学习的过程，而不是因为效率。

在允许AI协助之前，必须确保理解。这成本高昂，大多数公司不会这么做。那些会这么做的人，十年后将是仍保留高级开发人员的公司，因为其余的我们那时都将退休。医学医生之所以接受这样的训练是有原因的。衡量理解而非速度。你能解释代码的作用吗？你能不借助AI进行调试吗？如果这个功能失败会发生什么？结对编程是一种评估方式。观察他们的思维方式，而非他们产出的内容。将上下文视为基础设施。那些正确使用AI的团队，将编码后的上下文视为教学文档，而非配置文件。最好的文档读起来就像给一位已经掌握编程但不了解你代码库的高级工程师的入职指南。

我们已进入以文档为核心的编程时代。我发现这颇具讽刺意味，因为大多数开发者最讨厌的部分如今成了整个工作内容。作为一名前文档人员，我对此感到非常高兴。除此之外，我们需要建立诚实的预期。告诉初级开发者AI只是一个工具，而非老师。用它来跳过理解过程，相当于在透支你的未来。十年后真正有价值的人，是那些理解系统的人，而非擅长提示词的人。回到最初的METR研究，并基于当前的倍增速度进行大胆推测，到2027年AI代理将完成相当于一个完整工作日的任务，到2029年将完成相当于一个月的工作量。请注意，这需要谨慎对待，因为个人并不相信我们真的会达到这个程度。即使摩尔定律最终也会失效。到那时，中间的横档不仅消失，整个梯子正在被重建在不同的墙面上。

如果10位面包师每月生产1000条面包，而新烤箱让其中5位能够继续完成相同的工作，那么要么裁员，要么生产更多面包。Anthropic的数据提供了一种可能的出路：27%的Claude辅助工作来自那些在没有AI的情况下不会被完成的任务。新的实验、令人愉悦的工具、探索性工作，并不是让面包烤得更快，而是烤出以前不值得烤的东西。编写代码是一个巨大的瓶颈，曾经是巨大的瓶颈。软件最初是公司为自身用途定制开发的，当需求超过可用供应时，它才成为大规模生产的商品。整个SaaS市场建立在短缺的基础上，开发者短缺，为每个问题定制完美解决方案所需的时间短缺。相反，我们只能依赖电子表格和为大多数情况设计的网络应用。

我来举个个人例子。过去几个月，我一直在构建一种编程语言Vera，它专为AI生成的代码而设计，是一种让机器能够编写代码的语言。如果没有AI工具，这正是我根本不会考虑尝试的项目。一个人单独构建编译器、类型系统、测试套件、一致性框架，过去需要一个村庄的人力。历史上，新技术意味着更高的生产率，而不是减少工作机会。目前，劳动力市场数据表明城市正在选择更少的面包师。亚马逊在10月裁员14000名企业员工，1月又裁员16000名。Anthropic自己的观察数据表明，BLS预测大多数AI相关职业的增长将更弱。问题不是是否采用AI。这是一个已关闭的问题。我们将会采用AI。如果你认为你或你的公司不会采用，那么在12个月后，你将没有工作或公司。

真正的问题是，我们如何培养工程师，培养那些能够监督他们从未学过的事情的人？如果我们不能解决这个问题，10年后没有人将拥有公司，因为梯子不仅缺少台阶，还缺少最初创造建造梯子的人的机制。

问答环节

参与者1：我注意到你的演讲内容很大程度上依赖AI生成的内容。根据你自己的估计，你节省了多少时间，效率提升了多少？我还想问，在效果方面，你认为它对理解你的内容有多大帮助？

Alasdair Allan：对我来说，最耗时的事情一直是创建有趣的幻灯片来填满幻灯片。Midjourney对我来说是个救星，它至少减少了我制作演示文稿20%的时间。这就是效率提升的程度。这张幻灯片中有大量数据。是的，我用AI找到了所有这些数据。其实并非如此。很多数据出现在我的信息流中，我阅读了它们，并将它们输入AI以尝试综合这些数据。你必须相信，我今天提到的每一个数字我都逐一核对过。你必须相信，我查阅了每一个引用并确保它们确实存在。这是因为我在行业中有25到30年的痛苦经验。是的，AI可能让演讲制作更快了。它让找到来源、综合这些来源并看到它们如何结合变得更容易。但演讲内容本身仍然是我写的。我认为这证明了整个演讲的论点。

查看更多带文字稿的演讲

录制于：

2026年10月30日

由

/

• Alasdair Allan

#### 相关赞助商

• 自主代理AI的威胁：为什么你的Java补丁策略已不再足够

#### 相关赞助商

了解Azul如何帮助Java团队降低JVM漏洞风险，增强应用安全性，并为自主代理AI做好Java环境准备。发现如何在保持性能和可靠性的同时，实施保障Java工作负载的实际策略。了解更多。

#### 本内容属于“文化与方法”主题

##### 相关主题：

• 开发
• 架构与设计
• 文化与方法
• 人工智能、机器学习与数据工程
• 上下文工程
• AI编码
• Claude
• AI开发
• Anthropic
• 代码生成
• QCon伦敦2026
• 大型语言模型
• QCon软件开发大会
• 领导力
• 演讲实录
• 人工智能
• 职业发展
• 代码审查
• 生产力
• 敏捷开发
• InfoQ
• 相关编辑内容
• InfoQ热门文章
• Google使用Gemini 4 Argon优化其20万行Python代码库的夜间开发
• Cloudflare通过优化一致性哈希技术回收100TB内存
• 自主代理工具链的演变：从链式到图式再到代码
• Anthropic如何为AI驱动开发重新设计源代码控制
• AGNTCon + MCPCon 2026：自主代理AI基础新增四个项目，MCP转向安全领域
• 人工智能、机器学习与数据工程
• InfoQ趋势报告2026