为什么AI辅助开发比想象中更令人疲惫

AI辅助开发的承诺是让开发者的工作变得更轻松。某种程度上确实如此，但许多开发者却在经历后LLM时代的倦怠和疲惫。这在一定程度上源于组织不切实际的期望——它们被AI炒作和错失恐惧症冲昏了头脑。然而，还有一个更深层的问题，根植于人机交互（HCI）心理学。

从HCI视角看用户行为，我们会想到“模式”。模式不仅是界面的状态，更是用户的状态。想象一下使用项目管理应用的人：浏览看板时处于阅读模式，创建任务时处于输入模式，审查队友任务时处于评估模式。同一应用，同一屏幕，却对应三种不同的认知状态。每种状态动用不同的心智资源，在不同模式间切换正是让工作感觉多样而不是单调的原因。

软件开发历来也存在这类模式：规划、实施和集成。规划是最耗认知的模式，需要同时考虑多个因素、权衡取舍并做出影响后续所有步骤的决策。实施是将解决方案变为现实的过程，写代码、调试、测试——它提供了一个认知重置的机会。在规划的压力之后，投入构建的流程中，通过频繁的小成功积累动力。集成则是质量控制，包括代码审查和合并，它提供了认知反馈和自我反思的空间。

AI辅助开发不仅改变了开发者在每种模式上花费的时间比例，还改变了模式本身的性质和压力。规划：由于AI能在几分钟内实现功能，组织期望更多产出，导致规划量激增。开发者被迫以前所未有的速度进行最耗认知的工作，无法通过模式转换得到休息。实施：构建的心流被压缩为“提示、等待、审查”。提示本身是一种规划，等待是死时间，审查是集成。真正的构建被AI取代，留下的只是监督，这无法提供同样的恢复性收益。集成：审查AI代码失去了反思性，因为那不是你的工作。从他人审查中学习的机会也减少了，因为AI代码没有意图。集成变成了审计而非对话，开发者花在集成上的时间比以往更多，造成了瓶颈压力。

最终，开发者剩下大约一个半模式：规划和集成都被放大和扭曲，实施被自动化压缩。这种“单一模式倦怠”表现为持续在最高要求的模式下工作，缺乏恢复和反思。长期影响有三方面：技能（通过构建学习的机会减少）、动力（自然工作节奏的破坏导致疲劳和冷漠）和质量（验证没有构建背景变得更困难且不可靠，容易遗漏问题）。

我们需要有意识地重建认知基础设施。也许开发者应该为自己保留某些实施工作，不是因为AI做不了，而是需要认知收益。团队需要重新思考健康的工作流程，保护实施时间，并将AI代码积压视为需要关注的信号。关键在于承认问题：如果你感觉工作更累了，即使效率更高，这并非想象。AI辅助开发可以比我们以为的更令人疲惫。通过教育、创新和指导，我们可以建立更好的基础设施，但首先行业必须正视这个问题。