AI 疲劳是真实存在的：工程师用 AI 越多越累的底层原因与自救（v2）

这篇原文的信息密度很高，我把它按“工程师能直接照着改工作方式”的角度重新整理了一版。

一句话先立住：AI 让生产更便宜，但让判断更昂贵；而昂贵的部分，全部由人类大脑买单。

下面按作者的主线把“为什么更累”拆开，并给一组可执行的刹车策略。

1）悖论：单任务变快了，但一天更难了

AI 让单个任务变快，这是事实：原来 3 小时的活，现在 45 分钟。

但你不会因此做更少的事，你会做更多的事。作者给了一个非常直观的对比：

• 以前：一天解决一个设计问题，慢，但能深度思考。
• 现在：一天触碰六个问题，每个“用 AI 只要一小时”，但上下文切换对人类大脑极其昂贵。

AI 不会在问题之间累。你会。

结论就是那句很扎心的话：

• AI 降低了 production cost
• 却提高了 coordination / review / decision cost

而后者全部落在你身上。

2）你成了 reviewer，而且你没签过这份合同

作者描述得很真实：过去你的工作是“想清楚→写→测→发”。你是 maker。

现在你的循环变成：

prompt → 等输出 → 读输出 → 判断对不对/安不安全/合不合架构 → 修一部分 → 再 prompt → repeat。

这不是创作型工作，这是评审型工作。

创作会让人进入 flow，评审会制造 decision fatigue（决策疲劳）。

作者举了一个细节：某周他用 AI 写 microservice，到了周三连最简单的决策都做不动：

• 函数该叫什么？不在乎。
• 配置放哪？不在乎。

脑子满了，不是因为写代码，是因为“判断代码”。

3）残酷的反讽：AI 代码更需要审阅

作者指出一个反常识点：AI 产出的代码需要更谨慎审阅。

原因很现实：

• 同事写的代码，你知道他的习惯、强项与盲点，可以“信任一部分，重点看一部分”。
• AI 的代码每一行都“看起来很自信”，能编译、甚至能过测试，但可能在生产环境、在负载下、在 3am 才爆雷。

所以你会被迫逐行读。

读“你没写的代码”本来就累；读“一个不理解你团队历史与约定的系统生成的代码”，更累。

4）安全不是安全问题，是可持续性问题（Agent Security = Human Sustainability）

这段是原文里非常值钱但容易被忽略的观点：

如果我们无法 review AI 产出的全部内容（现实里确实做不到），那就需要系统层约束，让你不用一直担心“AI 会不会干危险的事”。

作者把这件事明确到工程措施：

• least-privilege access
• scoped tokens
• audit trails

意义不是“更安全”这么简单，而是：

你不需要把认知预算消耗在‘它有没有做危险动作’上，你才能把脑子留给真正重要的工作。

5）非确定性带来的低强度焦虑：工程师的脑子是 deterministic 的

工程师习惯“同输入→同输出”，这是 debug 的基础。

AI 打破了这个契约。

作者举了一个很具体的例子：周一同一个 prompt 生成的 endpoint 很干净；周二同 prompt 做类似 endpoint，却结构不同、异常处理不同，还引入了没要的依赖。

更糟的是：你很难解释原因。

没有 stack trace 告诉你“模型今天走了 B 路径”。这会制造一种持续的、磨人的背景焦虑：

• 你永远无法完全信任输出
• 你永远无法完全放松
• 每次交互都需要 vigilance

作者甚至因此去做了 Distill：至少让输入端变得“可推理、可 debug、可相信”。

6）FOMO 跑步机：工具更新不是一年，是几个月

这段我建议你把它当成“工程师注意力的 DoS 攻击”。

作者把最近几个月的变化列了一长串：子 agent、skills、SDK、CLI、MCP registry、各家框架 churn……再加上一句社媒恐吓“2026 不用多 agent 就过时”。

结果就是：周末都用来评测工具、迁移工作流，换来 5% 提升且不可测。

更可怕的是 knowledge decay：你花两周打磨的 prompt/template，三个月后模型一更新就失效。

作者的应对策略很工程化：

别追工具，去追“不会 churn 的基础层问题”。

比如：context efficiency / authorization / audit trails / runtime security。

