“每给 Claude Code 提一个请求，我就点上一根烟，放松下”

整理 | 褚杏娟

OpenFGA 核心维护者、Ona（前 Gitpod）软件工程师 Siddhant Khare 最近写了一篇博客吐槽了自己在使用 AI 编程中的“疲惫感”。

他以自身经历指出 AI 带来的职业疲惫真实存在且被行业集体回避：单任务变快≠工作变轻松，反而更累，期间工程师任务量膨胀、频繁切换引发深层耗竭；工作角色从创造者转为高消耗的 AI 产出评审者，加之 AI 输出的不确定性打破了工程师熟悉的确定性逻辑，持续带来焦虑。

同时，行业技术迭代过快形成 “FOMO 跑步机”，频繁追新工具造成时间浪费与知识衰减，还易陷入 “prompt 螺旋” 陷阱，长期依赖更会导致独立思考能力退化，社交媒体的高光展示则进一步加剧比较焦虑。他指出，AI 时代工程师的核心能力并非极致使用 AI，而是懂得设边界、及时停止，保护认知资源，追求可持续的长期产出。

他的博文引发了工程师们的共鸣。

“对我来说，这种疲惫感有点不一样，它来自于不断在‘写一点代码 / 做一点工作 / 看一点 review’和“‘停下来等大模型生成结果’之间来回切换。等待的时间是不可预测的，你根本不知道是该继续等，还是该切去做别的事。于是你只能在机器“思考”的时候，随便干点事打发时间。

你永远进不了心流状态，只能时刻盯着后台任务什么时候跑完。这种持续的“警觉等待”会让人特别消耗精力。我并不觉得自己更高效了，反而感觉自己像个偷懒的保姆，只是勉强看着孩子别把自己弄伤而已。”开发者 Parpfish 跟帖道。

“我知道这建议听起来既不负责任又很幼稚，但我现在的做法是：每次给 Claude Code 提一个不知道要跑多久的请求，我就点上一根烟，放松一下。有时候我也会切去玩那种随时拿起来、随时放下都不影响的小游戏。”

“对我个人来说，编程很多年前就没什么乐趣了，”Parpfish 也表示，“但有了 Claude Code 之后，我又重新觉得好玩起来了。虽然感觉不一样，但在我现在这个人生阶段，这样反而更让我享受。”

下面是 Siddhant Khare 的文章，我们进行了翻译，以飨读者。

AI 疲惫真实存在，

但几乎没人谈

你用 AI 是为了更高效，为什么反而比以前更累？这是每个工程师都得正视的悖论。

上个季度，我交付的代码量超过职业生涯任何一个季度；同时，我也比职业生涯任何一个季度都更疲惫。这两件事并不矛盾，甚至高度相关。

我的工作就是搭建 AI agent 的基础设施。我是 OpenFGA（CNCF Incubating）的核心维护者之一；做过用于 agent 授权的 agentic-authz；做过用于上下文去重的 Distill；上线过 MCP servers。我不是偶尔玩玩 AI 的那种人，我在这个领域深扎很久，我写的工具，正被其他工程师拿去把 AI agents 跑进生产环境。

但即便如此，我还是撞墙了。那种疲惫不是换一套工具、再优化一点流程就能解决的，而是一种更底层的耗竭感。

如果你是每天都在用 AI 的工程师，做设计评审、生成代码、排查 bug、写文档、做架构决策，并且你发现自己在“AI 时代”反而比以前更累，那这篇文章就是写给你的。你没有在幻想，也不是你不够强。你感受到的是真实存在的东西，只是行业在集体回避它：大家拼命讲效率、讲产出，却不讲代价。一个全职做 agent 基建的人都能在 AI 上 burnout，这件事可能发生在任何人身上。

我想实话实说。不是那种“AI 太神了，这是我的工作流”的版本，而是真实版本：夜里 11 点，你盯着屏幕，周围堆着一大片 AI 生成的代码还得你去 review，你开始怀疑那个本该帮你省时间的工具，为什么反而吞掉了你整天的时间。

没有人提醒过我们的悖论

有件事我曾经想了很久才想明白：AI 的确能让单个任务更快，这不是谎言。以前要 3 小时的事情，现在 45 分钟就能搞定，写设计文档、搭服务骨架、补测试用例、研究不熟的 API……都更快了。

但我的工作日变得更难了，不是更轻松，而是更难。

原因一旦看清就很简单，只是我花了几个月才真正意识到：当每个任务变快，你不会做更少的任务，你只会做更多。你的“产能”看起来提升了，于是工作会膨胀来填满它，甚至还会超出。你的领导看到你交付变快了，预期会跟着调整；你看到自己交付变快了，对自己的预期也会跟着调整。基准线被整体抬升。

