AI提效反增疲惫焦虑

来源：互联网 2026-07-30 06:21:09

AI资讯合集

AI在提升开发效率的同时，也带来了新的疲惫与焦虑。开发者需处理更多任务，频繁切换上下文，导致决策疲劳。工作重心从创造性编码转向对AI产出的持续审查，其不确定性和潜在隐患加剧了精神消耗。应对策略包括设定使用边界、接受不完美结果、聚焦关键审查，并区分趋势与跟风，核心在于有

AI开发效率背后的“被掏空感”：技术从业者的新挑战

近期，Siddhant Khare一篇关于AI的思考引发广泛讨论。他指出，在深度使用AI多年后，尽管产出效率大幅提升，却体验到一种前所未有的“被掏空感”。上个季度，他编写的代码量超过职业生涯任何时期，但疲惫感也达到顶峰。这或许是许多技术从业者正在经历的共鸣。

效率飞跃与新型疲惫模式

AI辅助开发最直观的益处是效率的飞跃。无论是撰写设计文档、搭建项目脚手架、编写测试用例，还是研究陌生API，以往需数日完成的任务，现在可能压缩至几小时。然而，效率提升并未减轻工作负担，反而催生了新的疲惫模式。

长期稳定更新的攒劲资源： >>>点此立即查看<<<

过去，开发者可能一整天专注攻克一个设计难题。节奏虽慢，但负担可控，思考可渗透到散步、沐浴等碎片时间中，本质上是围绕单一问题的深度专注。

如今，一天内可能要处理六个问题，每个都“用AI只需一小时”。但人类大脑在六次高强度的上下文切换中，承受着巨大的精神消耗。AI不会累，但人会。

开发者角色的悄然转变

这背后是开发者角色定位的转变。

部分开发者享受“创造”的完整流程：思考问题 → 编写代码 → 测试验证 → 部署上线。
而AI则将工作更多地推向“审稿人”或“质检员”模式：构思提示词 → 等待输出 → 阅读结果 → 判断正确性、安全性、架构符合度 → 修补问题 → 再次提示 → 循环往复。

这是两种本质不同的工作类型。创造行为更容易让人进入心流状态，并获得可量化的成就感；而持续的评审与决策，则极易导致“决策疲劳”。作者曾提到，在一次使用AI开发新微服务的三天后，他发现自己已不想再做任何决策。

整个项目开发下来，他的主要工作并非编写代码，而是评判代码。一天需要做出成百上千个微小判断。更严峻的挑战在于：AI生成的代码，往往需要比人类代码更谨慎的审查。

为何AI代码需要更严苛的审查？

阅读同事的代码，你或许了解其编码习惯和思维盲区，能够进行有选择的信任。但AI生成的代码，看起来总是那么自信、能编译、甚至能通过基础测试，却可能在某个意想不到的角落埋下隐患。这迫使你不得不对每一行都保持怀疑态度，而阅读一段自己既没写过、也不理解其背后逻辑与约定的代码，是极其耗费心神的。

有时，AI挖的坑确实令人防不胜防。作者的经历很有代表性：即便在项目中设定了详细的规则和规范，AI仍可能自行其是。例如，它可能会在任务中途突然“自我主张”：“虽然规则要求XXX，但我认为不能这样做，所以我决定采用YYY……”

因此，正如作者指出的，正因为你无法规模化地彻底审查所有AI产出，所以更需要依赖最小权限原则、作用域限制、审计日志等机制来加以约束。开发者必须持续不断地对这些细颗粒度的输出保持警惕并进行审核。

确定性的打破与背景噪音式压力

传统工程训练建立在确定性之上：相同的输入，理应得到相同的输出。这是调试与逻辑推理的基础。然而，AI打破了这份契约。作者举了一个例子：

周一，某个提示词（prompt）表现完美，生成了清晰的结构。
周二，将完全相同的提示词用于相似场景，输出风格却变了，甚至引入了你并未要求的依赖。而且，你无法追溯原因，因为没有“模型今天为何选择另一条路径”的调用堆栈可供查看。

