用Obsidian搭建LLM个人知识库：从零构建双链笔记与学习地图

1. 先说说我为什么折腾这个 llm_wiki

大概从大模型真正火起来开始，我的浏览器收藏夹就彻底失控了。今天存一篇《什么是Transformer》，明天收藏一个LangChain教程，后天又是一个Agent实战回放链接。结果真要找资料的时候，面对一堆标题各异的网页和PDF，完全不知道从哪下手。更尴尬的是，很多知识当时看过觉得懂了，一个月后再面对"RLHF和DPO到底有什么区别"这种基础问题，脑子里只剩一团浆糊。

后来我意识到，问题不在于我看得不够多，而在于我缺少一个能承载这些知识、并且能让知识之间产生连接的地方。普通笔记软件只是把笔记堆在一起，博客又偏向输出，都不适合做这种高频、碎片化、持续更新的知识积累。于是我做了一个叫 llm_wiki 的东西——用 wiki 的方式来管理大模型相关的一切：原理、论文、框架、项目、课程、回放、踩坑记录，全部拆成一条条互相链接的知识卡片，像一个不断生长的知识库。

这个项目做得越久，我越觉得它不只是一个笔记库。对刚开始学大模型的同学，它是一条清晰的学习地图；对做Agent、RAG应用的开发者，它是一个可以随时查的概念速查和方案对比库；对想在团队内沉淀知识的人来说，它又是一套可以直接复制的协作模板。这篇文章就把我从零搭建 llm_wiki 的完整思路、目录设计、实操流程和维护经验分享出来，希望你能少走点弯路。

2. 整体设计：为什么wiki模式和LLM知识管理是绝配

2.1 零散笔记和 wiki 模式到底差在哪

我最早也用过普通文件夹分类的方式，比如建一个"大模型学习"文件夹，里面再放"论文"、"教程"、"代码"三个子文件夹。但用了一段时间就发现一个问题：一条知识往往属于多个主题。比如一篇讲LoRA微调的文章，既属于"模型微调"，又属于"参数高效方法"，还可能跟我做的某个项目直接相关。在文件夹体系里，你只能把它放在一个地方，放到哪都觉得不对。

wiki 模式天然是网状而不是树状的。它不强调把笔记放到"正确"的文件夹，而是允许你用双链把任意两条笔记关联起来。一篇笔记可以同时被"高效微调"、"QLoRA"、"低资源训练"等多个主题引用。这种结构和LLM知识本身的特点非常吻合——大模型领域的概念彼此交织，不可能用一棵树完全装下。

为了让你更直观地感受差异，我整理了一个对比表：

所以我在设计 llm_wiki 时，第一步就明确了一个原则：文件夹只负责最粗粒度的分区，真正的组织靠双链和MOC（Map of Content，内容地图）来完成。文件夹不是知识地图，而是知识库的"楼层索引"。

2.2 这个知识库到底给谁用

很多知识库项目做着做着就变成自嗨，根本原因是没想清楚使用者。我给 llm_wiki 定义了三种典型角色：

第一类是刚接触大模型的小白。他们需要的是"学习路线"而不是一堆随机资料。llm_wiki 里的 MOC 页面就承担这个功能，比如"LLM学习路线图"这个页面，会按阶段把基础理论、模型技术、工程框架、应用实践串成一条链路。新手进来不用问别人"先学什么"，跟着路线走就行。

第二类是已经在做实际项目的人。他们更多是来查"某个概念怎么理解"、"某个工具该不该用"。比如你想知道 Dify 里的 LLM 为什么那样配置，直接在知识库里搜"Dify"，会看到框架介绍、典型坑点、还有关联的项目笔记。这比重新刷一遍文档高效得多。

第三类是团队。如果大家共同维护一个共享的 llm_wiki，项目资料、会议回放、方案评审记录都可以沉淀成标准化条目，新人入职培训直接看知识库就能了解团队技术脉络。

2.3 工具选型：为什么我选了 Obsidian

llm_wiki 的知识载体可以是现成的 Wiki.js，也可以是 Notion，但我最终选了 Obsidian，而且现在仍然认为这个选择是对的。原因可以拆成四点：

