最近看了一篇 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-box）AI 会话 ：不再无限制地用 AI，给每个任务设定 30 分钟计时器，到点就交付现有成果或切回自己写，用来同时抑制 prompt spiral 与完美主义
- 接受 AI 的 70%：把"可用阈值"设成 70% ： 停止追求完美输出，70% 可用就收工，剩下自己补，这也是他减少挫败感的最大杠杆
- 对 hype cycle 更策略化 ：保持信息获取，但不在新工具发布一周内就迁移，选一个主力助手深度掌握，新工具要"以月为单位证明自己"，而不是"以天为单位"
- 记录 AI 何时帮忙、何时帮倒忙： 这可以帮你判断什么地方的业务更适合用 AI
- 接受"审不完"，把审查精力放在关键处 ：最后，如果你用 AI 生成大量代码，那么现实你不可能逐行同等强度审完，所以需要把审查能量集中在安全边界、数据处理、错误路径等关键处，允许非关键代码存在一定粗糙度
实际上科技行业本就有倦怠问题，只是 AI 让它更严重，并非因为 AI 坏，而是因为它移除了过去保护人的"自然速度上限"（打字速度、查资料速度、思考推进速度等）
以前有"天花板"当作调速器；现在调速器没了，唯一上限变成你的认知耐力，而多数人只有在"超载之后"才知道自己的极限。
所以使用 AI ，关键不是"少用 AI"，而是"用 AI 要有边界和意图"，要承认人不是机器，不必跟机器同速，所以"真实核心技能"：
- 不是 prompt engineering
- 不是知道哪个模型最好
- 不是拥有完美工作流
而是，知道什么时候停下来 ：AI极大地提升了生产效率，但它把成本转移到了"决策"和"审查"上，而这恰恰是消耗人类认知资源最快的地方，所以不要去和 AI 毕竟自己的耐受。
