AI疲劳真实存在：工程师效率提升后为何更倦怠？行业深度探讨

你是否也曾满怀期待地拥抱AI，想着这下效率要起飞了：写代码更快、查资料更省事、思路也有人随时帮你梳理。但现实往往带着一丝讽刺——活儿确实干得更多了，人却感觉比以前更累。

这种“工具越强，疲惫感越甚”的状态，正在不少开发者身上悄然蔓延。它不像通宵加班那样显而易见，却更加隐蔽，也更难言说：明明生产力工具进化了，为什么反而停不下来？为什么总觉得脑子在超频运转，却很少获得真正的休息？

作为OpenFGA（CNCF孵化项目）的核心维护者之一、资深工程师Siddhant Khare，最近将这种感受写成了文章《AI疲劳正在发生，只是我们很少谈起》。他结合自己的切身体验，探讨了AI如何在“解放生产力”的同时，也悄然增加了工作的心理负荷。这篇文章很快登上Hacker News头条，引发了大量工程师的共鸣与讨论。

原文链接：https://siddhantkhare.com/writing/ai-fatigue-is-real

我在上个季度发布的代码量，超过了职业生涯中的任何一个季度。同时，我也比以往任何时候都更疲惫。这两件事之间，并非毫无关联。

我的日常工作就是构建AI Agent的基础设施。我开发了用于Agent授权的agentic-authz（https://github.com/Siddhant-K-code/agentic-authz），也开发了用于上下文去重的Distill（https://distill.siddhantkhare.com/），还发布了MCP服务器。我不是浅尝辄止的“玩票”工程师，而是深度参与其中——我所构建的工具，目标就是让其他工程师能将AI Agent真正运行在生产环境里。

但即便如此，我还是撞上了“南墙”。那种精疲力竭的感觉，远非更换工具或优化流程就能轻易解决。

如果你是一名每天都在使用AI的工程师，用它进行设计评审、写代码、查bug、编文档、做架构决策——并且隐约感觉：自从有了AI，自己反而更累了，那么这篇文章就是为你而写。

你并非在臆想，也并非不够努力。你正在经历的，是一种真实存在却被整个行业刻意忽视的状态。连一个全职做Agent基础设施的人都会被AI“榨干”，那么这件事，谁都有可能遇到。

我想坦诚地聊聊这件事。不是那种“AI太棒了，这是我的工作流”的胜利宣言，而是真实版本：晚上11点，你盯着屏幕，被一堆AI生成的代码包围，而你仍然得自己一行行审查。你开始怀疑，那个本该帮你省时间的工具，为什么反而吞噬了你的一整天。

那个没人提前告诉我们的悖论

曾有一段时间，真正让我感到困惑的是：AI确实能让单个任务变快，这一点毫不虚假。过去要花3个小时的事，现在45分钟就能搞定。无论是撰写设计文档、搭建新服务框架、编写测试用例，还是研究一个陌生的API，速度都得到了显著提升。

可问题在于，我的一天并没有因此变得轻松。恰恰相反，一切变得更难了。

原因其实很简单，但我花了数月才真正想明白：当每个任务所需的时间变少，你并不会因此做更少的事，而是会做更多的事。 你的工作能力似乎提高了，于是工作自然会随之增加，甚至超出预期。

你的经理看到你交付得更快，预期随之提高。你自己看到效率提升，对自己的要求也会悄然上调。于是，基准线被整体抬高了。

在AI出现之前，我可能会用一整天的时间去深度思考一个设计问题。先在纸上涂涂画画，洗澡时继续琢磨，出去走一圈，回来时思路逐渐清晰。节奏不快，但认知负担是可控的：一天，一个问题，深度且专注。

现在呢？一天之内，我可能要同时处理六个不同的问题。每一个都“只需要一小时，用AI就能搞定”。但对人类大脑而言，在六个问题之间频繁切换上下文，本身就是一笔极其昂贵的开销。AI不会因为切换任务而疲惫，但我会。