本地优先存储。Obsidian 的笔记就是一个个 Markdown 文件，存在本地磁盘里，不锁定在某个云服务上。我所有资料可以随时用 Git 管理，也能用其他工具打开，完全不受平台绑架。这一点对长期知识库来说太重要了——我用过一个云笔记产品，后来团队调整，导出数据花了两天，教训深刻。

双向链接成熟。Obsidian 的双链虽然不是首创，但体验确实做得最好。输入两个方括号就能建立链接，反链面板会自动显示所有引用当前笔记的地方。这种"反向链接"能力是 wiki 模式能跑起来的关键。

插件生态丰富。Dataview 可以把笔记变成数据库查询，Templater 可以批量生成模板，Obsidian Git 能自动提交备份。这些插件几乎覆盖了我后面要讲的所有知识管理流程。

成本低且社区活跃。个人使用完全免费，遇到问题随便一搜就有解决方案。GitHub 上还有很多公开的 Obsidian 知识库可以借鉴结构。

当然，如果你想做的是一个多人在线、带权限管理的团队百科，那 Wiki.js 或飞书文档可能更合适。但如果是"个人学习+轻量分享"的场景，Obsidian 这种本地优先的方案更稳。

3. LLM知识版图：把wiki目录搭成一张学习地图

3.1 顶层目录结构怎么定

llm_wiki 的目录结构我调整过好几轮，最终固定成下面这样。前面用数字编号，是为了保证文件管理器里的排序固定，不随创建时间乱跑。

llm_wiki/ ├── 00-Inbox/ # 临时收件箱，所有未处理材料先进这里 ├── 10-基础理论/ # 数学基础、机器学习基础、深度学习基础 │ ├── Transformer.md │ ├── Tokenization.md │ ├── 注意力机制.md │ ├── 预训练与损失函数.md │ └── 经典论文解读/ ├── 20-模型技术/ # 预训练、微调、对齐、推理优化 │ ├── 高效微调/ │ ├── RLHF与DPO.md │ ├── 量化压缩.md │ └── 推理加速.md ├── 30-工程框架/ # LangChain、LlamaIndex、Dify等 │ ├── LangChain/ │ ├── Dify.md │ ├── vLLM.md │ └── Ollama.md ├── 40-应用实践/ # RAG、Agent、多模态、行业应用 │ ├── RAG/ │ ├── Agent/ │ └── 意图识别方案对比.md ├── 50-学习资源/ # 课程、论文清单、回放汇总、开源项目 │ ├── 课程与书籍.md │ ├── 论文清单.md │ ├── 会议回放汇总.md │ └── 开源项目榜.md ├── 60-项目记录/ # 个人做过的实验、参与的项目 │ └── 知识库问答机器人/ ├── 99-MOC/ # 内容地图，知识库的入口 │ ├── LLM学习路线图.md │ ├── 概念索引.md │ └── 待深入问题清单.md └── README.md # 整个库的说明和规则

你可能注意到，文件夹只到十大类，每类下面不强制建子文件夹。比如"Agent"目录里可以直接放一堆 Markdown 文件，因为 Agent 相关概念之间有很多交叉引用，强行建多层子目录反而限制链接的灵活性。

3.2 每一块到底放什么内容

这里我把每个目录的内容边界说清楚，方便你参考的时候不会什么都往一个地方塞。

10-基础理论 只放"和模型本身强相关"的内容。Transformer 的结构拆解、Embedding 怎么工作、预训练任务中的掩码语言模型和下一个词预测有什么区别、损失函数为什么用的是交叉熵，这些都属于基础理论。我遇到过很多人一上来就学 LangChain，结果问"什么是自注意力"都答不上来，后面看论文会特别吃力。

20-模型技术 偏向"训练和部署过程中要用的技术"。比如大家常说的微调，我会把全量微调、LoRA、QLoRA、P-Tuning 这些方法放在一起；RLHF 和 DPO 可以单独建笔记，因为它们涉及的概念太多，适合成体系维护。量化、蒸馏、推理加速这类部署优化也放在这里。

30-工程框架 记录的是工具型知识。LangChain、LlamaIndex、Dify、vLLM、Ollama 这些框架的安装方式、核心概念、版本差异和踩坑记录都在这一块。每次我在Dify里配置模型的时候，就会把当时的参数截图和设置逻辑写进对应的Dify笔记里，下次再配就照着抄。

