这项由加州大学圣地亚哥分校、加州大学河滨分校、南加州大学和斯坦福大学共同完成的研究以预印本形式发布于2026年7月论文编号为arXiv:2607.25431感兴趣的读者可通过该编号查阅完整论文。当你请AI帮你写代码或修复软件漏洞时它首先需要读懂整个项目的代码库——就像一个新来的程序员要先翻遍公司所有的文档和源码才能开始干活。问题是这个翻阅的过程每次都要重头来过不仅慢还会把大量精力花在反复查找同样的内容上真正用来思考和解决问题的精力反而所剩无几。研究团队把这个问题比作一家没有档案管理系统的图书馆。每次有人来借书图书管理员就得从头把所有书架翻一遍找到需要的资料再递过去。如果有一套分类清晰、随时更新的档案室借阅效率自然会大幅提升。他们开发的系统叫做CodeNib核心思路就是提前把代码库整理成几种不同的索引卡片分门别类存放好AI助手来查的时候直接按需取用不必每次从零开始摸索。一、为什么AI编程助手总在原地打转要理解这个问题的根源先来看一下AI编程助手平时是怎么工作的。当它接到一个任务比如帮我找出这个bug在哪里它会像一个刚入职的程序员一样用搜索工具在代码里翻来翻去一个文件一个文件地阅读把看过的内容记在草稿本也就是它的对话历史里然后慢慢缩小范围最终定位问题。这个过程有三个明显的缺陷。第一每次接到新任务这个翻箱倒柜的过程都要重复一遍哪怕昨天刚查过同样的代码。第二随着查找过程越来越深草稿本越写越厚AI每次回答前都要把这本厚厚的草稿通读一遍这不仅费时还会因为草稿太长而超出AI的记忆上限。第三代码库的内容是会变化的——今天修改了某个函数昨天整理的笔记就可能过时了AI拿着旧笔记给出的建议自然不可靠。研究团队把这三个问题概括为三个挑战如何把代码库的不同侧面整理成不同类型的索引如何在代码更新后快速刷新这些索引以及如何把整理好的内容高效地交给AI使用。CodeNib就是针对这三个挑战设计的解决方案。二、档案室的三种索引卡片CodeNib的核心是提前为每个代码库的特定版本用专业术语叫提交版本可以理解为代码的某个历史快照建立三种不同性质的索引就像图书馆里分别有按关键词排列的索引卡、按内容相似度排列的推荐系统和按书目关系排列的引用图谱一样。第一种叫词法索引本质上是一个超级精细的关键词搜索系统。它会把代码里的所有标识符函数名、变量名、类名等、注释和文本内容全部拆解成可以快速检索的格式类似于搜索引擎的倒排索引。当AI想找某个特定名字或关键词出现的地方词法索引能在毫秒级时间内给出答案。第二种叫向量索引这是一种更聪明的索引方式。它会把每个代码片段的语义含义转化成一串数字向量语义相近的代码片段在数字空间里会彼此靠近。好处是可以做意思相近的搜索——即使没有用相同的词只要功能或逻辑相似也能被找到。这就像图书馆的推荐系统你借了一本讲理财的书系统会推荐其他讲投资的书哪怕书名里没有理财二字。第三种叫结构图索引记录的是代码元素之间的关系网络。哪个函数调用了哪个函数哪个类继承了哪个类哪个模块依赖了哪个模块——所有这些关系都像一张巨大的路线图一样被存储下来。当AI需要追踪某个函数的调用链、或者找出修改某个地方会影响哪些地方时结构图索引就像GPS导航一样指引它快速找到目标。这三种索引彼此独立存储但都使用同一套坐标系——每条索引记录都会指向代码库里的具体文件路径和行号就像档案室里每张卡片上都标注了对应书目的书架位置和页码一样。还有一份名为清单Manifest的总目录记录每种索引的状态、建立时间和支持的查询类型AI助手上班时第一件事就是查这份清单了解手头有哪些可用工具。三、代码更新后档案室怎么跟上现在来到第二个挑战代码库是动态变化的每次有人提交修改三种索引理论上都需要更新。如果每次更新都要从头重建所有索引那么对于一个几十万行的大型代码库来说每次可能需要几分钟甚至更长时间实用性大打折扣。研究团队的解决思路是外科手术式的精准更新——只修改真正受影响的部分而不是推倒重来。对于结构图索引他们开发了两种修复策略可以类比成修缮一栋楼的两种方案。第一种是楼层级翻新找出被修改文件对应的那层楼把整层拆掉重建再把和其他楼层的连接重新接好。第二种是房间级修缮对比代码修改的具体内容判断哪些函数被删除了、哪些被调整了、哪些只是位置挪了几行但内容没变然后保留不受影响的部分只修复真正改变的那些房间。后者需要借助语言服务器一种专门分析代码结构的工具来精确定位每个符号的位置和关系但可以少做很多重复工作。论文中有一个很直观的例子对同一处代码修改房间级修缮只需要5次查询而楼层级翻新需要9次效率提升了将近一半。对于向量索引更新策略则更加直接。由于每个代码片段都有唯一的内容指纹哈希值如果某段代码的内容完全没有变化它对应的向量可以直接复用根本不需要重新计算。只有内容确实发生变化的代码片段才需要重新生成向量。这就像书架上换了几本新书只需要为新书建索引卡原来的卡片一张都不用动。关键是为了确保这种快捷更新的结果是可靠的研究团队在每次更新之后都会单独做一次全量重建把快捷更新的结果和从零重建的结果逐一比对。只有在两者完全一致的情况下那次更新的速度数据才会被纳入统计。这意味着报告出来的速度优势都是有质量保证的而不是用准确性换来的。实验结果显示在通过质量检验的更新案例中房间级图修复的速度是全量重建的中位数8.67倍向量更新的速度是全量重建的25.44倍。不过图索引的通过率只有45.5%33次中有15次通过向量更新的通过率则高达90.3%31次中有28次通过。这个差异说明向量的内容寻址复用是一种相当成熟可靠的策略而代码结构关系的精确修复在某些语言特别是Rust和TypeScript/JavaScript上还存在难度需要进一步完善。四、查找代码就像问图书馆员而不是自己翻书架有了这三种索引之后AI助手查找代码的方式就完全变了。以前它要自己拿着搜索命令到处查现在它可以直接向CodeNib发出结构化的查询请求就像向专业图书馆员提问一样。CodeNib支持两类主要查询。第一类是排名检索给一个自然语言描述的问题返回一个按相关性从高到低排列的代码片段列表。这个检索可以仅用关键词匹配词法路线也可以仅用语义相似度向量路线也可以把两者的结果混合再排一次混合路线还可以在向量检索的基础上沿着代码的调用关系再扩展一跳把直接相关的代码片段的邻居也纳入候选结构路线。返回的结果中每个代码片段都带有它在代码库中的具体位置文件路径和行号可以直接跳过去看。第二类是符号导航给一个具体的代码位置询问这里定义在哪里或哪些地方引用了这里。这等于是把原来需要启动一个完整语言服务器才能回答的问题通过预先建好的结构图和符号索引来静态回答不再需要实时启动和运行一个重量级服务。研究团队对这两类查询都做了细致的实验。在排名检索方面他们测试了五种不同的嵌入模型用来把代码转成数字向量的工具从1.37亿参数的轻量级模型到70亿参数的大型模型都有。实验发现选用更大的模型确实能提高检索命中率但代价是更长的查询时间——最小的模型每次查询只需26毫秒最大的需要295毫秒。如果在检索基础上再加一个重排序步骤用一个语言模型对候选结果再评分一遍准确率还能进一步提升但时间代价急剧增加从毫秒级变成秒级甚至十几秒级。比如Jina模型加上4B重排序器文件命中率从81.2%提升到85.8%但时间从92毫秒变成了4.29秒慢了46倍多。这就意味着没有一个放之四海而皆准的最优组合需要根据具体场景在速度和准确率之间做出权衡。至于结构扩展沿着调用关系扩一跳的效果实验结论比较复杂在不同的嵌入模型组合下有时候有帮助有时候反而有轻微干扰而且统计上无法确认这种差异不是随机波动。所以这个功能被标注为需要针对具体部署场景单独验证而不是默认推荐。在符号导航方面研究团队把CodeNib的静态索引答案和五种主流语言服务器专门用于实时代码分析的工具的答案做了对比。结果显示在1000次查询中有63.2%的情况下两者的答案完全一致其中找定义的一致率高达87.4%而找引用的一致率只有39%。在答案一致的那63.2%里静态索引的响应速度中位数是0.62毫秒而语言服务器是2.26毫秒快了4.72倍。但这4.72倍的速度优势只在答案一致的子集里成立并不意味着所有情况都能用静态索引替代语言服务器——那36.8%答案不一致的请求仍然需要实时语言服务器来处理。五、把整理好的内容送到AI面前的三种策略档案室建好了查询效率也提升了最后一个问题是怎么把查到的内容最高效地交给AI使用这个环节的核心矛盾在于AI的记忆容量是有限的。就像一个人的工作台面有限放太多文件反而找不到要用的那份一样塞进AI对话里的内容越多它处理起来越慢、越贵有时候反而影响效果。研究团队设计了三种内容交付策略并用五种不同的AI模型包括Claude Haiku 4.5、Qwen3.5-9B、Qwen3.5-27B、Gemma 4-12B和Gemini 2.5 Flash做了系统对比实验。第一种策略叫搜了再读AI完全自主行动用搜索和阅读工具自己去找需要的代码不预先塞给它任何东西。这是最传统的方式。第二种策略叫急切模式在AI开始工作之前先把向量检索排名最高的前10个代码片段直接放进AI的工作记录里相当于帮它提前准备好了最可能有用的参考资料。第三种策略叫压缩模式先和急切模式一样预先放入前10个代码片段然后等AI做了第一次有效阅读之后把之前探索过程中积累的所有临时记录清空只保留一个精简的方向总结包括已读文件路径、最新的阅读结果以及最近一次AI自己写的分析摘要的前600个字符从这个清爽的起点继续往下工作。这就像一个人在大图书馆里查了半天资料把零散的草稿全部整理成一页核心笔记然后带着这页笔记继续深入研究避免被一堆乱纸搞晕。实验结果相当清晰地展示了一个规律急切模式和压缩模式在最终答案的准确率上和搜了再读基本持平在论文设定的±5个百分点容差范围内但用掉的对话令牌可以理解为AI处理这次任务花费的计算资源大幅减少。在五种模型中选出最省令牌又满足准确率要求的策略相比搜了再读可以节省50%到87%的令牌消耗。不过压缩模式并非万能解药。对于Haiku模型压缩反而让令牌消耗增加到了急切模式的123.3%所以对它最优的选择是急切模式而非压缩模式。Gemma和Gemini用压缩模式确实节省了大量令牌但准确率也有小幅下降好在下降幅度仍在可接受范围内。这说明最优策略是因模型而异的不存在一刀切的答案。六、一次完整的投入产出账算下来是多少研究团队还专门做了一次从头到尾的生命周期成本核算把建设档案室的一次性成本、每次打开档案室的启动成本和每次实际查询的运行成本分开计量。在25个代码库快照上词法索引BM25的构建中位时间是0.81秒结构图的构建中位时间是38秒向量索引的构建中位时间是59.5秒三者合计的完整物化时间中位数是116.7秒置信区间为65.6到153.9秒。把建好的索引加载到内存里准备查询需要7.40秒置信区间6.99到8.07秒。在标准测试场景下跑一个包含20组查询任务的服务追踪耗时0.73秒。用这些数字可以做一个简单的盘算假设同一份代码库的索引会被复用20次每次复用时索引的建设成本被平均摊薄到二十分之一每次打开档案室的加载成本则要完整支付一次那么每次使用的综合成本大约是13.2秒。如果有一个长期运行的驻场进程始终保持档案室打开加载成本也可以分摊那么每次使用成本降到6.24秒。而如果复用次数扩大到100次这两个数字会分别变成8.53秒和1.27秒后者已经非常接近单纯查询的运行成本下限。换句话说档案室越多人用、越频繁用每次使用的综合成本就越低。七、这套档案室适合哪些场景整个系统的设计边界同样值得关注研究团队对此保持了相当克制和诚实的态度。CodeNib解决的是找代码和理解代码库结构的问题而不是写代码或判断测试是否通过的问题。它的清单记录的是某一时刻代码库的状态但不能保证在建立索引的过程中代码库没有被其他人同时修改。三种索引是独立存储的没有跨索引的原子事务保证也就是说在代码更新的间隙有可能出现某个索引已更新而另一个还没更新的短暂不一致状态。静态符号导航在36.8%的请求上和实时语言服务器的答案不一致这部分请求仍然需要保留实时语言服务器作为后备。对于要求绝对准确的代码分析场景不能把静态索引当作语言服务器的完全替代品。研究团队在论文的讨论部分也坦承这套系统目前还不支持多个AI助手并发访问和更新同一个代码库时的版本管理也没有成本导向的自动路由决策这些都是未来可以继续完善的方向。说到底CodeNib做的事情用一句话来概括就是把原来每次任务都要重新翻查的代码库信息变成一套可以反复复用、按需取用的结构化档案并且通过精准的增量更新机制保持档案的时效性最终让AI编程助手把有限的注意力更多地用在实际解决问题上而不是反复做重复的信息查找工作。这个思路本身并不复杂但把它实现得足够可靠、可测量、可解释让每一环节的代价和收益都清晰可见正是这篇研究真正花了大力气的地方。有兴趣深入了解技术细节的读者可以通过arXiv:2607.25431查阅完整论文。QAQ1CodeNib的三种代码索引分别是什么各有什么用ACodeNib为代码库建立三种索引词法索引类似关键词搜索能快速找到特定名字或文本出现的位置向量索引把代码语义转成数字能找到功能相似但用词不同的代码结构图索引记录函数调用、类继承等关系帮助追踪代码之间的依赖链路。三者各司其职查询时按需取用。Q2CodeNib的增量更新速度比全量重建快多少可靠吗A在通过质量验证的案例中结构图的房间级修复比全量重建快8.67倍中位数向量内容复用比全量重建快25.44倍中位数。可靠性方面向量更新在90.3%的测试案例中与全量重建结果完全一致结构图更新的一致率为45.5%Rust和TypeScript等语言的图修复还有待改善。Q3CodeNib的三种内容交付策略在实际使用中该怎么选A研究发现没有万能最优解需根据使用的AI模型来定。对于Claude Haiku模型直接预加载代码片段的急切模式最省资源对于Qwen3.5、Gemma和Gemini等模型在急切模式基础上加一次历史压缩的压缩模式能进一步降低12%到72%的令牌消耗同时保持答案准确率基本不变。