本文翻译自 AI fatigue is real and nobody talks about it，原载于 Hacker News。

引言

上个季度我交付的代码比我职业生涯中任何一个季度都要多。同时，我也感到比以往任何时候都要疲惫。这两个事实并非毫无关联。

我以构建 AI agent 基础设施为生。我是 OpenFGA（CNCF 孵化项目）的核心维护者之一，我构建了 agentic-authz 用于 agent 授权，构建了 Distill 用于上下文去重，我还交付了多个 MCP 服务器。我不是一个在业余时间玩玩 AI 的人。我深度参与其中，构建着其他工程师用来让 AI agents 在生产环境中工作的工具。

即便如此，我还是撞到了墙。那种精疲力竭，是任何工具或工作流优化都无法修复的。

如果你是一名每天使用 AI 的工程师——用于设计评审、代码生成、调试、文档编写、架构决策——并且你注意到自己比 AI 出现之前更疲惫，这篇文章就是为你写的。你不是在想象。你不是软弱。你正在经历一件真实的事情，而这个行业正在假装它不存在。如果一个全职构建 agent 基础设施的人都可能被 AI 耗尽，那它可能发生在任何人身上。

我想诚实地谈论这件事。不是”AI 很棒，这是我的工作流”那个版本。而是真实版本。那个你在晚上 11 点盯着屏幕，被 AI 生成的代码包围，仍然需要审查它们，想知道那个本应该为你节省时间的工具如何消耗了你的一整天。

没有人警告过我们的悖论

有一段时间让我困惑的是：AI 确实让单个任务更快了。这不是谎言。以前需要 3 小时的事情现在只需要 45 分钟。起草设计文档、搭建新服务的脚手架、编写测试用例、研究不熟悉的 API——一切都更快了。

但我的日子变得更难了。不是更容易，是更难。

原因一旦你看清就很简单，但我花了几个月才弄明白。当每个任务花费的时间更少时，你不会做更少的任务。你会做更多的任务。你的能力似乎在扩展，所以工作就会扩展来填满它。甚至更多。你的经理看到你交付得更快，所以期望值就调整了。你看到自己交付得更快，所以你自己的期望值也调整了。基线移动了。

在 AI 之前，我可能会花一整天时间在一个设计问题上。我会在纸上画草图，在洗澡时思考，去散步，带着清晰的思路回来。节奏很慢，但认知负荷是可控的。一个问题。一天。深度专注。

现在？我可能在一天内接触六个不同的问题。每个”用 AI 只需要一小时”。但在六个问题之间切换上下文对人脑来说是极其昂贵的。AI 在问题之间不会累。我会。

这就是悖论：AI 降低了生产成本，但增加了协调、审查和决策的成本。而这些成本完全由人类承担。

你成了审查员，而你并没有报名参加这个

在 AI 之前，我的工作是：思考一个问题，编写代码，测试它，交付它。我是创造者。制造者。这是我们大多数人最初被工程吸引的原因——构建的行为。

在 AI 之后，我的工作越来越多地变成：提示、等待、阅读输出、评估输出、决定输出是否正确、决定输出是否安全、决定输出是否符合架构、修复不符合的部分、重新提示、重复。我成了一个审查员。一个法官。一条永不停止的装配线上的质量检查员。

这是一种根本不同的工作类型。创造是充能的。审查是耗能的。对此有研究——生成任务和评估任务之间的心理差异。生成性工作给你心流状态。评估性工作给你决策疲劳。

我第一次注意到这一点是在一周内大量使用 AI 为一个新的微服务工作时。到了周三，我无法再做简单的决策了。这个函数应该叫什么？我不在乎。这个配置应该放在哪里？我不在乎。我的大脑满了。不是因为写代码——是因为审查代码。数百个小的判断，整天，每天。

残酷的讽刺是，AI 生成的代码需要比人工编写的代码更仔细的审查。当同事编写代码时，我知道他们的模式、他们的优势、他们的盲点。我可以浏览我信任的部分，专注于我不信任的部分。对于 AI，每一行都是可疑的。代码看起来很自信。它可以编译。它甚至可能通过测试。但它可能以微妙的方式出错，只会在生产环境中暴露，在负载下，在凌晨 3 点。

所以你阅读每一行。阅读你没有编写的代码，由一个不了解你的代码库历史或团队约定的系统生成的代码，是令人筋疲力尽的工作。

