AI 用45分钟搞定原本3小时的工作，工程师直言：我现在更累了！

你用上了 AI，本来是想把效率拉满：写代码更快、查资料更省事、连思路都有人随时帮你捋清楚。可现实却有点反直觉——事情确实做得更多了，人却比以前更累了。

这种“效率越高，疲惫感越强”的状态，正在不少工程师身上反复上演。它不像加班那样显眼，却更隐蔽，也更难说清楚：明明工具更强了，为什么反而停不下来？为什么总觉得脑子一直在转，却很少真正休息过？

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

作者 | Siddhant Khare 编译 | 苏宓
出品 | CSDN（ID：CSDNnews）

我在上个季度发布的代码量，超过了职业生涯中的任何一个季度。同时，我也比以往任何时候都更疲惫。

这两件事之间并非毫无关联。

我日常就是以构建 AI Agent 的基础设施为生。我是 OpenFGA（CNCF 孵化项目）的核心维护者之一，我开发了用于 Agent 授权的 agentic-authz（https://github.com/Siddhant-K-code/agentic-authz），也开发了用于上下文去重的 Distill（https://distill.siddhantkhare.com/），还发布了 MCP 服务器。我不是那种“随便玩玩 AI”的工程师，我是深度参与其中的人，我自己所构建的工具，做的就是让其他工程师能把 AI Agent 真正跑在生产环境里。

但即便如此，我还是撞上了“南墙”。那种精疲力竭的感觉，不是换点工具、调优一下流程就能解决的。

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

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

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

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

有一段时间，真正把我“绕晕”的，其实是这样一件事：AI 的确能让单个任务变快，这一点毫不虚假。以前要花我 3 个小时的事，现在 45 分钟就能搞定。写设计文档、搭一个新服务的框架、编写测试用例、研究一个不熟的 API，速度都大大提升了。

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

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

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

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

现在呢？一天之内，我可能要同时碰六个不同的问题。每一个都“只需要一小时，用 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 版的“剃牦牛毛”（yak shaving，指本来简单的目标被复杂化的过程）。一开始你目标清晰，但三十分钟后，你调的不是代码，而是提示词；你优化的不是功能，而是让模型更懂你的指令。

提示词螺旋特别危险，因为它看起来很高效。你在不断迭代，似乎越来越接近目标，每一次尝试都略有进步。但边际收益在迅速下降，而你已经忘了最初的目标从来不是“让 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% 就好：停止追求完美输出，70% 可用就是底线，其余自己补全。这条规则是我工作流中减少 AI 挫败感的最大因素。

• 战略性看待炒作周期：我关注 AI 生态，因为要为其搭建基础设施，但不再第一时间上新工具。我选择一个主要编程助手，深入使用；新工具在经过几个月验证后再评估。了解趋势和被动跟风，是两回事。

• 记录 AI 的适用场景：我做了两周简单日志：任务、是否用 AI、花费时间、结果满意度。数据很清楚：AI 在模板化、文档、测试生成上省时，但在架构决策、复杂调试、需要深度上下文的地方反而耗时。现在我知道什么时候该用它，什么时候该靠自己。

• 不审查 AI 的每一行输出：这很难接受，但当你用 AI 生成大量代码时，物理上无法用同样严格的标准审查每一行。我把精力放在最关键部分——安全边界、数据处理、错误路径，其余依靠自动化测试和静态分析。非关键代码的小瑕疵可以容忍。

可持续性的问题

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

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

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

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

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

讽刺的是，倦怠期也是我最有产出的时期。停止追逐每一个 AI 工具，开始关注真正的问题时，我第一次看清了痛点：

上下文窗口被垃圾填满 → 于是有了 Distill

Agent 拥有全或无的 API Key 访问权限 → 于是有了 agentic-authz

无法审计 Agent 实际操作 → 正在开发 AgentTrace

疲惫迫使我停止“消费”，开始“创造”。不是更快地增加功能，而是有意识地构建真正重要的东西。

真正的技能

我认为，AI 时代真正的技能，不是提示词工程，也不是选模型，也不是完美工作流。

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

知道 AI 输出什么时候够用了。知道什么时候自己动手写。知道什么时候合上电脑。知道什么时候追求微小提升不值得付出认知成本。明白大脑是有限资源，保护它不是懒惰，而是一种工程智慧。

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

AI 是我用过的最强大工具，同时也是最消耗精力的工具。两者都是真的。能在这个时代茁壮成长的工程师，不是用 AI 最多的人，而是用得最明智的人。

如果你感到疲惫，不是因为你做错了，而是因为这真的很难。工具是新的，模式尚未形成，整个行业还在假装“更多输出等于更多价值”。其实并非如此——可持续的产出才是价值。

我仍每天在这个领域工作：agent 授权、上下文工程、审计轨迹、运行时安全——构建让 AI agent 在生产环境中真正可用的基础设施。我比以往任何时候都更投入 AI，但我以自己的节奏、自己的方式投入，构建有意义的东西，而不是追逐潮流。

照顾好你的大脑，它是你唯一的，而且没有任何 AI 能替代它。