💡 本文基于 Siddhant Khare 的博客文章《AI fatigue is real and nobody talks about it》精选编译，并收录了 Hacker News 社区讨论中最精彩的观点（原帖 471+ 赞，95+ 条讨论）。Siddhant 是 AI 基础设施工程师、OpenFGA（CNCF 孵化项目）核心维护者。全文约 5,500 字，预计阅读 14 分钟。
有一个做 AI 基础设施的工程师，每天的工作就是给其他工程师造 AI 工具。
上个季度，他写的代码比职业生涯里任何一个季度都多。
同时，他也比任何一个季度都更累。
这两件事不是巧合。
如果你也是每天靠 AI 干活的人——写代码、做评审、调 bug、写文档——然后发现自己居然比没有 AI 的时候更累了，那这篇文章就是写给你的。你不是矫情，也不是能力不行。你正在经历一种真实存在的东西，只不过整个行业都在假装它不存在。
文章发到 Hacker News 之后，Django 的创造者 Simon Willison 第一个站出来说：
"深有同感。我现在一天能推进六个项目，但下班时精疲力竭。最近跟一些人聊，他们因为'再来一个 prompt 就好了'而失眠——根本停不下来。我们花了几十年建立的'可持续工作节奏'的直觉，一夜之间全被推翻了。要找到新的平衡，需要时间，也需要自律。"
这不是一个人的问题。这是一整代工程师正在经历的集体症状。
一、每件事都变快了，但日子更难过了
这是最反直觉的地方。
AI 确实让单个任务变快了，毫无疑问。以前 3 小时的活儿，现在 45 分钟就搞定。写文档、搭服务、写测试，全都更快了。
但日子变得更难了，不是更轻松。
原因说穿了很简单：每件事花的时间少了，你不会因此少做事——你会做更多。
产出快了，工作量就会膨胀来把时间填满。领导看到你干得快了，期望就跟着上去。你自己看到自己干得快了，对自己的要求也跟着上去了。基准线悄悄地、不声不响地往上挪了。
以前，Siddhant 可能花一整天琢磨一个设计问题。在纸上画画，洗澡的时候想想，出去走一圈，回来思路就清晰了。节奏慢，但脑子吃得消。一个问题，一整天，踏踏实实。
现在呢？他一天要碰六个不同的问题。每个都"只需要一小时"，毕竟有 AI 嘛。但六个问题之间来回切换，对人脑来说成本极高。
AI 在问题之间跳来跳去不会累。人会。
这就是那个悖论：AI 降低了生产成本，却抬高了协调、审核和决策的成本。而这些成本，全落在人身上。
HN 上有条评论把这个悖论放到了更大的历史视角里。用户 tangotaylor 翻出了海伦·凯勒 1932 年写的一段话——没错，将近一百年前：
"我想说的只有一点：是时候让我们的省力机器真的去省力了，而不是拿它来漫无目的地往全国倾泻过剩的商品，堵住贸易的渠道。"
一百年了。省力的工具从来没让人省过力。它们只是让你多产出了。
另一位用户 zkmon 说得更直白：
"技术从来不是为了让干活的人活得轻松一点，而是为了让他们更能干、让产品更有竞争力。从马到汽车，你没多出来什么空闲时间。从座机到智能手机，你也没多出来什么钓鱼时间。你只是更忙了、更高效了、更随叫随到了。"
二、你变成了审核员，但没人问过你愿不愿意
工程师以前的日子是什么样的？想问题、写代码、测试、发布。你是创造者，是建造者。大多数人当初入行，就是冲着那种"亲手把东西做出来"的感觉来的。
现在呢？越来越像这样：写提示词、等、读输出、判断对不对、安不安全、合不合规范、修掉不对的、重新写提示词……如此循环。
你变成了审核员。流水线上的质检工。而这条流水线永远不会停。
HN 用户 geetee 打了个精辟的比方：
"谁能想到呢——管理一个十人团队，成员偶尔天才、但大多数时候不靠谱——会这么累。"
创造让人兴奋，审核让人疲惫。
心理学研究早就说过，"生成性任务"和"评估性任务"对大脑的消耗完全不同。生成性的工作能让你进入心流——全神贯注、忘了时间的那种状态。而评估性的工作带来的是决策疲劳——做了太多小决定之后，大脑罢工。
HN 用户 Chance-Device 从神经科学的角度给了一个更准确的说法——执行功能疲劳（Executive Function Fatigue）：
"以前你是在'运用技能'的间隙才需要做高层决策，但现在你一直在做决策、一直在推理各种可能性。你几乎没有喘息的时间——因为不用自己动手了，你从一个难题直接跳到下一个，中间几乎没有缓冲。你的前额叶皮层大概比平时热多了。"
有一周 Siddhant 密集地用 AI 写一个新的微服务，到周三的时候，他发现自己连最简单的决定都做不了了。
这个函数叫什么？随便。
这个配置放哪儿？随便。
脑子满了。
问题出在判断了太多代码。每天成百上千个小判断，像水滴一样积起来，最后溢了。
更讽刺的是，AI 写的代码反而比同事写的更需要仔细审查。为什么？因为你的同事有习惯、有偏好、有盲区，你心里有数，知道哪些可以略过、哪些要盯紧。
但 AI 呢？每一行都可疑。代码看起来很自信，能编译，甚至能跑通测试。但它可能以一种极其隐蔽的方式出错——只有在线上环境里、在高负载下、在凌晨三点才会炸。
三、"保姆疲劳"——你再也进不了心流了
原文之外，HN 社区贡献了一个特别贴切的新角度。
用户 parpfish 描述了一种他叫做"保姆疲劳"的状态：
"我的疲劳感不太一样——是在'干一点活/写一点代码/审查一下'和'停下来等 AI 出结果'之间不停切换。等多久完全不确定，所以你永远不知道该继续等还是切去干别的。于是你就随便做点小事打发时间。你永远进不了心流状态，那种'一直要盯着后台任务跑没跑完'的警觉感把你磨得筋疲力尽。我不觉得自己更高效了——我觉得自己像个偷懒的保姆，勉强确保孩子们不会伤到自己就行。"
这条评论引发了巨大共鸣。用户 ericmcer 的回复说出了很多工程师的心声：
"说真的，除了生产力，心流状态是我最喜欢这份工作的地方。一杯咖啡、一副降噪耳机、两小时沉浸式编程——那是我最热爱编程的时候。"
这可能是 AI 对工程师最隐蔽的伤害：不是取代了你的工作，而是偷走了你工作中最快乐的部分。
四、确定性消失了
工程师是靠"确定性"吃饭的。
相同的输入，相同的输出。这是契约。有了这个契约，调试才成立，推理才可能。
AI 把这个契约撕了。
Siddhant 有一个提示词，周一用的时候完美无缺，生成的代码干净漂亮。周二用同一个提示词写一个类似的功能，结果完全变了样——错误处理方式换了，还多引入了一个他根本没要求的依赖库。
为什么？没有为什么。
或者说，没有他能看得到的为什么。没有报错日志告诉你"模型今天决定走另一条路了"。没有任何解释。它就是不一样了。
对一个一辈子都靠"出了问题我就能查出来"这句话吃饭的人来说，这很不安。没有什么戏剧性，就是一种慢慢磨人的、像背景噪音一样的焦虑——你永远没法完全信任输出，永远没法完全放松。
你在跟一个概率系统合作，但你的大脑是按确定性系统长大的。
这种错配本身，就是一种持续的、低级别的压力源。
那些适应得最好的工程师怎么做的？他们跟这件事和解了。把 AI 的输出当成一个聪明但不靠谱的实习生交上来的初稿。默认要重写 30%，时间也留好。输出错了不生气——因为他们从来就没指望它是对的。
他们指望的是——它有用。
这是两回事。
五、永远追不上的焦虑
试试跟上过去几个月的节奏：
Claude 出了子代理，又出了 Agent SDK。OpenAI 出了 Codex CLI，又出了 GPT-5.3。GitHub 加了 MCP 注册表。Google 出了 Gemini CLI。CrewAI、AutoGen、LangGraph、MetaGPT——选一个框架吧，下周又有新的。"Vibe coding"成了一个热词……
这还不是一年的量，只是几个月。而且还漏了很多。
Siddhant 深陷其中。周末都在评估新工具，每个更新日志都看，每个演示都追。因为怕——怕落后。
一个编程助手换一个，再换一个，然后又换回第一个。每次迁移搭进去一个周末，改善大概 5%——还没法准确测量。
最糟的是知识在贬值。他在 2025 年初花了两周时间搭了一套精心设计的提示词工程流程。系统提示、少样本示例、思维链模板，都打磨过了。效果很好。三个月后模型更新了，最佳实践变了，他一半的模板效果反而不如一句简单的指令。
那两周就这么没了。不是投资，是消费。
后来他想通了：不再追每一个新工具，转去深耕工具底下的基础设施层。 工具来了又走，但它们要解决的问题不会变——上下文效率、Agent 授权、审计追踪、运行时安全。这些才是持久的东西，不管这个月流行什么框架。
把自己建在不会剧烈变化的那一层上，才是聪明的做法。
六、"再来一个 prompt"的陷阱
这个陷阱特别隐蔽。
你想让 AI 生成一个特定的东西。第一次出来 70% 对了。于是你调一下提示词。第二次 75% 对了，但第一次对的部分反而坏了。第三次 80% 对了，但结构全变了。第四次——你已经在这上面耗了 45 分钟，而你本来 20 分钟就能自己写完。
Siddhant 管这叫**"提示词螺旋"（Prompt Spiral）**。
提示词螺旋最危险的地方在于它感觉像是有进展。你在迭代，在逼近目标，每次都好一点点。但边际收益掉得飞快。而你忘了——目标从来不是"让 AI 给出完美的输出"。目标是把东西发出去。
他现在有一条硬规矩：
三次。
三次提示词之内如果出不来 70% 能用的东西，就自己写。没有例外。这条规矩比他学过的任何提示词技巧都管用。
七、70% 的心理陷阱
工程师天生爱较真。我们喜欢干净的代码、跑过的测试、行为可预测的系统。
但 AI 的输出永远不完美。永远是差不多、七八成的样子。变量名有点不对，错误处理不完整，边界情况没考虑。能用，但不对。
对完美主义者来说，"差一点"比"完全错"还难受。完全错了，扔掉重来就好。差一点，你得花一个小时去调——而且你调的是别人做的决定。一个不了解你的品味、不了解你的上下文、不了解你的标准的系统做出的决定。
HN 用户 preommr 给这种心理起了个名字——"感知成本厌恶"：
"AI 生成了一个功能能用但质量 70% 的方案。但要改进它却让人特别痛苦——花一个多小时去优化一个一分钟就生成出来的东西，感觉太亏了。而且你得真正深入去理解问题和方案，不能表面上 LGTM（看着没问题）就过了。既然能用，那何必费劲呢？——但长期来看，技术债会以极快的速度堆起来。因为你现在是用 AI 来生产的。"
Siddhant 后来学会了放手。他还是在意质量的。他放弃的是**"AI 应该给出高质量输出"这个期望**。每一个 AI 输出都当草稿。一个起点。原材料。在心里贴上"草稿"的标签——就这么一个转变，挫败感就少了一半。
他还发现了一个讽刺的规律：
被 AI 折磨得最厉害的工程师，往往是最好的工程师。 标准最高的那些人，每个瑕疵都看得见的那些人。AI 奖励的是另一种能力——从不完美的输出里快速提取价值，不在"让它完美"上投入太多情感。
八、大脑在退化——这是最可怕的
Siddhant 说这是最让他害怕的一件事。
他是在一次设计评审会上意识到的。有人让他在白板上推导一个并发问题——就是程序同时处理多件事时的逻辑冲突。没有电脑，没有 AI，就他和一支马克笔。
他卡住了。
不是因为不懂。他懂。但他好几个月没练过这块"肌肉"了。初步思考全外包给 AI 太久了，从零开始想问题的能力退化了。
就像 GPS。没有导航的年代，你脑子里有地图，你认识你的城市，能自己规划路线。用了几年导航之后，离开它你就不会走路了。技能退化了，因为你不用了。
当你什么事都先问 AI，你就不再去建立那些"自己跟问题较劲"时才会形成的神经通路。较劲才是学习发生的地方。困惑才是理解形成的地方。跳过这些，你得到更快的输出，但更浅的理解。
他现在的做法是：每天第一个小时不碰 AI。
在纸上想，用手画架构，用笨办法推理问题。效率低吗？确实低。但它让思维保持锋利。而这种锋利，后面用 AI 的时候会产生回报——你的脑子热了，才更能判断 AI 给你的东西靠不靠谱。
九、一个机械车间的故事
这篇文章讲的是软件工程师的疲劳，但 HN 上最打动人的一条评论，来自一个完全不同的行业。
用户 clejack 讲了他二十多岁在汽车零件机械车间实习的经历：
"一般来说活儿不算重。我改改 CAD 图，在 CNC 机床上跑跑试切，装上原材料，卸下成品。通常机器运转的节奏会留给我不少喘气的时间。但有一次碰到一个活——机器铣削速度太快了，我装料卸料的时间比做其他任何事都多。从第一个零件开始，我就再也没停过，一直干到全部结束。最后背扭伤了。我很震惊——我身体素质不差，搬的东西也不重。"
"不管个人感受如何，当工作流程发生文章里描述的那种突然逆转时，人总会受到影响。"
机器变快了，但装料卸料的是人。AI 变快了，但审核判断的也是人。不管你是在写代码还是在搬零件——瓶颈转移到了人身上，而人是有极限的。
十、反方观点：也有人说"我反而更轻松了"
公平起见，不是所有人都累。
HN 用户 bonoboTP 的体验完全相反：
"我个人压力小了很多。最近几个月心情好了不少。不那么担心漏事、漏问题、不知道从哪儿下手、一个人干活时的规划和排优先级了。'脑子里一团浆糊'的感觉少了很多。上下文切换也更顺了，苦力活少了，不用再花几个小时跟某个安装问题死磕了。全是一百万个小小的生活质量改善。"
这条评论其实恰好印证了原文的观点——疲劳不是 AI 本身造成的，是使用方式造成的。 bonoboTP 是独立工作者，自己决定做什么、做多少、什么时候收工。他没有"基准线上移"的问题，因为没人在移他的基准线。
另一位独立开发者 idopmstuff 也说了类似的话：
"正是这两件事加在一起，让我庆幸自己几年前辞职创业了。一个人干，用 AI 干活开心得很。长期来看，AI 一定会推动公司规模缩小。"
关键不在于 AI 好不好，而在于——谁在控制你的工作节奏？是你自己，还是一条永远在提速的流水线？
十一、Redis 之父的六条生存法则
所有讨论里，Redis 的创造者 antirez（Salvatore Sanfilippo）的评论获得了最高的认同。他没有抱怨，直接给了六条能用的建议：
1. 大段地休息。 干 1 小时，停 30 分钟以上。或者换种方式——每天只干半天（上午 2 小时 + 晚上 2 小时），产出比以前全天还多。生产力提升了，应该换来更多休息，不是更多活。
2. 不要同时干 N 件事。 专注地、深入地推一个项目。
3. 不要因为"反正现在做起来快"就什么都干。 只做真正重要的。
4. 人走了，让 Agent 继续跑。 把它放到对的方向上，让它去迭代代码质量、安全、性能、测试。回来检查结果，垃圾扔掉，好的留下（如果有的话）。这样提高了产出，但不压榨你。
5. 即使不再亲手写代码，也要保持极简。 在 prompt 和 AGENT.md 文件里告诉 Agent：保持专注、不加没用的依赖、不加复杂度、控制代码量、只有"复杂度的投入产出比"合理时才改进。
6. 把心流转向写规格说明。 停下来，花大块时间、不受打扰地写规格说明。这能极大提升 Agent 的产出质量。而对你来说，这是一段安静的、深度专注的时间。
有人质疑"打工人哪有可能干 1 小时歇 30 分钟"。这确实是个问题。但 antirez 的核心洞察不在具体的时间怎么分，而在一个根本性的态度转变：
AI 带来的效率提升，应该换来更多的休息和思考，不是更多的活。
十二、代码是负债
最后，HN 用户 tempodox 说了一句我觉得所有人都该记住的话：
"历史上，生产力提升从来没有改善过实际劳动者的生活。只是让工厂主更富了。而用 AI 衡量生产力的方式是'更快地写更多代码'——这是软件开发里最蠢的指标。记住，代码是负债。产出 10 倍的代码不是 10 倍的生产力。"
代码是负债——这话在软件行业流传已久，但在 AI 时代有了全新的重量。当 AI 一小时就能吐出几千行代码的时候，"写得多"变成了全世界最容易的事。但维护这些代码、理解这些代码、为这些代码的 bug 负责——这些成本不会因为 AI 而消失。只会成倍地涨。
写在最后
AI 时代真正的核心技能是什么？
不是提示词工程，不是知道该用哪个模型，不是搭出完美的工作流。
是知道什么时候该停。
知道 AI 的输出什么时候够用了。知道什么时候该关掉它自己写。知道什么时候该合上电脑。知道那一点点边际改进不值得你再搭半小时。知道你的大脑是有限的资源，保护它不是偷懒——是工程素养。
我们给系统加熔断器，加背压，做优雅降级。我们也该给自己加上这些东西。
在这个时代活得好的工程师，不会是用 AI 最多的人。而是用得最聪明的人。
如果你累了，你没做错什么。这确实很难。工具是新的，模式还在摸索，而整个行业都在假装——更多产出就等于更多价值。
不是这样的。可持续的产出才是。
照顾好你的大脑。它是你唯一的，没有任何 AI 能替代它。
📎 原文链接：siddhantkhare.com/writing/ai-fatigue-is-real
💬 HN 讨论：news.ycombinator.com/item?id=46934404
📌 点赞 + 在看 + 分享，让更多人看到这篇"行业不愿意承认"的真相