很多人以为 AI 越来越强，用起来会越来越顺。事实正好相反——项目一大，AI 反而变笨。

因为它根本不知道你更新了什么。大模型是基于静态数据训练的，每次项目更新，都得想办法让它知道。

AI 不知道更新了什么，会怎样？

1. 推理能力弱的模型，会直接想当然地回答。
2. 推理能力强的模型，每次新会话会从头探索一遍。VibeCoding 里很常见——AI 会一直用关键词查代码，直到找到正确信息为止。

现在的 AI 已经足够智能，一般会先主动用关键词查本地文件，或者上网搜一下。对单个项目来说完全没问题，尤其本地项目里 Agent 会调用各种命令行工具检索，效果很好。

但随着项目增长，以及越来越多项目需要融合，关键词搜索会越来越慢，消耗的上下文也越来越多。有时还没开始执行，上下文就已经用完了。

Markdown 索引方案

一种做法是用索引文件——通常放在 AGENTS.md 或 index.md 里，告诉 AI 有哪些项目、各自做什么。我建项目时会写大量文档，然后把每篇文档的路径和描述放进 index.md。AI 获取信息时可以直接先看相关文档，快很多。

但这只是个人规模。扩展到企业级，可能有数十万、上百万文档，还有散落在各种 SaaS 和数据库里的数据。这种量级再用一个索引文件，已经不可行了。

于是 RAG（Retrieval-Augmented Generation）登场。

RAG 怎么工作

RAG 通常经历四个阶段：索引（Indexing）→ 检索（Retrieval）→ 增强（Augmentation）→ 生成（Generation）。每一步都旨在用相关、实时的上下文丰富模型输出。

• 索引 各种外部内容——文档、邮件、工单等——会被转换成向量，代表文本的语义含义，随后存入向量数据库。后续可以根据内容的实际含义快速、准确地检索，而不只是依赖关键词。
• 检索 用户提交问题时，系统将其与已索引的嵌入比对，找出最相关的文档。具体检索方式因数据类型和场景而异，但目标始终一致：为模型回答提供最高质量的内容支撑。
• 增强 检索到的内容会被加入原始查询，形成增强后的 prompt。一些 RAG 系统还会在此阶段做查询改写、结果排序，或结合用户历史改进上下文。最终得到一个更有依据、往往也更有方向的 prompt。
• 生成（Generation） 语言模型基于增强后的 prompt 生成回答。因为输入同时包含用户问题和支持性信息，输出通常更准确、更少幻觉，也更贴合需求。高级系统还可能做重排序或摘要，进一步优化结果。这种架构让 RAG 能生成反映当前信息的动态回答，而不是仅依赖训练时的静态知识。

RAG 的实际价值

RAG 已在多个行业与职能中落地，带来清晰收益：

• 搜索与问答： 员工可通过单一入口，从邮件、文档、工单、CRM 等工具中获取准确、个性化的答案。
• 客户支持： 客服（或机器人）可快速检索知识文章、历史案例或技术文档，更快解决问题。
• 销售赋能： 销售代表可实时获取产品规格、定价指引或案例研究，定制沟通、缩短周期。
• 内容生成： 市场、HR 等团队可基于最新材料，自动生成摘要、入职指南或政策概览。
• 分析与报告： RAG 让 AI 工具能分析并综合数据，输出有意义的摘要，帮助团队更快行动。

这只是开始。随着 RAG 架构演进，还会看到更多面向合规、财务、法务等领域的定制化应用。

RAG 还是 Markdown？看规模

个人或小项目，文档不多，一个 index.md 加 AI 自己检索就够了，不必上 RAG。

企业不一样。几十万、上百万文档，散在 SaaS 和数据库里，关键词搜不动——这时候首选 RAG。

所以不是「先 Markdown 再 RAG」，是分场景：

• 个人、小团队 → Markdown 索引
• 文档很多的企业 → RAG