1. 从信息孤岛到知识中枢一个知识工作者的真实困境如果你和我一样每天在微信读书上划线、在知乎收藏回答、在Obsidian里写笔记那你一定也经历过这种痛苦信息散落在各处像一个个孤岛。微信读书里的高亮笔记想引用到自己的文章里得手动复制粘贴知乎上看到一个绝妙的观点想关联到之前读过的某本书只能靠模糊的记忆去翻找Obsidian里的卡片笔记越来越多但它们之间似乎缺少一根强有力的线无法形成真正的知识网络。我们收集了太多却难以“消化”和“连接”。这正是我决定动手搭建一个“知识中枢”的初衷。我不想再让工具成为知识的牢笼而是希望它们能协同工作让信息流动起来最终汇聚成一个属于我自己的、可被深度检索和智能关联的“第二大脑”。我的核心武器是 Obsidian一个以“双向链接”和“本地优先”著称的知识管理工具。但 Obsidian 本身只是一个优秀的“编辑器”和“仓库”它并不擅长主动从外部抓取和结构化信息。于是我引入了llm-wiki。这不是一个具体的软件而是一个理念和一套技术方案的组合。简单来说它利用大语言模型的能力将散乱、非结构化的信息如网页内容、电子书笔记、聊天记录进行理解、提取、结构化并导入到像 Obsidian 这样的知识库中形成一个可查询、可推理的“知识中枢”。我的目标很明确将微信读书的笔记、知乎的优质内容无缝、自动化地“装进”Obsidian并让它们与我已有的知识产生化学反应。这个过程远不止是简单的数据搬运。它涉及到本地环境的搭建、网络请求的处理、数据解析的准确性、以及如何设计一个可持续的自动化流程。接下来我将完整记录从零开始基于 llm-wiki 理念打通微信读书、知乎与 Obsidian 的全过程包括每一步的原理、踩过的坑和最终沉淀下来的稳定方案。2. 核心工具链选型与底层逻辑剖析在开始动手之前我们必须理清整个系统的技术栈和它们各自扮演的角色。盲目组合工具只会导致后期的混乱和崩溃。我的选型基于几个核心原则本地化优先数据安全、开源可控、以及尽可能利用现有成熟生态。2.1 Obsidian为什么它是不可替代的基座很多笔记工具都支持 Markdown但 Obsidian 的独特价值在于其“原子化”和“网络化”的理念。它的所有笔记都是纯文本 Markdown 文件存储在你的本地文件夹中。这意味着数据主权完全在你手中没有厂商锁定的风险文件可以用任何文本编辑器打开。双向链接与知识图谱这是核心。当你在一篇笔记中[[链接]]到另一篇笔记时Obsidian 会自动建立双向关系并可视化出知识图谱。这为后续的知识关联奠定了基础。强大的插件生态通过社区插件Obsidian 几乎可以扩展任何功能这也是我们能实现自动化导入的关键。注意Obsidian 的同步服务是付费的。但基于我们的本地化原则我强烈建议使用Syncthing或Git进行多设备同步。Syncthing 是点对点的同步工具完全免费且私密非常适合笔记库的同步。2.2 llm-wiki 理念与本地 LLM 的落地“llm-wiki”不是一个现成的软件包它更像一个架构蓝图。其核心思想是使用大语言模型作为“理解引擎”对输入的非结构化文本进行智能处理总结、提取、分类、打标签然后按照预定义的模板输出结构化的 Markdown 文本并保存到 Obsidian 库中。为了实现这个理念我们需要一个能在本地运行的 LLM。这里有几个选择Ollama当前最流行的本地大模型运行框架。它简化了模型的下载、加载和运行通过 API 接口。你可以轻松运行 Llama 3、Qwen、DeepSeek Coder 等开源模型。LM Studio一个带有图形界面的本地 LLM 运行和测试工具对新手更友好也提供 API。直接调用开源模型库如transformers灵活性最高但对编程和硬件要求也最高。我的选择是 Ollama。原因如下它提供了稳定的 REST API类似 OpenAI 的格式使得我们的自动化脚本可以像调用 ChatGPT 一样调用本地模型它社区活跃模型更新快部署极其简单一条命令即可。模型选择上我推荐Qwen2.5-7B-Instruct或Llama 3.2-3B-Instruct。对于文本处理、总结、提取信息这类任务7B 或更小参数量的模型在消费级显卡甚至只有 CPU上就能流畅运行且效果已经足够好。更大的模型如 70B虽然能力更强但响应速度慢对硬件要求高不适合作为高频调用的“知识处理流水线”。2.3 桥梁与粘合剂Python 自动化脚本Obsidian 和 Ollama 不会自动对话。我们需要一个“粘合剂”来指挥整个流程从源微信读书、知乎获取数据发送给 LLM 处理然后将结果写入 Obsidian。这个粘合剂的最佳选择就是Python。Python 拥有丰富的库requests/httpx用于网络请求抓取知乎页面内容。markdown/frontmatter用于处理和生成 Markdown 文件及 Front-matter元数据。json处理 API 返回的数据。pathlib优雅地处理文件路径。logging记录脚本运行日志便于排查问题。整个系统的架构如下图所示概念图[微信读书笔记/知乎网页] - (Python爬虫/导出工具) - [原始文本数据] - (Python脚本调用) - [Ollama本地LLM API] - [结构化Markdown文本] - (Python脚本写入) - [Obsidian知识库文件夹]这个流水线将是后续所有操作的核心。3. 实战打通微信读书笔记导入管道微信读书的笔记导出是第一个难关。官方不提供批量导出笔记的功能这迫使我们必须寻找技术解决方案。经过多次尝试目前稳定可靠的方法主要有以下两种。3.1 方案一使用浏览器插件“微信读书笔记助手”这是对非技术用户最友好的方式。在 Chrome 或 Edge 浏览器中安装“微信读书笔记助手”插件。安装后打开微信读书网页版进入“我的笔记”页面插件会自动出现导出按钮。操作流程点击导出可以选择导出格式如 Markdown。插件会帮你将笔记包括书籍信息、你的划线、想法整理成一个格式良好的 Markdown 文件。优点简单、直观、无需编程。缺点需要手动操作无法全自动化导出的笔记是“一本书一个文件”所有笔记混在一起不利于后续的原子化处理。如何实现自动化与原子化即使手动导出我们也可以在此基础上用 Python 进行二次处理。思路是编写一个脚本解析这个导出的 Markdown 文件。根据特定标记如##章节标题或划线内容将文件拆分成多个独立的笔记块。为每个笔记块提取关键信息书名、作者、划线内容、你的想法、章节。将每个笔记块作为一个独立的 Markdown 文件保存到 Obsidian 库的特定文件夹如Inbox/Books/《书名》/。在文件的 Front-matter 中写入元数据例如--- source: 微信读书 book: 《人类简史》 author: 尤瓦尔·赫拉利 chapter: 第一部分 认知革命 highlight_date: 2023-10-27 tags: [历史, 认知科学, 社会学] ---在笔记正文中使用双链[[ ]]链接到书籍的主索引页如《人类简史》从而实现笔记的原子化和网络化。3.2 方案二逆向工程微信读书接口高阶为了实现完全自动化我研究了微信读书的网页端接口。通过浏览器开发者工具F12 - Network可以观察到在翻看“我的笔记”时浏览器会向特定 API 发送请求返回结构化的 JSON 数据里面包含了所有的笔记信息。核心步骤在浏览器中登录微信读书网页版。打开开发者工具切换到 Network网络选项卡筛选 XHR/Fetch 请求。刷新“我的笔记”页面找到返回笔记数据的请求通常包含notebook或highlights等关键字。分析该请求的 Headers尤其是Cookie和Authorization等认证信息和 Response响应体。风险与挑战这种方法需要处理登录态Cookie的维护且微信读书的接口可能随时变更脚本需要一定的维护成本。此外大规模、高频次的抓取可能违反平台的使用条款因此仅建议用于个人、低频的同步需求。Python 脚本要点import requests import json session requests.Session() # 1. 需要手动从浏览器复制有效的Cookie字符串 headers { User-Agent: 你的浏览器UA, Cookie: 你复制的Cookie字符串, # 这是关键且敏感的一步 Referer: https://weread.qq.com/ } # 2. 构造请求URL通常需要书籍ID和分页参数 book_id 你的书籍ID url fhttps://i.weread.qq.com/book/notebook?bookId{book_id} response session.get(url, headersheaders) if response.status_code 200: data response.json() # 3. 解析data中的chapters和notes # ... 解析逻辑 # 4. 调用LLM处理并写入Obsidian重要提示Cookie 是个人隐私切勿分享或上传到公开仓库。脚本应本地运行。无论采用哪种方案最终目标都是获得结构化的笔记数据并将其送入下一环节——LLM 处理。4. 实战知乎内容结构化抓取与处理知乎内容比微信读书笔记更公开但也更复杂因为页面包含大量无关元素广告、推荐、评论区。我们的目标不是简单保存整个网页而是精准提取问题、回答正文、作者等核心信息并转化为知识卡片。4.1 爬虫策略请求与解析直接使用requests获取知乎页面 HTML 会遇到反爬机制如要求登录。更稳健的方法是使用httpx或requests-html库并模拟浏览器头部信息。import httpx from bs4 import BeautifulSoup async def fetch_zhihu_answer(url: str): headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8, } async with httpx.AsyncClient(timeout30.0, headersheaders, follow_redirectsTrue) as client: try: resp await client.get(url) resp.raise_for_status() return resp.text except httpx.RequestError as exc: print(f请求出错: {exc}) return None # 解析函数 def parse_zhihu_content(html: str): soup BeautifulSoup(html, lxml) # 提取问题标题 question_title soup.find(h1, class_QuestionHeader-title) # 提取回答正文 - 知乎的回答内容在特定的div中class可能会变需要观察 answer_content soup.find(div, class_RichContent-inner) # 提取作者 author soup.find(a, class_UserLink-link) # 这里需要大量的调试来定位正确的CSS选择器 return { title: question_title.get_text(stripTrue) if question_title else , content: answer_content.get_text(stripTrue) if answer_content else , author: author.get_text(stripTrue) if author else }关键点知乎的 HTML 结构经常变化上述 CSS 选择器class_很可能失效。更可靠的方法是寻找包含>import re def clean_text(text: str) - str: if not text: return # 合并多个空白字符为单个空格 text re.sub(r\s, , text) # 移除首尾空格 text text.strip() return text但清洗只是第一步。更重要的是增强。一个孤立的知乎回答价值有限我们需要为其添加上下文。这就是 LLM 发挥作用的地方。我们将原始回答文本发送给 Ollama 中的模型并设计一个提示词Prompt来让它帮我们提取和生成结构化信息。5. llm-wiki 核心设计提示词与构建处理流水线这是整个系统的“大脑”。LLM 的任务是将原始的、嘈杂的文本转化为格式统一、富含元数据、便于链接的知识卡片。5.1 为知识卡片设计提示词模板提示词的设计质量直接决定输出结果的好坏。我们的目标是让 LLM 扮演一个“知识提炼助手”。# 这是一个给LLM的提示词模板 PROMPT_TEMPLATE 你是一个知识管理助手负责将一段输入文本整理成结构化的知识卡片。 输入文本来源{source} 输入文本内容{raw_text}请严格按照以下要求输出一个JSON对象 1. title: 为这个知识卡片起一个简洁、核心的标题不超过15个字。 2. summary: 用一段话100字以内总结输入文本的核心观点或事实。 3. key_points: 提取3-5个关键要点以字符串数组形式列出。 4. tags: 根据内容生成3-5个相关的标签以字符串数组形式列出。标签应具体、可关联例如“机器学习”、“时间管理”、“中国经济”避免“文章”、“心得”等泛泛之词。 5. related_concepts: 思考这段内容可能与哪些已知概念、理论、人物或事件相关列出2-4个以字符串数组形式列出。这将用于后续的双向链接。 输出示例 {{ title: 刻意练习的核心原则, summary: 刻意练习强调脱离舒适区、有明确目标、包含反馈并针对弱点进行重复训练而非单纯的经验积累。, key_points: [在舒适区边缘学习, 专注与反馈至关重要, 心理表征的构建是专家与新手的区别], tags: [学习方法, 认知心理学, 技能提升], related_concepts: [一万小时定律, 安德斯·艾利克森, 心理表征] }} 现在请处理上面的输入文本只输出JSON对象不要有任何其他解释。 这个提示词明确了角色、输入、输出格式和示例能极大提高 LLM 回复的稳定性和质量。5.2 构建 Python 处理流水线现在我们将所有环节串联起来形成一个完整的流水线脚本。import asyncio import json from pathlib import Path import httpx from ollama import AsyncClient # 需要安装 ollama python 库 OBSIDIAN_VAULT_PATH Path(/path/to/your/obsidian/vault) LLM_MODEL qwen2.5:7b # 你本地 Ollama 运行的模型名称 async def process_content(source: str, raw_text: str, source_url: str ): 处理内容的核心函数 # 1. 调用 LLM 进行结构化处理 prompt PROMPT_TEMPLATE.format(sourcesource, raw_textraw_text[:3000]) # 限制文本长度 async with AsyncClient() as client: response await client.generate( modelLLM_MODEL, promptprompt, options{temperature: 0.1} # 低温度保证输出稳定 ) llm_output response[response] # 2. 解析 LLM 返回的 JSON try: card_data json.loads(llm_output.strip()) except json.JSONDecodeError as e: print(fLLM 返回了非 JSON 格式: {llm_output[:200]}) # 可以加入重试或降级处理逻辑 return # 3. 生成 Markdown 文件内容 frontmatter { source: source, source_url: source_url, processed_date: datetime.now().isoformat(), tags: card_data.get(tags, []), } # 使用 frontmatter 库来生成带 YAML 头部的 Markdown content f--- {frontmatter} --- # {card_data[title]} **来源**: {source} | **处理时间**: {frontmatter[processed_date]} ## 核心摘要 {card_data[summary]} ## 关键要点 {chr(10).join(f- {point} for point in card_data[key_points])} ## 原文精华节选 {raw_text[:500]}... [原文链接]({source_url}) ## 关联概念 {chr(10).join(f [[{concept}]] for concept in card_data.get(related_concepts, []))} ## 我的思考 !-- 在这里添加你的个人评论、延伸思考或与其它笔记的链接 -- # 4. 安全地保存文件 # 使用标题生成安全的文件名 import re safe_title re.sub(r[^\w\s-], , card_data[title]).strip().replace( , -) filename f{safe_title}.md # 按日期组织文件夹 today_folder OBSIDIAN_VAULT_PATH / Inbox / datetime.now().strftime(%Y-%m-%d) today_folder.mkdir(parentsTrue, exist_okTrue) file_path today_folder / filename # 防止覆盖 counter 1 while file_path.exists(): file_path today_folder / f{safe_title}-{counter}.md counter 1 file_path.write_text(content, encodingutf-8) print(f知识卡片已保存: {file_path}) # 主函数整合微信读书和知乎的抓取逻辑 async def main(): # 这里可以调度不同的抓取任务 # 例如定期运行微信读书接口抓取或监听一个包含知乎URL的文本文件 pass if __name__ __main__: asyncio.run(main())这个流水线实现了从原始文本到结构化知识卡片的自动化转换。保存到Inbox文件夹后你可以在 Obsidian 中定期回顾将这些卡片通过拖拽或手动添加链接的方式整合到你的主题笔记中。6. 高级集成与自动化让流程持续运转手动运行脚本不是终点。一个高效的知识中枢应该能半自动或全自动地运转。6.1 使用 Obsidian 插件增强体验Templater你可以为知识卡片创建一个模板。当上述脚本生成文件时可以调用 Templater 的 API 或直接按照模板格式写入确保所有卡片风格一致。QuickAdd这是一个强大的自动化插件。你可以设置一个 QuickAdd 命令比如“抓取当前知乎页面”。配合浏览器插件如Web Clipper的增强版或自定义书签脚本将当前页面的 URL 发送到本地的一个 API 端点由你的 Python 脚本提供触发抓取和处理流程然后将生成的卡片插入 Obsidian。这实现了“一键收藏”。Dataview当你的知识卡片积累到一定数量你可以用 Dataview 查询并动态生成索引页。例如创建一个“所有来自知乎的卡片”页面或者“本周处理的所有关于‘机器学习’的卡片”页面。dataview TABLE summary, file.ctime as “创建时间” FROM “Inbox” WHERE contains(source, “知乎”) SORT file.ctime DESC 6.2 搭建简单的本地调度服务为了让抓取微信读书笔记等任务定期自动执行你需要一个调度器。对于 macOS/Linux 用户使用cron定时任务是最简单的。# 每天凌晨2点运行一次脚本 0 2 * * * cd /path/to/your/script /usr/bin/python3 /path/to/your/script/weread_sync.py /tmp/weread_sync.log 21对于 Windows 用户可以使用“任务计划程序”。更优雅的方案在 Python 脚本内使用schedule库然后将其作为一个常驻的后台服务运行例如使用systemd或nssm。6.3 处理失败与日志监控自动化流程必须考虑异常。你的脚本应该包含完善的错误处理和日志记录。import logging logging.basicConfig( levellogging.INFO, format%(asctime)s - %(name)s - %(levelname)s - %(message)s, handlers[ logging.FileHandler(knowledge_hub.log), logging.StreamHandler() ] ) logger logging.getLogger(__name__) async def fetch_zhihu_answer(url): try: # ... 请求逻辑 return resp.text except httpx.RequestError as exc: logger.error(f请求知乎失败 {url}: {exc}) # 可以在这里加入重试逻辑 return None except Exception as e: logger.exception(f处理知乎URL时发生未知错误 {url}) return None定期检查日志文件能帮你发现是网络问题、API 变更还是 LLM 服务异常从而及时修复。7. 避坑指南与效能优化心得在搭建和运行这套系统的过程中我踩过不少坑也总结出一些提升效能的经验。7.1 常见问题与解决方案Ollama 响应慢或报错检查模型是否已下载运行ollama list确认。分配更多资源运行 Ollama 时可通过环境变量设置OLLAMA_NUM_PARALLEL或OLLAMA_HOST。对于 GPU 运行确保驱动和 CUDA 版本正确。降低上下文长度在调用 API 时设置num_ctx参数为一个较小的值如 2048可以显著提升小模型的速度。使用量化模型优先选择-7b-q4_K_M这类量化版本在几乎不损失精度的情况下大幅提升速度、降低内存占用。知乎/微信读书反爬导致抓取失败降低请求频率在脚本中增加随机延迟time.sleep(random.uniform(2, 5))。轮换 User-Agent准备一个 User-Agent 列表每次请求随机选择。使用代理 IP对于大规模抓取这是必要的但个人小规模使用通常不需要。考虑官方 API知乎和微信读书都有部分开放 API虽然限制多但更稳定。可以研究一下。生成的 Markdown 文件在 Obsidian 中显示异常检查 Front-matter 格式确保三个短横线---在单独一行YAML 内容缩进和冒号后空格正确。检查文件名和路径避免使用特殊字符\ / : * ? “ |和过长文件名。Obsidian 对中文文件名支持良好。图片链接问题如果抓取的内容包含图片需要额外处理图片下载和本地路径替换这是一个更复杂的主题。7.2 提升系统效能的技巧批量处理与队列不要来一条内容就调用一次 LLM。可以设置一个缓存队列积累到一定数量如 10 条或每隔一段时间如 1 小时批量处理一次。这能减少 LLM 的冷启动开销。优化提示词经过多次测试我发现给 LLM 一个清晰的输出格式示例如上面的 JSON 示例比只用文字描述要求成功率高出很多。同时在提示词开头明确指令“只输出 JSON不要有任何其他解释”能有效避免模型“说废话”。分级处理策略并非所有内容都需要经过 LLM 深度处理。对于微信读书中简单的划线句子可能只需要提取文本并打上书籍标签即可。对于长篇的知乎回答或文章才启用完整的 llm-wiki 流水线。这可以通过判断文本长度或来源类型来实现。定期清理与归档Inbox文件夹可能会快速增长。我每周会花 15 分钟回顾 Inbox 中的卡片将已经消化、链接到主笔记系统的卡片移入相应的主题文件夹如Projects/,Areas/,Resources/或者删除无价值的卡片。保持 Inbox 清空是知识流动的关键。搭建这样一套系统初期需要投入一些时间和精力进行调试和磨合。但一旦它稳定运行起来你就会发现信息收集和初步处理这个最耗时的环节被自动化了你可以将宝贵的注意力完全集中在更高层次的思考、连接与创造上。你的 Obsidian 库不再是一个被动的存储箱而是一个每天都在自动生长、不断与你已有知识产生新连接的活体知识中枢。这种从“收集”到“内化”的效率提升才是这套系统带来的最大价值。