有AI了,还啃什么源码?

有AI了，学习源码还有意义吗？

说实话，我也迷茫过。

去年开始，身边越来越多人跟我说：”别费劲读源码了，问AI呗，人家秒答，还讲得特别清楚。”

我试了几次，确实厉害。ES的search入口在哪？秒答。IndexingStrategy怎么选路径的？逐行解读。让我写个bulk工具类？质量比我还高。

那我还啃啥源码啊？

直到有一次在学员群里，有个学员@我，特别急：

“Fox老师，救命！生产环境搜索突然变慢，平时200ms，现在飙到2秒多，业务方在催。我问了AI，说可能缓存问题、可能是merge、可能是GC……挨个排查了一遍都没用，还是慢，我该从哪查啊？”

我让他把集群配置和索引mapping发过来看了一眼——他这个索引是按天滚动的，保留了30天的数据，也就是30个索引、60多个shard。

我问他：”你查询条件里加时间范围了吗？”

他说：”没加，但这不是重点吧？之前没加也很快啊，突然变慢了肯定是别的原因。”

我说：”之前数据量小，60个shard里大部分是空的，can_match阶段直接过滤掉了。现在30天数据攒满了，can_match过滤不掉任何shard，60多个shard全要走query，你不慢谁慢？加上时间范围试试，只查最近3天的。”

十分钟后，他回来说：”卧槽，真的降到180ms了！但我还是不懂，加时间范围我也能想到，为啥你一听就知道是can_match的问题？不是应该先怀疑缓存、GC这些吗？”

我说备课的时候把搜索的5阶段状态机啃了一遍，第一个阶段就是can_match，干的就是预过滤shard这活。你数据量小的时候它过滤得很好，你感觉不到它的存在。但数据一多、查询条件一宽，它就拦不住了——而你压根不知道有这么个阶段在默默帮你，自然也不会往这想。

你看，他问AI了，AI给了五六个方向，他挨个试了，都没用。加时间范围他自己也能想到，但他觉得”之前没加也很快啊”，所以排除了这个方向。不是AI说错了，也不是他笨——是他不知道为什么之前没加也很快、现在没加就慢了，这个”为什么”就藏在can_match的源码里。

这事之后我想了很久，AI到底差在哪？

不是差在知识量上，它比我强太多了。差在哪呢？差在它不会”判断”。

AI能告诉can_match是干什么的，但你得先知道”之前没加时间范围也很快、现在就慢了”这个现象背后是can_match在起作用，你才会往这想。学员其实自己能想到加时间范围，但他觉得”之前没加也很快”就排除了这个方向。他不知道有个can_match阶段在默默帮他过滤shard，数据量小的时候过滤得好，他感觉不到；数据量大了过滤不了了，他就懵了。

我为什么能判断？因为我备课的时候把TransportSearchAction2541行源码啃了一遍，花了整整一周。每个阶段干嘛的、什么场景会出问题、怎么调优——我得搞清楚，不然做出来的课程就是照本宣科，经不起推敲。

这不是AI不AI的问题，是你脑子里有没有那张图的问题。有图的人，看到问题就知道该往哪走。没图的人，只能一个一个试。

我再说个更具体的。

InternalEngine.index()这个方法，AI给你讲每一步，讲得清清楚楚。但你如果不是自己啃过，你不会知道这个optimizedAppendOnly路径是跳过了VersionMap查找的——也就是说，如果你bulk里混了update，会走processNormally路径，得多查一次Lucene索引，还要把旧文档soft delete再add新文档，性能直接掉一大截。

但你不读源码，你不会知道这个坑在哪。你问AI”bulk怎么写最快”，它告诉你用action和metadata分行，但它不会说”别混update”——因为你根本不会问这个问题。你都不知道有optimizedAppendOnly这条快路径，你怎么知道混了update会掉坑？

还有Translog的durability=async。AI会告诉你这个配置每5秒fsync一次，可能丢5秒数据。你问它”Translog多大合适”，它也能给你一个512MB的建议。

