AI编码优化只针对工程中最不痛苦的部分

在工程领域，大多数AI工具都在你编写新代码时出现，但当你凌晨3点试图挽救生产环境时，它们却无影无踪。这不是偶然的差距，它将成为你工程组织中最昂贵的代价。

凌晨3点14分，丹尼尔（化名）的手机异常地响起了未确认的警报。他是本周的值班高级工程师。结账延迟飙升，错误率上升。他打开笔记本电脑，开始了他最熟悉的过程：找出“什么发生了变化”。这个问题看似简单，但答案分散在六个互不相通的工具中。他检查部署仪表板，最近几小时有三个服务发布了。他翻阅团队Slack，两百条消息，寻找是否有人提到了支付路径。他打开公司内部搜索，输入“结账重试超时”，返回了一堆文档——2023年的运行手册、两份设计文档和一个未完成的Confluence页面。搜索技术上成功了，但并没有回答问题。他仍然逐一打开，判断是否最新，然后继续。凌晨3点，他用手工拼接系统的图景。

30分钟过去了，他还没修复任何东西。这不是他慢；这就是工作的本质。事件响应分析显示，40%到60%的时间浪费在跨工具重建上下文上，工程师花费15到25分钟收集分散的信息才能开始调查。一个典型的中断涉及5分钟在Slack上，10分钟检查最近的提交，5分钟查看仪表板，然后——25分钟后——才最终理解是某个特定部署导致了峰值。一旦知道该做什么，技术修复往往微不足道。但达到知道该做什么的节点，才是夜晚真正耗费的时间。

最终，丹尼尔通过时间序列形状缩小了范围——延迟呈锯齿状上升，像是重试堆积。他需要数据确认，这不仅是不同的工具，更是完全不同的工作模式：现在他需要针对指标后端编写临时查询，调整时间窗口，构建即用即弃的脚本来拉取所需数字，因为没有人提前构建的仪表板并不存在。终端、浏览器、指标工具、再回到终端。每次工具切换都打断流程，迫使他重新定位。

他找到了原因。有人在下午的部署中提高了重试上限。上限之所以存在是有原因的——总是有原因的——但原因存在于八个月前的一个代码审查评论和某位高级工程师的脑海中，而她此刻正在睡觉。丹尼尔做出决定，推送修复，看着图表正常化，在频道中发布解除警报。

然后是他最讨厌的部分：他必须把所有内容写下来。事后总结——时间线、根本原因、他做的决定和后续行动——以便下一个遇到此问题的人不必重复他的整个夜晚。凌晨5点，他知道自己会写出一份单薄、无趣的版本，因为他筋疲力尽，而三个月后，有人会遇到类似问题，不得不从头开始自己的凌晨3点。他们怎么能找到这份文档呢？

值得注意的是，在整个夜晚中，公司投资的任何AI工具都没有提供任何帮助。能够快速搭建服务的编码代理？沉默。起草PRD和总结会议的同事代理？无处可寻。“AI正在改变软件开发”的承诺在丹尼尔工作最艰难、风险最高、公司正在赔钱的九十分钟里完全缺席。这些代理只出现在编写快乐路径代码的愉悦部分，而在高级工程师大部分职业生涯所处的运营现实中缺席。

这从未是一个编程问题。让我们重放丹尼尔的夜晚，每一步问：“实际上缺少什么？”不是编码能力。他几乎可以在睡觉时编码。每次缺少的是组织某处存在但不在他需要时、需要地点的知识。过去四小时发生了什么？存在于部署日志和PR中。重试上限设置为何以及为什么？存在于审查线程中。是否有人之前见过这种形状？存在于过去的事故中，但无法被检索。当他重构了足够的上下文，修复方案立刻显现。

事故的每一步都是穿着事故外衣的知识问题。搜索工具失败不是因为它不好，而是因为找到一堆文档阅读不等于回答问题。凌晨3点，合成税以最昂贵的货币支付：一位资深工程师在压力下、在倒计时中的注意力。