这也是为什么我认为 agent 安全和授权如此重要的原因。如果我们无法审查 AI 产生的一切——我们确实不能，不能大规模——那么我们需要从一开始就限制 agents 可以做什么的系统。最小权限访问、范围令牌、审计跟踪。你越少担心”AI 是否做了危险的事情”，你就为真正重要的工作拥有更多的认知预算。这不仅是一个安全问题。这是一个人类可持续性问题。

不确定性问题

工程师在确定性上受过训练。相同的输入，相同的输出。这是契约。这就是使调试成为可能的原因。这就是使推理系统成为可能的原因。

AI 打破了那个契约。

我有一个提示在周一完美工作。为一个 API 端点生成干净、结构良好的代码。我在周二为类似的端点使用了相同的提示。输出在结构上不同，使用了不同的错误处理模式，并引入了一个我没有要求的依赖。

为什么？没有原因。或者更确切地说，没有我可以访问的原因。没有”模型今天决定走不同方向”的堆栈跟踪。没有”温度采样选择了路径 B 而不是路径 A”的日志。它只是…发生了不同的变化。

对于一个整个职业生涯建立在”如果它坏了，我可以找出原因”的人来说，这是深感不安的。不是戏剧性的方式。而是缓慢的、折磨的、背景焦虑的方式。你永远不能完全信任输出。你永远不能完全放松。每次交互都需要警惕。

我试图与之抗争。我对提示进行了版本控制。我构建了复杂的系统消息。我创建了模板。其中一些有所帮助。没有一个解决根本问题：你正在与一个概率系统协作，而你的大脑是为确定性系统连线的。这种不匹配是一个持续的、低级别的压力源。

这种挫折实际上导致我构建了 Distill——用于 LLM 的确定性上下文去重。没有 LLM 调用，没有嵌入，没有概率启发式。纯算法在约 12 毫秒内清理你的上下文。我希望 AI 管道的至少一个部分是我可以推理、调试和信任的。如果模型的输出将是不确定的，我至少可以做的是确保输入是干净和可预测的。

我与之交谈过的工程师中，最好地处理这个问题的是那些已经接受它的人。他们把 AI 输出视为聪明但不可靠的实习生的初稿。他们期望重写 30%。他们为重写预算时间。当输出错误时他们不会感到沮丧，因为他们从不期望它是正确的。他们期望它是有用的。有区别。

FOMO 跑步机

深呼吸并尝试跟上仅仅过去几个月。Claude Code 发布子代理，然后是技能，然后是 Agent SDK，然后是 Claude Cowork。OpenAI 推出 Codex CLI，然后是 GPT-5.3-Codex——一个真正帮助编码自己的模型。新的编码代理宣布具有数百个并发自主会话的背景模式。Google 推出 Gemini CLI。GitHub 添加 MCP 注册表。收购每周发生。Amazon Q Developer 获得 agent 升级。CrewAI、AutoGen、LangGraph、MetaGPT——选择你的 agent 框架，每周都有一个新的。Google 宣布 A2A（Agent-to-Agent 协议）与 Anthropic 的 MCP 竞争。OpenAI 推出自己的 Swarm 框架。Kimi K2.5 推出，协调 100 个并行代理的 agent swarm 架构。”Vibe coding”成为一件事。OpenClaw 推出技能市场，一周内，研究人员发现 ClawHub 上上传了 400+ 恶意 agent 技能。而在所有这些中间，有人在 LinkedIn 上发布”如果你在 2026 年不使用带子代理协调的 AI agents，你就已经过时了。”

这不是一年。这是几个月。而我省略了一些东西。

我深深地陷入了这个陷阱。我花周末评估新工具。阅读每个变更日志。观看每个演示。试图保持在前沿，因为我害怕落后。

这实际上看起来像：我会在星期六下午设置一个新的 AI 编码工具。到星期天我会有一个基本的工作流。到下周星期三，有人会发布一个”好得多”的不同工具。我会感到一阵焦虑。到下个周末，我会设置新东西。旧的东西会闲置不用的。一个编码助手到下一个到下一个再回到第一个。每次迁移花费我一个周末，给我可能 5% 的改进，我甚至无法正确测量。