这正是悖论所在：AI降低了执行任务的成本，却抬高了协调、审查和决策的成本。而这些新增的成本，几乎全部落在了人身上。

你成了代码审查者，但你从没主动想过做这个岗位

在AI出现之前，我的工作是这样的：想清楚问题、写代码、测试、发布。我是创造者，是动手做事的人。这也是大多数工程师最初选择这份职业的原因——因为“构建”本身就令人着迷。

而在AI介入之后，我的工作流程逐渐变成了另一套模式：写提示词、等待、阅读输出、评估结果；判断代码对不对，安不安全，是否符合整体架构；修改不合适的部分，再次写提示词，然后重复这一切。我不再只是创造者，而是变成了审查者、裁判、质检员，站在一条永不停歇的流水线上。

这是两种截然不同的工作。创作会让人精力充沛，而不断地审查与评估却会持续消耗精力。心理学对此早有研究：生成型任务和评估型任务对人的影响截然不同。前者容易让人进入“心流”状态，后者则更容易带来决策疲劳。

我第一次明显意识到这一点，是在密集使用AI开发一个新微服务的那一周。到了周三，我已经无法做出哪怕是最简单的决定了：这个函数该叫什么名字？无所谓。这个配置文件放哪？也无所谓。我的大脑被塞满了——不是因为写了多少代码，而是因为整天都在对代码做判断。成百上千个细小的判断，日复一日。

更讽刺的是，AI生成的代码，反而比人写的代码更需要仔细审查。同事写的代码，我了解他们的习惯、优势和盲区，可以快速略过我信任的部分，把精力集中在可能出问题的地方。但面对AI，每一行都值得怀疑。 代码看起来似乎很可靠，能编译，甚至可能通过测试，但它也可能在某个极其隐蔽的角落埋下隐患，这些“雷”往往只会在生产环境、高负载下或凌晨三点时突然引爆。

于是你只能逐行阅读。而阅读那些并非出自你之手、由一个并不了解你代码库历史和团队约定的系统生成的代码，本身就是一项极其消耗心力的工作。

这也是为什么我一直认为，Agent的安全与授权如此重要。如果我们不可能审查AI产出的每一行代码——事实上，在规模化之后这根本做不到——那就必须在一开始就限制Agent能做什么：最小权限、作用域清晰的令牌、完整的审计记录。你越不用担心“AI会不会做出危险的事”，就越能把有限的认知资源，用在真正重要的工作上。这不仅是一个安全问题，更是一个人能否长期健康工作的问题。

不可预测性的问题

工程师从入行起接受的就是“确定性”训练：相同的输入，必然得到相同的输出。这是一种默认契约。正是这份契约，让调试成为可能，让我们能够对系统进行推理和把控。

而AI，打破了这份契约。

我曾有一个提示词，在周一表现得近乎完美，为一个API接口生成了结构清晰、逻辑严整的代码。周二，我用同样的提示词去写一个类似的接口，输出却变了：整体结构不同，错误处理方式也不同，甚至还多引入了一个我根本不需要的依赖项。

为什么会这样？没有原因。至少，我找不到任何可解释的理由。这里没有“为什么会这样”的堆栈信息，也不会有日志告诉你“这次采样走了B路径而不是A路径”，事情就这么发生了。

对于一个职业生涯建立在“只要出问题，我就能查清原因”这一信念之上的工程师来说，这种体验令人极度不安。不是那种戏剧化的恐慌，而是一种缓慢、持续、在背景里不断磨损人的焦虑。你永远无法完全信任输出，也永远无法真正放松。每一次交互，都需要高度警惕。

我试图对抗这种不确定性。我给提示词做版本控制，设计复杂的系统消息，制作各种模板。这些方法多少都有帮助，但都没能解决根本问题：你正在和一个概率系统协作，而你的大脑是为确定性系统而生的。这种错位，本身就是一种长期、低强度的压力源。

