AI 在提高你工作效率的同时，也一直在增加你的疲惫和焦虑

最近看了一篇 Siddhant Khare 关于 AI 的感悟，突然觉得很有共鸣，因为在深度使用 AI 的这些年，他发现产出越来越高，但人也越来越“被掏空” ，特别是上个季度他写的代码比职业生涯任何一个季度都多，但也比任何时候都更疲惫。

对于使用 AI 开发，最直观的感受就是开发效率的提升，例如 ：写 design doc、搭脚手架、写测试、研究陌生 API，可以帮助开发者把以前需要几天的任务缩短到几小时，但是结果却不是让工作变得轻松，而是：

在之前开发者可能一整天只啃一个设计问题，慢慢想、散步、洗澡时想、回到电脑前继续梳理，节奏慢但负担可控，更多时候是针对问题的深度专注。

而现在一天可能要碰 6 个问题，每个都“用 AI 只要一小时”，但人类在 6 次上下文切换中会有被强烈的精神疲惫，特别是 AI 不会累，人会。

实际上这也是随着 AI 普及之后，开发者的定位在发生改变：

• 一些开发者喜欢“创造”的感觉：想问题→写代码→测试→上线
• 而 AI 让工作变成更像“审稿人/质检员”：提示词 → 等输出 → 读输出 → 判断对不对/安不安全/合不合架构 → 修补 → 再提示 → 循环

实际上这是本质不同的工作类型：创造更容易进入心流、更能量化，而评审则更消耗，容易“决策疲劳” ，例如作者在某次使用 AI 开发一个新的微服务，而当这个任务进行了三天后，他发现自己已经不想做决策了：

整个项目开发下来，他并不是写代码，而是判断代码，一天需要做成百上千个小评判，而更残酷的是：AI 生成的代码往往更需要谨慎审查。

为什么？因为同事写的代码你可能会知道和了解他的习惯和盲区，能有选择地信任和不信任。

但是 AI 的代码看起来很自信、能编译、甚至能过测试，但可能在奇奇怪怪的地方突然暴雷，于是你又不得不“每行都怀疑”，而阅读自己没写的、也不理解历史与约定的代码极其耗神。

有时候 AI 的坑是真的深，在这一点我对作者这个深有体会：

事实上项目里我也写了很多规则和 spec ，但是 AI 就是存在这样的问题，比如之前我给它设定了个规则是需要 xxx，然后任务到中间的时候，它自己就突然说“虽然规则是xxx，但是我觉得不能这样，所以我决定YYY”......

所以正如作者所说：因为你不可能规模化地审完 AI 产物，所以更需要最小权限、作用域 token、审计日志等限制，而你需要孜孜不倦的去对这些细小颗粒进行审核和保持警惕。

实际上在过去，工程训练依赖确定性：同输入同输出，这是调试与推理的基础，但 AI 打破了这个契约，作者举例：

• 周一某个 prompt 表现完美，生成干净结构
• 周二同样 prompt 用在相似场景，输出风格不同，还引入你没要的依赖，而且还没有可追踪的原因，因为没有“模型为何今天选了另一条路”的堆栈

这种不确定不是戏剧性的恐惧，而是“持续的背景噪音式压力”，你无法信任输出，所以也无法真正放松，每次交互都要保持警惕，而问题在于，你的审核速度要跟上它的产出速度。

对于这个，作者也尝试过 prompt 版本控制、复杂 system message、模板化等，但是只能缓解，无法消除，实际上原因在于：你在和概率系统协作，而你的大脑习惯确定性系统，这种错配会长期消耗。

同时 AI 现在也是焦虑的来源，“行业速度”带来了 AI 工具的压迫感，短短几个月内，各种 coding agent、CLI、sub-agent、协议、框架、registry、收购与升级滚动出现；社交媒体还会煽动“你不跟上就过时”，而作者也是深陷其中：

• 周六搭一个新工具，周日刚理顺顺，周三又看到“更强的工具”
• 每次迁移可能只换来“也许 5% 的提升”，而且根本没法严谨衡量
• 大量类别在等着你入坑：助手、界面、agent 框架、多 agent 编排、MCP server、context 管理、prompt 库、swarm 架构、skills marketplace，一个东西你还没深入，结果它就又过时了。

更让作者崩溃的是“知识贬值/工作沉没”：早期花两周打磨 prompt 工程模板，几个月后模型更新、最佳实践变化，模板反而更差。

所以后来作者开始不追每个新工具，而是下沉到更耐久的基础设施层（上下文效率、授权、审计、运行时安全等），因为工具会变，问题不变，并且把“了解趋势”与“被趋势驱动立刻采用”区分开。

而 AI 开发里的另一个问题是：你在 debug prompt 而不是 debug 代码 ，这个问题的区别在于：

• 第一次输出 70% 对，于是你改 prompt；
• 第二次 75% ，但破坏了第一版对的部分；
• 第三次 80% 结构又变；
• 第四次你已经花了 45 分钟，但是 prompt 反而让项目掉回 70%

所以作者后来给自己定了个规则：最多三次尝试，三次还不能到“70% 可用”，就自己写。

所以使用 AI 最忌完美主义，因为很多工程师天然追求可预期、干净、可靠，但是 AI 输出永远是“差不多” ，所以最容易被 AI 折磨的，往往是标准最高、最敏感的好工程师更难受，AI 时代更需要一种能力：快速从不完美里榨取价值，而不是沉迷把它打磨到完美。

最后，作者也提供了一些它对于 AI 疲倦的解法：

• 时间盒（time-box）AI 会话 ：不再无限制地用 AI，给每个任务设定 30 分钟计时器，到点就交付现有成果或切回自己写，用来同时抑制 prompt spiral 与完美主义

• 接受 AI 的 70%：把“可用阈值”设成 70% ： 停止追求完美输出，70% 可用就收工，剩下自己补，这也是他减少挫败感的最大杠杆

• 对 hype cycle 更策略化 ：保持信息获取，但不在新工具发布一周内就迁移，选一个主力助手深度掌握，新工具要“以月为单位证明自己”，而不是“以天为单位”

• 记录 AI 何时帮忙、何时帮倒忙： 这可以帮你判断什么地方的业务更适合用 AI

• 接受“审不完”，把审查精力放在关键处 ：最后，如果你用 AI 生成大量代码，那么现实你不可能逐行同等强度审完，所以需要把审查能量集中在安全边界、数据处理、错误路径等关键处，允许非关键代码存在一定粗糙度

实际上科技行业本就有倦怠问题，只是 AI 让它更严重，并非因为 AI 坏，而是因为它移除了过去保护人的“自然速度上限”（打字速度、查资料速度、思考推进速度等）

所以使用 AI ，关键不是“少用 AI”，而是“用 AI 要有边界和意图”，要承认人不是机器，不必跟机器同速，所以“真实核心技能”：

• 不是 prompt engineering
• 不是知道哪个模型最好
• 不是拥有完美工作流

而是，知道什么时候停下来 ：AI极大地提升了生产效率，但它把成本转移到了“决策”和“审查”上，而这恰恰是消耗人类认知资源最快的地方，所以不要去和 AI 毕竟自己的耐受。

参考链接

siddhantkhare.com/writing/ai-…