Skip to main content

RAG 和 Skill 区别？什么场景必须用 RAG？Skill 能替代吗？

· 9 min read

RAG 和 Skill 不是替代关系，是解决不同问题的两套机制。混着用很容易踩坑。

  1. 本质区别：RAG 按语义检索文档，Skill 按触发词加载流程
  2. 必须用 RAG：3 类场景——开放域语料、答案分布广、用户不知道要看哪篇
  3. Skill 能替代：3 类场景——知识结构化、触发条件明确、需要本地动作
  4. 决策框架：是「检索」还是「执行」？前者 RAG，后者 Skill
  5. Claude Code 案例：它用 Skill 不用 RAG，但 Skill 内部可以包 RAG
  6. 混合方案：Skill 触发 + RAG 检索子语料，渐进式披露

核心结论：把 RAG 当 Skill 用、或者把 Skill 当 RAG 用，都是常见的设计错误。

先把两个东西说清楚​

很多人觉得 RAG 和 Skill 都是"给 Agent 喂知识"，这是误解。它们做的事完全不同：

  • RAG（Retrieval-Augmented Generation）：每次用户提问，把问题丢进向量数据库，捞回最相关的 N 段文本，塞进 prompt 再让模型生成。检索是每次都跑、动态的。
  • Skill（以 Claude Code 为代表）：把领域知识/流程写成 SKILL.md，放在 ~/.claude/skills/ 下。Agent 读每个 skill 的 description，自己判断要不要调，调的时候才把正文加载进上下文。

类比一下：RAG 像图书馆的检索系统，每次问都得现查；Skill 像你桌上的工作手册，碰到特定场景才翻开。

必须用 RAG 的 3 类场景​

场景 1：语料太大，全量塞不进去​

你公司有 10000 篇产品文档，10 万条历史工单。任何一本"书"都装不进上下文。

这种规模只能走 RAG——用户问"订单超时怎么配置"，embedding 检索捞回来 5 段，模型拿到的相关度足够高。

Skill 范式在这里直接失败：1 万个 skill 的 description 就能把 prompt 撑爆，而且用户每次问的问题都是开放的，没法为每个意图维护一个 skill。

场景 2：用户不知道答案在哪​

客服系统典型场景：用户问"我上个月下单的商品一直没收到"，系统要自己去工单库/物流库/规则库翻答案。

用户给的信号就是一句话，没有任何结构化线索告诉模型该查哪本手册。这种只能靠语义检索——RAG 的强项。

Skill 在这种场景里基本无力：触发条件写不出来，因为"用户的问题"是不可枚举的。

场景 3：内容是"语义性"的，不是"程序性"的​

RAG 适合的事实是「自然语言段落、概念解释、案例描述」。比如：

  • 「微服务的服务发现怎么实现」
  • 「订单超时的赔付规则是什么」
  • 「React 18 的 Suspense 怎么用」

这些答案是写在文档里的自然语言，检索回来直接喂给模型。

Skill 能替代 RAG 的 3 类场景​

场景 1：知识已经被结构化（章节、模板、流程）​

如果你的知识天然有清晰结构——比如一本书有目录、一个流程有步骤、一种输出有 schema——章节边界比向量相似度更可靠。

book-to-skill 这个项目就是这条路：把书按章节拆成 skill，Agent 调的时候只加载相关的章节。它官方明确说过「比 RAG 更适合这类场景」——因为「书的章节是人写的，比向量相似度更可靠」。

反过来，RAG 在这里表现很差：把整本书切 chunk 喂 embedding，捞回来的段落经常是逻辑断裂的半句话。

场景 2：触发条件明确，写得出 description​

Skill 的核心机制是 description 匹配触发。如果你的意图能用一句话说清「什么时候调它」，就适合 Skill。

典型例子：

  • 「用户说部署 / 上线 / 发布 时使用」
  • 「把会议纪要转成 16:9 PPT」
  • 「画系统架构图」

RAG 在这里过度设计——你本来就知道答案在哪、何时查，检索那一套是浪费。

场景 3：需要本地动作（命令、文件、脚本）​

RAG 只能吐文本。Skill 可以带 scripts/、templates/、自定义工具，能跑命令、能生成 .drawio、能写 PDF。