40-应用实践 是"我用这些技术做了什么"。RAG 的文档检索流程、Agent 的工具调用逻辑、意图识别场景下 TextCNN、BERT 和 LLM 方案的差距对比，都归到这里。这类笔记的典型特征是"带着场景"，不会只讲干巴巴的理论。

50-学习资源 是一个索引层，不直接存资料。课程链接、论文清单、会议回放汇总、开源项目榜单都放这里。你可能会问：为什么不直接攒一个收藏夹？因为单纯的链接列表没有上下文。我会给每个资源配一段"为什么值得看"和"适合谁看"的说明，这样未来回来翻的时候，不用重新点开才知道讲什么。

60-项目记录 记录我的实际操作过程。比如我做过一个"知识库问答机器人"，里面包括需求文档、技术选型、遇到的问题、优化过程。以后再做类似项目，直接调取之前的记录做复盘。

99-MOC 是整个知识库的入口。我建议把顶部导航和日常使用频率最高的链接全部聚合在这一块，它的作用就像图书馆的目录卡片。

3.3 MOC：让首页成为智能导航

纯靠文件夹找笔记依然不够快，所以 llm_wiki 里专门设了一个 MOC 概念。MOC 本质上也是一个 Markdown 文件，但它的作用不是"存储内容"，而是"聚合链接"。

比如我在"概念索引.md"里会这样写：

# 概念索引 ## 模型架构 - [[Transformer]] - [[注意力机制]] - [[MoE]] - [[RWKV]] ## 训练技术 - [[预训练与损失函数]] - [[微调]] - [[RLHF与DPO]] - [[LoRA]] ## 推理优化 - [[量化压缩]] - [[vLLM]] - [[KV Cache]]

这个文件看起来简单，但配合 Obsidian 的反链面板，效果很强大。你在任何一篇笔记里写上[[概念索引]]，它就会自动出现在概念索引的反链中。所有人都可以沿着这张网从一个知识点跳到另一个知识点，而不是被迫按照目录线性阅读。

如果你想让首页更"智能"，可以用 Dataview 插件。比如我想在首页展示"最近一周更新过的所有笔记"，就写这样一段查询：

TABLE file.mtime as 更新时间 FROM "" WHERE file.mtime >= date(today) - dur(7 days) SORT file.mtime DESC LIMIT 20

这样每次打开知识库，最新动态一目了然，不需要手动维护更新列表。

4. 实操：从零到一搭建 llm_wiki 的完整流程

4.1 初始化库和目录

第一步很简单，先创建项目文件夹和基础的目录骨架。我习惯用 Git 管理，所以会先初始化仓库：

mkdir llm_wiki cd llm_wiki git init mkdir -p 00-Inbox 10-基础理论 20-模型技术 30-工程框架 40-应用实践 50-学习资源 60-项目记录 99-MOC touch README.md

然后用 Obsidian 打开这个文件夹，选择"作为仓库打开"即可。这里有个小建议：在 Obsidian 设置里把"新建笔记的存放位置"指定为00-Inbox，这样无论从移动端还是桌面端快捷创建，新笔记都会先进收件箱，不会散落到其他目录。

4.2 做一套统一的笔记模板

没有模板的 wiki 会变成垃圾堆。每个人写笔记的习惯不同，有的写几百字，有的就丢三行链接，最后很难统一。我在 llm_wiki 里定义了两种核心模板：概念笔记和资源笔记。

概念笔记模板：

--- title: 笔记标题 type: concept tags: - 待分类 status: 待完善 created: 2025-01-01 updated: 2025-01-01 source: 原始链接或出处 aliases: - 别名1 - 别名2 ---

# 概念名称 ## 一句话定义 （用一两句话说明这个概念是什么） ## 核心原理 （用自己的话解释，配图更好） ## 为什么重要 （解决什么问题，在LLM生态里的位置） ## 关联概念 - [[相关笔记1]] - [[相关笔记2]] ## 参考来源 - 链接或论文

资源笔记模板：

--- title: 资源标题 type: resource tags: - 教程 - 回放 status: 已看 created: 2025-01-01 source: 原始链接 ---

# 资源标题 ## 资源信息 - 作者/讲者： - 时间： - 链接： ## 核心内容 （资源讲了什么，分点列出） ## 我的收获 （对个人来说最有价值的信息） ## 关联笔记 - [[相关概念]]

