最近读到一篇文章，作者叫 Siddhant Khare，是一位专门做 AI 基础设施的工程师

铭光

最近读到一篇文章，作者叫 Siddhant Khare，是一位专门做 AI 基础设施的工程师，算是业内的资深玩家了。他说自己上个季度写的代码比职业生涯任何一个季度都多，但同时也比任何一个季度都更疲惫。

这两件事并非巧合。

这篇文章让我读完之后沉默了很久。因为他说出了很多人心里想说却不知道怎么表达的东西。如果你每天都在用 AI 工作，却发现自己莫名其妙地比以前更累了，那这篇文章可能会让你产生强烈的共鸣。

1、一个没人警告过我们的悖论

AI 确实让单个任务变快了，这一点毫无疑问。以前要花 3 小时的事情，现在 45 分钟就能搞定。写文档、搭建服务、写测试用例，全都更快了。

但日子却变得更难过了，而不是更轻松。

原因很简单，只是很多人没想明白：当每件事都花更少时间的时候，你并不会做更少的事，你会做更多的事。你的产出能力看起来提升了，工作量就会膨胀来填满它。你的领导看到你干得更快，期望值就会调整。你自己看到自己干得更快，对自己的期望也会调整。基准线悄悄移动了。

以前，作者可能花一整天时间思考一个设计问题。在纸上画画，洗澡的时候想想，出去散个步，回来就有了清晰的思路。节奏慢，但认知负担是可以承受的。一个问题，一整天，深度专注。

现在呢？他可能一天要接触六个不同的问题。每个问题都只需要一小时就能搞定，毕竟有 AI 帮忙。但在六个问题之间来回切换，对人脑来说是非常昂贵的。AI 在问题之间切换不会累，人会累。

这就是那个悖论：AI 降低了生产成本，却提高了协调、审核和决策的成本。而这些成本，全都落在人身上。

2、你变成了审核员，但你没有签字同意

以前，工程师的工作是：思考问题，写代码，测试，发布。是创造者，是建造者。这也是大多数人当初选择这一行的原因，就是那种亲手把东西做出来的感觉。

现在呢？工作越来越像这样：写提示词，等待，阅读输出，评估输出，判断输出对不对，判断输出安不安全，判断输出符不符合架构，修复不对的地方，重新写提示词，循环往复。你变成了审核员，变成了流水线上的质检员，而这条流水线永远不会停。

这是一种本质上完全不同的工作。创造是让人兴奋的，审核是让人疲惫的。有研究表明，生成性任务和评估性任务在心理上是完全不同的。生成性工作能让你进入心流状态，评估性工作只会给你带来决策疲劳。

作者在某一周大量使用 AI 写一个新的微服务，到周三的时候，他发现自己连最简单的决定都做不了了。这个函数叫什么名字？无所谓。这个配置放哪里？无所谓。大脑满了。并不是因为写了太多代码，而是因为判断了太多代码。每天都是成百上千个小判断。

更讽刺的是，AI 生成的代码比人写的代码需要更仔细的审查。因为当同事写代码的时候，你知道他的习惯，他的强项，他的盲点。你可以略读你信任的部分，专注于你不信任的部分。但 AI 呢？每一行都值得怀疑。代码看起来很自信，能编译，甚至能通过测试。但它可能以一种微妙的方式出错，只有在生产环境里、在高负载下、在凌晨三点才会暴露出来。

所以你得逐行阅读。而阅读那些你没写的、由一个不了解你代码库历史的系统生成的代码，是非常累人的工作。

3、确定性消失了

工程师是在确定性中成长的。相同的输入，相同的输出。这是契约，这是调试成为可能的基础，这是你能够推理系统的前提。

AI 打破了这个契约。

作者有一个提示词，周一用的时候完美无缺，生成了干净、结构良好的 API 端点代码。周二用同样的提示词写一个类似的端点，输出在结构上完全不同，用了不同的错误处理模式，还引入了一个他没要求的依赖。

为什么？没有原因。或者说，没有他能看到的原因。没有堆栈跟踪告诉你模型今天决定走一条不同的路。没有日志说温度采样选择了路径 B 而不是路径 A。它就是发生了，就是不一样了。

对于一个整个职业生涯都建立在如果它坏了我就能找出原因之上的人来说，这是非常令人不安的。不是那种戏剧性的不安，而是一种缓慢的、磨人的、背景噪音式的焦虑。你永远无法完全信任输出。你永远无法完全放松。每一次交互都需要警惕。