在 AI 之前，我可能会用整整一天只专注一个设计问题：在纸上画草图、洗澡时想、出去走走、回来突然清晰。节奏慢，但认知负担可控，一天只扛一个问题，深度专注。

现在呢？一天可能要摸六个问题。每个问题都“只要一小时，AI 帮你很快搞定”。但在六个问题之间来回切换，对人脑的代价极其昂贵。AI 不会在问题之间疲惫，我会。

这就是悖论：AI 降低了“生产”的成本，却抬高了“协调、评审、决策”的成本，而这些成本几乎全部落在人的身上。

你变成了 reviewer，

而你从没签过这份合同

以前我的工作流程是：想清楚问题 → 写代码 → 测试 → 发布。我是创造者，是建造者，这也是很多人最初喜欢工程的原因：能亲手把东西做出来。

AI 之后，我的工作越来越像：写 prompt → 等 → 读输出 → 评估输出 → 判断是否正确 → 判断是否安全 → 判断是否符合架构 → 修不对的部分 → 再 prompt → 再重复。我变成了审稿人、裁判、质检员，站在一条永不停歇的流水线旁边。

这是一种完全不同的劳动类型。创造会给人能量，评审会消耗能量。相关研究早就指出，“生成型任务”和“评估型任务”在心理体验上截然不同：生成更容易进入心流，评估更容易触发决策疲劳。

我第一次明确意识到这点，是在某一周用 AI 重度开发一个新 microservice 的时候。到周三，我连简单的决定都做不动了：这个 function 该叫什么？无所谓。配置放哪？也无所谓。我的大脑不是因为写代码累，而是因为“判断代码”累，每天一整个时间都在做无数个细小判断，会把你掏空。

更残酷的是：AI 生成的代码，往往比人写的更需要谨慎 review。人写的代码我大致知道对方的习惯、长处、盲点：可信的地方可以快扫，不放心的地方重点看。AI 不一样，每一行都值得怀疑。代码看起来很自信，能编译，甚至能过测试，但可能在极隐蔽的地方错得很深，直到线上、在高压负载下、凌晨三点才爆出来。

于是你只能逐行读。读自己没写过、由一个不了解你代码库历史和团队约定的系统生成出来的代码，是一种非常消耗人的工作。

这也是为什么我一直觉得 agent 安全和权限这么重要。我们不可能 review AI 产出的所有东西，规模一上来就做不到了，那就必须先在系统层面约束 agent 能做什么：最小权限原则、范围限制 tokens、审计轨迹。你越不需要担心“AI 会不会做出危险动作”，你越能把认知预算留给真正重要的工作。这不仅是安全问题，更是“人能否长期承受”的可持续问题。

非确定性问题：AI 破坏了

工程师最熟悉的契约

工程师从业训练的底层假设是确定性：同样的输入，得到同样的输出。它是调试的基础，也是系统推理的基础。

AI 把这份契约撕了。

我有个 prompt 周一跑得完美，生成了结构清晰、很干净的 API endpoint。周二我用同样的 prompt 做一个类似 endpoint，输出结构却明显不同，这次错误处理换了套路，还引入了我没要的依赖。

为什么？没有原因。更准确地说，没有我能触达的原因。这里没有“模型今天换了想法”的 stack trace，也没有日志告诉你“temperature sampling 走了 B 路径不是 A 路径”。它就是……不一样了。

对一个职业生涯建立在“坏了我就能找到为什么”的人来说，这种体验会带来持续的、背景噪音式的焦虑。它不一定戏剧化，却足够磨人。你无法完全信任输出，也无法真正放松，每一次交互都必须保持警惕。

我试过对抗，给 prompt 做版本控制，写复杂的 system message，做模板。一部分有用，但都无法解决根本矛盾。你在和一个概率系统协作，而你的大脑天生更擅长确定性系统，这种错位会长期产生低强度压力。

也正因为这种挫败感，我后来做了 Distill：为 LLM 做确定性的上下文去重，不调用 LLM，不用 embeddings，也不靠概率启发式，而是用纯算法，在大约 12ms 内把 context 清理干净。我至少想让 AI pipeline 里有一段东西是可推理、可调试、可信的。模型输出再怎么不确定，输入至少要干净、可控。

我发现适应得最好的一批工程师，通常已经“和不确定性和解”了。他们把 AI 当作一个聪明但不靠谱的实习生写的初稿，默认要重写其中 30%，并且提前把这部分重写时间算进计划。他们不会因为输出错了而愤怒，因为他们从来没期待它“正确”，只期待它“有用”。这两者差别很大。