但光知道建议没用，你得自己把”为什么”想通。async模式5秒fsync一次→重启需要replay Translog→replay时间跟Translog大小成正比→设太小，flush太频繁影响写入性能；设太大，宕机重启恢复慢→所以得根据你的RTO来权衡。

AI能给答案，但你得自己把”为什么”想通。 你自己没串一遍，别人一问”为什么是512″，你就只能”网上都这么说的”——你自己都没底，别人听得出来。

还有一类东西，AI更给不了，就是读源码时那种”原来如此”的感觉。

我读到soft delete的时候，第一反应是”这不就是打个标记嘛”。后来翻了Lucene的segment设计才明白，segment是不可变的，你要hard delete就得重写整个segment。Soft delete只是标一下，等merge顺带清理。

看到这我就好奇了：那什么时候merge？顺藤摸瓜翻到MergePolicy，segment超过5GB、doc超过100万、或者segment太老……这背后是一整套权衡。

AI能告诉你soft delete做了什么，但那种”我得再去看看MergePolicy”的冲动，是读源码时才会有的。 这种一环扣一环的探索，才是你越读越深的动力。

再比如Query和Fetch为什么要分两阶段。我一开始也想”分两次不是更慢吗”？后来才明白，分布式场景下先筛再取和先取再筛，传输量差几十倍。每个shard一百万doc，你要Top10。先筛后取，只需要从每个shard拿10条，传输量只有10×N。先取再筛？每个shard一百万条全传过来再选，那还得了？

AI能给你解释这个道理，但那种”卧槽原来是这样”的恍然大悟，是自己琢磨出来才有的。

所以我现在的想法是：AI改变了学源码的方式，但没改变学源码的必要性。

以前我读源码，80%的时间花在找代码上。哪个类、哪个方法、调用了谁，光是搞清楚这些就得翻半天。现在AI秒答，我腾出来的时间全用在理解设计决策上。

以前我读源码，恨不得从头读到尾，生怕漏了什么。现在只读关键路径，细节交给AI，但框架和设计意图一定自己啃。因为别人问你问题的时候，你不能说”等我问问AI”，你得有自己的判断。

说白了，以前学源码是为了”全知道”，现在学源码是为了”能判断”。

你不需要记住executeSearch的第1680行在干什么——AI能秒答。但你得知道搜索为什么是5阶段异步状态机而不是同步调，因为当你调优搜索性能的时候，你得知道瓶颈可能卡在哪个阶段。

我有个朋友，做ES运维的，以前出了问题就搜博客、问AI，能解决，但总觉得心里没底。后来他花了一个月啃源码，跟我说了句话：”以前我是’试出来的’，现在我是’算出来的’。”

我听完挺感慨的。源码给的不是知识，是底气。

AI能给你知识，但给不了你那种笃定——你指着某行代码说”问题就在这”，那种笃定，是你自己啃过源码才有的。

所以还要不要学源码？

学。但学法变了。

别再像读课文一样逐字逐句从头到尾了，读完就忘，AI时代也没必要了。

把源码当地图来读。先搞清楚数据怎么流的、模块怎么协作——这是系统模型。再搞清楚为什么这里用双缓冲、为什么那里分两阶段——这是设计意图。最后整理成自己能讲清楚的案例。

细节问AI，但框架必须自己建。案例必须自己磨。

我做ES源码分析课程，不是为了教大家背代码。说真的，代码不用背，AI比我们记得牢。

我想做的是帮大家建那个框架。读ES源码的时候知道该看什么、该跳过什么、该重点理解什么。搜索的5阶段状态机、索引引擎的8步写入流程、Translog和VersionMap怎么协作……把这些搞清楚，你脑子里就有了一张活地图。

有了地图，AI才能成为你的加速器。没有地图，AI只是一堆”有可能”。

AI时代，不缺答案，缺的是提出正确问题的人。而能提出正确问题的人，脑子里一定有那张图。

我是Fox，一个还在啃源码的程序员。

如果你也想建那张图，欢迎来找我聊聊。