7）Prompt spiral：三次不到 70%，就自己写

这条规则我觉得可以直接抄：

• 第一次 70% 对 → 想再提一点
• 第二次 75% 对但破坏了原来对的地方
• 第三次 80% 但结构变了

45 分钟过去，你本来 20 分钟能写完。

作者给了硬规则：

三次尝试不到 70% 可用，就自己写。

这条能同时挡住 prompt spiral 和完美主义陷阱。

8）完美主义遇到概率输出：最折磨的是“差一点对”

工程师往往是完美主义：喜欢干净、可预测、可测试。

AI 输出永远是“挺好但不够好”，变量名差一点、错误处理差一点、边界条件漏一点。

对完美主义来说，“几乎对”比“完全错”更折磨：完全错你会扔掉，几乎对你会花一小时去 tweak。

作者的解决是认知框架切换：

• 把 AI 输出默认为 draft
• 接受 70% 就够
• 剩下的自己改

9）思考能力萎缩：最吓人的不是产出，而是你不会从零推理了

作者最担心的是 thinking atrophy：习惯先问 AI，久了之后自己从零推理的肌肉会退化。

他举了一个白板讨论并发问题的场景：没有电脑、没有 AI，他居然卡住。

他的补救方式很简单但有效：

• 每天第一小时不用 AI
• 手写/画架构
• 让大脑“热身”

你之后再用 AI，评审能力会更强。

10）What actually helped：一组可执行的“自我 backpressure”

我把原文建议整理成工程师能执行的四条：

• Time-box AI sessions：开计时器（比如 30 分钟），到点要么交付要么切手写。
• Thinking time vs AI time 分离：早上思考、下午执行。
• 接受 70%：别追完美输出。
• 对 hype cycle 战略性应对：保持 informed，不要 reactive。

11）最后一句：AI 时代的核心技能不是 prompt，是“知道什么时候停”

作者最后给了一个非常工程师式的类比：

我们会给系统加 circuit breaker、backpressure、graceful degradation。

那对自己也该一样。

AI 很强，也很耗。两件事都是真的。

真正能长期跑下去的人，不是用 AI 用得最多的人，而是用得最聪明的人。

---

封面3要点

• 生产更快，判断更贵
• 你成了 reviewer
• 知道什么时候停

爆款标题备选（任选其一）

1. AI 让你更高产，却把你榨得更累：工程师的真实疲劳从哪来？
2. 你不是变弱了，是 AI 把你变成了“评审流水线”
3. Prompt 写得再好也救不了：AI 疲劳的底层机制与刹车法
4. 三次不到 70% 就自己写：AI 时代最值钱的自救规则
5. 从追工具到做基础设施：逃离 AI FOMO 跑步机的一种活法

变更摘要（改了什么）

相比 v1，这一版补齐了原文最关键的“认知税”细节：decision fatigue（判断小决策把脑子填满）、AI 代码审阅成本更高、agent security = 人类可持续性、非确定性带来的背景焦虑、FOMO 跑步机与 prompt spiral 的硬规则，并把可执行的刹车策略整理成工程化的 backpressure。

风险点（哪里可能翻车）

这套建议最容易翻车的地方是“你看懂了，但不愿意设边界”。只要你继续追求完美输出、继续无限迭代 prompt、继续追工具而不做深度使用，你的疲劳只会被工具放大；另外，如果你把“不能全量 review”理解成“那就随便上生产”，会直接引入安全事故。

回滚方案（怎么撤）

最小回滚路径：

1. 当周只保留 1~2 个关键交付；
2. 关掉非必要 cron/自动化，减少后台噪音；
3. 给 AI 使用设硬限制（time-box + 三次规则）；
4. 每天固定一段无 AI 的深度思考时间，恢复推理肌肉。

行动清单（读完怎么做）

今天就做两件事：给自己加一个“30 分钟 AI 计时器”和“三次不到 70% 就手写”的硬规则；然后在下一个涉及安全/架构/数据边界的任务里，强制慢下来做人工拍板，把审阅成本写进排期里。

#AI疲劳 #工程师倦怠 #决策疲劳 #上下文切换 #代码审阅 #AI安全 #最小权限 #认知负担 #效率陷阱 #反FOMO