他试过对抗这个问题，把提示词做版本控制，写复杂的系统消息，创建模板。有些有帮助，但都没能解决根本问题：你是在和一个概率系统合作，而你的大脑是为确定性系统准备的。这种错配是一种持续的、低级别的压力来源。

那些最能适应这种情况的工程师，是那些已经与它和解的人。他们把 AI 输出当作一个聪明但不可靠的实习生写的初稿。他们预期要重写 30%。他们为重写预留时间。当输出是错的时候他们不会沮丧，因为他们从来没期望它是对的。他们期望的是它有用。这是不一样的。

4、永远追不上的焦虑

试着跟上过去几个月的节奏看看。Claude 发布了子代理，然后是技能系统，然后是 Agent SDK，然后是 Claude Cowork。OpenAI 发布了 Codex CLI，然后是 GPT-5.3-Codex。新的编程代理宣布后台模式，可以同时运行数百个自主会话。Google 发布了 Gemini CLI。GitHub 添加了 MCP 注册表。收购每周都在发生。Amazon Q Developer 获得了代理升级。CrewAI、AutoGen、LangGraph、MetaGPT，选一个代理框架吧，每周都有新的。Google 宣布 A2A 协议与 Anthropic 的 MCP 竞争。OpenAI 发布了自己的 Swarm 框架。Kimi K2.5 推出了能编排 100 个并行代理的架构。

这还不是一年的内容，这只是几个月。而且还漏了很多。

作者深深陷入了这个陷阱。周末都在评估新工具，阅读每一个更新日志，观看每一个演示，试图站在前沿，因为他害怕落后。

这实际上是什么样子呢？周六下午设置一个新的 AI 编程工具，周日有了基本的工作流程，到下周三，有人发帖说另一个工具好多了。一阵焦虑袭来。到下个周末，又在设置新东西。旧东西被闲置。一个编程助手换到下一个再换到下一个然后又回到第一个。每次迁移花掉一个周末，带来的改进可能只有 5%，还没法准确测量。

把这个乘以每一个类别：编程助手、聊天界面、代理框架、多代理编排平台、MCP 服务器、上下文管理工具、提示词库、集群架构、技能市场……你得到的是一个永远在学习新工具、从未在任何工具上深入的人。

最糟糕的是知识的贬值。作者在 2025 年初花了两周时间构建了一套复杂的提示词工程工作流。精心设计的系统提示，少样本示例，思维链模板。效果很好。三个月后，模型更新了，提示词最佳实践变了，他一半的模板效果反而不如简单的一行提示词。那两周就这么没了。不是投资，是消费。

他后来采取了不同的方法。与其追逐每一个新工具，不如深入工具下面的基础设施层。工具来来去去，但它们要解决的问题不会变。上下文效率、代理授权、审计追踪、运行时安全，这些是持久的问题，无论这个月流行哪个框架。建立在不会剧烈变化的层上，才是明智之举。

5、再来一次提示词的陷阱

这个陷阱非常隐蔽。你想让 AI 生成一个特定的东西。第一次输出 70% 正确。于是你优化提示词。第二次输出 75% 正确，但打破了第一次正确的东西。第三次 80% 正确，但结构变了。第四次，你已经在这上面花了 45 分钟，而你本可以 20 分钟从头写完。

作者把这叫做提示词螺旋。你开始时有一个清晰的目标。三十分钟后，你在调试你的提示词而不是调试你的代码。你在优化给语言模型的指令，而不是解决实际问题。

提示词螺旋特别危险，因为它感觉很有生产力。你在迭代，你在接近目标，每次尝试都稍微好一点。但边际收益递减得很快，而你忘记了目标从来不是让 AI 产生完美的输出，目标是把功能发布出去。

他现在有一条硬性规则：三次尝试。如果 AI 在三次提示词内不能让他得到 70% 可用的东西，他就自己写。没有例外。这条规则比他学过的任何提示词技巧都节省更多时间。

6、完美主义者的噩梦

工程师倾向于完美主义。我们喜欢干净的代码，喜欢能通过的测试，喜欢行为可预测的系统。这是优点，这是让我们擅长构建可靠软件的原因。

