建好一个能查代码的 AI 知识库不算难，难的是让它三个月后还跟得上代码本身的变化——这是我们本周在掘金一篇长文里看到的核心判断。作者用一个真实场景举例：8 个文件发生变更，其中 0 个是真正的代码文件，正确的处理是「什么都不做」，否则就是在白白烧 API 预算和等待时间。

这是什么

这是关于「RAG（Retrieval-Augmented Generation，即让 AI 检索外部知识库后再回答）落地工程」的一篇深度文章，聚焦一个常被忽视的环节：索引的增量更新。文章提出三层判断机制——第一层决定「这次变更是跳过还是更新」，第二层决定「只重建变更函数」，第三层决定「沿调用链传播影响」。整套逻辑的核心假设是：函数是相对独立的语义单位（向量表征的最小单元），因此可以局部替换而不必全量重跑。

行业怎么看

支持方认为这是 RAG 工程化的必经之路——中型代码库全量重建动辄数小时，不可能每次代码提交（commit）都跑一遍，按文件类型过滤加函数级增量是务实的折中。文章给出的数字很具体：变更 50 个函数 vs. 总量 7,761 个函数时，更新成本约为全量的 0.6%。

但反对意见同样成立。这套「函数即独立语义单元」的预设，在实际工程里站不住脚：重命名一个函数会影响所有调用方的 embedding；重构一个类的继承关系会让符号索引整体偏移；跨文件的装饰器、动态导入、泛型展开都会让「局部替换」产生隐性误差。换句话说，增量更新节省的是时间，可能换来的是「三个月后没人发现的知识库漂移」。我们注意到，作者自己也承认传播分析是「更难的问题」，但没有给出可验证的方案。

对普通人的影响

对企业 IT 部门：如果你们正在评估代码 AI 工具，别只看「能不能查到」，要问「三个月后还能查到吗」——索引维护成本是隐性 TCO（总拥有成本）。

对个人职场：这类工程细节正在成为「AI 应用工程师」和「AI Demo 工程师」的分水岭，懂调用图传播的人远比只会调 API 的人稀缺。

对消费市场：短期内不会直接传导到 C 端产品，但企业级代码 AI 的定价可能从「按查询」转向「按维护」，最终影响采购预算。