【Translation】 AI 疲劳真实存在，却鲜有人提及

"对博文 AI fatigue is real and nobody talks about it 的翻译，原作者 Siddhant Khare 。这篇博文主要讲述了软件开发中开发者对AI 编码的疲劳现象，并且给出了作者自己应对该问题的方法论。也可以说这是一篇AI时代下的软件开发的方法论指南。"

你借助 AI 提升效率，为何却比以往更疲惫？这是每位工程师必须面对的矛盾现实。

上个季度，我交付的代码量超过了职业生涯中的任何一个季度。同时，我也感到前所未有的疲惫。这两件事并非毫无关联。

我以构建人工智能代理基础设施为业。我是 OpenFGA（CNCF 孵化项目）的核心维护者之一，开发了用于代理授权的 agentic-authz，构建了用于上下文去重的 Distill，并部署了 MCP 服务器。我并非浅尝辄止的 AI 爱好者，而是深度投身其中——我所打造的工具，正被其他工程师用于实现 AI 代理在生产环境中的高效运行。

然而，我碰壁了。那种疲惫感，是任何工具或工作流程优化都无法缓解的。

如果你是一名每天使用 AI 的工程师——无论是进行设计评审、代码生成、调试、文档编写还是架构决策——并且发现自己比 AI 出现前更加疲惫，那么这篇文章正是为你而写。你并非在胡思乱想，也并非意志薄弱。你正在经历的是一种真实存在的现象，而整个行业却刻意对此视而不见。如果连一位全职构建智能体基础设施的专业人士都会因 AI 而精疲力竭，那么任何人都可能面临同样的情况。

我想坦诚地谈谈这件事。不是那种“AI 太神奇了，这是我的工作流程”的版本。而是真实的版本——深夜十一点，你盯着屏幕，周围是仍需审阅的 AI 生成代码，心中疑惑：本该为你节省时间的工具，为何吞噬了你一整天。

无人事先告知我们的悖论

让我一度困惑的是：人工智能确实让单次任务变得更快了。这并非虚言。过去需要三小时完成的工作，如今只需四十五分钟。无论是起草设计文档、搭建新服务框架、编写测试用例，还是研究陌生的 API 接口，一切都在加速。

但我的日子却愈发艰难，而非轻松。

道理一旦点破就很简单，但我花了数月才想明白。当每项任务耗时缩短时，你并不会减少任务量，反而会承担更多。你的能力看似扩张，工作便随之膨胀直至填满所有空间——甚至溢出。管理者目睹你的交付速度提升，期待值随之调整；你见证自身效率增长，自我要求也水涨船高。基准线就这样悄然位移。

在人工智能出现之前，我可能得花上一整天来解决一个设计问题。我会在纸上涂鸦，在淋浴时思考，出门散个步，然后带着清晰的思路回来。节奏虽慢，但认知负担尚可承受。一个问题。一天时间。深度专注。

现在？我一天可能要处理六个不同的问题。每个问题"用 AI 只需一小时"。但对人脑而言，在六个问题间切换上下文是极其耗费精力的。AI 不会在问题间感到疲惫，但我会。

悖论在于： 人工智能 (AI) 降低了生产成本，却提升了协调、审查与决策的成本。而这些成本完全落在了人类身上。

莫名其妙地，你成了那个审稿的人

在人工智能出现之前，我的工作是：思考问题、编写代码、测试、发布。我是创造者，是构建者。这正是最初吸引我们大多数人投身工程领域的原因——亲手创造的过程。

在 AI 时代之后，我的工作逐渐演变为：提出指令、等待、阅读输出、评估输出、判断输出是否正确、判断输出是否安全、判断输出是否符合架构设计，修正不符合的部分，重新下达指令，周而复始。我变成了一名审查员。一名裁判。一条永不停歇的生产线上的质检员。

这是一种本质不同的工作类型。创造令人充满活力，审阅则使人疲惫。有研究探讨过这一点——生成性任务与评价性任务之间的心理差异。生成性工作能让你进入心流状态，而评价性工作则会带来决策疲劳。

我是在一周内大量使用 AI 开发新微服务时首次注意到这一点的。到了周三，我连做简单决定都困难了。这个函数该叫什么名字？我不在乎。配置文件该放哪里？我也不在乎。我的大脑已经饱和了——不是因为写代码，而是因为评判代码。每天从早到晚，成百上千个微小判断持续消耗着我的认知资源。