正是这种挫败感，促使我去构建Distill——一个面向LLM的确定性上下文去重工具。它不调用模型，不用embedding，也不依赖概率启发式，而是纯算法，在大约12毫秒内完成上下文清理。我希望至少在AI管道里，有一部分是我能够推理、调试并真正信任的东西。既然模型的输出注定是非确定的，那我至少要保证输入是干净、可预测的。

我接触过的工程师里，真正适应得最好的人，往往是那些已经与这种不确定性“和解”的人。他们把AI的输出当成一个聪明但不太靠谱的实习生交来的初稿，默认需要重写其中30%的内容，并在计划里为这一步留出时间。输出不对时，他们不会沮丧，因为他们从一开始就没指望它是“绝对正确的”，而只是希望它“有用”。这两者之间，差别很大。

被FOMO推着跑的跑步机

让我们先深呼吸一下，试着回顾最近这几个月发生了什么。

Claude Code先是上线了子agent，接着是skills，然后是Agent SDK，再到Claude Cowork；OpenAI推出了Codex CLI，紧接着又发布了GPT-5.3-Codex——一个“参与了自身代码编写”的模型；新的编程agent宣布支持后台模式，可以同时跑上百个自治会话；Google发布了Gemini CLI；GitHub加了MCP Registry；并购几乎每周都在发生；Amazon Q Developer迎来agent化升级；CrewAI、AutoGen、LangGraph、MetaGPT……随便选一个agent框架，每周都会冒出新的；Google推出A2A（Agent-to-Agent协议）来对标Anthropic的MCP；OpenAI发布了自家的Swarm框架；Kimi K2.5上线，号称用agent swarm架构同时编排100个并行agent；“氛围编程”成了流行词；OpenClaw推出技能市场，结果一周之内，研究人员就在ClawHub上发现了400多个恶意agent技能；而在这一切的某个间隙，LinkedIn上有人轻飘飘地丢下一句：“如果你在2026年还没用上带子agent编排的AI agent，那你已经被淘汰了。”

注意，这不是一年发生的事。只是短短几个月。而且，我还漏掉了不少。

我自己曾深陷其中。周末几乎都在评测新工具，刷每一条更新日志，看每一个演示视频，只因为害怕掉队，拼命想站在“最前沿”。

现实是什么样的？一个周六下午，我开始折腾一个新的AI编程工具；到周日，勉强搭出一个基础工作流；再到下周三，就有人出来说另一个工具“强得多”。焦虑随之而来。下个周末，我又在重新配置新的工具。旧的那个被丢在一旁，几乎再没打开过。一个编程助手换到下一个，再换下一个，最后又绕回最初那个。每一次迁移，都消耗掉一个周末，换来的也许只是根本无法量化的5%提升。

把这种循环乘以每一个类别——编程助手、聊天界面、agent框架、多agent编排平台、MCP server、上下文管理工具、提示词库、swarm架构、技能市场——你得到的，是一个永远在学新工具、却从未真正吃透任何一个的人。光是刷Hacker News首页，就足以让人感到信息过载：今天是「Show HN：自治研究swarm」，明天就是「Ask HN：AI swarm要怎么协作？」没人知道答案，但所有人都在继续造。

最糟糕的，其实是知识的快速贬值。

2025年初，我花了两周时间搭了一套相当复杂的prompt工程流程：精心设计的system prompt、few-shot示例、chain-of-thought模板，效果确实不错。三个月后，模型更新了，最佳实践变了，我的一半模板，效果甚至不如一句简单的指令。那两周时间，不是“投资”，而是直接消耗掉了。

MCP server也是一样。我做过五个定制server（Dev.to发布、Apple Notes集成、Python和TypeScript沙盒等等），后来协议演进，GitHub上线了MCP Registry，一夜之间出现了成千上万个现成方案。我的部分工作，瞬间变得多余。

