生产力陷阱：为什么 AI 辅助工程正导致职业倦怠

软件工程领域对 AI 的承诺一直很简单：机器处理枯燥的部分，人类工作量减少。我们被告知 LLM 将把我们从样板代码和语法的繁琐工作中解放出来，让我们能够专注于高层架构和创造性问题的解决。

然而，整个行业呈现出的现实却大相径庭。许多工程师并没有因此减少工作，反而发现自己陷入了“末日编码”（doom-coding）的状态——一种高强度认知负荷与收益递减的循环，直接导致了职业倦怠。

随着我们以超音速的速度生成代码，我们发现 AI 辅助的生产力并非没有代价；它对我们的心理健康和职业满意度造成了显著的隐性成本。

生产力陷阱的数学逻辑

要理解为什么 AI 会导致倦怠，我们必须区分工作的 持续时间 与工作的 强度。

考虑两位工程师：一位手动编码，另一位委托给 AI。手动编码者可能需要四个小时来完成一项任务，但他们的认知努力是分散的。他们进行计划、输入、停顿思考并迭代。这是一场受控的马拉松。

AI 辅助工程师可能在两小时内完成同样的工作。从纸面上看，他们的生产力提高了 2 倍。然而，这两小时处于高强度的认知消耗状态：提示词工程、审查、引导和调试。

当 AI 辅助工程师在两小时后没有停止工作时，陷阱就闭合了。因为工作“感觉很轻松”（尽管在认知上非常耗竭），他们会立即转向下一个任务。在四个小时的时间窗口内，AI 辅助工程师执行的高强度工作量是手动编码者的两倍，从而导致快速的精疲力竭。

手艺精神的侵蚀

职业倦怠不仅仅关乎工作量；它还关乎工作的 性质。编程传统上是一个 计划 $\rightarrow$ 制作 $\rightarrow$ 结果 的循环。其中的“制作”阶段——编写代码的触感过程——通常是工作中最为沉思且最有成就感的环节。

AI 通过跳过制作阶段，直接从计划跳转到结果，从而破坏了这一过程。我们正在用工作中我们最厌倦的部分来取代我们热爱的一部分：审查他人（或某个智能体）的工作。这导致了几个关键问题：

1. 上下文与直觉的丧失

当智能体处理实现细节时，工程师就不再需要在大脑中构建项目的架构和边缘情况。正如一位社区成员所指出的：“编写代码很慢，但你能理解你构建了什么。审查 AI 代码很快，但你正在积累盲点。”

2. 被动思考的消亡

传统的编码允许进行无意识处理——即大脑在后台连接知识点的“淋浴思考”（shower thoughts）。AI 填补了这种沉默。通过提供即时的建议，LLM 将思考过程压缩成了一系列二元决策（同意或不同意），这往往导致非最优解，且后续必须重新进行重构。

3. 审查瓶颈

AI 可以在几秒钟内生成数千行代码，但人类的审查仍然是一个线性过程。这使得不成比例的风险和认知负荷转移到了资深工程师身上，他们现在必须充当大量平庸代码的监督者，而这些代码除了他们自己，没人能真正理解。

一场无声的职业转型

许多工程师在没有意识到自己选择了转行的情况下，正在经历职业身份的转变。角色正在从 创造者 演变为 监督者。

对某些人来说，这是一个“向食物链顶端移动”的机会，进入更高层级的产品和工程设计。而对其他人来说，这感觉像是剥夺了吸引他们从事这一职业的核心要素。如果编码的乐趣被剥夺，工作就变成了一种纯粹的质量控制行政练习，对于那些由手艺精神驱动的人来说，这在根本上是不可持续的。

可持续 AI 工作流的策略

为了避免倦怠，工程师必须有意识地远离“在每一刻都追求生产力最大化”的目标。以下是重建与 AI 建立可持续关系的一些实用方法：

重拾你的手艺

• 保护“手艺时间”： 专门划出特定时间或任务，禁止使用 AI。利用这些窗口重新连接到手动编码那份安静、愉悦的过程。
• 避免在个人兴趣项目中使用 AI： 将你的个人项目作为纯粹手艺精神的避风港，免受智能体速度的压力。
• 使用“询问”模式： 使用 LLM 进行导航和建议，而不是直接进行实现。让 AI 充当地图，但你仍是驾驶员。

优化工作流

• 计划更多，审查更少： 在生成任何一行代码之前，花更多时间在计划阶段，以确保逻辑严密。目标应该是通过更少的迭代次数获得有效的执行结果。

• 分解任务： 抵制一次性生成数百行代码的冲动。将任务分解可以减轻审查过程的心理负担，并防止你在 AI 的输出中“迷失”。

• 避免并行任务：： 生成的便捷性使得人们很容易诱惑去同时处理多个功能。这是一个会增加心理压力和技术债务的陷阱。

建立硬性边界

• 记录你的工时： 使用时间追踪工具，不是为了企业监控，而是为了你自己的理智。当时间到达工作日的结束时，请停止——即使你正处于某个功能的开发中。
• 进行适当的休息： 由于 AI 辅助工作是高强度的，你的大脑比手动编码时期需要更频繁且更深度的恢复期。

结语

AI 是现代工程领域的永久性特征，但那种认为我们都应该成为“10x 工程师”的市场营销叙事，其实是崩溃的导火索。目标不应是看我们能尽可能多地交付多少代码，实现多少功能，而应是确定如何利用这些工具来增强我们的工作，而不牺牲我们的福祉。

随着行业的发展，最成功的工程师不会是那些生成代码量最大的工程师，探索如何利用工具，但仍能保持好奇心、能量和真正享受构建过程的能力的人。