比如「按团队规范生成 PR 描述」「应用代码风格配置」这类 有副作用的任务，RAG 完全帮不上。一个 Skill 写完能直接执行。

决策框架：一张图说清​

更短的判断：

这个问题用 RAG用 Skill
语料 10000+ 篇✓
语料 100+ 篇，结构化✓
用户问法开放、不可枚举✓
用户问法用 trigger 词能覆盖✓
答案分布在语义段落里✓
答案需要执行命令/生成文件✓

Claude Code 案例：为什么它选 Skill 不选 RAG​

Claude Code 放弃了 RAG，这是公开承认过的工程决策。三个原因：

  1. Embedding 对代码标识符失效——getUserById 和 deleteUserById 在向量空间里很近，但语义相反
  2. 管线准确率是乘法——文档切分 × embedding × 检索 × 重排 × 组装，5 个 90% 串起来只剩 60%
  3. 索引永远会过时——代码高频变动，索引漂移是常态

但这不等于 Claude Code 是"反 RAG"的。它选 Skill 而不选 RAG，是因为 代码检索是程序性、结构化、可枚举的 —— 不需要语义检索。

Claude Code 的实际做法：

  • ~/.claude/skills/ 装各种 skill，每个 skill 是确定的工作流
  • description 触发条件，Agent 调的时候才加载正文
  • 内部动作（grep、读文件、跑命令）由 Skill 里的脚本完成

Skill 触发 + RAG 检索：

claude-video-skill 这个 skill 是个典型混合方案——它读视频时，Skill 包了 RAG。具体流程：

几个关键点：

  • Skill 负责"流程"：触发意图、装脚本（yt-dlp / ffmpeg）、组织输出
  • RAG 负责"长上下文"：5000 行字幕扔进 prompt 烧 token，必须检索
  • Skill 失败 的场景：用户问"这段视频讲了什么"——必须返回 top-k，但 k=5 可能漏
  • RAG 失败 的场景：用户问"app login 怎么操作"——用 trigger 词直接命中描述，走 Skill 更快

这种「Skill 触发 + RAG 子检索」是 Claude Code 里最常见的混合模式，Agent 海量 Skill 加载 文章里讲的三层架构里，L3 那层就是 RAG。

几个常见的设计错误​

错误 1：把 RAG 当 Skill 用

"我每个 FAQ 折成一个 skill，description 写得详细一点。"

FAQ 多到 200+ 之后，description 严重超载，prompt 被撑爆，Agent 选错 skill 的概率飙升。FAQ 就该走 RAG，把语料丢进向量库，每次问现查。

错误 2：把 Skill 当 RAG 用

"我把团队所有规范文档折成一个 skill，正文里涵盖所有场景。"

结果是：用户每次问相关的都得加载整个 skill，token 烧得离谱，而且因为没有按章节拆分，Agent 只能机械地匹配关键词，逻辑链断了也不知道。

正确做法：按章节/场景拆成多个 skill，description 写清楚各自触发条件，按需加载。

错误 3：硬要 RAG 替代 Skill

"我觉得 RAG 才是 AI 时代的未来，把所有 skill 都改成 RAG，description 都不写了。"

RAG 触发不靠语义、不靠 description，靠 相似度阈值。阈值低了频繁误触发，阈值高了该触发的没触发。没有 description 这套契约机制，Skill 范式的可调试性、复用性、组合性都丢光了。

怎么选：3 个判断问题​

下次面对一个新需求，问自己 3 个问题：

  1. 这份知识是「段落」还是「步骤」？ 段落 → RAG；步骤 → Skill

  2. 用户问法是开放的，还是 trigger 词能概括的？ 开放 → RAG；trigger 词 → Skill

  3. 答案需要本地副作用吗？ 需要（命令、文件、生成）→ Skill；纯文本 → 都可以，看 Q1

3 个问题答完，答案基本就出来了。

References​

  1. ClaudeCode 为什么放弃了 RAG？ —— 2026-06-24
  2. book-to-skill 把一本书按章节拆成 Skill —— 2026-07-06
  3. Agent 如何加载海量 Skill？ —— 2026-07-22
  4. 怎么写一个 Agent Skill？ —— 2026-07-09
  5. Anthropic Agent Skills 官方文档 —— Skill 触发 / 加载机制
  6. Skills Manager —— 多 AI 工具的 Skill 统一管理