Agent框架的动荡更是夸张。我亲眼见过一些团队在一年之内，从LangChain换到CrewAI，再到AutoGen，最后干脆自己写编排层。每一次迁移，都是重写集成、重新学习API、重建工作流。有时候，那些什么都没做、只是静观其变的人，反而比早早入场、被迫迁移两次的人站得更稳。

后来我换了一种思路。与其追逐每一个新工具，不如深入它们之下的基础设施层。工具会不断更替，但它们试图解决的本质问题不会变：上下文效率、agent授权、审计记录、运行时安全——不管当下流行哪一个框架，这些问题都会长期存在。这也是为什么我选择在OpenFGA之上构建agentic-authz，而不是绑定某个具体的agent框架；为什么Distill关注的是上下文层，而不是prompt层。要站在不那么容易翻新的那一层去构建。

我仍然密切关注整个生态——做基础设施的人不可能不关注。但我的目的，是理解技术方向，而不是第一时间“跟上去用”。了解前沿，和被前沿牵着跑，是两回事。

“再来一个提示词”陷阱

这个陷阱非常隐秘，你几乎在不知不觉中就掉了进去。你试图让AI生成一个特定的结果，第一次输出大概70%对。于是你微调提示词，第二次输出75%对，但却把第一次做对的部分给破坏了。第三次尝试，80%对了，但结构又变了。第四次……你已经折腾了45分钟，而如果自己动手，从头写出来可能只需要20分钟。

我称之为提示词螺旋。它是AI版的“剃牦牛毛”。一开始你目标清晰，但三十分钟后，你调的不是代码，而是提示词；你优化的不是功能，而是让模型更懂你的指令。

提示词螺旋特别危险，因为它看起来很高效。你在不断迭代，似乎越来越接近目标，每一次尝试都略有进步。但边际收益在迅速下降，而你已经忘了最初的目标从来不是“让AI产出完美结果”，而是“把功能交付出来”。

我现在有一个硬性规则：三次尝试。如果三次都没达到70%可用，我就自己写。没有例外。这条规则，帮我节省的时间，比我学过的任何提示词技巧都多。

完美主义与概率输出的碰撞

工程师天生倾向完美主义。我们喜欢干净利落的代码，喜欢能通过所有测试的代码，喜欢行为可预测的系统。这正是我们的优势，也是我们能构建可靠软件的根本原因。

而AI的输出，从来不会完美。它总是“差不多对”，大约70–80%正确。变量名稍有偏差，错误处理不完整，边缘情况被忽略，抽象不适合你的代码库。它能用，但不够对。

对完美主义者来说，这简直是折磨。因为“几乎正确”比“完全错误”更令人痛苦。完全错了，你扔掉重写就好；几乎对了，你要花一小时去微调。而调AI输出特别让人挫败——你不是在修自己的设计，而是在修别人的设计，一个既不懂你品味，也不理解你上下文和标准的系统做出的设计。

我不得不学会放手。不是放弃质量——我依然追求质量——而是放下对AI会产出“高质量成品”的期望。我现在把每一条AI输出都当作初稿、起点、原料，一旦出现，我就在心里标记它为“draft”。仅仅这个心理框架的改变，就让我的挫败感减半。

那些最难适应AI的工程师，往往是最优秀的工程师——标准最高，能注意到每一个微小的瑕疵。AI时代需要的技能恰恰不同：快速从不完美的输出中提取价值，而不在追求“完美”上投入过多情绪。

思维退化

有一种恐惧，比其他都更让我不安。

我是在一次设计评审会议上注意到这一点的。有人让我在白板上推演一个并发问题——没有电脑，没有AI，只有我和一支马克笔。结果我很挣扎。并不是因为我不懂概念，我懂。但我已经几个月没锻炼过这块思维肌肉了。我太长时间把初稿思考交给AI处理，以至于从零开始独立推演问题的能力已经退化。

这就像GPS改变了我们的导航技能。以前没有GPS，你会在脑海里绘制地图，熟悉城市街区，能推理路线。几年使用GPS后，你离开导航就容易迷路。技能会退化，因为你停止使用它。

