有AI了学习源码还有意义吗说实话我也迷茫过。去年开始身边越来越多人跟我说别费劲读源码了问AI呗人家秒答还讲得特别清楚。我试了几次确实厉害。ES的search入口在哪秒答。IndexingStrategy怎么选路径的逐行解读。让我写个bulk工具类质量比我还高。那我还啃啥源码啊直到有一次在学员群里有个学员我特别急Fox老师救命生产环境搜索突然变慢平时200ms现在飙到2秒多业务方在催。我问了AI说可能缓存问题、可能是merge、可能是GC……挨个排查了一遍都没用还是慢我该从哪查啊我让他把集群配置和索引mapping发过来看了一眼——他这个索引是按天滚动的保留了30天的数据也就是30个索引、60多个shard。我问他你查询条件里加时间范围了吗他说没加但这不是重点吧之前没加也很快啊突然变慢了肯定是别的原因。我说之前数据量小60个shard里大部分是空的can_match阶段直接过滤掉了。现在30天数据攒满了can_match过滤不掉任何shard60多个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新文档性能直接掉一大截。但你不读源码你不会知道这个坑在哪。你问AIbulk怎么写最快它告诉你用action和metadata分行但它不会说别混update——因为你根本不会问这个问题。你都不知道有optimizedAppendOnly这条快路径你怎么知道混了update会掉坑还有Translog的durabilityasync。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顺藤摸瓜翻到MergePolicysegment超过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时代不缺答案缺的是提出正确问题的人。而能提出正确问题的人脑子里一定有那张图。