人工智能生产力陷阱：为什么你最优秀的工程师变得越来越慢

我们都听过这个提案。到现在，这几乎成了每个科技会议的背景噪音：AI编码已经解决。我们被告知大型语言模型（LLM）很快将编写80%的代码，剩下人类工程师仅需监督输出。

对于CIO来说，这种叙事颇具吸引力。它承诺大幅降低软件生产成本，同时提升工程速度。这表明编写代码的瓶颈即将消失。

但作为一个每天都致力于构建关键任务金融基础设施和自主代理平台的人，我必须带来坏消息：事情并没有按计划发展。至少，对于你们最优秀的工程师来说是这样。

将AI副驾驶部署到经验丰富的工程师工作流程中，并未带来宣传册中承诺的无摩擦加速效果。相反，我看到的是生产力陷阱的出现——一种对速度的隐藏税，不成比例地影响了你最宝贵的技术人才。

我说这些并不是因为我对这项技术持怀疑态度。我是一名人工智能乐观主义者，职业是构建人工智能系统。但我们需要对数据保持诚实。对于复杂且高风险的工程任务，AI工具目前正让经验丰富的开发者变慢。

一、速度的隐性税

生成式人工智能热潮的最初几年，我们靠着氛围运作。我们有轶事证据和供应商支持的研究声称生产力大幅提升。对于那些做简单任务的初级开发者来说，这些进步是真实的。如果你只需要一个基础的React组件来登录按钮，使用AI简直是奇迹。

但我们在2025年年中迎来了现实的警示。METR（模型评估与威胁研究）进行的一项随机对照试验分析了对高级工程人才的影响。与以往用玩具问题的研究不同，这项研究观察了经验丰富的开发者在自己成熟的代码库中工作——那种混乱、复杂的遗留系统，实际上是驱动业务的动力。

结果非常明显。当有经验的开发者使用人工智能工具完成现实世界的维护任务时，他们比没有AI工具时所花的时间长了19%。

一个能瞬间生成代码的工具，怎么会导致时间净损失？

归根结底，我称之为速度错觉。在这项研究中，开发者感觉更快。他们预测AI会为他们节省大量时间。即使完成后——而且客观上记录显示速度较慢——他们仍然认为AI是节省时间的。

AI会给你带来多巴胺刺激。屏幕上以超人速度显示文字，空白页的问题也随之消失。但工程师的角色已经从创作者转变为审稿人，这正是陷阱关闭的地方。

二、几乎正确的死亡谷

问题的核心在于，人工智能非常擅长几乎正确。

根据2025年Stack Overflow开发者调查，开发者最大的挫败感是面对看似正确但略有偏差的AI解决方案。近一半的开发者明确表示，调试AI生成的代码比自己编写代码花费更多时间。

在软件工程中，明显损坏的代码是可以接受的。编译器会尖叫，应用启动时崩溃，红色波浪线出现。你立刻就知道那是错的。

几乎正确的代码是阴险的。它会编译。它能运行。它通过了基础单元测试。但它存在一些微妙的逻辑缺陷或边缘性失败，这些并不立即显现。

当我从零开始写代码时，我是在做前瞻工程。我构建了一个逻辑的心理模型。我知道为什么每个变量都会存在。如果出现bug，我可以自己追溯到错误的起点。

当我使用人工智能时，我被迫进行逆向工程。我收到的代码块是我没写的。我必须阅读它，解读模型的意图，然后将该意图与系统需求对应。

我在为企业物流构建财务系统时亲眼见过这一点。计算净收入所需的逻辑非常复杂，并且有定制的业务规则。如果我让大型语言模型生成计费代码，它会给我数学上完美的结果。它会正确地将各项加总。

但这不可避免地忽略了一个关键且未明说的背景——也许只有当承运人属于特定专属项目时，空里程的计费率才会有所不同。在100行AI生成的代码中发现这个缺失，比自己写100行难得多。我花在揭穿AI可能幻觉上的时间，比单纯做工作还多。

三、上下文腐烂与流态

还有上下文切换的代价。深度工作，或称心流状态，是高层工程的本质。将分布式系统的上下文加载到大脑中需要时间。

目前基于聊天的AI工具鼓励了分散的工作流程。你停止编码，提示机器人，等待，复审，拒绝，再重新提示。流畅感消失了。

更糟的是，当你试图通过给AI添加更多代码片段来修复错误时，会出现上下文腐烂。模型被无关细节分心，开始生成臃肿、偏离目标的代码。高级工程师最终成了一个被美化的编辑，辅导一个非常快速、非常自信的实习生，而实习生不了解公司的历史。

四、改变战术

那么，如果当前的副驾驶模式是针对你最优秀人才的陷阱，我们该怎么办？我们当然不会禁止人工智能。这就像因为你有时按错按钮就封禁计算器一样。

我们需要从AI辅助编码转向AI驱动的架构。目标不是让你的高级工程师打字更快，而是让他们能够构建足够稳健的系统，能够应对AI生成代码的混乱。

五、从评论家到建筑师

流行的80/20比例——即AI完成80%的工作，人类完成20%的工作——具有误导性。这暗示人性只是最后的点缀。实际上，这20%就是价值的100%。关键在于架构、安全模型和业务逻辑。

为了摆脱生产力陷阱，你需要指示你的工程领导完全专注于这20%的人。

我自己的工作已经从编写特征转向定义我们代码库的物理原理。我在Uber时花了大量时间迁移系统，采用严格的类型和模式。

通过严格执行规则，我实际上创造了一个护栏系统。如果我们在那个环境中使用人工智能，人工智能就被迫编写合规代码。如果它幻觉到不存在的场，编译器会立即拒绝它。

这就是战略转变。高级工程师的角色是为人工智能构建编译器。他们需要创建模式、类型系统和自动规则，来限制AI的行为。

这改变了“几乎正确的问题”。系统不需要我手动审核代码找出错误，而是如果代码不符合架构，系统会自动拒绝。我不再做评审，而是成为立法者。

六、如何引领变革

对于CIO来说，这需要改变管理策略。你不能只买光标订阅就指望速度和稳定性指标提升。

首先，你必须停止测量输出。你现在最危险的做法是用代码行数（LOC）或每天提交次数来衡量生产力。在人工智能的世界里，这些指标很容易纵，完全脱离了价值。

你需要衡量结果。如果一位高级工程师花一个月时间零写代码，却设计出一个能100%防止生产漏洞的模式，那是巨大的胜利。你必须奖励阻止工作，而不仅仅是完成工作。

其次，你需要投资于上下文引擎。AI缺乏上下文时会很吃力。你的高级工程师应该负责构建内部开发者平台（IDP），以结构化的方式展示你的代码库。一个干净、严格类型化的代码库是有效AI应用的前提。

最后，你需要重新定义你对高级工程师的期望。掌握语法的技能正在迅速下降。系统验证技能的价值正在飙升。

你需要的是讲解原理图、类型安全和架构的工程师。让他们自己构建限制AI的护栏，而不仅仅是和AI聊天。

人工智能生产力陷阱确实存在，但并非不可避免。这是用旧流程应用新技术的一个症状。前路严谨、建筑化且极具人性。它要求我们将设计和约束设置视为工程的真正核心。

由CXOUNION-CXO联盟（cxounion.cn）转载而成，来源于数智化转型网；编辑/翻译：CXOUNIONCXO联盟小O。

如需加入CXO UNION（CXO联盟）高管社群，请联系社群小伙伴哦~

免责声明: 本网站(http://www.cxounion.cn/)内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何责任。