代码知识工程怎么选：RAG、Skills、Repo Map、FastCode 与 LLM Wiki

RAG、Skills、Repo Map、FastCode 和 LLM Wiki 经常被放在一起讨论，因为它们都在解决同一类表面问题：代码和业务资料太多，模型一次看不完。

但它们不是五种不同品牌的“知识库”。每种方案交付给 Agent 的东西不同：RAG 给片段，Skill 给规则，Repo Map 给地图，FastCode 给本次任务需要的代码路径，LLM Wiki 给已经组织好的知识页面。核心产物不同，适合的问题自然不同。

如果忽略这个差别，选型很容易变成“哪个更先进”。更有用的问题是：当前任务缺的是事实、规则、结构、动态探索，还是一套可以反复阅读的整体解释？

一、先用一句话分开五种方案

• RAG：问题来了，从知识源中找出几段最相关的证据。
• Skills：任务开始时，把稳定规则、步骤、边界和验收方式交给 Agent。
• Repo Map：预先压缩仓库结构，让模型先知道有哪些模块、符号和关系。
• FastCode：围绕当前任务多步侦察，从入口逐渐找到真正需要阅读和修改的代码。
• LLM Wiki：预先把代码、文档和业务知识整理成可阅读、可引用、可更新的页面。

这个划分比实现技术更重要。五种方案都可能使用关键词检索、向量索引、语法树和大模型，但底层组件相似，不等于它们解决同一个问题。

二、RAG：把当前问题需要的证据找回来

RAG 的初始状态是一批已经接入的资料。离线阶段把资料解析、切块并建立稀疏或向量索引；在线阶段收到问题后，系统先检索候选片段，再重排、拼装证据，最后让模型基于证据回答。

用户问题
  ↓ 查询改写
稀疏召回 + 向量召回
  ↓ 融合、去重、重排
相关证据片段
  ↓ 带引用生成
回答

它最擅长的是开放式事实查询。例如“退款成功回调有哪些字段”“RefundTask 的最大重试次数是多少”。问题发生时才取材料，知识更新后重建索引或增量入库即可，不必重新训练模型。

RAG 的问题也来自“片段”这个产物。一次需求往往需要分散在多处的规则、代码和历史原因，单次 Top-K 召回可能只找回其中一部分。片段彼此相关，却不一定组成完整流程。召回错误、重排丢失、证据过期和权限过滤遗漏，都会让最终回答失真。

所以 RAG 适合“我已经知道要问什么”，不天然适合“我刚进入这个领域，不知道该从哪里开始”。完整机制见《RAG 技术地图：从向量检索到 Agentic RAG》。

三、Skills：把必须遵守的工作方法放进执行上下文

Skill 不是把所有业务资料复制进一个 Markdown 文件。它更像一份给 Agent 的操作规程：何时触发、需要先读哪些资料、允许调用什么工具、必须遵守哪些业务约束、怎样验证完成。

例如退款 Skill 可以规定：

触发：修改退款、渠道回调或退款状态机
先读：退款状态定义、渠道能力表、补偿任务入口
约束：退款金额不得超过支付快照中的可退金额
动作：修改实现后检查状态迁移与幂等键
验收：单测、状态机测试、渠道降级路径全部通过

它最擅长的是稳定而高价值的规则。有些要求靠检索并不稳，因为 Agent 每次都可能找不到，或者找到却没有把它当作硬约束。把这些规则放入按场景加载的 Skill，可以在执行前明确告诉模型“这件事必须怎样做”。

Skill 的弱点是依赖人工取舍。规则没人维护就会过期，写得过宽会占用上下文，写得太细又会变成另一套难维护的文档。它也不适合保存每个函数的事实，更不能替代对当前代码的读取。

选择 Skill 的信号很明确：同一种错误反复出现，原因不是资料不存在，而是 Agent 没有稳定执行某项规则或步骤。具体组织方式见《让 Code Agent 读懂业务：把仓库知识做成可维护的 Skills》。

四、Repo Map：先给模型一张压缩过的仓库地图

Repo Map 的初始状态是一个大仓库。构建器解析目录、文件、符号以及部分引用关系，再按重要度和 Token 预算压成一张地图。地图通常包含符号签名和位置，不会塞入每个函数的完整实现。

它回答的是：

• 仓库里有哪些主要模块；
• 这个类或接口在哪里；
• 哪些符号可能互相引用；
• 下一步应该打开哪些文件。

Repo Map 最擅长结构导航。Agent 不必从文件名盲猜，也不必把整个仓库塞进上下文。它看到 RefundController → RefundService → ChannelGateway 的骨架后，可以决定先读哪几处实现。

地图终究不是代码本身。反射、配置注入、消息路由和运行时数据流不一定能从静态符号中恢复；业务规则也可能根本不在仓库里。地图过期时，模型还会沿着旧路走。因此它适合回答“东西在哪、结构怎样”，不负责解释“为什么这样做”。

如果项目不大，模型通过文件搜索很快就能定位，维护 Repo Map 的收益可能有限。大仓库、符号多、入口难找时，它才更明显。细节见《Repo Map：让模型在动手前先看清仓库》。

