我一直觉得个人知识库里最难的不是记下来而是记下来之后还有人管。我的笔记库里躺着几千条剪藏、摘录和半截想法真正被复用的不到百分之五。后来我把这套流程改造成机器负责整理、人负责判断的结构用 Obsidian 当底座用 WorkBuddy 这类自动化编排工具当不限时长的执行器把采集、清洗、摘要、打标、建双链、做索引这些体力活全交出去最后只留下一个需要我动手的环节——读和判断。这篇就完整讲一遍这个Obsidian LLM Wiki 自动更新个人知识库的方案从目录怎么切、frontmatter 怎么定、提示词怎么写、增量更新怎么去重到跑起来之后会遇到哪些坑全部按我能复现的标准写出来。适合两类人看一类是笔记库里已经积压了成百上千条素材、想一次性盘活的人另一类是刚搭好库、想从一开始就把自动化架子搭对、少走弯路的人。1. 为什么要把知识库交给机器维护方案选型与整体拆解1.1 手工知识库烂尾的三个真实原因绝大多数人的知识库不是建不起来而是建起来之后慢慢废掉。我复盘过自己前后三版笔记库烂尾的原因其实高度一致跟意志力关系不大跟流程设计关系极大。第一个原因是采集速度远大于整理速度。剪藏一条素材只要三秒把它读透、提炼成自己的话、挂到已有的知识节点上可能要二十分钟。这个剪刀差会持续放大最后库里百分之九十是未经处理的原料你每次打开都面对一堆待办久而久之就不想打开了。工具一旦让人产生负罪感它就死了。第二个原因是存和用之间缺一层转化。原始剪藏里混着作者的观点、案例、广告、错别字而你需要的是可检索、可引用、可对比的结论。这两者在结构上完全不同前者是长文本后者应该是带字段的短条目。很多人把这两类东西放在同一个目录里用同一套命名结果检索时噪音极大找一条结论要翻十条原文。第三个原因是双链和索引是纯手工劳动人一懒就断。双链的价值在于我以后能顺着这条线找回来但前提是每次新建笔记都老老实实挂链接。现实是写着写着就忘了半年后打开图谱一堆孤岛。至于索引页手工维护的索引页几乎必然滞后于内容最后变成一份过期目录。1.2 底座为什么锁定 Obsidian选底座这件事我的判断标准只有一条数据必须能被任意脚本直接读写且不依赖某个服务的在线状态。按这条标准筛下来Obsidian 几乎是唯一顺手的选择。它的库就是一个普通文件夹每条笔记就是一个.md文件路径就是层级文件名就是标题。这意味着我用 Python 写个脚本open()就能创建、修改、重命名笔记不需要走任何 API不需要处理鉴权也不会因为接口改版而崩掉。这一点非常关键——自动化流程最怕的就是中间某一环只有图形界面能做一旦某步必须人工点击整条链路就断了。第二个原因是 frontmatter。Obsidian 原生支持在文件头写 YAML 元数据而这些元数据又能被查询插件读取生成表格。这相当于给你的笔记免费配了一套轻量数据库正文是内容frontmatter 是字段。你可以在 frontmatter 里塞source、tags、created、confidence、status然后用一条查询把所有status: 待复核的条目拉出来。LLM 输出的结构化结果刚好能直接落进这些字段衔接得非常自然。第三个原因是双链语法极简。[[笔记名]]就是链接反链自动生成不需要维护任何索引表。脚本要建链只需要在正文里拼一个双方括号。这种零成本建链的特性是自动化的前提——如果建链需要三步操作机器也嫌烦。最后是可迁移性。纯文本加文件夹二十年后照样能读。工具会换代但md不会。我不想再把知识资产押在某个产品的生命周期上。1.3 WorkBuddy 在这条链路里到底扮演什么角色这里要先说清楚定位否则很容易把它当成另一个笔记软件那就用错了。WorkBuddy 这类工具的价值不在界面而在于它是一个能长时间挂着、能调模型、能执行脚本、能读写本地文件的编排器。它没有笔记界面也不需要。它就是我伸进文件系统里的一双手。为什么不让笔记软件自己的插件去调模型我试过问题有三个。一是插件运行在沙箱里长任务容易被中断处理五十篇素材跑到一半卡住前面的全白干。二是插件的并发能力弱串行调用模型五十篇要跑一个多小时。三是错误处理粗糙接口超时了它不重试直接给你留个空文件你还得自己找哪篇漏了。编排器做这些事就从容得多可以并发、可以重试、可以记录日志、可以断点续跑。所以这个方案的分工是清晰的Obsidian 负责存和看WorkBuddy 负责跑模型负责想。三者之间只通过文件系统交互耦合度极低。哪天你想换掉编排工具脚本一行不用改换个调度器照样跑。1.4 整体数据流一次自动更新要经过哪几站把整条链路拆开其实是七个环节。我把它画成一张职责表方便你对照自己的库看缺哪一环。环节职责输入输出常见故障采集汇总各类来源的原始素材剪藏、订阅、手记原始文件来源格式混乱清洗去广告、去导航、统一编码原始文件纯正文正文被误删切分按语义边界拆成块纯正文文本块句子被截断抽取调模型产出结构化知识卡文本块JSON/YAML输出格式跑偏落盘按模板写入 Markdown结构化结果笔记文件覆盖已有笔记建链生成双链、标签、索引页全部笔记关系网络死链、孤岛巡检找断链、过期、重复整个库待办清单无人处理这七站里前四站是原料到半成品后三站是半成品到可用资产。很多人的自动化只做到第四站就停了结果库里多了一堆格式漂亮的摘要但依然找不到东西——因为建链和巡检没做知识之间没有关系索引也不更新。还有一个设计上的取舍要说清楚整条链路必须是幂等的。同一篇素材跑两次结果应该一样或者至少不产生重复笔记。这决定了后面所有的去重设计。如果做不到幂等你就不敢让它定时跑只能人工盯着那自动化就失去意义了。2. 环境搭建先把地基打平2.1 软件与目录结构的最小可用配置我这套配置不需要复杂的插件组合先把核心几个装上就行。查询插件负责把 frontmatter 变成表格模板插件负责新建笔记时自动填字段版本管理插件负责给每次自动写入留一个回滚点。其余的花哨插件可以后加前期加了反而干扰排查。组件作用是否必需备注笔记客户端本体承载库与双链必需库放在本地磁盘查询类插件frontmatter 转表格强烈建议用来做索引页和待办页模板类插件新建笔记套模板建议保证字段一致性版本管理插件自动提交历史建议出问题能回滚编排工具调度与执行必需独立进程运行Python 运行环境跑处理脚本必需装两个依赖即可目录结构我踩过最大的坑是一开始分得太细。第一版我按主题分了二十多个文件夹结果每加一条素材都要纠结放哪儿纠结本身就是摩擦。现在我只用六层层级不超过两层KnowledgeVault/ ├── 00_Inbox/ 原始素材未处理 ├── 10_Cards/ 知识卡机器生成人工修订 ├── 20_Topics/ 主题综述页人工主导 ├── 30_Index/ 自动生成的索引与待办 ├── 40_Assets/ 图片与附件 └── 90_Archive/ 过期或合并掉的旧卡00_Inbox是唯一允许乱的地方任何来源的东西先扔这里不做任何整理。10_Cards是核心资产一个概念一张卡文件名就是概念名。20_Topics是我自己写的长文机器只负责往里插链接和更新最近变更区块绝不改我的正文。这个边界要划死否则你会有我的笔记被机器改乱了的不安全感。2.2 frontmatter 字段设计机器和人的契约frontmatter 是这套方案里最容易被低估的部分。它不是装饰而是机器和人类之间的一份契约机器按字段填人按字段查。字段设计得糙后面所有查询都会难受。我的字段表经过三轮删减现在保留这些--- title: 增量更新的去重策略 uid: kn-20240612-0031 source: 某技术博客/2024-06 source_hash: 9f2c1a7e tags: [知识管理, 数据处理, 自动化] type: concept status: reviewed confidence: high created: 2024-06-12 updated: 2024-06-12 related: [[[内容切分]], [[幂等设计]]] ---几个字段的设计意图值得单独说。uid是唯一标识格式是前缀-日期-序号它不随标题变化是去重和关联的锚点。很多人用标题当唯一键一旦改标题就全乱这是必须要避开的。source_hash存原始素材的哈希前八位用来判断这条素材是不是处理过。status只有三档draft机器生成的初稿、reviewed我人工看过并修订过、stale内容可能过期待复核。这个字段是所有巡检查询的入口。confidence是我加的一个比较主观的字段表示这条知识的可靠程度。机器抽取的东西不一定准尤其是需要推理的结论。标成low的条目在索引页里会单独列出来提醒我优先核对。这个字段救过我几次——有些模型脑补出来的关联一眼看过去很顺实际是错的。注意frontmatter 里的字符串如果包含冒号、井号、方括号必须用引号包起来否则 YAML 解析会失败整个文件的元数据都会读不出来。源地址这类字段最容易踩这个坑。2.3 模型接入与凭据管理调用模型这一步我只用一件事走标准的对话补全协议用通用的 HTTP 请求发出去。这样不绑定任何一家想换随时换。凭据绝对不能写进代码里也不能写进笔记里——笔记是会被同步、被分享、被版本管理记录的地方密钥写进去等于公开。我的做法是全部走环境变量脚本启动时读取export KB_API_BASEhttps://your-endpoint.example.com/v1 export KB_API_KEYsk-xxxxxxxx export KB_MODELyour-model-name编排工具那边配置定时任务时也是引用这几个变量名不落明文。如果你是多个人共用一个库还要额外注意自动写入的笔记里绝对不能带任何凭据、内网地址、个人身份信息。我在落盘脚本里加了一道正则过滤凡是匹配到密钥形态的字符串直接替换成占位符并记一条警告日志。这道过滤看起来多余但它拦住过一次我把调试信息误写进正文的事故。2.4 触发方式定时跑还是变化跑触发方式有两种各有适用场景我最后是两个都用。定时触发适合每天固定时间把当天的素材处理掉比如每天早上七点跑一次处理前一天积压的00_Inbox。好处是节奏固定坏处是如果你白天写了东西要等到第二天才处理。文件监听触发适合素材一进来就处理延迟低但要注意防抖。我试过没做防抖的版本一个文件从创建到写完内容会触发三次事件结果同一篇素材被处理了三遍虽然去重逻辑拦住了重复笔记但白白烧了三次调用。后来加了文件大小连续两秒不变才触发的判断问题解决。实际配置里我给监听加了一条白名单只监听00_Inbox其他目录的变化一律不响应。这条限制很重要否则机器生成的笔记写入10_Cards时会再次触发监听形成自激循环越跑越忙。3. 核心实现一条素材变成一张知识卡的全过程3.1 采集层先把输入源归一化采集这步看起来最简单实际上是整条链路里最脏的一环。来源不同格式差异极大网页剪藏带一堆导航和评论手写备忘没有标题复制粘贴的片段可能连出处都没有。如果不对齐格式后面的清洗逻辑就得写一堆分支判断越写越乱。我的处理原则是进00_Inbox之前先归一化。所有来源统一转成一个格式一个.md文件文件头三行固定是来源、采集时间、原始标题下面空一行再放正文。不管来源是什么都先转成这个形状。这一步我用一个很短的脚本做逻辑就是读入、抽取正文、拼头信息、写文件。归一化带来的好处在调试时特别明显出问题时你只需要看一个格式不用去想这次是网页还是手记。而且后续所有脚本都只认这一个格式扩展新来源时只需要加一个转换器主流程一行不用改。3.2 清洗与切分为什么必须先把长文切开这里要说清楚一个反直觉的点大多数人不切分直接把整篇丢给模型这是效果差的主因之一。原因有两个一个是上下文预算一个是注意力稀释。先算预算。中文文本按常见的分词方式一个字大约对应 1.5 到 2 个 token。一篇八千字的深度文章光正文就一万二到一万六千 token加上提示词模板、字段说明、示例输出很容易顶到两万。如果你的模型上下文窗口是十六 k直接就溢出了就算窗口够大成本也上去了。我做过对比同样一篇八千字的文章整篇丢进去抽取出来的知识卡字段完整度反而不如切成三段分别抽取再合并——因为长文本里信息密度不均模型容易只抓住开头和结尾。切分策略我用的是优先按语义边界切硬上限兜底。具体做法是先按标题层级切二级标题切一刀三级标题再切一刀如果某个块还是超过阈值就按段落切段落还超才按句子切。阈值我设在 1200 字这个数字是试出来的低于八百字模型容易缺少上下文抽出来的结论偏窄高于一千五百字单块的字段完整度开始下降。一千二左右是个平衡点。def split_blocks(text, soft_limit1200, hard_limit1800): # 先按标题切保留标题作为块的上下文 sections split_by_heading(text) blocks [] for sec in sections: if len(sec) hard_limit: blocks.append(sec) else: # 超长则按段落累加接近 soft_limit 就断开 buf for para in sec.split(\n\n): if len(buf) len(para) soft_limit and buf: blocks.append(buf) buf para else: buf buf \n\n para if buf else para if buf: blocks.append(buf) return blocks切分时有一件事必须做给每个块带上来源标题和前后文提示。我见过太多切分之后句子被拦腰截断模型拿着半句话去推断结论完全跑偏。我的做法是给每个块加一行前缀写明本文标题是 X本段属于第 N 部分并在块尾标注是否完结。这几个字成本极低但对抽取准确率的提升很明显。注意切分时绝对不要在代码块、表格、引用块内部下刀。我在第一版里没做这个判断结果一个代码示例被切成两半模型把后半段当成了独立的技术方案生成了一条完全错误的知识卡还在库里躺了两个月才被发现。3.3 提示词模板把总结改成结构化抽取这是整篇文章里最值得反复打磨的部分。很多人写的提示词是请总结以下内容得到的就是一段泛泛的摘要既不能检索也不能对比。我需要的不是摘要是带字段的结构化输出。思路上的转变是把模型当成一个填表员而不是一个写手。你要告诉它表有几列、每列填什么、不满足条件时填什么。模板我固定成四段结构角色与任务、字段定义、输出格式、禁止事项。字段定义里每个字段都要给一句解释和一个正例这是提升稳定性的关键。你是知识抽取助手。请从给定文本中抽取知识条目严格按下方字段输出 JSON不要输出任何解释性文字。 字段定义 - concept: 本条知识的核心概念名8 到 20 字名词性短语不要用完整句子。 - summary: 用你自己的话概括不超过 120 字不得直接复制原文超过 15 个字。 - points: 数组3 到 5 条每条是一个可独立成立的结论不超过 50 字。 - conditions: 该结论成立的前提条件若原文未提及输出 未说明。 - tags: 数组2 到 4 个从下列受控词表中选... - confidence: high / medium / low判断依据是原文对该结论的支持是否充分。 禁止事项 - 不得补全原文没有的信息宁可留空也不要推测。 - 不得输出 markdown 代码块包裹直接输出裸 JSON。 - 若文本不含任何可抽取的知识点输出 {skip: true, reason: ...}。这个模板里有三个设计是踩坑换来的。第一是禁止输出代码块包裹因为模型很喜欢用三反引号把 JSON 包起来解析时容易把反引号带进去导致失败。第二是不得复制原文超过 15 个字这是为了防抄袭式摘要——模型偷懒时会把原句原样搬过来那样知识卡就退化成原文碎片毫无价值。第三是skip出口没有这个出口模型面对一段纯广告也会硬编出三条结论。conditions字段是我最推荐加的一个。任何结论都有前提把前提显式抽出来能极大减少后续误用。比如某条性能优化的经验前提可能是数据量在十万条以内脱离这个前提去套用就会翻车。这个字段在别处很少见但用起来真的香。3.4 输出解析与落盘稳一点别信模型拿到模型输出之后第一件事不是解析是清洗。我遇到过的情况包括输出前后带一句好的以下是抽取结果、JSON 外面包了三反引号、字段名拼错、数组里混了字符串。所以解析必须写成防御式。import json, re, hashlib, os from datetime import date def parse_output(raw): # 去掉可能的包裹与前后缀只留最外层大括号 s raw.strip() s re.sub(r^(json)?, , s).strip() s re.sub(r$, , s).strip() start, end s.find({), s.rfind(}) if start -1 or end -1: return None try: data json.loads(s[start:end 1]) except json.JSONDecodeError: return None if data.get(skip): return None # 字段兜底缺字段的补默认值别让下游崩 for k in (points, tags, related): if not isinstance(data.get(k), list): data[k] [] data.setdefault(conditions, 未说明) data.setdefault(confidence, low) return data解析失败的处理策略比解析本身更重要。我的策略是最多重试两次仍然失败就落到待处理区并记日志绝不写入半成品。有些人为了跑通直接跳过失败项结果库里缺了几条你根本不知道缺的是哪几条后面排查成本极高。落盘时的文件名也有讲究。我用的格式是概念名.md但如果同名文件已存在不覆盖而是对比source_hash一致就跳过不一致就说明是新的来源在讲同一个概念这时追加一节其他来源并保留原有内容。这个逻辑保证了三件事重复处理不会产生垃圾、多个来源可以汇聚到同一张卡、我的手工修订永远不会被机器覆盖。3.5 双链、标签与索引页的自动生成知识卡写完了如果不建链它就是一座孤岛。自动建链的核心是找到这张卡应该连到哪张卡。我的做法分两步先做基础关联再做语义关联。基础关联靠标签共现。两张卡如果有两个以上相同标签就把它们互相挂上related。这个规则简单粗暴但有效因为标签本身就是受控词表共现次数高说明主题确实接近。语义关联则是在全部卡片标题里做一次相似度匹配取最接近的三张作为候选写进related但标注为待确认状态。后者精度不如前者所以我只让它做建议不直接确认为正式链接。索引页我是用一个模板生成的查询页不写死内容## 最近更新的知识卡 查询按 updated 倒序取 20 条 ## 待复核对列 查询status 为 draft或 confidence 为 low ## 孤儿笔记 查询related 为空且无任何反链这三块内容各有用途。第一块让我知道机器最近在忙什么第二块是我的工作队列第三块是断链预警。索引页不写死内容这一点很重要——写死的索引页必然过期而查询页永远是活的。3.6 增量更新用哈希指纹替代全量重跑不做增量这个方案在素材上到几百篇之后就跑不动了。全量重跑的代价不只是时间还有成本而且每次全量都会产生大量内容一致但需要判断是否覆盖的冲突人工核对量爆炸。增量的核心是给每篇素材算一个指纹。我用的是正文归一化之后的哈希去掉空白、去掉标点、转小写再算摘要。这样同一篇文章即使换了个网址、多了几行导航指纹也不变。指纹存在两个地方一个是素材文件的 frontmatter一个是知识卡的source_hash字段。处理前先扫一遍10_Cards里所有source_hash命中就跳过。def fingerprint(text): norm re.sub(r\s, , text) norm re.sub(r[。、,.!?;:\()\[\]【】], , norm) return hashlib.sha256(norm.lower().encode(utf-8)).hexdigest()[:16]这里有个坑要说指纹不能用原始文本直接算。我第一版就是这么干的结果同一篇素材在两个平台转载正文一样但排版不同指纹完全不同被当成两篇处理库里出现两张内容几乎一样、但uid不同的卡。后来加了归一化才解决。归一化的力度也要控制我把标点全去了但保留了段落结构因为完全去掉空白会让两篇不同文章碰巧撞哈希的概率上升——虽然极小但知识库里出现一次串内容就很难查。至于被修改过的素材怎么办比如某篇文章作者日后更新了内容。这种情况哈希会变会被当成新素材处理然后走到同名概念卡追加来源的逻辑追加一节而不是覆盖。我接受这个设计因为它保证了历史信息不丢失代价是同一张卡里可能有前后矛盾的表述——但这个矛盾是显式的比悄悄覆盖掉旧版本要好。4. 让它自己跑起来自动更新、合并与质量巡检4.1 变更检测与增量刷新自动更新这个词有两层意思一层是新素材自动进来另一层是旧知识自动刷新。前者好办后者才是真正决定这个库能不能长期用的关键。我的做法是给每张知识卡记一个updated时间然后设一个复核周期。周期性复核的逻辑是超过 90 天没动过的卡标成stale如果这张卡有对应来源就把来源正文重新读一遍和卡里现有内容做一次一致性比对发现明显差异就生成一条可能过期的提示插到待办索引页。这个提示不会自动改内容只提请我注意。一致性比对我不让模型做开放式判断而是问一个很具体的问题下面这两段内容是否有互相矛盾的表述如果有请指出矛盾点。开放式问这两段是否一致的准确率很低模型倾向于说基本一致等于白问。限定成找矛盾它才会认真挑刺。另一层刷新是标签体系演进。我一开始定的标签只有十几个后来慢慢加到三十多个早期生成的卡用的还是老标签导致查询漏掉。所以我加了一个标签归一的脚本定期扫全库把不在受控词表里的标签按映射表替换。这个脚本我只让它做替换不删除因为有些标签虽然不在词表里但确实有区分度。4.2 知识卡的合并与版本管理卡片越积越多必然出现重复概念。比如内容切分和文本分块讲的是同一件事可能被抽成了两张卡。合并这件事我试过全自动效果不好——模型判断这两个概念是否等价的阈值很难拿捏太宽松会把相关但不同的概念合并掉太严格又会漏。现在的方案是机器提议、人来定。脚本每天扫一遍用标题相似度和标签重合度筛出候选对写进一张合并候选.md的表格包含两边的标题、标签、摘要前六十字。我每天花两分钟过一遍勾选要合并的跑一个合并脚本。合并动作本身是全自动的正文拼接、去重、related合并、旧卡移到90_Archive并在原位置留一个重定向链接。版本管理这块我强烈建议开自动提交。理由很实际自动写入意味着你不可能每次盯着出了问题你需要一个明确的昨天这个时候是什么样的快照。我有一次提示词改错了一个字段名导致三百多张卡的名字全部变成了字段值如果没有版本历史那一天就得手工改回来。开了自动提交一条命令回滚。4.3 检索层全文够不够什么时候需要语义很多人一上来就想搞向量检索我的建议是先别急。Obsidian 自带的全文搜索配合 frontmatter 查询能覆盖九成以上的日常需求。你要找的是我记过的关于幂等设计的那条全文搜关键词就够了毫秒级返回。语义检索真正有价值的场景是你记得有个人讲过类似的意思但用的不是这个词或者你想找和当前这张卡主题相近的所有卡。这两种需求全文搜索确实无能为力。我的做法是给每张卡生成一个稠密向量存到本地文件做成一个轻量索引只在相关推荐这个场景里调用不作为主检索入口。这里有个成本核算要做。假设库里有五千张卡每张卡的摘要平均两百字全部算一遍向量大概要几十万 token一次性成本可以接受但增量更新时每新增一张卡就要算一次长期下来是持续支出。所以我的策略是只给reviewed状态的卡算向量draft状态不算——因为草稿内容可能还会大改算了也是浪费。4.4 质量巡检断链、孤儿与重复的三类体检自动化跑久了库会慢慢腐化。腐化的表现有三种链接指向不存在的笔记、笔记没有任何链接进出、同一概念有多张卡。这三种都能用脚本查问题在于查出来之后得有人处理所以巡检结果必须足够省事。我写的巡检脚本每天跑一次输出一张表检查项判定规则处理建议优先级死链双链目标文件不存在建空卡或改链接高孤儿卡无出链且无反链补标签或挂到主题页中重复卡标题相似度高于阈值进合并候选表中过期卡updated 超过 90 天重读来源做一致性比对低空壳卡正文字数少于 80删除或合并高这张表的价值在于处理建议这一列。如果巡检只告诉你有 47 个死链你还是不想动告诉它这 12 个是笔误可以直接改那 35 个需要建空卡动手成本就低多了。我甚至让脚本把笔误类的死链自动修掉只把需要判断的留给人。注意自动修死链时一定要做目标唯一性判断。如果改完之后可能匹配到多个文件宁可不动也不要猜。我吃过这个亏——一个模糊的链接名被自动指向了错误的卡表面上巡检全绿实际内容关联错了比死链更难发现。5. 常见问题与排查实录5.1 故障速查表跑了大半年遇到的问题基本能归到几类。整理成表出问题时按症状对号入座比从头读日志快得多。症状最可能的原因排查动作修复方式笔记生成了但内容全空模型返回被截断或解析失败看原始返回是否有闭合括号调大输出上限加重试同一素材反复处理指纹未归一化或状态没回写检查 source_hash 是否写入补写状态加已处理标记序号 uid 冲突并发写入同一计数器看日志时间戳是否重叠改用时间戳随机后缀frontmatter 读不出来值里有未转义的特殊字符打开文件看头部字符串统一加引号索引页一片空白查询语法或字段名拼错手动跑一次查询对齐字段名跑一半就停单次调用超时无重试看是否有超时日志加退避重试与断点续跑内容被机器改乱写入逻辑命中了人工修订区对比版本历史划出不可写区块成本突然翻倍全量重跑或切分粒度变细统计当日调用次数恢复增量检查切分阈值这张表里最值得展开的是内容被机器改乱和成本突然翻倍两条因为这两条最伤。关于改乱根本原因是脚本没有区分机器生成的区和人工写的区。后来我在每张卡里加了两个固定标记机器只写标记之间的内容标记之外一律不碰。这个约束写进脚本的第一行判断成了硬规则。关于成本我遇到过一次单日调用量暴涨八倍查下来是文件监听的自激循环——机器写入触发了监听监听又触发处理处理再写入。日志里能看到同一个文件被处理了十几遍。这类问题不会报错只会悄悄烧钱所以监控调用量是必须的。5.2 几个踩坑场景的复盘第一个坑是编码问题。中文内容里混着全角标点和特殊符号有些来源还带着不可见字符。我第一版脚本用默认编码写文件结果在某个平台上打开是乱码。后来统一成 UTF-8 并且在写入前做一次字符清洗把所有不可见控制字符去掉。这个坑的隐蔽之处在于在你自己机器上看一切正常换台设备才暴露。第二个坑是模型偶尔自作主张补充信息。提示词里明明写了不得补全原文没有的信息它还是会在conditions字段里编出个适用于大规模场景。我的应对是加一道校验把points和conditions里的每条内容拿去和原文做子串匹配匹配率低于某个阈值就标记为可疑。这个校验不能百分百拦住但能拦住大部分明显编造的内容。可疑的卡会进待办我看一眼就知道真假。第三个坑是并发写入的顺序问题。为了提高速度我开了并发结果两张卡同时读写同一个索引文件最后写的那次把前一次覆盖了索引少了十几条。解决办法很简单索引文件不并发写所有卡写完之后单独跑一次索引重建。这个原则后来扩展成了所有聚合类文件都不参与并发写。第四个坑是提示词改版导致存量不一致。我优化了一次模板字段含义微调结果新旧卡片的字段口径不一样查询时对不上。后来我给模板加了版本号写进 frontmatter 的schema字段查询时按版本号分组需要的时候批量重跑旧版本。这个字段平时没人看但改模板的时候是救命的。5.3 成本与耗时的控制方法成本这块我算过一笔账。假设每天新增素材五十篇平均每篇切成三段每段输入一千二百字约两千 token输出约八百字约一千二百 token单次调用合计三千二百 token 上下。五十篇乘三段就是一百五十次调用总计约四十八万 token。按公开价目区间估算一天的成本在几块钱以内一个月百元级别。这个量级对个人使用是完全可以接受的。真正会让成本失控的不是日常增量是三件事全量重跑、切分过细、失败重试无上限。前两个前面说过了第三个特别容易被忽视——如果接口不稳定重试策略又没设上限一次故障可能烧掉一天的量。我的策略是每个任务最多重试三次指数退避三次都失败就落盘到失败队列等下次定时任务再处理绝不在当前轮次死磕。耗时方面串行处理五十篇大约要二三十分钟并发控制在五路能压到五分钟以内。并发数不建议开太高一是接口侧通常有限流二是并发太高时错误率会上升反而拖慢整体。我实测五到八路是比较舒服的区间再往上收益递减明显。6. 几个我踩过之后才想明白的细节这套东西跑到现在最有价值的体会都不是技术层面的而是边界层面的。第一条是机器只负责让信息变得可读不负责判断信息对不对。我一度想让模型自动给每张卡打正确性评分试了两周放弃了。模型对内容正确性的判断力很有限它给高分的东西可能只是表述流畅。现在confidence字段只表示原文对该结论的支持是否充分不表示这个结论是否成立这个区分很重要混淆了就会盲目相信机器。第二条是自动化的价值不在于省时间而在于降低启动摩擦。以前我打开笔记库要先想今天该整理哪块现在打开就是一张待办表勾选就行。省下的不是整理的二十分钟是决定要不要开始的那份心理成本。这一点比任何技术优化都重要。第三条是一定要给机器划一块不能碰的地方。我的20_Topics目录机器只能追加链接不能改正文。这块自留地让我对这个库始终有掌控感不会觉得这是机器的东西。心理上的所有权决定了你还会不会长期用它。最后分享一个具体的做法。我在30_Index里放了一张本周变化页只做一件事列出过去七天新增和修改过的所有卡。每周日花十分钟扫一遍看到不认识的标题就点进去看看——这既是一次巡检也是一次复习。这个习惯坚持下来之后我发现机器生成的内容里确实有我需要的东西只是如果不主动回顾它们就会沉底。自动更新解决了内容会不会过时但解决不了你会不会去看后者还是得靠一点人为设计的仪式感。
我一直觉得个人知识库里最难的不是记下来而是记下来之后还有人管。我的笔记库里躺着几千条剪藏、摘录和半截想法真正被复用的不到百分之五。后来我把这套流程改造成机器负责整理、人负责判断的结构用 Obsidian 当底座用 WorkBuddy 这类自动化编排工具当不限时长的执行器把采集、清洗、摘要、打标、建双链、做索引这些体力活全交出去最后只留下一个需要我动手的环节——读和判断。这篇就完整讲一遍这个Obsidian LLM Wiki 自动更新个人知识库的方案从目录怎么切、frontmatter 怎么定、提示词怎么写、增量更新怎么去重到跑起来之后会遇到哪些坑全部按我能复现的标准写出来。适合两类人看一类是笔记库里已经积压了成百上千条素材、想一次性盘活的人另一类是刚搭好库、想从一开始就把自动化架子搭对、少走弯路的人。1. 为什么要把知识库交给机器维护方案选型与整体拆解1.1 手工知识库烂尾的三个真实原因绝大多数人的知识库不是建不起来而是建起来之后慢慢废掉。我复盘过自己前后三版笔记库烂尾的原因其实高度一致跟意志力关系不大跟流程设计关系极大。第一个原因是采集速度远大于整理速度。剪藏一条素材只要三秒把它读透、提炼成自己的话、挂到已有的知识节点上可能要二十分钟。这个剪刀差会持续放大最后库里百分之九十是未经处理的原料你每次打开都面对一堆待办久而久之就不想打开了。工具一旦让人产生负罪感它就死了。第二个原因是存和用之间缺一层转化。原始剪藏里混着作者的观点、案例、广告、错别字而你需要的是可检索、可引用、可对比的结论。这两者在结构上完全不同前者是长文本后者应该是带字段的短条目。很多人把这两类东西放在同一个目录里用同一套命名结果检索时噪音极大找一条结论要翻十条原文。第三个原因是双链和索引是纯手工劳动人一懒就断。双链的价值在于我以后能顺着这条线找回来但前提是每次新建笔记都老老实实挂链接。现实是写着写着就忘了半年后打开图谱一堆孤岛。至于索引页手工维护的索引页几乎必然滞后于内容最后变成一份过期目录。1.2 底座为什么锁定 Obsidian选底座这件事我的判断标准只有一条数据必须能被任意脚本直接读写且不依赖某个服务的在线状态。按这条标准筛下来Obsidian 几乎是唯一顺手的选择。它的库就是一个普通文件夹每条笔记就是一个.md文件路径就是层级文件名就是标题。这意味着我用 Python 写个脚本open()就能创建、修改、重命名笔记不需要走任何 API不需要处理鉴权也不会因为接口改版而崩掉。这一点非常关键——自动化流程最怕的就是中间某一环只有图形界面能做一旦某步必须人工点击整条链路就断了。第二个原因是 frontmatter。Obsidian 原生支持在文件头写 YAML 元数据而这些元数据又能被查询插件读取生成表格。这相当于给你的笔记免费配了一套轻量数据库正文是内容frontmatter 是字段。你可以在 frontmatter 里塞source、tags、created、confidence、status然后用一条查询把所有status: 待复核的条目拉出来。LLM 输出的结构化结果刚好能直接落进这些字段衔接得非常自然。第三个原因是双链语法极简。[[笔记名]]就是链接反链自动生成不需要维护任何索引表。脚本要建链只需要在正文里拼一个双方括号。这种零成本建链的特性是自动化的前提——如果建链需要三步操作机器也嫌烦。最后是可迁移性。纯文本加文件夹二十年后照样能读。工具会换代但md不会。我不想再把知识资产押在某个产品的生命周期上。1.3 WorkBuddy 在这条链路里到底扮演什么角色这里要先说清楚定位否则很容易把它当成另一个笔记软件那就用错了。WorkBuddy 这类工具的价值不在界面而在于它是一个能长时间挂着、能调模型、能执行脚本、能读写本地文件的编排器。它没有笔记界面也不需要。它就是我伸进文件系统里的一双手。为什么不让笔记软件自己的插件去调模型我试过问题有三个。一是插件运行在沙箱里长任务容易被中断处理五十篇素材跑到一半卡住前面的全白干。二是插件的并发能力弱串行调用模型五十篇要跑一个多小时。三是错误处理粗糙接口超时了它不重试直接给你留个空文件你还得自己找哪篇漏了。编排器做这些事就从容得多可以并发、可以重试、可以记录日志、可以断点续跑。所以这个方案的分工是清晰的Obsidian 负责存和看WorkBuddy 负责跑模型负责想。三者之间只通过文件系统交互耦合度极低。哪天你想换掉编排工具脚本一行不用改换个调度器照样跑。1.4 整体数据流一次自动更新要经过哪几站把整条链路拆开其实是七个环节。我把它画成一张职责表方便你对照自己的库看缺哪一环。环节职责输入输出常见故障采集汇总各类来源的原始素材剪藏、订阅、手记原始文件来源格式混乱清洗去广告、去导航、统一编码原始文件纯正文正文被误删切分按语义边界拆成块纯正文文本块句子被截断抽取调模型产出结构化知识卡文本块JSON/YAML输出格式跑偏落盘按模板写入 Markdown结构化结果笔记文件覆盖已有笔记建链生成双链、标签、索引页全部笔记关系网络死链、孤岛巡检找断链、过期、重复整个库待办清单无人处理这七站里前四站是原料到半成品后三站是半成品到可用资产。很多人的自动化只做到第四站就停了结果库里多了一堆格式漂亮的摘要但依然找不到东西——因为建链和巡检没做知识之间没有关系索引也不更新。还有一个设计上的取舍要说清楚整条链路必须是幂等的。同一篇素材跑两次结果应该一样或者至少不产生重复笔记。这决定了后面所有的去重设计。如果做不到幂等你就不敢让它定时跑只能人工盯着那自动化就失去意义了。2. 环境搭建先把地基打平2.1 软件与目录结构的最小可用配置我这套配置不需要复杂的插件组合先把核心几个装上就行。查询插件负责把 frontmatter 变成表格模板插件负责新建笔记时自动填字段版本管理插件负责给每次自动写入留一个回滚点。其余的花哨插件可以后加前期加了反而干扰排查。组件作用是否必需备注笔记客户端本体承载库与双链必需库放在本地磁盘查询类插件frontmatter 转表格强烈建议用来做索引页和待办页模板类插件新建笔记套模板建议保证字段一致性版本管理插件自动提交历史建议出问题能回滚编排工具调度与执行必需独立进程运行Python 运行环境跑处理脚本必需装两个依赖即可目录结构我踩过最大的坑是一开始分得太细。第一版我按主题分了二十多个文件夹结果每加一条素材都要纠结放哪儿纠结本身就是摩擦。现在我只用六层层级不超过两层KnowledgeVault/ ├── 00_Inbox/ 原始素材未处理 ├── 10_Cards/ 知识卡机器生成人工修订 ├── 20_Topics/ 主题综述页人工主导 ├── 30_Index/ 自动生成的索引与待办 ├── 40_Assets/ 图片与附件 └── 90_Archive/ 过期或合并掉的旧卡00_Inbox是唯一允许乱的地方任何来源的东西先扔这里不做任何整理。10_Cards是核心资产一个概念一张卡文件名就是概念名。20_Topics是我自己写的长文机器只负责往里插链接和更新最近变更区块绝不改我的正文。这个边界要划死否则你会有我的笔记被机器改乱了的不安全感。2.2 frontmatter 字段设计机器和人的契约frontmatter 是这套方案里最容易被低估的部分。它不是装饰而是机器和人类之间的一份契约机器按字段填人按字段查。字段设计得糙后面所有查询都会难受。我的字段表经过三轮删减现在保留这些--- title: 增量更新的去重策略 uid: kn-20240612-0031 source: 某技术博客/2024-06 source_hash: 9f2c1a7e tags: [知识管理, 数据处理, 自动化] type: concept status: reviewed confidence: high created: 2024-06-12 updated: 2024-06-12 related: [[[内容切分]], [[幂等设计]]] ---几个字段的设计意图值得单独说。uid是唯一标识格式是前缀-日期-序号它不随标题变化是去重和关联的锚点。很多人用标题当唯一键一旦改标题就全乱这是必须要避开的。source_hash存原始素材的哈希前八位用来判断这条素材是不是处理过。status只有三档draft机器生成的初稿、reviewed我人工看过并修订过、stale内容可能过期待复核。这个字段是所有巡检查询的入口。confidence是我加的一个比较主观的字段表示这条知识的可靠程度。机器抽取的东西不一定准尤其是需要推理的结论。标成low的条目在索引页里会单独列出来提醒我优先核对。这个字段救过我几次——有些模型脑补出来的关联一眼看过去很顺实际是错的。注意frontmatter 里的字符串如果包含冒号、井号、方括号必须用引号包起来否则 YAML 解析会失败整个文件的元数据都会读不出来。源地址这类字段最容易踩这个坑。2.3 模型接入与凭据管理调用模型这一步我只用一件事走标准的对话补全协议用通用的 HTTP 请求发出去。这样不绑定任何一家想换随时换。凭据绝对不能写进代码里也不能写进笔记里——笔记是会被同步、被分享、被版本管理记录的地方密钥写进去等于公开。我的做法是全部走环境变量脚本启动时读取export KB_API_BASEhttps://your-endpoint.example.com/v1 export KB_API_KEYsk-xxxxxxxx export KB_MODELyour-model-name编排工具那边配置定时任务时也是引用这几个变量名不落明文。如果你是多个人共用一个库还要额外注意自动写入的笔记里绝对不能带任何凭据、内网地址、个人身份信息。我在落盘脚本里加了一道正则过滤凡是匹配到密钥形态的字符串直接替换成占位符并记一条警告日志。这道过滤看起来多余但它拦住过一次我把调试信息误写进正文的事故。2.4 触发方式定时跑还是变化跑触发方式有两种各有适用场景我最后是两个都用。定时触发适合每天固定时间把当天的素材处理掉比如每天早上七点跑一次处理前一天积压的00_Inbox。好处是节奏固定坏处是如果你白天写了东西要等到第二天才处理。文件监听触发适合素材一进来就处理延迟低但要注意防抖。我试过没做防抖的版本一个文件从创建到写完内容会触发三次事件结果同一篇素材被处理了三遍虽然去重逻辑拦住了重复笔记但白白烧了三次调用。后来加了文件大小连续两秒不变才触发的判断问题解决。实际配置里我给监听加了一条白名单只监听00_Inbox其他目录的变化一律不响应。这条限制很重要否则机器生成的笔记写入10_Cards时会再次触发监听形成自激循环越跑越忙。3. 核心实现一条素材变成一张知识卡的全过程3.1 采集层先把输入源归一化采集这步看起来最简单实际上是整条链路里最脏的一环。来源不同格式差异极大网页剪藏带一堆导航和评论手写备忘没有标题复制粘贴的片段可能连出处都没有。如果不对齐格式后面的清洗逻辑就得写一堆分支判断越写越乱。我的处理原则是进00_Inbox之前先归一化。所有来源统一转成一个格式一个.md文件文件头三行固定是来源、采集时间、原始标题下面空一行再放正文。不管来源是什么都先转成这个形状。这一步我用一个很短的脚本做逻辑就是读入、抽取正文、拼头信息、写文件。归一化带来的好处在调试时特别明显出问题时你只需要看一个格式不用去想这次是网页还是手记。而且后续所有脚本都只认这一个格式扩展新来源时只需要加一个转换器主流程一行不用改。3.2 清洗与切分为什么必须先把长文切开这里要说清楚一个反直觉的点大多数人不切分直接把整篇丢给模型这是效果差的主因之一。原因有两个一个是上下文预算一个是注意力稀释。先算预算。中文文本按常见的分词方式一个字大约对应 1.5 到 2 个 token。一篇八千字的深度文章光正文就一万二到一万六千 token加上提示词模板、字段说明、示例输出很容易顶到两万。如果你的模型上下文窗口是十六 k直接就溢出了就算窗口够大成本也上去了。我做过对比同样一篇八千字的文章整篇丢进去抽取出来的知识卡字段完整度反而不如切成三段分别抽取再合并——因为长文本里信息密度不均模型容易只抓住开头和结尾。切分策略我用的是优先按语义边界切硬上限兜底。具体做法是先按标题层级切二级标题切一刀三级标题再切一刀如果某个块还是超过阈值就按段落切段落还超才按句子切。阈值我设在 1200 字这个数字是试出来的低于八百字模型容易缺少上下文抽出来的结论偏窄高于一千五百字单块的字段完整度开始下降。一千二左右是个平衡点。def split_blocks(text, soft_limit1200, hard_limit1800): # 先按标题切保留标题作为块的上下文 sections split_by_heading(text) blocks [] for sec in sections: if len(sec) hard_limit: blocks.append(sec) else: # 超长则按段落累加接近 soft_limit 就断开 buf for para in sec.split(\n\n): if len(buf) len(para) soft_limit and buf: blocks.append(buf) buf para else: buf buf \n\n para if buf else para if buf: blocks.append(buf) return blocks切分时有一件事必须做给每个块带上来源标题和前后文提示。我见过太多切分之后句子被拦腰截断模型拿着半句话去推断结论完全跑偏。我的做法是给每个块加一行前缀写明本文标题是 X本段属于第 N 部分并在块尾标注是否完结。这几个字成本极低但对抽取准确率的提升很明显。注意切分时绝对不要在代码块、表格、引用块内部下刀。我在第一版里没做这个判断结果一个代码示例被切成两半模型把后半段当成了独立的技术方案生成了一条完全错误的知识卡还在库里躺了两个月才被发现。3.3 提示词模板把总结改成结构化抽取这是整篇文章里最值得反复打磨的部分。很多人写的提示词是请总结以下内容得到的就是一段泛泛的摘要既不能检索也不能对比。我需要的不是摘要是带字段的结构化输出。思路上的转变是把模型当成一个填表员而不是一个写手。你要告诉它表有几列、每列填什么、不满足条件时填什么。模板我固定成四段结构角色与任务、字段定义、输出格式、禁止事项。字段定义里每个字段都要给一句解释和一个正例这是提升稳定性的关键。你是知识抽取助手。请从给定文本中抽取知识条目严格按下方字段输出 JSON不要输出任何解释性文字。 字段定义 - concept: 本条知识的核心概念名8 到 20 字名词性短语不要用完整句子。 - summary: 用你自己的话概括不超过 120 字不得直接复制原文超过 15 个字。 - points: 数组3 到 5 条每条是一个可独立成立的结论不超过 50 字。 - conditions: 该结论成立的前提条件若原文未提及输出 未说明。 - tags: 数组2 到 4 个从下列受控词表中选... - confidence: high / medium / low判断依据是原文对该结论的支持是否充分。 禁止事项 - 不得补全原文没有的信息宁可留空也不要推测。 - 不得输出 markdown 代码块包裹直接输出裸 JSON。 - 若文本不含任何可抽取的知识点输出 {skip: true, reason: ...}。这个模板里有三个设计是踩坑换来的。第一是禁止输出代码块包裹因为模型很喜欢用三反引号把 JSON 包起来解析时容易把反引号带进去导致失败。第二是不得复制原文超过 15 个字这是为了防抄袭式摘要——模型偷懒时会把原句原样搬过来那样知识卡就退化成原文碎片毫无价值。第三是skip出口没有这个出口模型面对一段纯广告也会硬编出三条结论。conditions字段是我最推荐加的一个。任何结论都有前提把前提显式抽出来能极大减少后续误用。比如某条性能优化的经验前提可能是数据量在十万条以内脱离这个前提去套用就会翻车。这个字段在别处很少见但用起来真的香。3.4 输出解析与落盘稳一点别信模型拿到模型输出之后第一件事不是解析是清洗。我遇到过的情况包括输出前后带一句好的以下是抽取结果、JSON 外面包了三反引号、字段名拼错、数组里混了字符串。所以解析必须写成防御式。import json, re, hashlib, os from datetime import date def parse_output(raw): # 去掉可能的包裹与前后缀只留最外层大括号 s raw.strip() s re.sub(r^(json)?, , s).strip() s re.sub(r$, , s).strip() start, end s.find({), s.rfind(}) if start -1 or end -1: return None try: data json.loads(s[start:end 1]) except json.JSONDecodeError: return None if data.get(skip): return None # 字段兜底缺字段的补默认值别让下游崩 for k in (points, tags, related): if not isinstance(data.get(k), list): data[k] [] data.setdefault(conditions, 未说明) data.setdefault(confidence, low) return data解析失败的处理策略比解析本身更重要。我的策略是最多重试两次仍然失败就落到待处理区并记日志绝不写入半成品。有些人为了跑通直接跳过失败项结果库里缺了几条你根本不知道缺的是哪几条后面排查成本极高。落盘时的文件名也有讲究。我用的格式是概念名.md但如果同名文件已存在不覆盖而是对比source_hash一致就跳过不一致就说明是新的来源在讲同一个概念这时追加一节其他来源并保留原有内容。这个逻辑保证了三件事重复处理不会产生垃圾、多个来源可以汇聚到同一张卡、我的手工修订永远不会被机器覆盖。3.5 双链、标签与索引页的自动生成知识卡写完了如果不建链它就是一座孤岛。自动建链的核心是找到这张卡应该连到哪张卡。我的做法分两步先做基础关联再做语义关联。基础关联靠标签共现。两张卡如果有两个以上相同标签就把它们互相挂上related。这个规则简单粗暴但有效因为标签本身就是受控词表共现次数高说明主题确实接近。语义关联则是在全部卡片标题里做一次相似度匹配取最接近的三张作为候选写进related但标注为待确认状态。后者精度不如前者所以我只让它做建议不直接确认为正式链接。索引页我是用一个模板生成的查询页不写死内容## 最近更新的知识卡 查询按 updated 倒序取 20 条 ## 待复核对列 查询status 为 draft或 confidence 为 low ## 孤儿笔记 查询related 为空且无任何反链这三块内容各有用途。第一块让我知道机器最近在忙什么第二块是我的工作队列第三块是断链预警。索引页不写死内容这一点很重要——写死的索引页必然过期而查询页永远是活的。3.6 增量更新用哈希指纹替代全量重跑不做增量这个方案在素材上到几百篇之后就跑不动了。全量重跑的代价不只是时间还有成本而且每次全量都会产生大量内容一致但需要判断是否覆盖的冲突人工核对量爆炸。增量的核心是给每篇素材算一个指纹。我用的是正文归一化之后的哈希去掉空白、去掉标点、转小写再算摘要。这样同一篇文章即使换了个网址、多了几行导航指纹也不变。指纹存在两个地方一个是素材文件的 frontmatter一个是知识卡的source_hash字段。处理前先扫一遍10_Cards里所有source_hash命中就跳过。def fingerprint(text): norm re.sub(r\s, , text) norm re.sub(r[。、,.!?;:\()\[\]【】], , norm) return hashlib.sha256(norm.lower().encode(utf-8)).hexdigest()[:16]这里有个坑要说指纹不能用原始文本直接算。我第一版就是这么干的结果同一篇素材在两个平台转载正文一样但排版不同指纹完全不同被当成两篇处理库里出现两张内容几乎一样、但uid不同的卡。后来加了归一化才解决。归一化的力度也要控制我把标点全去了但保留了段落结构因为完全去掉空白会让两篇不同文章碰巧撞哈希的概率上升——虽然极小但知识库里出现一次串内容就很难查。至于被修改过的素材怎么办比如某篇文章作者日后更新了内容。这种情况哈希会变会被当成新素材处理然后走到同名概念卡追加来源的逻辑追加一节而不是覆盖。我接受这个设计因为它保证了历史信息不丢失代价是同一张卡里可能有前后矛盾的表述——但这个矛盾是显式的比悄悄覆盖掉旧版本要好。4. 让它自己跑起来自动更新、合并与质量巡检4.1 变更检测与增量刷新自动更新这个词有两层意思一层是新素材自动进来另一层是旧知识自动刷新。前者好办后者才是真正决定这个库能不能长期用的关键。我的做法是给每张知识卡记一个updated时间然后设一个复核周期。周期性复核的逻辑是超过 90 天没动过的卡标成stale如果这张卡有对应来源就把来源正文重新读一遍和卡里现有内容做一次一致性比对发现明显差异就生成一条可能过期的提示插到待办索引页。这个提示不会自动改内容只提请我注意。一致性比对我不让模型做开放式判断而是问一个很具体的问题下面这两段内容是否有互相矛盾的表述如果有请指出矛盾点。开放式问这两段是否一致的准确率很低模型倾向于说基本一致等于白问。限定成找矛盾它才会认真挑刺。另一层刷新是标签体系演进。我一开始定的标签只有十几个后来慢慢加到三十多个早期生成的卡用的还是老标签导致查询漏掉。所以我加了一个标签归一的脚本定期扫全库把不在受控词表里的标签按映射表替换。这个脚本我只让它做替换不删除因为有些标签虽然不在词表里但确实有区分度。4.2 知识卡的合并与版本管理卡片越积越多必然出现重复概念。比如内容切分和文本分块讲的是同一件事可能被抽成了两张卡。合并这件事我试过全自动效果不好——模型判断这两个概念是否等价的阈值很难拿捏太宽松会把相关但不同的概念合并掉太严格又会漏。现在的方案是机器提议、人来定。脚本每天扫一遍用标题相似度和标签重合度筛出候选对写进一张合并候选.md的表格包含两边的标题、标签、摘要前六十字。我每天花两分钟过一遍勾选要合并的跑一个合并脚本。合并动作本身是全自动的正文拼接、去重、related合并、旧卡移到90_Archive并在原位置留一个重定向链接。版本管理这块我强烈建议开自动提交。理由很实际自动写入意味着你不可能每次盯着出了问题你需要一个明确的昨天这个时候是什么样的快照。我有一次提示词改错了一个字段名导致三百多张卡的名字全部变成了字段值如果没有版本历史那一天就得手工改回来。开了自动提交一条命令回滚。4.3 检索层全文够不够什么时候需要语义很多人一上来就想搞向量检索我的建议是先别急。Obsidian 自带的全文搜索配合 frontmatter 查询能覆盖九成以上的日常需求。你要找的是我记过的关于幂等设计的那条全文搜关键词就够了毫秒级返回。语义检索真正有价值的场景是你记得有个人讲过类似的意思但用的不是这个词或者你想找和当前这张卡主题相近的所有卡。这两种需求全文搜索确实无能为力。我的做法是给每张卡生成一个稠密向量存到本地文件做成一个轻量索引只在相关推荐这个场景里调用不作为主检索入口。这里有个成本核算要做。假设库里有五千张卡每张卡的摘要平均两百字全部算一遍向量大概要几十万 token一次性成本可以接受但增量更新时每新增一张卡就要算一次长期下来是持续支出。所以我的策略是只给reviewed状态的卡算向量draft状态不算——因为草稿内容可能还会大改算了也是浪费。4.4 质量巡检断链、孤儿与重复的三类体检自动化跑久了库会慢慢腐化。腐化的表现有三种链接指向不存在的笔记、笔记没有任何链接进出、同一概念有多张卡。这三种都能用脚本查问题在于查出来之后得有人处理所以巡检结果必须足够省事。我写的巡检脚本每天跑一次输出一张表检查项判定规则处理建议优先级死链双链目标文件不存在建空卡或改链接高孤儿卡无出链且无反链补标签或挂到主题页中重复卡标题相似度高于阈值进合并候选表中过期卡updated 超过 90 天重读来源做一致性比对低空壳卡正文字数少于 80删除或合并高这张表的价值在于处理建议这一列。如果巡检只告诉你有 47 个死链你还是不想动告诉它这 12 个是笔误可以直接改那 35 个需要建空卡动手成本就低多了。我甚至让脚本把笔误类的死链自动修掉只把需要判断的留给人。注意自动修死链时一定要做目标唯一性判断。如果改完之后可能匹配到多个文件宁可不动也不要猜。我吃过这个亏——一个模糊的链接名被自动指向了错误的卡表面上巡检全绿实际内容关联错了比死链更难发现。5. 常见问题与排查实录5.1 故障速查表跑了大半年遇到的问题基本能归到几类。整理成表出问题时按症状对号入座比从头读日志快得多。症状最可能的原因排查动作修复方式笔记生成了但内容全空模型返回被截断或解析失败看原始返回是否有闭合括号调大输出上限加重试同一素材反复处理指纹未归一化或状态没回写检查 source_hash 是否写入补写状态加已处理标记序号 uid 冲突并发写入同一计数器看日志时间戳是否重叠改用时间戳随机后缀frontmatter 读不出来值里有未转义的特殊字符打开文件看头部字符串统一加引号索引页一片空白查询语法或字段名拼错手动跑一次查询对齐字段名跑一半就停单次调用超时无重试看是否有超时日志加退避重试与断点续跑内容被机器改乱写入逻辑命中了人工修订区对比版本历史划出不可写区块成本突然翻倍全量重跑或切分粒度变细统计当日调用次数恢复增量检查切分阈值这张表里最值得展开的是内容被机器改乱和成本突然翻倍两条因为这两条最伤。关于改乱根本原因是脚本没有区分机器生成的区和人工写的区。后来我在每张卡里加了两个固定标记机器只写标记之间的内容标记之外一律不碰。这个约束写进脚本的第一行判断成了硬规则。关于成本我遇到过一次单日调用量暴涨八倍查下来是文件监听的自激循环——机器写入触发了监听监听又触发处理处理再写入。日志里能看到同一个文件被处理了十几遍。这类问题不会报错只会悄悄烧钱所以监控调用量是必须的。5.2 几个踩坑场景的复盘第一个坑是编码问题。中文内容里混着全角标点和特殊符号有些来源还带着不可见字符。我第一版脚本用默认编码写文件结果在某个平台上打开是乱码。后来统一成 UTF-8 并且在写入前做一次字符清洗把所有不可见控制字符去掉。这个坑的隐蔽之处在于在你自己机器上看一切正常换台设备才暴露。第二个坑是模型偶尔自作主张补充信息。提示词里明明写了不得补全原文没有的信息它还是会在conditions字段里编出个适用于大规模场景。我的应对是加一道校验把points和conditions里的每条内容拿去和原文做子串匹配匹配率低于某个阈值就标记为可疑。这个校验不能百分百拦住但能拦住大部分明显编造的内容。可疑的卡会进待办我看一眼就知道真假。第三个坑是并发写入的顺序问题。为了提高速度我开了并发结果两张卡同时读写同一个索引文件最后写的那次把前一次覆盖了索引少了十几条。解决办法很简单索引文件不并发写所有卡写完之后单独跑一次索引重建。这个原则后来扩展成了所有聚合类文件都不参与并发写。第四个坑是提示词改版导致存量不一致。我优化了一次模板字段含义微调结果新旧卡片的字段口径不一样查询时对不上。后来我给模板加了版本号写进 frontmatter 的schema字段查询时按版本号分组需要的时候批量重跑旧版本。这个字段平时没人看但改模板的时候是救命的。5.3 成本与耗时的控制方法成本这块我算过一笔账。假设每天新增素材五十篇平均每篇切成三段每段输入一千二百字约两千 token输出约八百字约一千二百 token单次调用合计三千二百 token 上下。五十篇乘三段就是一百五十次调用总计约四十八万 token。按公开价目区间估算一天的成本在几块钱以内一个月百元级别。这个量级对个人使用是完全可以接受的。真正会让成本失控的不是日常增量是三件事全量重跑、切分过细、失败重试无上限。前两个前面说过了第三个特别容易被忽视——如果接口不稳定重试策略又没设上限一次故障可能烧掉一天的量。我的策略是每个任务最多重试三次指数退避三次都失败就落盘到失败队列等下次定时任务再处理绝不在当前轮次死磕。耗时方面串行处理五十篇大约要二三十分钟并发控制在五路能压到五分钟以内。并发数不建议开太高一是接口侧通常有限流二是并发太高时错误率会上升反而拖慢整体。我实测五到八路是比较舒服的区间再往上收益递减明显。6. 几个我踩过之后才想明白的细节这套东西跑到现在最有价值的体会都不是技术层面的而是边界层面的。第一条是机器只负责让信息变得可读不负责判断信息对不对。我一度想让模型自动给每张卡打正确性评分试了两周放弃了。模型对内容正确性的判断力很有限它给高分的东西可能只是表述流畅。现在confidence字段只表示原文对该结论的支持是否充分不表示这个结论是否成立这个区分很重要混淆了就会盲目相信机器。第二条是自动化的价值不在于省时间而在于降低启动摩擦。以前我打开笔记库要先想今天该整理哪块现在打开就是一张待办表勾选就行。省下的不是整理的二十分钟是决定要不要开始的那份心理成本。这一点比任何技术优化都重要。第三条是一定要给机器划一块不能碰的地方。我的20_Topics目录机器只能追加链接不能改正文。这块自留地让我对这个库始终有掌控感不会觉得这是机器的东西。心理上的所有权决定了你还会不会长期用它。最后分享一个具体的做法。我在30_Index里放了一张本周变化页只做一件事列出过去七天新增和修改过的所有卡。每周日花十分钟扫一遍看到不认识的标题就点进去看看——这既是一次巡检也是一次复习。这个习惯坚持下来之后我发现机器生成的内容里确实有我需要的东西只是如果不主动回顾它们就会沉底。自动更新解决了内容会不会过时但解决不了你会不会去看后者还是得靠一点人为设计的仪式感。