AI与工程思维的关系也是如此。当你总是先求助AI，你就停止了自己与问题搏斗、从而形成深刻理解的那些神经通路。正是在挣扎中，你学会了；在困惑中，你真正理解了。 跳过这个过程，你或许能更快地产出结果，却换来了更肤浅的理解。

我现在会刻意把一天的第一个小时留给无AI的思考时间。用纸笔推演，用手画架构图，用“慢方法”理清问题。看起来低效，确实低效。但它让我保持思维敏锐，而这种清醒又会让下午使用AI时的收益倍增——因为当我自己的推理能力充分“热身”后，我能更准确、更高效地评估AI的输出。

比较陷阱

社交媒体上，到处是似乎已经“玩转AI”的人：晒出复杂的工作流，展示惊人的效率数据，发布“用AI两小时造出整款应用”的长篇教程。你回头看看自己——失败的提示词，浪费的时间，被迫重写的代码——心里不免一阵自责：我是不是哪里做得不对？

你没错。那些帖子只是精心剪辑后的“高光时刻”。没人会发“我花了三小时让Claude理解我的数据库schema，最终放弃并手写了迁移脚本”；没人会发“AI生成的代码吞掉了一个错误，最终导致了生产事故”；更没人会发“我感觉累死了”。

比较陷阱还因为AI技能的难以衡量而被放大。在传统工程领域，可以通过阅读代码大致判断一个人的能力；而AI的产出则受到模型版本、提示词质量、上下文、温度参数，甚至运气成分的复杂影响。别人做出的惊艳demo，在你的特定开发环境和代码库上下文上，未必能成功复现。

我现在对社交媒体上的AI内容选择更为谨慎。我依然紧跟行业动态——这是我的工作所需，但我不再盲目吸收每个人的“热门观点”，而是有选择地关注那些真正在一线构建和交付复杂系统的人。信息与焦虑的比例很重要：如果一个信息流让你更多地感到落后而非获得新知，它就是在消耗你，而非帮助你。

真正帮到我的方法

我愿意具体分享一下，哪些方法让我与AI的关系从“对抗”转向了“可持续”。

• 限定AI使用时间：不再无期限地与AI“纠缠”。为每项任务设定30分钟定时器。时间一到，就基于现有结果交付，或者自己动手完成剩余部分。这个方法同时避免了“提示词螺旋”和“完美主义陷阱”。
• 分开AI时间与思考时间：早晨用于无干扰的深度思考，下午用于AI辅助的高效执行。并非绝对僵化，有时会根据情况打破规则。但有了这个默认的结构，大脑既能得到思维锻炼，也能高效利用AI。
• 接受AI产出70%可用即可：停止追求AI的“完美输出”。70%的可用性就是我的接受底线，其余部分自己动手补充完善。这条规则是我工作流中减少AI相关挫败感的最大功臣。
• 战略性看待炒作周期：我关注AI生态，因为需要为其搭建基础设施，但不再做“第一时间尝鲜者”。我选择一个主力的编程助手，并深入使用它；对于新工具，我会等待几个月，待其经过市场验证后再进行评估。了解趋势和被趋势被动牵着跑，是两回事。
• 记录AI的适用场景：我做了为期两周的简单日志：记录任务、是否使用AI、花费时间、结果满意度。数据清晰地显示：AI在模板化代码、文档撰写、测试生成等方面确实省时；但在架构决策、复杂调试、需要深度领域知识的地方，反而更加耗时。现在我知道什么时候该调用AI，什么时候该依靠自己。
• 不审查AI的每一行输出：这一点很难接受，但当你使用AI生成大量代码时，物理上无法用同样严格的标准审查每一行。我把有限的精力集中在最关键的部分——安全边界、核心数据处理逻辑、关键错误路径，其余则依靠完善的自动化测试和静态分析工具来保障。对于非关键代码中的小瑕疵，可以选择性容忍。

可持续性的问题