五、FastCode：为当前任务动态侦察代码

Repo Map 给的是相对稳定的地图，FastCode 强调的是一次任务中的动态侦察过程。系统先从需求提取线索，用关键词、向量和结构索引得到候选，再沿调用、依赖或继承关系扩展，直到证据足够支持下一步修改。

任务：修改退款金额计算
  ↓ 找入口和领域词
RefundController / RefundService / refundableAmount
  ↓ 沿调用与数据关系扩展
支付快照 → 优惠分摊 → 退款流水 → 渠道请求
  ↓ 判断证据是否足够
不足：继续侦察    足够：组装最小上下文
  ↓
交给编码 Agent 规划、修改和验证

它比一次检索更适合边界不明确的跨模块任务。第一次召回只提供起点，后续每一步根据已经发现的代码决定往哪里走。最终交付的不是整张仓库地图，而是当前任务需要的一条或几条代码路径。

代价是系统更复杂。它需要结构索引、搜索策略、停止条件、Token 预算和失败回退。索引漏边时可能提前停止，探索太宽时又会带回大量噪声。它也不能自动补齐仓库外的业务背景。

当 Agent 经常“搜到一个文件就开始改”，最后遗漏跨模块影响时，FastCode 的价值会高于再加一次普通向量检索。详细机制见《FastCode：先侦察代码结构，再把上下文交给模型》。

六、LLM Wiki：把反复需要的理解预先编译出来

LLM Wiki 的输入不必只有代码。它可以接入 PRD、接口文档、数据库 schema、代码仓库、事故复盘和决策记录，抽取实体、关系、结论与证据，再生成概览、流程、规则、决策和排障页面。

它最擅长建立稳定的整体认识。新人可以从“支付域总览”逐层读到退款流程，Agent 也可以先读页面理解背景，再回到具体证据。页面之间有导航和交叉引用，不要求使用者一开始就知道该问什么。

LLM Wiki 的成本主要在更新和信任。来源冲突时不能替读者做无依据的裁决；来源变化后要知道哪些结论和页面受影响；权限还要贯穿解析、生成、索引和展示。只生成一次而没有更新闭环，页面很快就会变成更难识别的旧文档。

它适合组织规模较大、知识分散、同一个领域被反复解释的情况。只是为了给 Agent 找一个函数，做完整 Wiki 反而太重。多源实现见《LLM Wiki：把代码、文档与业务知识编译成可维护的知识页》。

七、把五种方案放到同一张表里

方案	核心产物	何时构建	最擅长的问题	主要代价	典型失败
RAG	与当前问题相关的证据片段	离线建索引，在线检索	“某个事实是什么”	解析、召回、重排和评测	关键片段没召回，证据被切碎
Skills	规则、步骤、工具边界和验收方式	人工或半自动维护，任务前加载	“这类任务必须怎样做”	取舍和持续维护	规则过期、过宽或互相冲突
Repo Map	压缩后的目录、符号与关系地图	仓库变化后重建或增量更新	“代码在哪里，结构怎样”	解析多语言代码、控制预算	静态关系缺失，地图过期
FastCode	当前任务的代码路径和最小上下文	离线建索引，在线多步侦察	“这次修改真正涉及哪些代码”	探索策略、停止条件和延迟	提前停止或探索范围失控
LLM Wiki	有导航、引用和版本的知识页面	离线生成并持续更新	“这个领域整体怎样工作”	冲突治理、增量更新和权限	页面流畅但过期或无证据

这张表还有一个容易忽略的信息：RAG、Repo Map 和 FastCode 更直接地服务机器的上下文选择；LLM Wiki 首先是知识产品，人和 Agent 都能消费；Skill 则更接近执行策略，告诉 Agent 怎样使用知识和工具。

八、用同一个退款需求看五种方案

现在有一个需求：

新增一种营销补贴。退款时，用户实付按支付快照原路退回，平台补贴不可退给用户；修改后要保证重复回调不会重复退款。

只有 RAG 时

Agent 查询“退款金额怎样计算”，RAG 可能找回产品规则、某段退款代码和优惠分摊文档。它能提供事实，但如果 Top-K 漏掉“支付快照是金额基准”或“渠道回调会重复”中的一项，方案仍可能不完整。

RAG 适合帮 Agent回答局部问题，不负责保证它已经问完所有关键问题。

加上 Skill 时

退款 Skill 会在任务开始就声明：金额以支付快照为准；任何渠道回调都按退款单业务键做幂等；修改状态机必须补正常、超时和重复回调测试。

这三条不是临时搜到的背景，而是本次执行必须满足的条件。Skill 降低“知道规则却没执行”的概率，但 Agent 仍要寻找具体实现。

加上 Repo Map 时

地图告诉 Agent，退款入口在 RefundController，金额计算落到 RefundAmountCalculator，渠道请求通过 RefundGateway，幂等状态保存在 refund_order。Agent 不需要遍历几千个文件，能快速打开候选位置。

地图给出的是骨架。新的营销补贴具体怎样影响金额，仍要读实现和业务资料。

使用 FastCode 时