残酷的反讽在于，AI 生成的代码比人类编写的代码需要更细致的审查。当同事写代码时，我了解他们的编码习惯、擅长领域和思维盲区。我可以快速浏览可信的部分，专注于存疑之处。而对 AI 生成的代码，每一行都需存疑。代码看起来自信满满，能顺利编译，甚至通过测试。但它可能隐藏着微妙错误，只在生产环境、高负载压力下或凌晨三点突然暴露。

所以你逐行阅读。而阅读那些并非由你编写、而是由一个不了解你代码库历史或团队规范的系统生成的代码，是一项令人疲惫不堪的工作。

这也正是我认为代理安全与授权至关重要的原因。如果我们无法审查人工智能生成的一切内容——事实上我们确实无法做到全面审查——那么我们就需要建立一套系统，从根本上限制代理的操作权限。最小权限访问、限定范围的令牌、审计追踪机制。当人们无需过度担忧"人工智能是否做出了危险行为"时，就能将更多认知资源投入到真正重要的工作中。这不仅是安全问题，更是关乎人类可持续发展的根本课题。

非确定性问题

工程师接受的是确定性训练。相同的输入，必然产生相同的输出，这是铁律。正是这一原则让调试成为可能，也让系统推理得以实现。

人工智能打破了这份契约。

周一我用的一个提示词效果完美，为 API 端点生成了清晰、结构良好的代码。周二我用同样的提示词处理类似的端点，结果输出的结构完全不同，采用了不同的错误处理模式，还引入了我没要求添加的依赖项。

为什么？没有原因。或者说，没有我能触及的原因。不存在“模型今天决定换个方向”的堆栈跟踪，也没有日志记录“温度采样选择了路径 B 而非路径 A”。它只是……以不同的方式发生了。

对于一个职业生涯完全建立在“若出问题，我必能查明原因”之上的人来说，这感觉如坐针毡。并非戏剧性的冲击，而是一种缓慢、持续、如影随形的焦虑。你永远无法全然信任其输出，也无法彻底放松。每一次互动都需保持警惕。

我曾试图对抗这一点。我给我的提示词做了版本控制，构建了精细的系统指令，还创建了模板。这些努力有些许帮助，但无一能解决根本问题： 你正在与一个概率性系统协作，而你的大脑却习惯于确定性模式。 这种不匹配，是一种持续存在的、低强度的压力源。

这种挫败感正是我开发 Distill 的原因——一个为 LLM 设计的确定性上下文去重工具。无需调用 LLM，无需嵌入向量，不用概率启发式。纯算法方案能在约 12 毫秒内净化你的上下文。我希望在 AI 流程中至少有一个环节是能够被推理论证、调试验证并值得信赖的。既然模型的输出注定具有不确定性，那我至少能确保输入是洁净且可预测的。

与我交流过的工程师中，那些最能妥善应对此事的，是那些已经坦然接受现状的人。他们将 AI 的产出视为一位聪明却不太可靠的实习生提交的初稿，预料到需要重写其中 30%的内容，并为此预留了时间。当输出出错时，他们不会感到沮丧，因为他们从未期待它完全正确——他们期待的是它的实用性。这二者之间，存在着微妙的差别。

FOMO 的焦虑循环

深吸一口气，试着跟上最近几个月的节奏。Claude Code 先是推出了子代理功能，接着是技能模块，随后发布 Agent SDK，紧接着又推出 Claude Cowork 协作工具。OpenAI 相继发布 Codex 命令行工具和 GPT-5.3-Codex——这个模型甚至能协助编写自身代码。新兴编程代理宣布支持后台模式，可同时运行数百个自主会话。谷歌悄然上线 Gemini 命令行工具。GitHub 新增 MCP 注册中心。行业收购每周都在发生。亚马逊 Q Developer 获得智能体升级。CrewAI、AutoGen、LangGraph、MetaGPT——各种代理框架层出不穷，几乎每周都有新品。谷歌发布 A2A（代理间协议）与 Anthropic 的 MCP 抗衡。OpenAI 推出自研 Swarm 框架。Kimi K2.5 携代理集群架构亮相，可协调 100 个并行代理。"氛围编程"成为新潮流。OpenClaw 上线技能市场，仅一周内研究人员就在 ClawHub 发现 400 多个恶意代理技能。而在这一片喧嚣中，领英上有人写道："如果 2026 年你还没用上具备子代理协同的 AI 智能体，那你已经过时了。"

那不是一年，而是几个月。而且我还省略了一些内容。

我深陷此陷阱，难以自拔。每个周末都在评估新工具，逐条阅读更新日志，观看每一场演示。只因害怕落后于人，我竭尽全力试图站在前沿。