“FOMO 跑步机”：你永远追不上

深呼吸一下，试着只跟上最近几个月的变化：Claude Code 先发 sub-agents，再发 skills，再发 Agent SDK，再发 Claude Cowork；OpenAI 上线 Codex CLI，又上 GPT-5.3-Codex，一个甚至“参与了自我编写”的模型；新的 coding agents 宣布 background mode，可并发上百个 autonomous sessions；Google 推出 Gemini CLI；GitHub 增加 MCP Registry；并购几乎每周发生；Amazon Q Developer 得到 agentic 升级；CrewAI、AutoGen、LangGraph、MetaGPT，随便挑一个 agent framework，每周都冒出新版本；Google 发布 A2A（Agent-to-Agent protocol）对标 Anthropic 的 MCP；OpenAI 发布自己的 Swarm framework；Kimi K2.5 采用 agent swarm 架构，编排 100 个并行 agents；“Vibe coding”成了热词；OpenClaw 上线 skills marketplace，一周之内研究者在 ClawHub 发现 400+ 恶意 agent skills；与此同时 LinkedIn 还会冒出一句话：“2026 年不做 sub-agent orchestration，你就已经过时了。”

这还不是一年发生的事，是短短几个月，并且我还漏掉了很多。

我也曾深陷其中：周末不断评测新工具，追每一条 changelog，看每一个 demo，拼命留在所谓“前沿”，因为我害怕落后。

现实是什么？周六下午我搭起一个新的 AI coding tool，周日形成基本 workflow，而到了下周三，社交网络开始吹另一个“更强”的工具，我就会焦虑；下一个周末又去搭新的，旧的躺着吃灰。从一个 coding assistant 迁到下一个、再迁下一个，最后又回到第一个，每次迁移耗掉我一个周末，换来大概 5% 的提升，而且我还很难测出来。

把这种循环乘以所有类别：coding assistants、聊天界面、agent frameworks、多 agent 编排平台、MCP servers、context 管理工具、prompt 库、swarm 架构、skills marketplace，你会变成一个永远在学习新工具、却从没真正把任何一个工具用深的人。Hacker News 首页就足够让人眩晕：今天是“Show HN：Autonomous Research Swarm”，明天是“Ask HN：AI swarms 怎么协作？”没人知道答案，但大家都在造。

更糟糕的是知识衰减。我在 2025 年初花了两周搭出一套复杂的 prompt 工程流程：精雕 system prompts、few-shot examples、chain-of-thought 模板。它当时非常好用，三个月后模型更新，最佳实践迁移，一半模板反而不如一句简短指令效果好。那两周不是“投资”，而是“消耗”。我的 MCP server 也是：我写了五个自定义 servers（Dev.to 发布、Apple Notes 集成、Python/TypeScript 沙盒等），后来协议演进，GitHub 上线 MCP Registry，突然出现成千上万预制 servers，我的部分工作一夜之间变得可有可无。

Agent framework 的 churn 更夸张。我见过团队一年内从 LangChain → CrewAI → AutoGen → 自研编排连续迁移。每次迁移都意味着重写集成、重学 API、重建 workflow。那些选择“等等再说”的团队，很多时候反而比早早冲进去、被迫迁两次的人更占便宜。

后来我换了策略, 不再追每个新工具，而是深挖它们下面的基础设施层。工具会来会走，它们解决的问题不会。context 效率、agent authorization、audit trails、runtime security，这些是跨框架、跨周期的耐久问题，这也是我把 agentic-authz 建在 OpenFGA 上、而不是绑死某个 agent framework 的原因；也是 Distill 做 context 层、而不是 prompt 层的原因：要构建在不那么 churn 的层上。

我仍然会密切关注生态，做基础设施的人必须如此。但我关注是为了理解方向，而不是把每个新东西都立刻搬进生产。信息充分和被动反应，是两回事。

“再改一版 prompt

就好了”陷阱

这个陷阱非常阴险：你让 AI 生成一个很具体的东西，第一版 70% 是对的；于是你 refine prompt；第二版 75% 的对，但把第一版对的地方弄坏了；第三版 80% 对，但结构又变了；第四次你回过神来，已经 45 分钟过去了，而你自己从头写可能 20 分钟就写完。

我叫它 prompt spiral，AI 时代的 yak shaving。你原本有明确目标，半小时后却在调 prompt，而不是写代码。你在优化“给模型的指令”，而不是解决真正的问题。

更危险的是，prompt spiral 会让你产生“我在推进”的错觉。每一轮都有小进步，你会继续投入，但边际收益正在快速递减，你甚至忘了目标从来不是“让 AI 产出完美内容”，而是交付功能。