你会发现模板里都有 YAML front matter，虽然不是必须，但配合 Dataview 做筛选、配合模板做批处理都方便。比如我可以迅速列出所有"status: 待完善"的笔记，把存量内容变成可管理的任务清单。

4.3 用一篇示例笔记演示完整写法

空说理论不如直接看一篇实际笔记。下面这篇是我早期写的"什么是大语言模型"的缩写版，展示了完整结构应该长什么样。

--- title: 大语言模型（LLM） type: concept tags: - 基础概念 status: 基本完善 created: 2025-01-10 updated: 2025-01-15 aliases: - LLM - 大模型 --- # 大语言模型（LLM） ## 一句话定义 大语言模型是基于海量文本数据预训练、以自回归方式生成文本的深度学习模型，核心能力是对自然语言进行概率建模。 ## 核心原理 - 以 Transformer 为基础架构，通过自注意力机制捕捉长距离依赖。 - 预训练阶段使用大规模语料，优化目标通常是下一个词预测或掩码语言模型。 - 通过微调和人类反馈对齐，让模型更符合使用者的意图。 ## 为什么重要 LLM 改变了自然语言处理的应用方式，从以前按任务训练专用模型，转向"预训练+微调+提示"的通用范式。 ## 关联概念 - [[Transformer]] - [[预训练与损失函数]] - [[RLHF与DPO]] - [[上下文学习]] ## 参考来源 - 某公开课笔记 - 某综述论文

可以看到，我没有把整篇笔记写成教科书，而是尽量控制在"能讲清楚、能链接出去"的粒度。更详细的推导过程可以单独建一篇子笔记。wiki 的价值不在于单篇长，而在于每一篇都能成为后续检索和链接的节点。

4.4 双链和标签怎么用才不乱

很多人在 Obsidian 里用双链用得很随意，什么都敢加链接，结果反链面板一堆无关引用。我在 llm_wiki 里给自己定了三条规则：

第一，双链只连"概念级"的内容。比如提到微调，就链接到[[微调]]这个专有笔记；但如果只是顺便提到一个工具名，并不打算为它单独写一篇笔记，就不要硬建链接。当然你也可以用未创建的链接——Obsidian 支持链接到不存在的笔记，点击即可创建，这其实是一个很自然的"待办提示"。

第二，标签用来标记状态和类型，不用来做主题分类。比如#已读/未读、#要做、#疑难。主题分类应该靠 MOC 和文件夹，而不是靠标签。因为标签是扁平的，数量一多就乱；MOC 是网状的，可以表达层级关系。

第三，一篇笔记的别名尽量统一。LLM、大模型、大语言模型三个词在笔记里会交替出现，如果不设置 aliases，搜索"大模型"时可能搜不到[[LLM]]这篇笔记。所以我在 YAML 里设置好别名，搜索时就能自动命中。

建议定期检查"孤立笔记"——没有任何链接指向、也没有链出去的笔记。孤立笔记往往是被遗忘的内容，要么补充链接，要么删掉。Obsidian 自带的图谱视图可以直观看到那些孤立的小点。

4.5 必装的 Obsidian 插件清单

我会把插件控制在一个合理范围，装太多反而拖慢启动速度。目前用得最顺手的是这几个：

插件不是越多越好。我给 llm_wiki 定的原则是：插件解决"流程"问题，而不是"内容"问题。如果你发现自己花大量时间配置插件，而不去写笔记，那就该做减法了。

5. 内容生产流水线：让资料自动流进 wiki

5.1 收集：所有东西先丢进 Inbox

很多人的笔记系统最后崩掉，是因为在做收集的时候就开始整理。看文章看到一半，停下来思考应该放哪个文件夹、建什么标签，这种打断感会让人丧失做笔记的欲望。

我的做法是：任何值得留的资料，先用最快的方式丢进 Inbox。浏览器端用剪藏插件一键保存正文；手机上用 Obsidian 的快捷指令直接创建新笔记；看到会议回放链接，先粘贴到一个临时文档里，连标题都不改。整个过程十秒以内完成，完全不思考分类问题。

收集阶段唯一要做的判断是"值不值得留"。标准就一条：这条信息未来有没有可能被我再次引用。如果只是随手一刷的新闻，直接关掉，不要进 Inbox，否则 Inbox 很快就堆满垃圾。

5.2 提炼：用卡片笔记法写自己的话