实际情况是这样的：周六下午，我会花时间设置一个新的 AI 编程工具。到了周日，我就能建立起一个基本的工作流程。但紧接着的下周三，总会有人发帖谈论另一款“远胜一筹”的工具。这时，一股焦虑感便会袭来。于是到了下一个周末，我又开始折腾新工具。而旧工具则被闲置一旁。从一个编程助手换到另一个，再换到下一个，有时甚至又绕回最初的那个。每一次迁移都耗费我一个周末的时间，换来的可能只是约 5%的提升——这提升微小到我甚至无法准确衡量。

将这一现象乘以每一个类别——编码助手、聊天界面、智能体框架、多智能体协同平台、MCP 服务器、上下文管理工具、提示库、集群架构、技能市场——你就会得到一个永远在学习新工具，却从未深入掌握其中任何一项的人。仅 Hacker News 的首页就足以让你感到眼花缭乱。今天可能是“展示 HN：自主研究集群”，明天又变成“提问 HN：AI 集群将如何协调？”没人知道答案。但每个人都在埋头构建。

最糟糕的是知识贬值的速度。2025 年初，我花了两周时间构建了一套精密的提示工程工作流——精心设计的系统提示、少量示例、思维链模板，当时效果很好。三个月后模型更新，最佳提示实践随之改变，我一半的模板输出效果反而不如一句简单指令。那两周时间不是投资，是彻底蒸发。我的 MCP 服务器配置也遭遇同样命运：我搭建了五个定制服务器（Dev.to 发布器、苹果备忘录集成、Python/TypeScript 沙箱等），随后协议升级，GitHub 上突然出现 MCP 注册库，涌现出成千上万个预制方案，部分定制工作一夜之间就失去了价值。

智能体框架的变动更加令人头疼。我目睹团队在短短一年内从 LangChain 转向 CrewAI，再到 AutoGen，最终选择定制化编排系统。每一次迁移都意味着重写集成代码、重新学习 API 接口、重构工作流程。那些选择观望、按兵不动的团队，最终往往比那些早早采用新技术却被迫经历两次迁移的团队处境更佳。

自那以后，我采取了不同的策略。我不再追逐每一个新工具，而是深入探究它们之下的基础设施层。工具来来去去，但它们要解决的问题却始终存在。上下文效率、代理授权、审计追踪、运行时安全——这些都是持久性的挑战，无论本月流行哪种框架。正因如此，我选择在 OpenFGA 上构建 agentic-authz，而非将其绑定于任何特定的代理框架。这也是为什么 Distill 在上下文层面而非提示层面发挥作用。要构建在那些不易变动的层次之上。

我依然密切关注着行业动态——在为其构建基础设施时，你必须这样做。但我关注是为了理解生态系统的发展方向，而非盲目追随每个新事物。保持信息灵通与被动反应之间有着本质区别。

“再来一条指令”的陷阱

这玩意儿真够阴险的。你本想用 AI 生成特定内容，第一次输出对了七成。于是你优化指令，第二次结果准确度提到七成五，却把之前正确的部分搞砸了。第三次尝试：准确度八成，但整体结构已面目全非。等到第四次——你已折腾了四十五分钟，而这东西从头开始手写也不过二十分钟。

我称之为“提示螺旋”。这是人工智能领域的“牦牛剃毛”。你起初目标明确，三十分钟后却在调试你的提示而非代码。你在优化给语言模型的指令，而非解决实际问题本身。

提示词螺旋尤其危险，因为它给人一种高效推进的错觉。你在反复调试，看似步步逼近目标。每次尝试都有微小的改进，但边际效益正在急剧递减。此时你已忽略了一个核心事实：真正的目标从来不是“让 AI 输出完美结果”，而是将产品功能成功交付。

我现在定下一条铁律：最多尝试三次。如果人工智能在三次提示内无法让我得到70%可用的内容，我就自己动手写。没有例外。这条简单的规则，比我学过的任何提示技巧都节省了更多时间。

完美主义遭遇概率性输出

工程师往往倾向于追求完美主义。我们偏爱整洁的代码，乐于见到测试通过，享受系统行为可预测的稳定感。这并非缺陷，而是一种特质——正是这种特质让我们擅长构建可靠的软件。

人工智能的输出从来都不是完美的。它总是“相当不错”，能达到70-80%的程度。变量命名略有偏差，错误处理不够完善，边缘情况被忽略，抽象层次与你的代码库不匹配。它虽然能运行，但并不正确。