将这个乘以每个类别——编码助手、聊天界面、agent 框架、多代理协调平台、MCP 服务器、上下文管理工具、提示库、swarm 架构、技能市场——你会得到一个永远在学习新工具而从未深入了解任何一个的人。仅 Hacker News 首页就足以让你头晕目眩。一天是”Show HN: 自主研究 Swarm”，第二天是”Ask HN: AI swarms 将如何协调？”没人知道。每个人都在构建。

最糟糕的部分是知识衰减。我在 2025 年初花了两周时间构建一个复杂的 prompt engineering 工作流。精心制作的系统提示、少样本示例、思维链模板。它工作得很好。三个月后，模型更新了，prompt 最佳实践转移了，我的一半模板产生的结果比简单的单行更差。那两周不见了。不是投资。是花费。同样的事情发生在我的 MCP 服务器设置上——我构建了五个自定义服务器（Dev.to 发布者、Apple Notes 集成、Python 和 TypeScript 沙箱等），然后协议演变了，然后 MCP 注册表在 GitHub 上启动，突然有数千个预构建的。我的一些自定义工作一夜之间变得多余。

Agent 框架的 churn 甚至更糟。我看到团队在一年内从 LangChain 到 CrewAI 到 AutoGen 到自定义编排。每次迁移都意味着重写集成、重新学习 API、重建工作流。那些等待什么都不做的人往往比早期采用并必须迁移两次的人最终处于更好的位置。

我后来采用了不同的方法。与其追逐每个新工具，我深入研究它们下面的基础设施层。工具来来去去。它们解决的问题不会。上下文效率、agent 授权、审计跟踪、运行时安全——这些都是持久的问题，无论本月哪个框架趋势。这就是为什么我在 OpenFGA 上构建 agentic-authz 而不是将其绑定到任何特定的 agent 框架。这就是为什么 Distill 在上下文级别工作，而不是在 prompt 级别。在不 churn 的层上构建。

我仍然密切关注格局——当你为它构建基础设施时你必须这样做。但我跟踪它是为了了解生态系统的发展方向，而不是采用每个新东西。知情和反应之间有区别。

“就再多一个提示”陷阱

这个是阴险的。你试图让 AI 生成特定的东西。第一个输出是 70% 正确。所以你完善你的提示。第二个输出是 75% 正确但破坏了第一个正确的部分。第三次尝试：80% 正确但现在结构不同。第四次尝试：你已经在这个上花了 45 分钟，你可以在 20 分钟内从头开始编写。

我称之为提示螺旋。这是 yak shaving 的 AI 等价物。你从一个明确的目标开始。三十分钟后你在调试你的提示而不是调试你的代码。你在优化你对语言模型的指令而不是解决实际问题。

提示螺旋特别危险，因为它感觉很有生产力。你在迭代。你越来越接近。每次尝试都稍微好一点。但边际收益递减很快，你已经忘记了目标从来不是”让 AI 产生完美的输出”。目标是交付功能。

我现在有一个硬性规则：三次尝试。如果 AI 在三个提示中不能让我达到 70% 可用，我自己写。没有例外。这一个规则比我学过的任何提示技术为我节省了更多时间。

完美主义遇到概率输出

工程师倾向于完美主义。我们喜欢干净的代码。我们喜欢通过的测试。我们喜欢可预测行为的系统。这是一个功能，而不是一个 bug——这是使我们擅长构建可靠软件的原因。

AI 输出永远不会完美。它总是”相当好”。70-80% 到位。变量名稍微偏离。错误处理不完整。边缘情况被忽略。抽象对你的代码库来说是错误的。它工作，但它不对。

对于完美主义者来说，这是折磨。因为”几乎正确”比”完全错误”更糟糕。完全错误，你扔掉重新开始。几乎正确，你花一个小时调整。而调整 AI 输出是特别令人沮丧的，因为你修复别人的设计决策——由一个不分享你的品味、你的上下文或你的标准的系统做出的决策。

我必须学会放手。不是质量——我仍然关心质量。而是 AI 会产生质量的期望。我现在将每个 AI 输出视为粗略草稿。一个起点。原材料。我在它出现的那一刻在心理上将其标记为”草稿”，仅这一框架变化就将我的挫败感减少了一半。

最挣扎于 AI 的工程师往往是最好的工程师。那些标准最高的人。那些注意到每一个不完美的人。AI 奖励一种不同的技能：能够从不完美的输出中快速提取价值，而不会在情感上投入使其完美。