我现在有一条硬规则：三次。三次 prompt 内拿不到 70% 可用的结果，我就自己写，没有例外。这条规则省下的时间，超过我学过的任何 prompt 技巧。

完美主义遇上概率输出：

最优秀的人往往最难受

工程师倾向完美主义：喜欢干净代码、喜欢测试全绿、喜欢可预测系统。这不是缺点，是我们能做出可靠软件的原因。

但 AI 输出从来不是“完美”，永远是“还不错”，大约 70–80%：变量名不对味，错误处理不完整，边界条件没考虑，抽象不符合你的代码库。能跑，但“不对”。

对完美主义者来说，这很折磨，因为“差一点对”比“完全错”更糟。完全错，你直接丢掉重来；差一点对，你会花一小时去修修补补。修 AI 输出尤其痛苦，因为你在修“别人做的设计决策”，而这个“别人”并不分享你的审美、你的上下文和你的标准。

我不得不学会放下。不是放下质量，我仍然在乎质量，而是放下“AI 会产出质量”的期待。我现在把每次 AI 输出都当作毛坯、当作起点、当作原材料。它出现的那一刻，我脑子里就贴上“draft”的标签。仅仅是这个心智框架的变化，就让我的挫败感减少了一半。

很多在 AI 上最痛苦的工程师，恰恰是最好的工程师：标准最高、细节最敏感、瑕疵一眼就能看出来。AI 奖励的反而是另一种能力：能快速从不完美的输出里榨取价值，而不把情绪绑定在“把它打磨到完美”。

思考能力在萎缩：

这才是最让我害怕的

我在一次设计评审会上发现了这个问题。有人让我在白板上推一个并发问题，没有电脑、没有 AI，只有我和一支笔，我居然卡住了。不是我不懂概念，我懂，而是我几个月没练这个“肌肉”了。我把“第一轮思考”外包给 AI 太久，导致从零推理的能力在退化。

它像 GPS 和导航。没有 GPS 的年代，你会建立城市的心理地图，能自己推路线。用了多年 GPS，你离开它就不会走了，因为这项技能已经萎缩。

AI 对工程思考也是一样：当你总是先问 AI，你就少了自己挣扎的过程。而学习就发生在挣扎里：困惑是理解成形的地方。跳过它，你会更快拿到输出，但理解会更浅。

我现在刻意让每天的第一个小时不碰 AI：在纸上思考、手绘架构、用慢的方法推问题。它确实低效，但它让我的思考保持锋利，而锋利的思考会在我之后使用 AI 时带来回报。因为你自己的推理被“热身”后，你对 AI 输出的评估会更准确。

比较陷阱：社交媒体

只展示高光，不展示代价

社交媒体上到处都是“看起来已经把 AI 玩明白的人”：晒 workflow、晒产出数据、晒“我两小时用 AI 做完一个 app”。你回头看自己的经历：prompt 失败、时间浪费、生成代码不得不重写，于是你开始怀疑自己是不是哪里不对。

你没有任何问题。那些帖子是高光剪辑。没人会发：“我花了三小时让 Claude 理解我的数据库 schema，最后放弃，迁移还是手写。”没人会发：“AI 生成的代码线上吞错导致事故。”没人会发：“我很累。”

更麻烦的是，AI 技能很难衡量。传统工程里，你看看代码大致能判断水平；AI 输出却受模型、prompt、上下文、temperature、甚至玄学因素影响。别人一个惊艳 demo，很可能在你的机器、你的代码库上复现不出来。

我后来对 AI 内容变得更挑，我仍然关注这个领域，毕竟是工作，但我更少看“热闹”，更多看“真的在建和在交付的人”。信号和焦虑的比例很重要。如果一个信息流让你更焦虑而不是更清醒，那它就不在为你服务。

真正有用的改变是什么

我具体说说，哪些做法让我的 AI 使用方式从对抗变成可持续。

• 给 AI 使用设时间盒。我不再开放式使用 AI，会设定计时器：这件事用 AI 30 分钟，时间到就交付现状或自己写。它同时拦住了 prompt spiral 和完美主义陷阱。

• 把思考时间和执行时间分开。早上用来思考，下午用来 AI 辅助执行。规则不绝对，但有默认结构，就能确保大脑既锻炼也得到助力。

• 接受 AI 只做到 70%。我不再追求完美输出，70% 可用就够了，剩下我自己补。这个接受，是我减少 AI 挫败感最有效的一件事。