对一个完美主义者来说，这简直是折磨。因为“差不多对”比“完全错”更糟。完全错了，你可以丢掉重来；差不多对，却要花上一个小时修修补补。而调整人工智能的输出尤其令人沮丧，因为你是在修正别人的设计决策——这些决定出自一个与你品味不同、背景不同、标准也不同的系统之手。

我必须学会放手。不是对质量放手——我依然在乎质量。而是对人工智能能产出高质量成果的期待放手。如今，我将每一次 AI 的输出都视为初稿、一个起点、原始素材。当它出现的那一刻，我就在心里给它贴上“草稿”的标签，仅仅是这一思维方式的转变，就让我的挫败感减少了一半。

与人工智能抗争最激烈的工程师，往往是那些最优秀的工程师。他们是标准最高的一群人，对每一处瑕疵都洞若观火。然而，AI 所青睐的却是另一种能力：能够迅速从不完美的输出中提取价值，而不必在追求完美的过程中投入过多情感。

思维萎缩

这是最令我恐惧的那个。

在一次设计评审会上，我意识到了这一点。有人让我在白板上推导一个并发问题。没有笔记本电脑，没有 AI，只有我和一支马克笔。而我却感到吃力。不是因为我不懂那些概念——我懂。而是因为我已经好几个月没有锻炼过这种思维能力了。长久以来，我一直在将我的初步思考外包给 AI，以至于我从零开始思考的能力已经退化了。

这就像全球定位系统（GPS）与导航的关系。在 GPS 出现之前，人们构建心理地图，熟悉自己的城市，能够推理路线。然而，经过多年依赖 GPS 导航后，一旦离开它，人们便无法自如寻路。这项技能因长期闲置而逐渐退化。

人工智能与工程思维正经历着同样的转变。当你总是先求助 AI，便停止了自我解题过程中构建神经通路的努力。正是在挣扎中学习得以发生，在困惑中理解得以成形。跳过这些，你或许能更快地得到结果，但理解却流于肤浅。

如今，我刻意将每天的第一个小时留给无 AI 状态。我在纸上思考，手绘架构草图，用缓慢的方式推演问题。这感觉效率低下，也确实低效。但它让我的思维保持敏锐，而这份敏锐在我随后使用 AI 时带来了回报——当我的思维已充分预热，便能更好地评估 AI 的输出。

比较陷阱

社交媒体上充斥着看似已精通人工智能的人们。他们展示自己的工作流程，晒出惊人的生产力数据，分享那些“仅用 2 小时就靠 AI 构建完整应用”的帖子。而当你回顾自己的经历——那些失败的指令尝试、被虚耗的时间、不得不重写的代码——不禁会想：我到底哪里出了问题？

你没有任何问题。那些帖子都是精彩集锦。没人会发“我花了 3 小时试图让 Claude 理解我的数据库结构，最终放弃并手动编写了迁移脚本。”没人会发“AI 生成的代码因静默吞掉一个错误而导致生产事故。”没人会发“我好累。”

人工智能技能的难以衡量，加剧了比较陷阱的存在。在传统工程领域，你可以通过查看某人的代码大致评估其能力。但在 AI 领域，输出结果取决于模型、提示词、上下文环境、温度参数，甚至月相变化。某人展示的惊艳演示，在你的机器和代码库上可能根本无法复现。

在社交媒体上，我对 AI 内容变得挑剔多了。我依然密切关注这个领域——这是我的工作所需。但我已从盲目追随众人的热议，转向关注那些真正在构建和交付产品的人，而非仅仅展示演示。信息与焦虑的比例至关重要。如果一个信息流让你感到落后而非增长见识，那它就没有为你服务。

实际上有所帮助的是

让我具体说明是什么将我与人工智能的关系从对立转变为可持续。

为 AI 会话设定时间限制。 我不再以开放式的方式使用 AI。我会设置一个计时器，比如这项任务给 AI 30 分钟。计时器一响，我就交付已有的成果或转而自己动手撰写。这能同时避免陷入无限提示循环和完美主义陷阱。

将 AI 时间与思考时间分离。 上午用于思考，下午则借助 AI 辅助执行。这并非一成不变——有时我也会打破规则。但拥有一个默认的结构，意味着我的大脑能在恰当的比例下获得锻炼与辅助。

接受 AI 产出 70%的完成度。 我不再强求完美输出，以 70%可用性为标准线，剩余部分自行完善。这种接纳态度，极大缓解了我工作流程中因 AI 产生的挫败感。