科技行业的倦怠问题早在AI出现之前就存在，而AI的出现，并没有缓解它，反而让它更加明显。不是因为AI本身是“坏”的，而是因为它打破了曾经在无形中保护我们的自然速度限制。

在AI出现之前，你一天能产出的工作量存在一个天然的上限——这个上限由你的打字速度、思考速度、查阅资料所需的时间共同决定。虽然有时会让人感到焦躁，但它也是一种保护机制。工作本身设置了界限，你无法把自己累垮，因为工作会自动限制你。

AI取消了这个保护机制。现在，唯一的限制是你的认知耐力。而大多数人，只有在突破极限之后，才会痛苦地意识到自己的认知边界在哪里。

我在2025年末经历了倦怠。不是戏剧化的崩溃——我没有辞职，也没有情绪失控，只是不再在乎了。代码审查变成了走过场，设计决策变成“随AI的建议而定”。我一边高产输出，一边心力枯竭。花了一个月才意识到发生了什么，又用了一个月才慢慢恢复过来。

恢复的关键，不在于少用AI，而在于改变使用AI的方式——设定清晰的边界，有意识、有策略地使用，明白自己不是机器，也不必与机器同速奔跑。在我为Ona（一家企业AI基础设施公司）工作的经历中，我清晰地看到了这一点——当你为企业客户构建AI Agent基础设施时，你会真实地看到大规模不可持续的AI工作流所带来的巨大人力成本。这不仅是个人层面的问题，更是系统性问题，需要在工具和流程层面去解决，而不能只依赖个人的自我调节。

讽刺的是，那段倦怠期也是我“产出”最多的时期之一。当我停止追逐每一个新的AI工具，开始将注意力转向真正持久的问题时，我第一次看清了业界的核心痛点：

• 上下文窗口被低质量信息填满 → 于是有了Distill
• Agent拥有全或无的API密钥访问权限 → 于是有了agentic-authz
• 无法有效审计Agent的实际操作 → 正在开发AgentTrace

疲惫迫使我停止了盲目的“消费”，转而开始有意义的“创造”。不是更快地堆砌功能，而是有意识地构建那些真正重要、能解决根本问题的东西。

真正的技能

我认为，AI时代工程师真正的核心技能，不是提示词工程，不是模型选择，也不是构建一个看似完美的工作流。

而是——知道什么时候该停下。

知道AI的输出什么时候已经“足够好”，可以交付了。知道什么时候应该关掉聊天窗口，自己动手写。知道什么时候应该合上笔记本电脑，彻底休息。知道什么时候为了一点微小的性能或代码风格提升而付出的巨大认知成本是不值得的。明白我们的大脑是一种有限的珍贵资源，保护它、合理使用它不是懒惰，而是一种高级的工程智慧。

我们为软件系统设计可持续性：添加断路器、实现背压、设计优雅降级。现在，我们也应该为自己设计同样的保护机制。

AI是我职业生涯中用过的最强大的工具，同时也是最消耗精力的工具。这两点都是真实的。能在这个时代真正茁壮成长的工程师，不是那些使用AI时间最长、次数最多的人，而是用得最明智、最可持续的人。

如果你也感到疲惫，不是因为你做错了什么，而是因为这真的很难。工具是新的，工作模式尚未定型，整个行业有时还在盲目推崇“更多输出等于更多价值”的叙事。其实并非如此——可持续的、高质量的产出，才是长期价值所在。

我仍然每天在这个领域工作：研究agent授权、上下文工程、审计追踪、运行时安全——构建让AI Agent在生产环境中真正可靠、可用的基础设施。我比以往任何时候都更深入AI领域，但我选择以自己的节奏、自己的方式投入，专注于构建有意义、能解决实际问题的东西，而不是盲目追逐每一个转瞬即逝的潮流。

照顾好你的大脑，它是你唯一的、真正不可替代的“核心算力”，没有任何AI能替代它。欢迎在云栈社区分享你在使用AI工具过程中的体验与思考。