• 对 hype cycle 保持策略性。我会跟踪生态，但不再每个新工具一上线就立刻迁移。我只用一个主力 coding assistant，并把它用深。评估新工具看“几个月后的验证”，不看“几天内的热度”。信息充分和被动反应，是两回事。

• 记录 AI 什么时候帮忙、什么时候拖后腿。我做过两周简单日志：任务、是否用 AI、耗时、满意度。数据非常清晰：AI 在样板代码、文档、测试生成上省了大量时间；在架构决策、复杂调试、需要深代码库上下文的工作上反而耗时。知道这一点后，我更清楚什么时候该用它，什么时候不该用。

• 不再试图 review AI 产出的每一行。这很难接受，但如果你用 AI 生成大量代码，你不可能以同样严苛的标准逐行审。我的 review 精力集中在最关键的部分：安全边界、数据处理、错误路径；其它交给自动化测试和静态分析。非关键代码有一点粗糙是可以接受的。

可持续性问题：AI 不是治好

burnout，而是在放大它

科技行业的 burnout 早在 AI 之前就存在。AI 正在让它更严重，不是因为 AI 很坏，而是因为 AI 移除了曾经保护我们的“自然限速器”。

在 AI 之前，你一天能产出多少有上限：打字速度、思考速度、查资料的时间。这些限制有时令人沮丧，但它们也是一种“调速器”。工作本身会限制你把自己榨干的速度。

AI 拿掉了这个调速器。现在唯一的上限是你的认知耐力，而大多数人只有在把这条线冲破之后，才知道自己的极限在哪。

我在 2025 年末 burnout 了。不是戏剧化那种：我没有辞职，也没有崩溃。我只是开始不在乎了。code review 变成走过场，设计决策变成“AI 怎么说就怎么做”。我在机械地产出更多，却感受更少。我花了一个月才意识到发生了什么，又花了一个月才恢复过来。

恢复并不是“少用 AI”，而是“换一种方式用 AI”：设边界、有意图，并且承认我不是机器，我不需要跟机器同速。Working at Ona 让我更清楚看到这一点：当你为企业客户做 AI agent 基础设施，你会看到不可持续的 AI 工作流在规模化之后的“人类成本”。这不是个人问题，而是系统问题，必须在工具层面解决，而不只是靠个人硬扛。

讽刺的是，我最好的几个项目反而诞生在 burnout 期间。当我停止追工具、开始思考到底哪里坏掉时，问题第一次变得清晰：context window 被垃圾填满，这催生了 Distill；agents 拿着全权限 API key，这催生了 agentic-authz；无法审计 agent 做了什么，这正在变成 AgentTrace。疲惫迫使我停止消费、开始建设，不是更快地堆功能，而是更有意识地去做正确的东西。

AI 时代真正的技能

我认为 AI 时代最重要的技能不是 prompt engineering，不是知道该用哪个模型，也不是拥有“完美工作流”，而是知道什么时候该停。

知道 AI 输出什么时候“够用”；知道什么时候该自己写；知道什么时候该合上电脑；知道边际提升不值得继续消耗认知；知道你的大脑是一种有限资源，保护它不是偷懒，而是一种工程能力。

我们做系统会优化可持续性：加熔断、做 backpressure、设计优雅降级。我们也应该对自己做同样的事。

AI 是我用过最强的工具，同时也是最消耗人的工具，这两件事可以同时成立。能在这个时代长期活得好的工程师，不会是用 AI 用得最多的人，而会是用得最聪明的人。

如果你很累，不是因为你做错了，而是因为这件事本身就很难。工具很新，模式还在形成，行业却装作“更多产出 = 更多价值”。事实不是这样。可持续的产出才是价值。

我依旧每天都在这个领域里建 agent authorization、context engineering、audit trails、runtime security，让 AI agents 真正在生产环境可运行的基础设施。我对 AI 的投入比以往更深，但我会按自己的节奏、用自己的边界，去做真正重要的事，而不是追逐短暂的趋势。

照顾好你的大脑。它只有一个，而任何 AI 都无法替代它。

https://siddhantkhare.com/writing/ai-fatigue-is-real

声明：本文为 AI 前线整理，不代表平台观点，未经许可禁止转载。

会议推荐

InfoQ 2026 全年会议规划已上线！从 AI Infra 到 Agentic AI，从 AI 工程化到产业落地，从技术前沿到行业应用，全面覆盖 AI 与软件开发核心赛道！集结全球技术先锋，拆解真实生产案例、深挖技术与产业落地痛点，探索前沿领域、聚焦产业赋能，获取实战落地方案与前瞻产业洞察，高效实现技术价值转化。把握行业变革关键节点，抢占 2026 智能升级发展先机！

今日荐文

你也「在看」吗？