Inbox 里的原始材料必须被加工，否则它永远只是剪藏。我加工资料时用的思路类似卡片笔记法：

第一步，读完后写一个"核心内容"小节，用三四句话复述原文讲了什么。这一步强制你完成理解，而不是复制粘贴。

第二步，写"我的理解"。这里要回答三个问题：这个概念和我已知的知识有什么联系？它可以用在什么场景？有什么局限或反直觉的地方？不需要长篇大论，几句都行，但一定要用自己的话。

第三步，把原文里的术语和概念找出两到三个，作为双链连接到已有笔记。比如你在某篇关于 Agent 的文章里看到"ReAct"这个词，顺手就链接到已有的[[ReAct]]笔记，如果还没有这篇笔记，就新建一个空壳，等后续补充。

为什么这么强调"自己的话"？因为你直接粘贴原文，搜索引擎也能做到，你的知识库就沦为二手内容仓库。只有经过自己转述和加工，信息才真正变成你的知识。

5.3 整理：每周固定清空 Inbox

Inbox 如果不定期清空，就变成垃圾场。我给自己定了每周一次的"清收件箱"时间，半小时到一小时。

流程很固定：在 Dataview 里列出00-Inbox下所有文件，逐个处理。每篇笔记做三件事：确定它最终应该归属哪个主题目录，移动文件；补充 YAML front matter 和模板字段；把其中的关键概念链接到知识库已有的笔记中。

如果一篇笔记看完后觉得不值得保留，就直接删掉，不要有"留着以后再看"的念头。以后再看通常意味着永远不看。如果一篇笔记信息量很大，但暂时没时间细读，我会把它标记为#待深入并保留在 Inbox，但同一时间这类笔记不允许超过十篇。这是一个强制控制遗忘负载的小技巧。

整体流线可以用一句话概括：收集不整理，整理不收集。把两个动作在时间上分开，精力损耗会小很多。

5.4 实战：把一个会议回放沉淀成一条 wiki 记录

举一个真实的例子。有一次我参加了一个线上分享，主题是"LLM Agent 的工程化落地"，有一个回放链接。这个分享价值很高，但我肯定没时间在活动结束当天整理。

我当天的操作是：在 Inbox 里新建一条笔记，粘贴回放链接，标题写成"分享回放：LLM Agent 工程化落地 2025-xx-xx"。然后就关掉，不再管了。

到了周末清 Inbox 的时候，我打开回放，倍速看一遍，同时在草稿里记录关键点。看完后，我把它加工成一条资源笔记：

• 资源信息：讲者、时间、链接。
• 核心内容：Agent 框架选型、任务拆解策略、工具调用中的容错设计、评测方法。
• 我的收获：原来我们的 Agent 项目缺了"计划重试机制"，这解释了之前为什么老失败。
• 关联笔记：链接到已有的[[Agent]]、[[工具调用]]、[[评测]]。

最后，我把这条笔记的链接追加到50-学习资源/会议回放汇总.md中，这样以后想看回放汇总，只需打开那一个文件。整个流程下来，一条外部的、临时的信息，变成了知识库里一个有上下文、有可链接性的永久资产。

6. 维护过程中踩过的坑

6.1 Obsidian 库变大后开始卡顿

llm_wiki 用了半年后，明显感觉启动变慢，输入时也有轻微掉帧。查了一圈发现原因有三个：一是00-Inbox堆了几百个文件，Obsidian 每次要索引整个库；二是插件装了十几个，每个都在后台跑；三是我往库里塞了大量截图，图片拖慢了文件扫描。

解决办法并不复杂：定期清空 Inbox；把不常用的插件禁用，只留 Dataview 和 Templater 这种核心插件；图片统一放到attachments文件夹并开启"附件自动存放"功能，这样就不会和 Markdown 文件混在一起。如果库实在太大，可以在设置里排除node_modules这类无关目录，减少扫描范围。

6.2 外链失效与资料漂移

这是知识库维护中最烦的问题。我刚建库时存了一堆网页链接，半年后回头点开，三分之一已经 404。外链本质上是不可控的，特别是那些个人博客、临时分享链接。