侦察从退款入口出发，沿数据关系追到支付快照和优惠分摊，又沿回调入口追到退款单状态迁移和唯一键。系统发现旧补贴类型在另一个模块还有一处分支，于是把它也加入上下文。

FastCode 在这里解决“影响范围到底多大”。若它的关系索引没有识别配置驱动的补贴处理，就需要退回关键词搜索、运行时 Trace 或让人补充线索。

使用 LLM Wiki 时

Agent 或开发者先读“退款金额规则”和“重复回调恢复”两页，知道为何使用支付快照、历史上发生过什么事故、产品和代码当前是否一致。页面还会链接到相关 PRD、代码符号和数据库字段。

Wiki 提供背景与来龙去脉，但最后修改哪些代码，仍应交给 Repo Map、FastCode 或实际搜索确认。

九、实际系统怎样组合，而不是五选一

一个比较自然的组合顺序是：

任务进入
  ↓ Skill 加载稳定规则与验收条件
  ↓ Wiki 提供领域背景和已有决策
  ↓ Repo Map 给出仓库骨架
  ↓ FastCode 围绕任务侦察影响路径
  ↓ RAG 按需补具体文档与代码证据
  ↓ 编码、测试、证据回收

这不是固定流水线。问题很小，可以只用搜索和 RAG；仓库结构清楚，可以跳过 Repo Map；没有反复阅读需求，就不必建 Wiki。组合的目的，是让每种产物承担它擅长的部分，而不是凑齐五个名词。

底层基础设施可以共享：

• 文档解析结果同时供 RAG 和 Wiki 使用；
• AST、符号和依赖图同时供 Repo Map、FastCode 和 Wiki 使用；
• 来源版本、权限和删除状态由一套元数据管理；
• Agent 使用后的证据与失败样本进入统一评测集。

最浪费的做法，是五套产品各自解析一遍相同资料，各自维护版本与权限，最后产生五份互相不一致的事实。

十、按当前痛点选择第一步

事实找不到：先做 RAG

团队已经有文档，只是分散、搜索差，问题又大多是明确事实查询。先把解析、切块、混合召回、重排和引用做稳，不急着生成 Wiki。

Agent 总违反同一类规则：先做 Skills

资料明明存在，Agent 也偶尔能找到，但它经常忘记先查状态、漏跑验证或违反业务红线。把高价值规则做成按场景加载的 Skill，比继续堆资料有效。

大仓库里找不到入口：先做 Repo Map

问题集中在定位，业务规则相对简单。优先提供目录、符号和引用骨架，再让模型按地图打开代码。

跨模块改动经常漏影响：考虑 FastCode

一次搜索不够，任务要沿调用、数据和配置关系逐步扩展。此时需要动态侦察和停止条件，而不是只增加召回数量。

同一领域被反复解释：考虑 LLM Wiki

新人、跨团队协作者和 Agent 都在重复理解相同流程，知识又散落在代码与文档之间。把高频领域编译成稳定页面，收益才可能覆盖维护成本。

规模很小：可以一个都不做

十几个文件的小项目，准确的 README、清晰命名和普通文本搜索可能已经够用。技术选型的目标是减少任务成本，不是让知识架构看起来完整。

十一、做完以后分别看什么指标

不同产物不能共用一个“回答准确率”概括。

• RAG：正确证据的 Recall@K、重排后保留率、引用支持率、无证据拒答率；
• Skills：触发准确率、规则遵守率、验收通过率、过期规则比例；
• Repo Map：入口定位成功率、关键符号覆盖率、地图 Token 成本、地图新鲜度；
• FastCode：影响文件召回率、无关上下文比例、侦察步数、任务成功率；
• LLM Wiki：关键结论证据覆盖率、页面过期率、真实任务完成率、冲突处理时长。

共同指标是任务结果：修改是否正确，是否漏影响，使用者花了多少时间，失败后能否定位到知识链路中的具体环节。若指标只统计“生成了多少页”“索引了多少文档”，很容易得到一个规模很大却没人依赖的系统。

十二、最后的判断

这五种方案可以按一句话记住：

RAG 找证据
Skills 定规矩
Repo Map 给地图
FastCode 找路径
LLM Wiki 建认识

选型时先看缺口。缺事实就补检索，缺稳定约束就补 Skill，缺仓库结构就做 Repo Map，缺任务级影响分析再做 FastCode，缺长期可复用的整体理解才做 LLM Wiki。

真正成熟的代码知识系统通常会组合其中几种，但不会一开始把五种全做完。先用最轻的方案解决最频繁的失败，再让共享事实层逐步长出来，比从一张完整架构图倒推实现更可靠。

参考资料

• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks：RAG 的经典论文，明确了参数记忆与外部非参数记忆的组合方式。
• Aider: Repository Map：使用符号与依赖关系压缩仓库结构的工程实现。
• FastCode: Fast and Cost-Efficient Code Understanding and Reasoning：围绕代码任务先侦察、再组装上下文的研究方案。
• Microsoft GraphRAG: Indexing Dataflow：多源文本转为实体、关系、Claim 和报告的知识组织例子。
• Cognition DeepWiki：把代码仓库生成可阅读 Wiki 的具体产品形态。