对炒作周期保持战略定力。 我之所以关注人工智能领域动态，是因为我为其构建基础设施。但我不再追逐每个新工具上市首周就盲目采用。我专注于使用一个主力编程助手并深入掌握其特性。对于新工具，我会在它们经过数月（而非数日）市场验证后才进行评估。保持信息灵通与保持条件反射式的跟风是两回事。

记录 AI 在哪些方面有帮助，哪些方面没有。 我进行了为期两周的简单记录：任务、是否使用 AI、花费时间、对结果的满意度。这些数据很有启发性。AI 在模板代码、文档编写和测试生成方面为我节省了大量时间。但在架构决策、复杂调试以及任何需要深入了解代码库深层背景的任务上，它反而耗费了我的时间。现在我知道何时该使用它，何时不该用了。

不审查人工智能生成的所有内容。 这一点起初难以接受。但如果你利用人工智能生成大量代码，客观上不可能以同等严格标准逐行审查。我将审查精力集中在最关键的部分——安全边界、数据处理、错误路径——其余则依赖自动化测试和静态分析工具。对于非关键代码中的某些粗糙之处，是可以接受的。

可持续性问题

科技行业在人工智能兴起之前就已存在职业倦怠问题。如今，人工智能非但未能缓解这一状况，反而加剧了困境。这并非因为人工智能本身有害，而是因为它移除了曾保护我们的天然速度限制。

在人工智能出现之前，你一天能产出的成果是有上限的。这个上限由打字速度、思考速度、查找资料所需的时间决定。这有时令人沮丧，但同时也是一种约束。你无法把自己累垮，因为工作本身设定了限制。

人工智能移除了调速器。现在唯一的限制是你的认知耐力。而大多数人直到突破极限后，才意识到自己的认知边界。

2025 年末，我陷入了职业倦怠。并非戏剧性地爆发——我没有辞职，也没有崩溃，只是变得漠不关心。代码审查成了走过场，设计决策变成了"AI 建议什么就用什么"。我机械地完成工作，产出量比以往都多，却感受到前所未有的空洞。花了一个月我才意识到发生了什么，又用了一个月才逐渐恢复。

恢复的关键并非减少使用人工智能，而是以不同的方式运用它。要设定界限，带着明确意图，并理解自己并非机器，无需与之竞速。在 Ona 的工作经历让我清晰地认识到这一点——当你为企业客户构建 AI 智能体基础设施时，你会看到大规模不可持续 AI 工作流程背后的人力代价。这些问题不仅关乎个人，更是系统性的。它们需要在工具层面得到解决，而不仅仅停留在个体层面。

讽刺的是，倦怠期反而成就了我的一些最佳作品。当我停止试图使用所有 AI 工具，转而思考真正的问题所在时，我才第一次看清了症结所在。上下文窗口充斥着无用信息——这催生了 Distill；智能体要么全权访问 API 密钥要么毫无权限——这催生了 agentic-authz；无法审计智能体的实际行为——这正在催生 AgentTrace。这种疲惫感迫使我停止盲目消费，开始专注构建。不是更快地堆砌功能，而是深思熟虑地打造真正有价值的东西。

真正的技能

我认为，人工智能时代真正的技能在于，并非仅仅是提示工程，也不仅在于懂得选用何种模型，更不在于拥有完美的工作流程。

懂得何时收手。

知道何时 AI 的输出已足够好。知道何时该亲自动笔。知道何时合上笔记本。知道何时边际改进不值得认知成本。明白你的大脑是有限资源，保护它并非懒惰——那是精心设计。

我们为可持续性优化系统，增设断路器，实施背压机制，设计优雅降级方案。对于自身，我们也应如此。

人工智能是我用过最强大的工具，也是最耗费精力的。这两点都是事实。在这个时代能够脱颖而出的工程师，不会是最频繁使用 AI 的人，而是最明智运用它的人。

如果你感到疲惫，那并非你做错了什么，而是因为这一切确实艰难。工具尚新，模式仍在形成，而整个行业却假装更高的产出等同于更大的价值。事实并非如此，可持续的产出才是真正的价值所在。

我每天都在这个领域持续耕耘：代理授权、上下文工程、审计追踪、运行时安全——这些正是让 AI 智能体能在实际生产中真正运转起来的基础架构。如今，我对人工智能的投入比以往任何时候都更加坚定。但这份投入始终遵循我的原则，按照我的节奏，专注于构建真正有意义的事物，而非追逐转瞬即逝的热点潮流。

照顾好你的大脑。它是你唯一的头脑，任何人工智能都无法替代。

原文可见：https://siddhantkhare.com/writing/ai-fatigue-is-real

【END】