何时打开:你想搭知识库 / 在 RAG vs Long Context vs NotebookLM 选不出来 / 用 RAG 但答得不准 / 听说 GraphRAG / LightRAG 不知道值不值得用 / 想理解为啥 Claude Code 不用 RAG。本 wiki 把 9 份 author wiki 在 RAG 主题上的视角融合。
一句话核心:RAG 不是"模型变强",是"提示词被自动加强"(老 D 反直觉判断);当前(2026)RAG 在 3 大方向被替代:Long Context 吃局部场景 / NotebookLM 吃个人场景 / Agentic Search 吃代码场景;仍然有价值的只剩 3 个场景:文档总量超 Long Context / 多 Tenant 隔离 / 实时索引。
0. 5 重视角的"RAG / 知识库"
| 视角 | 来源 | 核心定位 | 一句话立场 |
|---|---|---|---|
| 5 代架构演化派 | newtype 知识系统与 Life OS 全演化 / newtype · RAG 实战与知识库演化(黄益贺) | AnythingLLM 屠宰场 → Cursor+Obsidian → Claude Code AI OS → newtype OS → wiki.newtype.pro | "自己的东西 → Obsidian,别人的东西 → NotebookLM" |
| 反直觉教学派 | dontbesilent AI 自媒体课程 / 13 节系统化方法论 §L03(老 D) | "RAG 不是模型变强,是提示词被自动加强" | "ima知识库 / 元气 / Perplexity 底层都是 RAG" |
| LLM 面试技术派 | LLM 面试 / RAG 检索增强生成完整专题(16 份 PDF) | R/A/G 三模块 + PDF 解析 + 表格识别 + HYDE + 负难样本 + RAG-Fusion + GraphRAG | "RAG 6 大痛点 + 优化策略" |
| Agentic Search 派 | 王凯 Claude Code 终端工作流方法论(完整版) + Claude Code 最佳实践(Cal Rueb · Anthropic 内部讲座)(Cal Rueb) | 代码场景 Agentic Search 强过 RAG | "Cline 拒绝 RAG / Claude Code 自带 grep+glob 比 RAG MCP 强" |
| 数据准确性派 | 王凯 Agent 工程实操 §3(王凯) | 自建数据 MCP(FMP)代替 AI 联网搜索 | "投资决策的'数字'必须走 MCP,不走 RAG / 不走联网搜索" |
1. 跨作者共识(6 条)
1.1 RAG 三模块 R/A/G(行业共识)
| 模块 | 作用 |
|---|---|
| R - Retriever 检索 | 把外部知识源转化为向量,根据 query 检索相关文档 |
| A - Augment 增强 | 把检索结果与用户 query 拼接成新 prompt |
| G - Generator 生成 | 大模型基于增强 prompt 生成最终答案 |
6 步工作流:
1. 知识库构建:文档 → 切分 chunk → embedding → 向量库
2. 用户提问:Query → embedding
3. 检索:向量相似度搜索 Top-K chunk
4. 增强:Query + 检索 chunk → 新 Prompt
5. 生成:LLM 基于新 Prompt 生成答案
为什么需要 RAG(不用微调 / In-Context Learning):
- 微调成本高 / 灾难遗忘 / 训练时间长
- In-Context Learning 上下文长度受限
- RAG = 灵活 + 低成本 + 易更新
1.2 老 D 反直觉判断:RAG 不是模型变强(全作者印证)
dontbesilent AI 自媒体课程 / 13 节系统化方法论 §L03 最直接的科普:
最常见误解:"知识库让大模型变强了"。
真相:模型没变。RAG 只是改了你的提示词输入。
工作顺序(以ima知识库为例):
1. 用户输入提问("做生意第一步...")
2. RAG 用向量检索去文档库找相关资料(找出 27 篇)
3. 把 [27 篇资料 + 用户问题] 一起灌给大模型
4. 大模型基于 28 个信息源综合输出
为什么粗略提问也能拿到好答案:不是模型变聪明,是提示词被自动加强了。
知识库其实是被"伪装"的智能体:
- 创建ima知识库时其实内部有系统提示词(只是你看不到)
- 当问题超出知识库范围时,它主动拒答(说明有"如果文档没有就拒绝回答"的内置指令)
- Perplexity 也是同样架构 —— Perplexity = 知识库 + 互联网作为"知识源"
1.3 文档预处理是最重要的优化(老黄共识)
newtype · RAG 实战与知识库演化 §2.1:
- PDF → Markdown(用 Marker / MinerU / Markitdown / 微软 markitdown-mcp)
- PPT 不建议直接用(视觉逻辑模型理解不了)→ 把每页文字单独写下来
- Excel 慎用(结构化数据 RAG 处理弱)
- 每节自包含 + 明确边界(模糊文档 RAG 一定崩)
老黄 2024-03 帖 36:
"如果文档里的内容含混不清,那肯定会影响大模型的回答质量。我都是尽量把文档手动改成简单的形式,比如一个概念或问题对应一个答案。"
LLM 面试 / RAG 检索增强生成完整专题 PDF 解析 5 大难点:
- 多列布局(学术论文双栏)
- 嵌入图表(财报中的表格图)
- 字符编码异常(自定义字体不可逆)
- 扫描图 PDF(无文本层,需 OCR)
- 文档结构信息丢失(标题层级 / 段落归属)
1.4 模型推理能力是天花板(7B 在 RAG 场景很弱)
newtype · RAG 实战与知识库演化 §2.4 关键洞察(老黄 2025-05 帖 1076):
实测:
- 公网 Qwen Max:正确率高
- 本地 DeepSeek 70B / Qwen 2.5 70B:正确率不高
老黄解释:
"模型综合能力天壤之别。Qwen Max 的训练资源、推理资源远超本地运行的量化版本。它在指令遵循能力强得多。70B 的开源模型容易偏离给定上下文,或依赖内部知识而非检索到的信息。"
结论:7B-14B 本地模型在 RAG 场景很弱。先用 GPT-4 验证流程,再降到本地。
1.5 RAG 不擅长全局推理(老黄 + Cline 共识)
newtype · RAG 实战与知识库演化 §2.5:
"目前这些应用所使用的 RAG 技术,对于需要全局理解之类的问题,回答效果都不好。我个人使用的时候,只会把 QA、局部文字包含完整意思的文档(例如笔记)放到知识库里。"
RAG 致命弱点:
- 全局问题(比如"这篇文章主旨")→ RAG 只看片段,答不准
- 跨段落推理 → 检索可能漏关键片段
- 表格 / 图表 → RAG 处理弱
Cline 拒绝 RAG 的核心理由(newtype · AI Coding 实战与工具栈演化 §4):
"一个函数,定义在 200 行,调用在 300 行,相关依赖在 400 行。RAG 只能读取片段,打断了逻辑。"
1.6 数据库 + 模型解耦(老黄 Milvus + MCP)
newtype · RAG 实战与知识库演化 §5(2025-04 帖 1083 关键):
思路:
- 把文档存进 Milvus,本地向量化
- 通过 Milvus MCP,任意 AI 客户端(Cursor / Claude Desktop / ChatWise)都可以访问
Why 这个组合好:
"这比之前的方案都更灵活,因为把数据库和模型分开了。模型端可以随意更换,只要能调用 MCP 就可以接入。"
| 维度 | 传统 RAG 应用 | Milvus + MCP |
|---|---|---|
| 数据库 + 模型耦合 | 是 | 解耦 |
| 模型切换 | 应用支持哪些就哪些 | 任意 LLM 通过 MCP 接入 |
| 多客户端共享 | 不行 | OK |
| 升级模型代价 | 改应用 | 0 |
关联:OpenMemory MCP 也是同源思想(详见 MCP 协议生态(跨作者主题综合) §4.1)。
2. 显式分歧(3 条 —— 不抹平)
2.1 分歧 1:RAG vs Long Context vs NotebookLM 怎么选?
newtype · RAG 实战与知识库演化 §9 三种知识接入方式对比:
| 方式 | 容量 | 适合 |
|---|---|---|
| RAG | 任意大(分块存) | 局部精确检索,但全局弱 |
| Long Context(Gemini 1M+) | 1M tokens(一本书) | 全局推理强,但成本随长度涨 |
| NotebookLM | 50-300 文档 / 笔记本 | Source-Grounding 不胡说,平衡 |
老黄的选择(2026-01):
- 自己笔记 < 100MB → 直接 Obsidian + Copilot/MCP,够用
- 别人资料 / 论文 → NotebookLM(免费版 50 个文档,高级版 300)
- 真正大型 → Gemini Pro(1M Context)直接喂
RAG 在哪里仍然有价值(只剩 3 个场景):
- 文档总量超 Long Context 上限(几百万 token)
- 多 Tenant 隔离(每用户独立 RAG 库)
- 频繁更新的实时索引
真分歧:RAG 是不是会被完全替代:
- 老黄立场:个人场景已经被替代(Obsidian + NotebookLM 终态)
- LLM 面试派:技术细节(HYDE / 负难样本 / RAG-Fusion / GraphRAG)仍有学习价值
- 王凯立场:数据准确性场景完全跳过 RAG,直接走 MCP 接 API
2.2 分歧 2:GraphRAG 值不值得用?
newtype · RAG 实战与知识库演化 §3(2024-07 帖 358, 360 精华):
GraphRAG 优势:全局性问题处理强(比如"这本书主旨是什么")
致命缺点(2024-07):成本极高
- 单文档 + 单次问答 = $11(用 OpenAI API)
- 老黄试图接本地 Ollama,但嵌入环节总报错
| 视角 | 立场 |
|---|---|
| 老黄(2024-07 当时) | 企业级深度调研用 / 个人场景太贵 |
| 老黄(2026 终态) | 被 Source-Grounded NotebookLM 替代 |
| LLM 面试派 | 仍然需要学 —— 14 份专题里 GraphRAG 单独一份 |
判断:
- 个人场景 → 不用 GraphRAG,用 NotebookLM(免费 50 文档)
- 企业级深度调研 + 不在乎成本 → 可以做
- 学习目的 → 仍然要学概念
2.3 分歧 3:Agentic Search vs RAG(代码场景)
| 视角 | 立场 |
|---|---|
| Cal Rueb(Claude Code 最佳实践(Cal Rueb · Anthropic 内部讲座) §2) | Claude Code 不用 RAG,用 Agentic Search —— "RAG 是把书的目录扫描成向量,然后用相似度找页。但代码不是书,代码是图 —— 文件互相 import,函数互相调用。LLM 拿着 grep / glob 就像工程师拿着 find / ag" |
| 老黄(newtype · AI Coding 实战与工具栈演化 §4) | 4 种代码检索方式对比 —— Cline 实时搜索 / Claude Code Agentic Search / Cursor RAG / WindSurf 低延迟 RAG |
| Cursor(默认 RAG) | 经典 Embeddings + RAG,性价比高 + 受限于 Embedding 理解能力 |
真分歧:代码这种"强结构化文档" 该不该用 RAG:
- Anthropic 立场:不用 RAG,Agentic Search 准确性最高
- Cursor 立场:RAG 性价比好,接受信息片段损失
- 老黄综合:短笔记 / QA 形式 → RAG;代码 / 强结构化 → 实时搜索;跨片段推理 → Long Context
3. 老黄 5 代知识库架构演化(独家)
newtype 知识系统与 Life OS 全演化 —— 1085 帖 26 个月 5 代架构:
graph LR
A["2024-Q1<br/>AnythingLLM 屠宰场<br/>+ Obsidian 第二大脑"] --> B["2024-Q4<br/>Cursor + Obsidian<br/>知识库"]
B --> C["2025-H1<br/>Claude Code AI OS"]
C --> D["2026-Q1<br/>newtype OS<br/>多 Agent 编排"]
D --> E["2026 中<br/>wiki.newtype.pro<br/>第三层(发布层)"]
3.1 屠宰场 + 第二大脑(2024)
两套子系统:
- 外部信息处理 / 屠宰场:AnythingLLM + 大模型。日常看到的信息扔进去,让 LLM 这把"刀"做肢解,看清楚"全身构造"和"有价值部位"
- 笔记生成 / 第二大脑:Obsidian + 各种插件。手动把信息层层筛选,挑出最值得记的,用自己的话写下来
核心仪式:必须过自己脑子、亲手敲字。否则一定不会成为自己的东西。
3.2 PAFP → 漏斗目录(2024 → 2025)
- PAFP(Projects / Areas / Files / Personal)= 初期 Obsidian 目录结构
- 漏斗目录(2025-02 帖 857)= Input → Processing → Output
- Input:各种想细看的文章、论文(收集层)
- Processing:分领域的沉淀(消化层)
- Output:最终产出,所有视频脚本都存这(创造层)
Why:PAFP 适合静态收纳;漏斗适合流水线 —— 信息从 Input 流向 Processing 流向 Output,有清晰方向。
3.3 三层关联(老黄 / Karpathy LLM Wiki 共识)
- 文件夹 = 第一层关联
- 标签(tag) = 第二层关联,跨文件夹的逻辑
- 内部链接 / wikilinks = 第三层关联,知识图谱
马斯克的话:"记忆是生物生存的关键,所以大脑总是会遗忘,这是保护机制。如果想让大脑记住,必须建立相关性。"
Obsidian 三层关联 = 给大脑建立相关性 = 减少遗忘。这是为什么老黄一直选 Obsidian 而不是 Notion 的根本原因。
3.4 2026 终极结论(2026-01 帖 2201)
经过两年迭代,2026-01-03 老黄给出当前最稳定的结论:
个人知识库的终极解决方案:
- 自己的东西,放到 Obsidian 里
- 别人的东西,放到 NotebookLM 里
Why each:
- 自己的东西:必须 local-first,不能相信任何公司。Markdown 文档对 AI 极其友好,可用 Obsidian AI 插件或 Claude Code / OpenCode 高度定制化处理
- 别人的东西:不需要考虑隐私,追求性能。NotebookLM 是当下最强大的工具(多模态、播客生成、Source Grounding、Gemini 调用、移动端拍照上传)
4. LLM 面试技术派(独家完整专题)
LLM 面试 / RAG 检索增强生成完整专题 —— 16 份专题 PDF 全集:
| 专题 | 关键内容 |
|---|---|
| 11. langchain 面 | LangChain RAG 实战范本 |
| 12. 多轮对话 8 种记忆优化 | 短期 / 长期 / 摘要 / 实体 / 图谱 / 向量 / RAG / Hybrid |
| 13. langchain RAG 问答应用实战 | 百度百科"藜麦"数据 + 简单 RAG |
| 14. LLM + 向量库文档对话 | 框架级实现 |
| 15. 大模型 RAG 经验面 | 工程实践 |
| 16. PDF 解析 | 5 大难点 + 4 种方案 |
| 17. RAG 版面分析 - 表格识别 | 规则法 / CNN / Transformer / GPT-4V |
| 18. RAG 版面分析 - 文本分块 | 固定 / 语义 / 段落 / 层次 |
| 19. 大模型辅助召回(HYDE) | 假设性文档 |
| 20. 负样本挖掘 | 减少幻觉 |
| 21. RAG 评测 | RAGAS 框架 |
| 22. RAG 优化策略 | 全栈优化 |
| 23. RAG 关键痛点 | 6 大类 |
| 24. RAG-Fusion | RRF(Reciprocal Rank Fusion) |
| 25. Graph RAG | 知识图谱 + RAG |
4.1 RAG 6 大关键痛点
| 痛点 | 缓解策略 |
|---|---|
| 块边界丢失语义 | overlap chunk / 段落对齐 |
| 检索遗漏关键片段 | HYDE / RAG-Fusion / 多 query 改写 |
| 检索结果矛盾 | 模型推理整合 / Re-Rank |
| PDF 解析失败 | Marker / Donut / GPT-4V |
| 表格 / 图表 RAG 弱 | 单独抽取 + 表格识别 |
| 多轮对话记忆漂移 | 8 种记忆方案 |
4.2 8 种多轮对话记忆优化
- 会话内 short-term(默认)
- 滑动窗口(固定保留最近 N 轮)
- 摘要式(每 N 轮总结一次)
- 实体抽取式(只保留实体)
- 知识图谱式(关系图)
- 向量记忆(过往对话 embed 存)
- RAG 记忆(从 vector store 检索过往)
- Hybrid(组合上述)
5. 老 D 国内适配(独家)
dontbesilent AI 自媒体课程 / 13 节系统化方法论 §L03 + 配套:
5.1 国内 RAG 平台清单
| 工具 | 用途 | 注意 |
|---|---|---|
| ima知识库 | 国内 RAG 平台 | 内置 RAG + 个人 AI 分身 |
| 腾讯元气(yuanqi.tencent.com) | 国内智能体平台 | 免登录扫码用 / 模型可换 R1 |
| DeepSeek R1 | 驱动智能体 | 国内可用 / 国际第一梯队 |
5.2 实战:做个人 AI 分身
1. 收集你的内容:推文 + 直播文稿 + 微信群问答 + 付费资料 + 写过的书
2. 上传到ima知识库(腾讯)或元气
3. 设定系统提示词:"你是 X 的 AI 分身,基于他的内容回答..."
4. 问问题 → 比直接问大模型多 90% 个性 + 风格
老 D 自己的 AI 分身已有 1000+ 用户在用。
5.3 模型选择 ≠ 提示词不足的解药
"很多人问 GPT 写不好就想换 Claude / Gemini。但忽略了核心是提示词本身。改善提示词比换模型更重要。"
6. Karpathy LLM Wiki 思维(老黄独家)
newtype 知识系统与 Life OS 全演化 §10:
Karpathy 2024-10 给的"LLM Wiki" 概念:
"我可以把一些感兴趣的领域(物理、生物等)放到我有 SOTA 工具的应用里。我对它们提问,加入相关的笔记,让它们组织、可视化、链接,等等。"
老黄印证:这是 Obsidian + Cursor + Claude 组合自然演化的方向 —— 知识不再是"静态笔记",而是 "可对话、可结构化、可调用、可演化的活生 wiki"。
3 层关联实现:
- 文件夹 = 第一层(物理组织)
- 标签 = 第二层(逻辑组织)
- wikilinks
[[]]= 第三层(关系图)
用户已基于 Karpathy LLM Wiki 实现自己的 memory system(详见 ~/.claude/CLAUDE.md 的 memory 设计)。
7. RAG vs Agentic Search(代码场景的 4 种检索方式对比)
newtype · RAG 实战与知识库演化 §6 + newtype · AI Coding 实战与工具栈演化 §4:
| 工具 | 方式 | 优 / 缺 |
|---|---|---|
| Cline | 实时搜索(文件内容 + 正则) | 准 + 实时 / Token 高 |
| Claude Code | Agentic Search(动态决定内容/文件名/多轮) | 准确性最高 / Token 更高 |
| Cursor | 经典 Embeddings + RAG | 性价比高 / Embedding 理解力受限 |
| WindSurf | 同 Cursor 但低延迟 + 企业 | 企业级 / 初始索引慢 |
对个人 RAG 的启发:
- 处理代码类、强结构化文档 → 实时搜索可能比 RAG 好
- 处理短笔记、QA 形式 → RAG 适用
- 跨片段推理 → 优先 Long Context 模型(Gemini 1M+)
详见 Claude Code 工作流(跨作者主题综合) §1.2 Agentic Search vs RAG。
8. 反 pattern 总结
| ❌ | ✅ |
|---|---|
| RAG 完美主义(找最强 Embedding/最佳 chunk size) | 先跑通 GPT-4 + 默认配置,再降级优化 |
| 文档堆海(几千 PDF 直接入库) | 挑选 + 预处理 + 改 Markdown 形式 |
| 7B 模型期待 GPT-4 效果 | 模型推理力是天花板,先用 GPT-4 验证 |
| 用 GraphRAG 个人场景 | 太贵,Source-Grounded NotebookLM 替代 |
| 知识库塞所有信息 | 只塞 QA 形式 + 自包含 + 高质量 内容 |
| RAG 期待全局推理 | 全局问题用 Long Context 或 GraphRAG |
| 数据库 + 模型耦合 | Milvus + MCP 解耦,任意 LLM 接入 |
| 处理代码用 RAG | Cline 实时搜索 / Claude Code Agentic Search 更准 |
| 不用 citation 校验 | 必看引用对不对,RAG 错很难自检 |
| 把"装好 RAG 工具"当目标 | 知识库的本质是 知识本身,工具只是承载 |
| 期待 RAG 让"模型变强" | RAG 是"提示词被自动加强"(老 D) |
| 自己东西塞 NotebookLM | 自己东西用 Obsidian local-first |
| 别人资料堆 Obsidian | 别人资料用 NotebookLM(性能优先) |
9. 怎么选 —— 按身份的知识库路径
| 你是谁 | 主用方法 | 起点 |
|---|---|---|
| 个人小白 | 老黄 2026 终态 | 自己东西 → Obsidian / 别人东西 → NotebookLM |
| AI 工程师 / 想学技术细节 | LLM 面试 14 份专题 | R/A/G 三模块 + PDF 解析 + 表格识别 + HYDE + RAG-Fusion + GraphRAG |
| 国内不科学上网 | 老 D ima知识库 / 元气 / DeepSeek R1 | 上传内容 + 系统提示词 + 个人 AI 分身 |
| 想做多客户端共享知识库 | 老黄 Milvus + MCP | 数据库 + 模型解耦 / 任意 LLM 接入 |
| 代码场景 | Cal Rueb / 老黄 | Agentic Search 不用 RAG / 大代码库 Gemini 2.5 Pro 扫码 |
| 数据准确性 / 投资场景 | 王凯自建数据 MCP | 不走 RAG / 不走联网搜索 / 直接 FMP API → MCP |
| 企业级 + 不在乎成本 | GraphRAG / 企业 RAG 工具 | $11/问可以接受 |
| 学习 / 论文 / 书籍 | NotebookLM | Source-Grounding 不胡说 / 多模态 / 移动端拍照 |
通用起步顺序(任何身份):
- 判断知识源:自己的 vs 别人的
- 判断接入方式:RAG / Long Context / NotebookLM / Agentic Search
- 过文档预处理:PDF → Markdown / 每节自包含
- 用 GPT-4 / Claude / Gemini 旗舰模型验证(7B 本地模型 RAG 弱)
- chunk size 默认 1000 token + overlap
- 必看 citation(RAG 错很难自检)
- 稳定后 → 解耦数据库(Milvus + MCP)
- 进一步 → 知识结构化(Karpathy LLM Wiki 3 层关联)
10. 引用清单
主要原始 author wiki:
- newtype · RAG 实战与知识库演化 —— 老黄 RAG 演化完整 / 5 关键点 / GraphRAG / Cohere Command R+ / Milvus+MCP / 3 种知识接入对比
- newtype 知识系统与 Life OS 全演化 —— 1085 帖 / 5 代架构演化 / PAFP→漏斗 / 三层关联 / Karpathy LLM Wiki / 2026 终态
- newtype · MCP 协议与生态实战 —— Milvus / OpenMemory / NotebookLM MCP / context7
- newtype · AI 工具栈实战与演化 —— AnythingLLM / Open WebUI / RAGFlow / NotebookLM 工具评价
- newtype 杂项实战:llms.txt 协议 + CrewAI Obsidian 项目 + n8n MCP 工作流 —— CrewAI Obsidian 项目 / 3 Agent(Research+Edit+Notetake)
- LLM 面试 / RAG 检索增强生成完整专题 —— 16 份 RAG 专题 PDF / R/A/G / PDF 解析 / 表格 / 分块 / HYDE / 负难样本 / 6 大痛点 / GraphRAG / RAG-Fusion / 8 种记忆优化
- dontbesilent AI 自媒体课程 / 13 节系统化方法论 §L03 —— "RAG 不是模型变强,是提示词被加强" / ima知识库 / 元气 / Perplexity 同源 / 个人 AI 分身
- 王凯 Claude Code 终端工作流方法论(完整版) §1.2 —— Agentic Search vs RAG
- Claude Code 最佳实践(Cal Rueb · Anthropic 内部讲座) §2 —— Cal Rueb Agentic Search / grep+glob
相关主题 wiki(本系列):
- Claude Code 工作流(跨作者主题综合) —— Claude Code 工作流(Batch 1)
- MCP 协议生态(跨作者主题综合) —— MCP 协议生态(本批 Batch 3)
- Prompt / Context Engineering(跨作者主题综合) —— Prompt / Context Engineering(本批 Batch 3)
History
- 2026-05-18:Topic-dimension wiki 首发。从 9 份 author wiki 综合改写。显式标注 3 条分歧:RAG vs Long Context vs NotebookLM / GraphRAG 经济性 / Agentic Search vs RAG(代码场景)
来源与关联资料
- newtype · RAG 实战与知识库演化
- newtype 知识系统与 Life OS 全演化
- newtype · MCP 协议与生态实战
- newtype · AI 工具栈实战与演化
- newtype 杂项实战:llms.txt 协议 + CrewAI Obsidian 项目 + n8n MCP 工作流
- LLM 面试 / RAG 检索增强生成完整专题
- dontbesilent AI 自媒体课程 / 13 节系统化方法论
- 王凯 Claude Code 终端工作流方法论(完整版)
- Claude Code 最佳实践(Cal Rueb · Anthropic 内部讲座)
- Claude Code 工作流(跨作者主题综合)
- MCP 协议生态(跨作者主题综合)
- Prompt / Context Engineering(跨作者主题综合)