这是关于资深工程师的安静真相，没有组织架构图显示：最有经验的人充当着公司的活知识层。团队“问丹尼尔”的原因是丹尼尔头脑中拥有系统实际上如何运作以及为什么的映射、调和、最新、有来源的理解。这些是在会议中决定的、在审查中争论的、在之前的事故中学到的，并且从未在任何机器或新人能够访问的地方写下来。他就是知识库。这在他睡觉、度假或离职时成了问题。

这不是一个小的或罕见的问题——只是普通工程日。多项研究一致发现，开发人员实际花费在编写应用程序代码上的时间仅约16%，其余时间用于运营和支持工作：监控、维护、协调和无休止的上下文搜索。约64%的人报告每天花30分钟以上只是搜索东西，三分之一的人花超过一个小时。真正的瓶颈从来不是写代码——而是知道。

AI在16%方面进步显著，而其他84%几乎没有变化。这就是为什么任何押注于“AI将提高工程速度”的人都会感到复杂。编码工具进步很快，但在受控试验中，在熟悉代码库上工作的经验丰富的开发人员在使用AI工具时实际上更慢——而且更显著的是，他们相信自己更快。你应该诚实地看待这一发现，并注意感知差距：工程师会感觉自己更快，无论实际是否如此，这意味着感觉不是可以用来管理工程组织的指标。

从编码退一步，更大的模式显现出来。企业分析发现，代理辅助工作失败的原因始终是相同的：不是原始模型能力，而是缺少上下文和规划——代理不知道约束、组织如何运作、或没有明确写下来的东西。能力曲线垂直增长，但团队特定的运营知识曲线根本没有移动。重试理由、必须同时部署的组件、运营陷阱——它们仍然只存在于丹尼尔的头脑中。困在人的头脑中和分散在工具中。

因此，收益在知识存在于某人头脑中的特定地方停滞不前。这正是丹尼尔凌晨3点14分所处的位置。

随着你采用更多代理，情况会变得更糟。每个代理都是一名没有记忆的新员工。它从未参加过你的架构评审，不知道支付和库存必须一起部署，或者去年春天的“临时”限流器现在已成为承载结构。因此，每个代理每次都会重新提出新工程师问的同样问题——而答案仍然存在于你的资深工程师头脑中。你没有减少丹尼尔的上下文负担，而是增加了询问他上下文的事物数量，并全部指向同一个未文档化的瓶颈。

与此同时，基础衰减仍在继续。随着每次离职和重组，部落知识逐渐消失。新工程师——人类和代理——缓慢地上手，因为入职正是一对一转移这些未书面知识的过程，而这种转移不会通过招聘更多人或启动更多代理来扩展。随着运营负担五年内首次增加30%，负担在增加，而处理负担的知识却变得更薄、更分散。

工程组织越自主化，未书面、未调和、困在人脑中的知识就越成为一切的瓶颈。你可以购买更多能力，但无法买回团队从未写下的上下文。

优秀团队正在采取的措施：将工作知识视为真正的基础设施层，而非偶然积累在人们头脑中的副产品。一些做法：捕获原因而不仅仅是内容；将约束放在工作发生的地方；将上下文作为第一类工件；将事故反馈循环到知识中。

丹尼尔凌晨5点讨厌写的事后总结就是为了提供这个层。悲剧在于，它是由疲惫的人手动完成的，而所需的大部分信息——时间线、部署、决定、线程——已经存在于见证它发生的系统中。

最后一点是关键。值班是知识问题的原因也正是它可以解决的原因——下一个响应者所需的一切已经产生并记录在某处。只需要在关键时刻调和成一个当前答案。

想象一下丹尼尔的夜晚有一件事情改变了。警报响起。在丹尼尔打开笔记本电脑之前，一个代理查询：“过去4小时结账发生了什么变化？”和“结账的硬约束是什么？”在他打开六个工具之前，调和后的答案已经在等待他：三个部署，它们的作者，以及那张真正重要的代码审查评论。他不再需要合成；他可以直接行动。团队已经将知识构建到了响应中，而没有将其留给凌晨3点的手工拼接。