这种不确定性带来的并非戏剧性的恐惧，而是一种“持续的背景噪音式压力”。你无法完全信任其输出，因此也无法真正放松，每一次交互都必须保持警觉。问题的关键在于，你的审核速度必须跟上它的产出速度。

对此，作者尝试过提示词版本控制、复杂的系统指令（system message）、模板化等方法，但这些都只能缓解，无法根除问题。根本原因在于：你是在与一个概率系统协作，而你的大脑却习惯于确定性的系统。这种错配会造成长期的认知消耗。

AI工具迭代带来的焦虑

同时，AI本身也成了焦虑的来源之一。“行业速度”带来了AI工具的压迫感。短短几个月内，各种编码智能体（coding agent）、命令行工具、子智能体（sub-agent）、协议、框架、注册中心、收购与升级新闻层出不穷。社交媒体还在不断渲染“不跟上就被淘汰”的紧迫感。作者本人也深陷其中：

周六刚搭好一个新工具，周日才理顺，周三就看到宣称“更强大”的工具出现。
每次迁移可能只换来“也许5%”的效率提升，而且这种提升往往无法严谨衡量。
大量类别等待“入坑”：助手、界面、智能体框架、多智能体编排、MCP服务器、上下文管理、提示词库、集群架构、技能市场……往往一个东西还没深入研究，它就似乎已经过时了。

更令人沮丧的是“知识贬值”或“工作沉没”：早期花费两周时间精心打磨的提示工程模板，几个月后可能因为模型更新或最佳实践变化，反而变得低效甚至更差。

后来，作者调整了策略，不再追逐每一个新工具，而是下沉到更耐久的基础设施层（如上下文管理效率、授权机制、审计体系、运行时安全等）。因为工具会变，但核心问题不变。同时，他将“了解趋势”与“被趋势驱动立刻采用”区分开来。

调试提示词与调试代码的本质区别

AI开发中另一个独特的问题是：你常常在调试提示词（prompt），而非调试代码。这两者有本质区别：

第一次输出，正确率70%，于是你修改提示词；
第二次，正确率提升到75%，但破坏了第一版中正确的部分；
第三次，正确率80%，但代码结构又变了；
第四次，你已经花了45分钟，提示词却让项目质量掉回70%。

因此，作者给自己定下一条规则：最多尝试三次。如果三次迭代后仍不能达到“70%可用”的标准，就转而自己动手编写。

使用AI最忌讳完美主义。许多工程师天性追求可预期、整洁、可靠，但AI的输出永远是“差不多”。因此，最容易在AI时代感到折磨的，往往是那些标准最高、对细节最敏感的优秀工程师。AI时代更需要一种能力：快速从不完美的产出中榨取价值，而不是沉迷于将其打磨到完美。

应对AI疲劳的具体策略

最后，作者也提供了一些应对AI疲劳的具体策略：

为AI会话设定时间盒（Time-box）：不再无限制地使用AI。为每个任务设定一个计时器（例如30分钟），时间一到，就基于现有成果进行交付，或切换回手动编码。这能有效抑制陷入无休止的提示词调试循环和完美主义陷阱。
接受AI的“70%”：将“可用阈值”设定在70%。停止追求完美输出，达到70%可用性就收工，剩余部分自己补充。这是减少挫败感最有效的杠杆。
对技术炒作周期（Hype Cycle）采取更策略化的态度：保持信息获取，但不在新工具发布一周内就急于迁移。选择一个主力助手深度掌握。新工具需要“以月为单位证明其价值”，而不是“以天为单位”。
记录AI何时帮忙、何时帮倒忙：这有助于你理性判断，在哪些业务环节使用AI真正有效。
接受“审不完”，聚焦关键审查：现实是，如果AI生成了大量代码，你不可能以同等强度逐行审查。因此，需要将审查精力集中在安全边界、数据处理、错误路径等关键核心处，允许非关键路径的代码存在一定的粗糙度。