最近看了一篇 Siddhant Khare 关于 AI 的感悟突然觉得很有共鸣因为在深度使用 AI 的这些年他发现产出越来越高但人也越来越“被掏空” 特别是上个季度他写的代码比职业生涯任何一个季度都多但也比任何时候都更疲惫。Siddhant Khare 是长期在 AI/agent 基础设施里工作的开发者维护着 OpenFGA、 agentic-authz 、 Distill 、和各种 MCP server 等 AI 相关项目。对于使用 AI 开发最直观的感受就是开发效率的提升例如 写 design doc、搭脚手架、写测试、研究陌生 API可以帮助开发者把以前需要几天的任务缩短到几小时但是结果却不是让工作变得轻松而是变快并不会让你做更少任务而是让你做更多任务。在之前开发者可能一整天只啃一个设计问题慢慢想、散步、洗澡时想、回到电脑前继续梳理节奏慢但负担可控更多时候是针对问题的深度专注。而现在一天可能要碰 6 个问题每个都“用 AI 只要一小时”但人类在 6 次上下文切换中会有被强烈的精神疲惫特别是 AI 不会累人会。实际上这也是随着 AI 普及之后开发者的定位在发生改变一些开发者喜欢“创造”的感觉想问题→写代码→测试→上线而 AI 让工作变成更像“审稿人/质检员”提示词 → 等输出 → 读输出 → 判断对不对/安不安全/合不合架构 → 修补 → 再提示 → 循环实际上这是本质不同的工作类型创造更容易进入心流、更能量化而评审则更消耗容易“决策疲劳”例如作者在某次使用 AI 开发一个新的微服务而当这个任务进行了三天后他发现自己已经不想做决策了这个函数应该叫什么名字我不在乎。这个配置应该放在哪里我不在乎。“整个项目开发下来他并不是写代码而是判断代码一天需要做成百上千个小评判而更残酷的是AI 生成的代码往往更需要谨慎审查。为什么因为同事写的代码你可能会知道和了解他的习惯和盲区能有选择地信任和不信任。但是 AI 的代码看起来很自信、能编译、甚至能过测试但可能在奇奇怪怪的地方突然暴雷于是你又不得不“每行都怀疑”而阅读自己没写的、也不理解历史与约定的代码极其耗神。有时候 AI 的坑是真的深在这一点我对作者这个深有体会某次 AI 的任务我恰好没看他过程只 review 它修改的 diff 结果它把本地一个库里的一个可执行文件的属性从可写改成只读然后因为项目正运行着还在 hotload 也没发现问题但是后面退出后再增量编译就一直出现失败但是 cmake 的错误又看不出来什么鬼然后我每次只能 clean 后全量编译怎么回滚代码都不行一增量就报错直到后来好几天里一个一个翻中间文件才发现是一个库的可执行文本被修改成只读了然后增量编译每次会覆盖一覆盖就报错······而这种修改变化是不回有 git 记录你不知道它为什么突然就做了这个行为。事实上项目里我也写了很多规则和 spec 但是 AI 就是存在这样的问题比如之前我给它设定了个规则是需要 xxx然后任务到中间的时候它自己就突然说“虽然规则是xxx但是我觉得不能这样所以我决定YYY”…所以正如作者所说因为你不可能规模化地审完 AI 产物所以更需要最小权限、作用域 token、审计日志等限制而你需要孜孜不倦的去对这些细小颗粒进行审核和保持警惕。实际上在过去工程训练依赖确定性同输入同输出这是调试与推理的基础但 AI 打破了这个契约作者举例周一某个 prompt 表现完美生成干净结构周二同样 prompt 用在相似场景输出风格不同还引入你没要的依赖而且还没有可追踪的原因因为没有“模型为何今天选了另一条路”的堆栈这种不确定不是戏剧性的恐惧而是“持续的背景噪音式压力”你无法信任输出所以也无法真正放松每次交互都要保持警惕而问题在于你的审核速度要跟上它的产出速度。对于这个作者也尝试过 prompt 版本控制、复杂 system message、模板化等但是只能缓解无法消除实际上原因在于你在和概率系统协作而你的大脑习惯确定性系统这种错配会长期消耗。所以现阶段AI 更像是“聪明但不可靠的实习生”。同时 AI 现在也是焦虑的来源“行业速度”带来了 AI 工具的压迫感短短几个月内各种 coding agent、CLI、sub-agent、协议、框架、registry、收购与升级滚动出现社交媒体还会煽动“你不跟上就过时”而作者也是深陷其中周六搭一个新工具周日刚理顺顺周三又看到“更强的工具”每次迁移可能只换来“也许 5% 的提升”而且根本没法严谨衡量大量类别在等着你入坑助手、界面、agent 框架、多 agent 编排、MCP server、context 管理、prompt 库、swarm 架构、skills marketplace一个东西你还没深入结果它就又过时了。更让作者崩溃的是“知识贬值/工作沉没”早期花两周打磨 prompt 工程模板几个月后模型更新、最佳实践变化模板反而更差。实际上这个我也深有体会之前打磨过一套模版工具结果还没整完skills 来了然后我就放弃了因为 skills 确实更方便好用。所以后来作者开始不追每个新工具而是下沉到更耐久的基础设施层上下文效率、授权、审计、运行时安全等因为工具会变问题不变并且把“了解趋势”与“被趋势驱动立刻采用”区分开。而 AI 开发里的另一个问题是你在 debug prompt 而不是 debug 代码这个问题的区别在于第一次输出 70% 对于是你改 prompt第二次 75% 但破坏了第一版对的部分第三次 80% 结构又变第四次你已经花了 45 分钟但是 prompt 反而让项目掉回 70%这个过程里开发者很容易忘了目标是交付功能而不是让 AI 输出完美因为 AI 是概率预测它就像是一只猫对你的诉求可是有着自己的叛逆心理。所以作者后来给自己定了个规则最多三次尝试三次还不能到“70% 可用”就自己写。所以使用 AI 最忌完美主义因为很多工程师天然追求可预期、干净、可靠但是 AI 输出永远是“差不多” 所以最容易被 AI 折磨的往往是标准最高、最敏感的好工程师更难受AI 时代更需要一种能力快速从不完美里榨取价值而不是沉迷把它打磨到完美。最后作者也提供了一些它对于 AI 疲倦的解法时间盒time-boxAI 会话不再无限制地用 AI给每个任务设定 30 分钟计时器到点就交付现有成果或切回自己写用来同时抑制 prompt spiral 与完美主义接受 AI 的 70%把“可用阈值”设成 70% 停止追求完美输出70% 可用就收工剩下自己补这也是他减少挫败感的最大杠杆对 hype cycle 更策略化保持信息获取但不在新工具发布一周内就迁移选一个主力助手深度掌握新工具要“以月为单位证明自己”而不是“以天为单位”记录 AI 何时帮忙、何时帮倒忙 这可以帮你判断什么地方的业务更适合用 AI接受“审不完”把审查精力放在关键处最后如果你用 AI 生成大量代码那么现实你不可能逐行同等强度审完所以需要把审查能量集中在安全边界、数据处理、错误路径等关键处允许非关键代码存在一定粗糙度实际上科技行业本就有倦怠问题只是 AI 让它更严重并非因为 AI 坏而是因为它移除了过去保护人的“自然速度上限”打字速度、查资料速度、思考推进速度等以前有“天花板”当作调速器现在调速器没了唯一上限变成你的认知耐力而多数人只有在“超载之后”才知道自己的极限。所以使用 AI 关键不是“少用 AI”而是“用 AI 要有边界和意图”要承认人不是机器不必跟机器同速所以“真实核心技能”不是 prompt engineering不是知道哪个模型最好不是拥有完美工作流而是**知道什么时候停下来 **AI极大地提升了生产效率但它把成本转移到了“决策”和“审查”上而这恰恰是消耗人类认知资源最快的地方所以不要去和 AI 毕竟自己的耐受。参考链接https://siddhantkhare.com/writing/ai-fatigue-is-real