后来我给资源笔记定了一个要求：重要信息必须离线保存。比如一篇很有价值的 PDF 论文，我会下载到知识库的50-学习资源/论文目录；一个关键的博客文章，我用剪藏把正文存为 Markdown。在线链接只作为补充，不是唯一载体。这一步会稍微增加工作量，但换来的知识库稳定性非常高。

6.3 知识库成了"死库"，只看不回顾

我建知识库的第二个月就遇到了低谷：笔记越写越多，真正回看和使用的很少。原因为当时只关心"收集"，不关心"消化"。

后来我加了两个机制：第一，用首页 Dataview 展示"最近更新"和"随机笔记"；第二，安装了 Spaced Repetition 插件，把重要知识点做成问答卡片，每隔几天提醒复习一次。更大的转变是，我把一些整理好的 wiki 内容转化为博客文章发布出去。一旦你要给别人讲清楚，就会倒逼自己重新审视和修正笔记，这个过程比任何"收藏"都有用。知识库的价值不在你存了多少，而在于你调用了多少。

6.4 多人协作时怎么避免冲突

如果你打算和团队成员共用一个 llm_wiki，直接用同步盘是非常痛苦的事情。两个人同时改一个 Markdown 文件，就可能出现冲突副本。

我建议用 Git 工作流：主分支保持稳定，每个成员在自己的分支上修改，定期合并。Obsidian Git 插件可以自动完成提交和推送，基本不需要手动敲命令。具体分工可以是"每人维护自己负责的目录"——比如小张管模型技术，小李管应用实践，这样冲突概率很低。即使出现冲突，Markdown 文件的冲突标记也比较容易手动解决。

6.5 常见问题速查表

为了方便你对照排查，我把常见问题整理成一张表：

7. 把 llm_wiki 从本地变成在线维基

7.1 几个可选方案对比

本地知识库做得再好，如果只有自己能看，还是有点可惜。把 Obsidian 仓库发布成在线维基是很自然的需求。我在调研和试过几个方案：

如果你的目标只是"给朋友分享一下我的学习笔记"，Obsidian Publish 最省事；如果你希望站点长期维护、还想要不错的搜索引擎表现，Quartz 是我比较推荐的选择。

7.2 使用 Quartz 发布的快速流程

Quartz 是一个专门把 Obsidian 仓库转换成静态网站的工具，基于 Hugo。发布的核心步骤大致是这样：

# 前提：已安装 Node.js 和 Git git clone https://github.com/jackyzha0/quartz.git cd quartz npm i npx quartz create

创建过程中会要求指定内容目录，指向你的 Obsidian Vault 路径即可。然后：

npx quartz build npx quartz sync

sync命令会把生成的静态站点推送到你关联的 GitHub 仓库，配合 GitHub Pages 就能得到一个在线 wiki。注意，Quartz 默认会渲染整个 Vault，所以发布前一定要在配置里排除隐私目录，比如60-项目记录里那些包含内网信息的记录。

7.3 发布前要做的安全与内容检查

我第一次发布时就差点把一些内部链接暴露出去，后来养成了一个发布前检查习惯：

• 全局搜索关键词，比如"内网"、"密码"、"公司"等，确认没有敏感信息。
• 检查40-应用实践和60-项目记录里有没有包含真实业务数据或未公开的评测结论。
• 在 config 里设置需要排除的路径，例如ignorePatterns: ["60-项目记录/**", "attachments/**"]。
• 发布后手动打开几个页面，确认编码正常、图片能显示、双链跳转没有 404。

在线维基一旦公开，就是你的技术名片，所以内容质量要格外用心。这也是一个很好的正向反馈——为了让外人看得懂，你会把原本私密、潦草的知识打磨得更准确更有条理。

这个大半年维护下来，我最深的一点体会是：llm_wiki 真正改变我的，不是我现在能随时查资料，而是它逼着我从"收藏过"变成了"能讲清楚"。每次把一条新知识挂进知识库的网里，我都会经历一次"原以为自己懂了，写的时候才发现不懂"的过程。这种不舒服，恰恰是成长最快的时刻。

最后给你一个我踩过很多次坑后总结出来的建议：不要等知识库"设计完美"了才开始填内容。先搭一个最简目录，然后立刻写第一篇词条，后面再慢慢调整结构。知识库是长出来的，不是设计出来的。哪怕一开始只有十篇笔记，只要你持续往里加、持续建立链接，三个月后它就会成为你在大模型领域最有价值的私人参考资料。