思维萎缩

这是最让我害怕的一个。

我在设计评审会议期间注意到了这一点。有人要求我在白板上推理一个并发问题。没有笔记本电脑。没有 AI。只有我和一个标记。我挣扎了。不是因为我不懂概念——我懂。而是因为我已经好几个月没有锻炼那块肌肉了。我太久以来将我的初稿思维外包给 AI，以至于我从头开始思考的能力退化了。

这就像 GPS 和导航。在 GPS 之前，你构建心理地图。你了解你的城市。你可以推理路线。经过多年的 GPS，你无法在没有它的情况下导航。技能萎缩了，因为你停止使用它。

同样的事情正在发生在 AI 和工程思维上。当你总是先问 AI 时，你停止构建来自自己挣扎问题的神经通路。挣扎是学习发生的地方。困惑是理解形成的地方。跳过那个，你会得到更快的输出但更浅的理解。

我现在故意每天的第一小时不使用 AI。我在纸上思考。我手绘架构。我通过慢速方式推理问题。这感觉低效。它是低效的。但它保持我的思维敏锐，这种敏锐性在当天晚些时候我使用 AI 时会带来回报——因为当我自己的推理预热时，我可以更好地评估它的输出。

比较陷阱

社交媒体上充满了似乎已经弄清楚 AI 的人。他们发布他们的工作流。他们的生产力数字。他们的”我在 2 小时内用 AI 构建了这个整个应用”的线程。而你看看你自己的经验——失败的提示、浪费的时间、你必须重写的代码——你认为：我怎么了？

你没有任何问题。这些线程是精彩集锦。没有人发布”我花了 3 小时试图让 Claude 理解我的数据库架构最终放弃并手动编写迁移。”没有人发布”AI 生成的代码导致生产事件，因为它悄悄地吞下了一个错误。”没有人发布”我累了。”

比较陷阱被以下事实放大：AI 技能很难测量。对于传统工程，你可以查看某人的代码并大致评估他们的能力。对于 AI，输出取决于模型、提示、上下文、温度、月相。某人令人印象深刻的演示可能无法在你的机器上用你的代码库重现。

我对社交媒体上的 AI 内容变得更加选择性。我仍然密切关注这个领域——我必须这样做，这是我的工作。但我从消费每个人的热门观点转变为专注于那些实际构建和交付的人，而不仅仅是演示。信号与焦虑的比例很重要。如果一个订阅源让你感觉落后而不是知情，它不为你服务。

什么真正有帮助

我将具体说明什么将我与 AI 的关系从对抗性转变为可持续性。

为 AI 会话设置时间框。我不再以开放式方式使用 AI。我设置一个计时器。这个任务用 AI 30 分钟。当计时器响起时，我交付我拥有的或切换到自己编写。这同时防止了提示螺旋和完美主义陷阱。

将 AI 时间与思考时间分开。早晨用于思考。下午用于 AI 辅助执行。这不是刚性的——有时我会打破规则。但有一个默认结构意味着我的大脑以正确的比例获得锻炼和协助。

接受 AI 的 70%。我停止尝试获得完美的输出。70% 可用是标准。我自己修复其余部分。这种接受是我工作流中 AI 相关挫败感的最大单一减少器。

对炒作周期进行战略性思考。我跟踪 AI 领域，因为我为它构建基础设施。但我停止在每周推出时采用每个新工具。我使用一个主要的编码助手并深入了解它。当新工具在数月而不是数天内证明自己时，我会评估它们。保持知情和保持反应是不同的事情。

记录 AI 有帮助的地方和没有帮助的地方。我保留了一个简单的日志两周：任务、使用 AI（是/否）、花费时间、对结果的满意度。数据是有启发性的。AI 在样板代码、文档和测试生成上为我节省了大量时间。它在架构决策、复杂调试和任何需要深入了解我的代码库的事情上花费了我时间。现在我知道何时伸手以及何时不要。

不审查 AI 产生的一切。这很难接受。但如果你使用 AI 生成大量代码，你无法以同样的严格程度审查每一行。我将我的审查精力集中在最重要的部分——安全边界、数据处理、错误路径——并为其余部分依赖自动化测试和静态分析。非关键代码中的一些粗糙度是可以接受的。

可持续性问题