AI 输出永远不完美。永远是差不多，七八成的样子。变量名有点不对，错误处理不完整，边缘情况被忽略，抽象对你的代码库来说是错的。它能用，但不对。

对完美主义者来说，这是折磨。因为差一点比完全错还糟糕。完全错了，你就扔掉重来。差一点，你花一个小时去调整。而调整 AI 输出特别令人沮丧，因为你在修复别人的设计决策，而这些决策是由一个不分享你的品味、你的上下文、你的标准的系统做出的。

作者不得不学会放手。不是放弃质量，他仍然在意质量。而是放弃对 AI 会产出高质量内容的期望。他现在把每一个 AI 输出都当作草稿，一个起点，原材料。这种心态的转变，就让他的挫败感减少了一半。

在 AI 面前挣扎最多的工程师，往往是最好的工程师。那些标准最高的人，那些注意到每一个缺陷的人。AI 奖励的是另一种技能：快速从不完美的输出中提取价值的能力，而不会在让它完美这件事上投入太多情感。

7、大脑在退化

这是最让作者害怕的一点。

他是在一次设计评审会议上注意到的。有人让他在白板上推导一个并发问题。没有笔记本电脑，没有 AI，就他和一支马克笔。他挣扎了。不是因为他不懂概念，他懂。而是因为他好几个月没有锻炼那块肌肉了。他把初步思考外包给 AI 太久了，以至于从头思考的能力已经退化。

就像 GPS 和导航一样。在 GPS 之前，你会建立心理地图。你了解你的城市，你能推理路线。用了几年 GPS 之后，没有它你就不会导航了。技能退化了，因为你不再使用它。

同样的事情正在 AI 和工程思维上发生。当你总是先问 AI，你就停止了建立那些来自自己与问题搏斗的神经通路。挣扎是学习发生的地方，困惑是理解形成的地方。跳过这些，你得到更快的输出，但更浅的理解。

他现在刻意让每天的第一个小时不用 AI。在纸上思考，用手画架构，用慢方法推理问题。感觉效率低，确实效率低。但它让他的思维保持敏锐，而这种敏锐在他后面使用 AI 的时候会产生回报，因为当他自己的推理热身好了，他就能更好地评估 AI 的输出。

8、社交媒体上的幻象

社交媒体上到处都是那些似乎已经搞定 AI 的人。他们分享工作流，分享生产力数据，分享那种我用 AI 两小时就做了整个应用的帖子。然后你看看自己的经历：失败的提示词，浪费的时间，不得不重写的代码。你会想：我是不是有什么问题？

你没有问题。那些帖子是精选集锦。没人发帖说我花了 3 小时试图让 Claude 理解我的数据库结构，最后放弃了自己手写了迁移脚本。没人发帖说 AI 生成的代码导致了生产事故，因为它悄悄吞掉了一个错误。没人发帖说我累了。

比较陷阱被一个事实放大了：AI 技能很难衡量。传统工程，你可以看看别人的代码，大致判断他们的能力。用 AI 的话，输出取决于模型、提示词、上下文、温度、月相。别人令人印象深刻的演示，在你的机器上用你的代码库可能根本复现不了。

作者变得对社交媒体上的 AI 内容非常挑剔。他仍然密切关注这个领域，毕竟这是他的工作。但他从消费每个人的热门观点，转向专注于那些真正在构建和发布的人，而不是只在演示的人。信号和焦虑的比例很重要。如果一个信息流让你感到落后而不是获得信息，它就没有在服务你。

9、真正有用的方法

作者很具体地分享了什么改变了他与 AI 的关系，从对抗变成可持续。

给 AI 会话设置时间限制。不再以开放式的方式使用 AI。设定计时器，这个任务用 AI 做，30 分钟。计时器响了，要么发布现有的，要么切换到自己写。这同时防止了提示词螺旋和完美主义陷阱。

把 AI 时间和思考时间分开。上午用来思考，下午用来 AI 辅助执行。这不是死板的规定，有时候会打破规则。但有一个默认结构意味着大脑能以正确的比例得到锻炼和协助。

接受 AI 给 70% 就够了。不再试图得到完美输出。70% 可用就是标准，剩下的自己修。这种接受是他工作流中减少 AI 相关挫败感最大的单一因素。

对炒作周期保持战略眼光。他追踪 AI 领域是因为他为它构建基础设施。但他不再在每个新工具发布的那一周就采