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知识本身的特点非常吻合——大模型领域的概念彼此交织不可能用一棵树完全装下。为了让你更直观地感受差异我整理了一个对比表维度普通笔记博客wiki 式知识库组织方式按文件夹归类按时间线或主题分类按概念和关系双链互联更新方式写完基本不动发布后较少更新持续迭代随学随改交叉引用靠手动搜索链接有限任意笔记可互相引用生命周期短应付当下中多为一次性输出长知识不断沉淀进化目标记录分享建立个人/团队知识资产所以我在设计 llm_wiki 时第一步就明确了一个原则文件夹只负责最粗粒度的分区真正的组织靠双链和MOCMap of Content内容地图来完成。文件夹不是知识地图而是知识库的楼层索引。2.2 这个知识库到底给谁用很多知识库项目做着做着就变成自嗨根本原因是没想清楚使用者。我给 llm_wiki 定义了三种典型角色第一类是刚接触大模型的小白。他们需要的是学习路线而不是一堆随机资料。llm_wiki 里的 MOC 页面就承担这个功能比如LLM学习路线图这个页面会按阶段把基础理论、模型技术、工程框架、应用实践串成一条链路。新手进来不用问别人先学什么跟着路线走就行。第二类是已经在做实际项目的人。他们更多是来查某个概念怎么理解、某个工具该不该用。比如你想知道 Dify 里的 LLM 为什么那样配置直接在知识库里搜Dify会看到框架介绍、典型坑点、还有关联的项目笔记。这比重新刷一遍文档高效得多。第三类是团队。如果大家共同维护一个共享的 llm_wiki项目资料、会议回放、方案评审记录都可以沉淀成标准化条目新人入职培训直接看知识库就能了解团队技术脉络。2.3 工具选型为什么我选了 Obsidianllm_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 插件清单我会把插件控制在一个合理范围装太多反而拖慢启动速度。目前用得最顺手的是这几个插件作用使用建议Dataview把笔记当数据库查询生成动态列表适合做首页导航、待办清单、笔记统计Templater根据模板快速生成笔记可以绑定快捷键按一下自动带入 front matterQuickAdd快速捕获灵感发送到指定文件夹搭配 Inbox 使用最佳Excalidraw画架构图和概念图适合画模型结构、流程图Obsidian Git自动提交和推送仓库本地备份和远程同步双保险Spaced Repetition间隔重复复习配合卡片笔记做定期回顾Auto Link Title粘贴 URL 时自动抓取标题收集资料时省时间插件不是越多越好。我给 llm_wiki 定的原则是插件解决流程问题而不是内容问题。如果你发现自己花大量时间配置插件而不去写笔记那就该做减法了。5. 内容生产流水线让资料自动流进 wiki5.1 收集所有东西先丢进 Inbox很多人的笔记系统最后崩掉是因为在做收集的时候就开始整理。看文章看到一半停下来思考应该放哪个文件夹、建什么标签这种打断感会让人丧失做笔记的欲望。我的做法是任何值得留的资料先用最快的方式丢进 Inbox。浏览器端用剪藏插件一键保存正文手机上用 Obsidian 的快捷指令直接创建新笔记看到会议回放链接先粘贴到一个临时文档里连标题都不改。整个过程十秒以内完成完全不思考分类问题。收集阶段唯一要做的判断是值不值得留。标准就一条这条信息未来有没有可能被我再次引用。如果只是随手一刷的新闻直接关掉不要进 Inbox否则 Inbox 很快就堆满垃圾。5.2 提炼用卡片笔记法写自己的话Inbox 里的原始材料必须被加工否则它永远只是剪藏。我加工资料时用的思路类似卡片笔记法第一步读完后写一个核心内容小节用三四句话复述原文讲了什么。这一步强制你完成理解而不是复制粘贴。第二步写我的理解。这里要回答三个问题这个概念和我已知的知识有什么联系它可以用在什么场景有什么局限或反直觉的地方不需要长篇大论几句都行但一定要用自己的话。第三步把原文里的术语和概念找出两到三个作为双链连接到已有笔记。比如你在某篇关于 Agent 的文章里看到ReAct这个词顺手就链接到已有的[[ReAct]]笔记如果还没有这篇笔记就新建一个空壳等后续补充。为什么这么强调自己的话因为你直接粘贴原文搜索引擎也能做到你的知识库就沦为二手内容仓库。只有经过自己转述和加工信息才真正变成你的知识。5.3 整理每周固定清空 InboxInbox 如果不定期清空就变成垃圾场。我给自己定了每周一次的清收件箱时间半小时到一小时。流程很固定在 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 常见问题速查表为了方便你对照排查我把常见问题整理成一张表问题原因解决方法启动越来越慢Inbox 文件过多、插件太多、图片体积大清 Inbox、精简插件、图片放统一附件目录经常找不到旧笔记命名不统一、没有别名设置标题规范用 aliases 收录别称链接失效外链网站关闭或迁移关键内容离线保存外链仅作补充Wiki 成为死库只收集不回顾笔记之间无链接设置定期回顾把笔记转化为输出多人同步冲突同时编辑同一文件用 Git 分支管理按目录分工文件结构混乱没有分类原则乱建文件夹回归顶层十大目录用 MOC 组织内容7. 把 llm_wiki 从本地变成在线维基7.1 几个可选方案对比本地知识库做得再好如果只有自己能看还是有点可惜。把 Obsidian 仓库发布成在线维基是很自然的需求。我在调研和试过几个方案方案成本技术门槛自定义程度适合场景Obsidian Publish付费订阅极低一般个人轻量发布Quartz GitHub Pages免费中高个人或小团队想完全控制样式Docusaurus GitHub Pages免费中高高技术团队做文档站Wiki.js 自建免费但需服务器中高高团队知识百科需要权限管理如果你的目标只是给朋友分享一下我的学习笔记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 syncsync命令会把生成的静态站点推送到你关联的 GitHub 仓库配合 GitHub Pages 就能得到一个在线 wiki。注意Quartz 默认会渲染整个 Vault所以发布前一定要在配置里排除隐私目录比如60-项目记录里那些包含内网信息的记录。7.3 发布前要做的安全与内容检查我第一次发布时就差点把一些内部链接暴露出去后来养成了一个发布前检查习惯全局搜索关键词比如内网、密码、公司等确认没有敏感信息。检查40-应用实践和60-项目记录里有没有包含真实业务数据或未公开的评测结论。在 config 里设置需要排除的路径例如ignorePatterns: [60-项目记录/**, attachments/**]。发布后手动打开几个页面确认编码正常、图片能显示、双链跳转没有 404。在线维基一旦公开就是你的技术名片所以内容质量要格外用心。这也是一个很好的正向反馈——为了让外人看得懂你会把原本私密、潦草的知识打磨得更准确更有条理。这个大半年维护下来我最深的一点体会是llm_wiki 真正改变我的不是我现在能随时查资料而是它逼着我从收藏过变成了能讲清楚。每次把一条新知识挂进知识库的网里我都会经历一次原以为自己懂了写的时候才发现不懂的过程。这种不舒服恰恰是成长最快的时刻。最后给你一个我踩过很多次坑后总结出来的建议不要等知识库设计完美了才开始填内容。先搭一个最简目录然后立刻写第一篇词条后面再慢慢调整结构。知识库是长出来的不是设计出来的。哪怕一开始只有十篇笔记只要你持续往里加、持续建立链接三个月后它就会成为你在大模型领域最有价值的私人参考资料。