科技行业有一个 AI 之前的职业倦怠问题。AI 使其变得更糟，而不是更好。不是因为 AI 不好，而是因为 AI 移除了以前保护我们的自然速度限制。

在 AI 之前，你一天能生产的东西有一个上限。这个上限由打字速度、思考速度、查找事物所需的时间设定。有时这很令人沮丧，但这也是一个调节器。你不能工作到死，因为工作本身强加了限制。

AI 移除了调节器。现在唯一的限制是你的认知耐力。而且大多数人不知道他们的认知极限，直到他们超越它们。

我在 2025 年底职业倦怠了。不是戏剧性的——我没有辞职或崩溃。我只是不再关心。代码审查变成了橡皮图章。设计决策变成了”无论 AI 建议什么。”我在走过场，生产得比以往任何时候都多，感觉比以往任何时候都少。我花了一个月才意识到发生了什么，又一个月才恢复。

恢复不是关于减少使用 AI。而是关于以不同方式使用 AI。有边界。有意地。有理解我是一个机器，我不需要跟上它的步伐。在 Ona 工作帮助我清楚地看到这一点——当你为企业客户构建 AI agent 基础设施时，你会大规模地看到不可持续的 AI 工作流的人力成本。问题不仅仅是个人的。它们是系统性的。它们需要在工具级别解决，而不仅仅是在个人级别。

具有讽刺意味的是，职业倦怠期是我一些最好的工作发生的时候。当我停止尝试使用每个 AI 工具并开始思考真正坏了什么时，我第一次清楚地看到了问题。上下文窗口充满了垃圾——这变成了 Distill。拥有全有或全无 API 密钥访问权限的 agents——这变成了 agentic-authz。无法审计 agent 实际做了什么——这正在成为 AgentTrace。疲劳迫使我停止消费并开始构建。不是更快地构建更多功能，而是故意构建正确的东西。

真正的技能

这是我认为 AI 时代的真正技能。它不是 prompt engineering。它不是知道使用哪个模型。它不是拥有完美的工作流。

它是知道何时停止。

知道 AI 何时足够好。知道何时自己写。知道何时关闭笔记本电脑。知道边际改进不值得认知成本。知道你的大脑是一个有限的资源，保护它不是懒惰——它是工程学。

我们优化系统的可持续性。我们添加断路器。我们实现背压。我们为优雅降级设计。我们应该对自己做同样的事情。

AI 是我使用过的最强大的工具。它也是最耗能的。两件事都是真的。在这个时代蓬勃发展的工程师不会是那些使用最多 AI 的人。他们将是那些最明智地使用它的人。

如果你累了，不是因为你做错了。是因为这确实很难。工具是新的，模式仍在形成，行业假装更多输出等于更多价值。它不等于。可持续输出等于。

我仍然每天都在这个领域构建。Agent 授权、上下文工程、审计跟踪、运行时安全——使 AI agents 在生产环境中实际工作的基础设施。我比以往任何时候都更致力于 AI。但我按照我的条款、以我的节奏致力于它，构建重要的事情而不是追逐趋势的东西。

照顾你的大脑。它是你唯一的一个，没有 AI 可以替代它。

作者撰写关于 AI agent 基础设施、安全、上下文工程以及使用 AI 构建的人性化方面。你可以在他的写作页面上找到他所有的写作。

核心要点

1. AI 确实能提高单个任务的效率，但会增加认知负荷——你做了更多的任务，但上下文切换和审查工作带来了更大的心理负担。

2. AI 将你的角色从创造者转变为审查者——创造是充能的，而审查是耗能的。AI 生成的代码需要更仔细的审查，因为每一行都可能是可疑的。

3. AI 输出的不确定性给工程师带来了额外的压力——工程师习惯于确定性系统，但 AI 是概率性的，这种不匹配是持续的焦虑来源。

4. FOMO（害怕错过）导致工具追逐循环——每周都有新工具推出，但不断迁移成本很高。作者建议专注于基础设施层而不是追逐趋势工具。

5. “提示螺旋”会浪费时间——与其花 45 分钟调整提示，不如设置一个限制（如 3 次尝试），然后自己编写代码。

6. AI 时代最重要的技能是知道何时停止——知道何时 AI 输出足够好，何时自己写，何时关闭笔记本电脑。

7. 保护你的认知资源是工程学，不是懒惰——就像我们为系统设计可持续性一样，我们也需要为自己设计可持续的工作流程。