前谷歌工程师15年经验：AI编程助手让我重燃构建热情

一位在软件行业摸爬滚打15年、其中三年在谷歌度过的资深工程师，最近在Reddit上发帖，直言自己受够了反AI的论调。他承认AI有很多问题，但反感人们假装AI做不到它已经在做的事情。这篇文章基于他的亲身经历，探讨AI如何改变复杂调试工作，以及开发者应如何理性看待AI编程助手。

复杂调试：从数天到一下午

他举了一个C++搜索服务系统的例子：排查尾延迟问题。请求通过RPC扇出到多个后端，大部分快速完成，但少数慢响应拖累整体。中位数延迟看起来正常，p99却惨不忍睹。一个通过所有基础测试的变更，仍可能在负载下崩盘。

更棘手的是，慢RPC会触发对另一个副本的第二次请求。调用方最终超时，但后端工作仍在继续。负载下这些额外请求填满队列，让一切更慢——本用于降低延迟的机制反而加剧了过载。修复它需要沿调用链追踪deadline、检查取消并限制额外工作。接着是C++生命周期问题：如果完成回调在取消后仍可能运行，过早释放请求状态会引入use-after-free。恭喜，延迟修复现在偶尔会让进程崩溃。

“这种任务在2016年能吃掉几天时间。”他写道。读不熟悉的代码、对比trace、翻profile、因为现有测试从未覆盖该序列而构建复现器、再走一轮评审因为补丁修好一条路径却弄坏另一条。

尾延迟（Tail Latency）与p99： 在分布式系统中，延迟通常用分位数描述，p99指99%的请求完成时间低于该值，而剩余1%的请求可能极慢。尾延迟正是关注这些最慢的请求，它们虽少，却会显著拉高整体响应时间，尤其在扇出（fan-out）场景下，一个慢后端可能拖累整个请求。文章中的C++搜索服务正是典型：中位数正常，但p99飙升，说明少数慢请求成为了瓶颈。

RPC扇出与超时传播： RPC（远程过程调用）扇出指一个请求被分发到多个后端服务并行处理。当某个后端响应慢时，调用方可能超时并重试到另一个副本，但原后端的工作仍在继续，导致额外负载。deadline（截止时间）需要在调用链中传播，以便下游及时取消无用工作，否则队列积压会加剧过载。

Use-after-free与C++生命周期： Use-after-free是一种内存安全漏洞，指程序在释放对象内存后继续使用指向该内存的指针。在异步RPC中，如果取消操作后完成回调仍可能执行，而请求状态已被提前释放，回调就会访问非法内存，导致崩溃。修复尾延迟时引入的取消逻辑若未妥善处理回调生命周期，就可能触发此类问题。这要求开发者仔细管理对象所有权和回调的生存期，例如使用智能指针或引用计数。

AI如何介入：从手动到监督

现在，他把相关实现、trace和约束交给Opus，立即开始梳理问题。让模型跨文件跟踪请求生命周期，找出deadline停止传播的位置，提出补丁，编写故意在取消后交付回调或模拟慢后端的测试。他的注意力转移到检查推理和测试结果上。

“我仍然对修复负责。生产性能问题仍然需要负载测试。但得到一个严肃的候选补丁现在容易多了，我再也没兴趣手动做每一步。”他说。许多过去在多人间 bouncing 数周的任务，现在一个下午就能完成。

过去一年，他完成了搁置已久的项目，趁自己还在意这些想法时把它们实现出来。

Opus与AI编程助手： Opus通常指Anthropic公司推出的Claude 3 Opus模型，属于大型语言模型（LLM），具备强大的代码理解和生成能力。在这类调试场景中，AI助手可以接收代码库、分布式追踪（trace）和性能剖析（profile）数据，进行跨文件推理，定位问题根源，并生成补丁和测试用例。它并非自动修复，而是作为“候选补丁生成器”，由工程师审查推理过程和测试结果，最终对修复负责。

反AI rhetoric 忽略了什么

这位工程师的抱怨并非针对AI的缺陷，而是针对对话中普遍存在的“假装”现象——假装AI不能完成它明明已经在做的工作。这种否认无助于解决问题，反而让讨论失焦。

他的态度很务实：讨厌承认模型能部分做得比自己好，但可以接受。因为“太享受构建东西的乐趣，没时间坚持老方法更好”。

对开发者的启示

AI编程助手不是银弹，它需要人类监督和最终负责。但在复杂调试、跨文件推理、测试生成等任务上，它已经能显著压缩从问题到候选补丁的时间。拒绝承认这一点，可能错过的是自己重新获得的时间与乐趣。

对于资深工程师，AI不是替代，而是把重复性、上下文切换成本高的劳动接管过去，让人专注于更高价值的判断和验证。对于团队，这意味着任务流转模式可能改变——从漫长的手工调试周期，转向更快的人机协作迭代。

正如这位前谷歌工程师所说：“我受够了反AI的论调。”也许，是时候停止争论AI能不能，而是看看它已经在做什么，并学会与之协作。