1. 為什么要在 Obsidian 里折騰自動(dòng)打標(biāo)簽這件事Obsidian 用久了的人都會(huì)遇到同一個(gè)瓶頸筆記越攢越多標(biāo)簽卻越來越亂。剛開始可能只有十幾個(gè)標(biāo)簽手動(dòng)敲一敲也就過去了等到筆記數(shù)量上了幾百上千你會(huì)發(fā)現(xiàn)兩個(gè)致命問題——一是新筆記經(jīng)常忘記打標(biāo)簽二是同一個(gè)概念被寫成了好幾種形式比如#AI工具、#ai工具、#AI-工具搜索的時(shí)候根本搜不全。我自己的庫里有段時(shí)間就是這樣光效率相關(guān)的標(biāo)簽就有七八個(gè)變體整理起來比寫筆記還累。這個(gè)項(xiàng)目的核心思路就是借助 Jev 模型的能力把給筆記打標(biāo)簽這件事從純手工變成半自動(dòng)甚至全自動(dòng)。具體來說就是讓模型讀一遍筆記正文理解內(nèi)容主題然后返回一組結(jié)構(gòu)化的標(biāo)簽建議再通過 Obsidian 的接口把這些標(biāo)簽寫回筆記的 frontmatter 或者正文里。聽起來不復(fù)雜但真正落地的時(shí)候涉及模型調(diào)用、API 密鑰管理、Obsidian 插件配置、標(biāo)簽規(guī)范化這幾塊每一塊都有坑。這篇文章適合三類人看第一類是 Obsidian 重度用戶筆記量已經(jīng)大到手動(dòng)打標(biāo)簽不現(xiàn)實(shí)第二類是想把大模型能力接進(jìn)自己知識(shí)庫的折騰黨第三類是對(duì) API 調(diào)用、標(biāo)簽體系設(shè)計(jì)感興趣的技術(shù)同學(xué)。哪怕你之前沒寫過一行代碼只要跟著步驟走也能把這套流程跑起來。我會(huì)把每一步為什么這么做講清楚而不是只丟一堆配置讓你抄。需要提前說明的是Jev 模型在這里扮演的是內(nèi)容理解 標(biāo)簽生成的角色它不負(fù)責(zé)存儲(chǔ)也不負(fù)責(zé)檢索真正的標(biāo)簽落庫還是靠 Obsidian 自己的機(jī)制。理解這個(gè)分工后面配置的時(shí)候就不會(huì)迷糊。2. 整體方案設(shè)計(jì)與核心思路拆解2.1 為什么選模型生成 本地寫入這條路線給筆記打標(biāo)簽市面上大概有三條路可走。第一條是純規(guī)則匹配比如關(guān)鍵詞命中就加某個(gè)標(biāo)簽優(yōu)點(diǎn)是快、免費(fèi)、可控缺點(diǎn)是死板同義詞、上下文、隱含主題它一概識(shí)別不了。第二條是純手工質(zhì)量最高但完全靠人肉筆記一多就崩。第三條就是模型生成讓大模型讀懂內(nèi)容再給標(biāo)簽靈活性和準(zhǔn)確度都上了一個(gè)臺(tái)階。我最終選第三條核心原因是標(biāo)簽這件事本質(zhì)上是個(gè)語義歸納任務(wù)而不是字符串匹配任務(wù)。一篇講如何用 API 批量處理文件的筆記規(guī)則匹配可能只抓到API和文件但模型能理解它其實(shí)屬于自動(dòng)化批處理腳本這幾個(gè)主題。這種理解能力是規(guī)則給不了的。那為什么是本地寫入而不是把標(biāo)簽存到云端因?yàn)?Obsidian 的整個(gè)哲學(xué)就是本地優(yōu)先你的筆記是純文本 Markdown 文件標(biāo)簽直接寫在文件里搜索、圖譜、Dataview 查詢?nèi)家蕾囘@個(gè)本地結(jié)構(gòu)。如果標(biāo)簽存在外部數(shù)據(jù)庫Obsidian 原生功能就用不上了等于自斷雙臂。所以方案定成模型負(fù)責(zé)想Obsidian 負(fù)責(zé)存。2.2 Jev 模型在這個(gè)流程里到底干什么很多人一聽到模型打標(biāo)簽就以為是讓模型直接改文件其實(shí)不是。Jev 模型在這里只做一件事接收一段筆記文本返回一個(gè) JSON 格式的標(biāo)簽數(shù)組。它不碰你的文件系統(tǒng)也不碰 Obsidian純粹是個(gè)文本進(jìn)、標(biāo)簽出的黑盒。這樣做的好處是解耦。模型換了、API 換了、甚至你哪天想換成別的模型只要輸入輸出格式不變整個(gè)流程不用動(dòng)。我試過把同一批筆記分別喂給不同的模型標(biāo)簽質(zhì)量確實(shí)有差異但因?yàn)榻涌谑墙y(tǒng)一的切換成本幾乎為零。具體調(diào)用的時(shí)候提示詞的設(shè)計(jì)是關(guān)鍵。我用的提示詞大致是這樣的結(jié)構(gòu)先告訴模型你是一個(gè)知識(shí)管理助手再說明請(qǐng)閱讀以下筆記內(nèi)容提取 3 到 8 個(gè)最能代表主題的標(biāo)簽然后強(qiáng)調(diào)標(biāo)簽用中文不要帶 # 號(hào)不要重復(fù)優(yōu)先使用已有標(biāo)簽體系里的詞最后附上筆記正文。這個(gè)優(yōu)先使用已有標(biāo)簽的約束非常重要否則模型每次都會(huì)造新詞標(biāo)簽體系永遠(yuǎn)收斂不了。2.3 標(biāo)簽體系設(shè)計(jì)軟標(biāo)簽和硬標(biāo)簽怎么配合熱詞里出現(xiàn)了軟標(biāo)簽這個(gè)詞這里正好展開講一下。所謂硬標(biāo)簽就是固定的、受控的、有明確層級(jí)的那一批比如#領(lǐng)域/編程、#類型/教程、#狀態(tài)/待整理。軟標(biāo)簽則是自由生長的、描述性的比如#踩坑記錄、#靈感。兩者各有用途硬標(biāo)簽負(fù)責(zé)結(jié)構(gòu)化管理軟標(biāo)簽負(fù)責(zé)細(xì)節(jié)檢索。我的做法是讓模型只生成軟標(biāo)簽硬標(biāo)簽由規(guī)則或者手動(dòng)控制。原因很簡(jiǎn)單硬標(biāo)簽一旦被模型亂改整個(gè)分類體系就亂了。比如模型可能把#領(lǐng)域/編程寫成#編程領(lǐng)域看著差不多實(shí)際查詢的時(shí)候完全對(duì)不上。所以硬標(biāo)簽必須鎖死模型碰不得。標(biāo)簽層級(jí)用斜杠表示這是 Obsidian 原生支持的#領(lǐng)域/編程/Python會(huì)自動(dòng)形成父子關(guān)系在圖譜和搜索里都能按層級(jí)過濾。這個(gè)設(shè)計(jì)在筆記量大的時(shí)候特別香你可以只看#領(lǐng)域/編程下的所有筆記也可以下鉆到#領(lǐng)域/編程/Python。2.4 整體數(shù)據(jù)流長什么樣把上面幾塊拼起來完整的數(shù)據(jù)流是這樣的Obsidian 里選中一篇或多篇筆記插件讀取筆記正文把正文和提示詞拼成請(qǐng)求發(fā)給 Jev 模型的 API模型返回標(biāo)簽數(shù)組插件解析 JSON去重、規(guī)范化、過濾掉硬標(biāo)簽然后把結(jié)果寫回筆記的 frontmatter 或者正文末尾的標(biāo)簽區(qū)。這里有個(gè)細(xì)節(jié)值得說寫回位置選 frontmatter 還是正文我建議放 frontmatter也就是文件頂部---包起來的那塊。原因是 frontmatter 是結(jié)構(gòu)化的Dataview 可以直接查詢而且不會(huì)污染正文內(nèi)容。正文里的標(biāo)簽適合那種隨手記的場(chǎng)景正式筆記還是 frontmatter 干凈。3. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)3.1 API 密鑰管理別把密鑰寫死在代碼里熱詞里那條unexpected status 401 unauthorized: incorrect api key provided報(bào)錯(cuò)幾乎每個(gè)接 API 的人都踩過。401 的意思很直白密鑰不對(duì)、過期了、或者根本沒傳對(duì)。但比報(bào)錯(cuò)更嚴(yán)重的是密鑰泄露如果你把密鑰硬編碼在插件源碼里一旦分享出去別人就能白嫖你的額度。正確的做法是把密鑰放在環(huán)境變量或者 Obsidian 的插件設(shè)置里。Obsidian 插件可以通過loadData()和saveData()讀寫插件配置密鑰就存在那里不進(jìn)版本控制。如果你是用腳本調(diào)用那就用.env文件加dotenv庫.env記得加進(jìn).gitignore。還有一個(gè)常見坑是密鑰格式。有些平臺(tái)的密鑰帶前綴比如sk-開頭復(fù)制的時(shí)候容易多帶空格或者換行。我建議拿到密鑰后先做一次trim()處理把首尾空白去掉能省掉一半莫名其妙的 401。提示密鑰輪換要養(yǎng)成習(xí)慣。定期在平臺(tái)后臺(tái)重新生成密鑰舊的作廢這樣即使某次不小心泄露了損失也是可控的。3.2 提示詞工程讓模型穩(wěn)定輸出結(jié)構(gòu)化標(biāo)簽?zāi)Ｐ痛驑?biāo)簽最大的不確定性在于輸出格式。你希望它返回[標(biāo)簽1, 標(biāo)簽2]它可能給你返回一段解釋文字或者帶 markdown 代碼塊的 JSON。解決辦法有兩個(gè)一是提示詞里明確要求只返回 JSON 數(shù)組不要任何解釋二是代碼里做容錯(cuò)解析用正則把 JSON 部分摳出來。我實(shí)測(cè)下來光靠提示詞約束還不夠穩(wěn)尤其是筆記內(nèi)容比較長的時(shí)候模型容易發(fā)揮。所以我在提示詞里加了一句如果無法確定標(biāo)簽返回空數(shù)組這樣至少不會(huì)瞎編。另外溫度參數(shù)temperature建議調(diào)到 0.2 到 0.3太低會(huì)死板太高會(huì)發(fā)散0.2 左右在標(biāo)簽任務(wù)上比較平衡。標(biāo)簽數(shù)量也要約束。不限制的話模型可能給你返回二十個(gè)標(biāo)簽等于沒打。我一般限制在 3 到 8 個(gè)這個(gè)區(qū)間既能覆蓋主題又不會(huì)太碎。如果筆記特別短比如只有一句話那就限制 1 到 3 個(gè)。3.3 標(biāo)簽規(guī)范化去重、大小寫、同義詞合并模型返回的標(biāo)簽不能直接用必須過一遍規(guī)范化。這一步是很多人忽略的但恰恰決定了標(biāo)簽體系能不能長期維護(hù)。規(guī)范化主要做四件事。第一是去重模型有時(shí)候會(huì)返回[API, api]這種得合并。第二是統(tǒng)一大小寫我建議英文標(biāo)簽統(tǒng)一小寫中文標(biāo)簽保持原樣這樣搜索的時(shí)候不用糾結(jié)大小寫。第三是去除特殊字符#、空格、標(biāo)點(diǎn)都要處理掉Obsidian 的標(biāo)簽不允許空格多個(gè)詞要用連字符或者駝峰。第四是同義詞映射維護(hù)一張映射表比如人工智能映射到AI機(jī)器學(xué)習(xí)映射到ML這樣標(biāo)簽才能收斂。這張映射表是長期資產(chǎn)越用越準(zhǔn)。我建議一開始就建一個(gè)tag-mapping.json每次發(fā)現(xiàn)新的同義詞就加進(jìn)去。用久了你會(huì)發(fā)現(xiàn)模型生成的標(biāo)簽越來越貼合你已有的體系因?yàn)樘崾驹~里帶了優(yōu)先使用已有標(biāo)簽而映射表又做了一層兜底。3.4 Obsidian 側(cè)的寫入機(jī)制寫回筆記有兩種方式。一種是通過 Obsidian 的 API 直接操作文件用app.vault.modify()方法這種方式實(shí)時(shí)生效但要注意別在文件被其他程序占用的時(shí)候?qū)憰?huì)沖突。另一種是直接讀寫文件系統(tǒng)用 Node.js 的fs模塊這種方式更底層但需要處理文件路徑和編碼問題。我推薦用 Obsidian API因?yàn)樗鼛湍闾幚砹寺窂?、編碼、緩存這些瑣事。寫入 frontmatter 的時(shí)候要注意 YAML 格式標(biāo)簽數(shù)組要寫成tags: [標(biāo)簽1, 標(biāo)簽2]或者多行列表。如果 frontmatter 里已經(jīng)有tags字段要合并而不是覆蓋否則會(huì)丟掉手動(dòng)打的標(biāo)簽。注意批量寫入前一定要先備份。我吃過一次虧腳本有個(gè) bug 把幾十篇筆記的 frontmatter 全沖了幸好有 Git 版本控制才救回來。Obsidian 庫建議用 Git 管理或者至少定期打包備份。4. 實(shí)操過程與核心環(huán)節(jié)實(shí)現(xiàn)4.1 環(huán)境準(zhǔn)備與依賴安裝先把基礎(chǔ)環(huán)境搭起來。你需要一個(gè) Obsidian 庫建議專門建一個(gè)測(cè)試庫來折騰別拿主力庫冒險(xiǎn)。然后確認(rèn)你的 Obsidian 版本支持插件開發(fā)桌面版都支持移動(dòng)版有限制。如果走插件路線需要 Node.js 環(huán)境建議 18 以上版本。初始化插件項(xiàng)目可以用官方的 sample plugin 模板克隆下來改改就行。核心依賴其實(shí)不多一個(gè) HTTP 請(qǐng)求庫Node 18 自帶 fetch不用額外裝一個(gè) YAML 解析庫比如js-yaml基本就夠了。如果不想寫插件也可以走腳本路線用 Python 或者 Node 腳本直接讀寫 Markdown 文件。腳本路線的優(yōu)點(diǎn)是靈活缺點(diǎn)是沒法實(shí)時(shí)觸發(fā)得手動(dòng)跑。我兩種都試過最后留在插件路線因?yàn)檫x中筆記點(diǎn)一下就能打標(biāo)簽體驗(yàn)順暢太多。4.2 調(diào)用 Jev 模型 API 的完整代碼下面這段是核心調(diào)用邏輯用 JavaScript 寫的可以直接放進(jìn) Obsidian 插件里。注意密鑰是從插件設(shè)置里讀的不要硬編碼。async function generateTags(noteContent, apiKey, existingTags) { const prompt 你是一個(gè)知識(shí)管理助手。請(qǐng)閱讀以下筆記內(nèi)容提取 3 到 8 個(gè)最能代表主題的標(biāo)簽。 要求 1. 標(biāo)簽用中文英文術(shù)語保持小寫 2. 不要帶 # 號(hào)不要有空格多個(gè)詞用連字符連接 3. 不要重復(fù)不要生成過于寬泛的標(biāo)簽 4. 優(yōu)先使用以下已有標(biāo)簽${existingTags.join(, )} 5. 只返回 JSON 數(shù)組不要任何解釋文字 6. 如果無法確定返回空數(shù)組 筆記內(nèi)容 ${noteContent}; const response await fetch(https://api.jev.example.com/v1/chat/completions, { method: POST, headers: { Content-Type: application/json, Authorization: Bearer ${apiKey.trim()} }, body: JSON.stringify({ model: jev-model, messages: [{ role: user, content: prompt }], temperature: 0.2 }) }); if (!response.ok) { throw new Error(API 請(qǐng)求失敗: ${response.status}); } const data await response.json(); const rawText data.choices[0].message.content; return parseTagsFromResponse(rawText); }這里的parseTagsFromResponse是個(gè)容錯(cuò)函數(shù)負(fù)責(zé)從模型返回的文本里摳出 JSON 數(shù)組。因?yàn)槟Ｐ团紶枙?huì)加 markdown 代碼塊標(biāo)記所以要用正則先清理一下。function parseTagsFromResponse(text) { const cleaned text.replace(/json|/g, ).trim(); const match cleaned.match(/\[[\s\S]*\]/); if (!match) return []; try { const tags JSON.parse(match[0]); return Array.isArray(tags) ? tags : []; } catch (e) { return []; } }4.3 標(biāo)簽規(guī)范化函數(shù)的實(shí)現(xiàn)拿到原始標(biāo)簽后過一遍規(guī)范化。這個(gè)函數(shù)把去重、大小寫、特殊字符、同義詞映射全包了。function normalizeTags(rawTags, mapping) { const seen new Set(); const result []; for (let tag of rawTags) { tag tag.trim().replace(/^#/, ).replace(/\s/g, -); if (!tag) continue; // 英文轉(zhuǎn)小寫 if (/^[a-zA-Z-]$/.test(tag)) { tag tag.toLowerCase(); } // 同義詞映射 if (mapping[tag]) { tag mapping[tag]; } if (!seen.has(tag)) { seen.add(tag); result.push(tag); } } return result; }映射表長這樣放在插件目錄下的tag-mapping.json里隨時(shí)可以改。{ 人工智能: AI, 機(jī)器學(xué)習(xí): ML, 深度學(xué)習(xí): DL, 自然語言處理: NLP, 大語言模型: LLM }4.4 寫回 Obsidian 筆記的完整流程寫回這一步要小心處理 frontmatter。我的做法是先讀文件內(nèi)容用正則匹配出 frontmatter 塊解析成對(duì)象合并 tags 字段再序列化寫回。如果文件沒有 frontmatter就在文件開頭插入一個(gè)。async function writeTagsToNote(app, file, newTags) { const content await app.vault.read(file); const fmRegex /^---\n([\s\S]*?)\n---/; const match content.match(fmRegex); let frontmatter {}; let body content; if (match) { frontmatter jsyaml.load(match[1]) || {}; body content.slice(match[0].length); } const existing Array.isArray(frontmatter.tags) ? frontmatter.tags : []; const merged [...new Set([...existing, ...newTags])]; frontmatter.tags merged; const newFm ---\n${jsyaml.dump(frontmatter)}---; await app.vault.modify(file, newFm body); }這段代碼的關(guān)鍵點(diǎn)是合并而非覆蓋。手動(dòng)打的標(biāo)簽是寶貴的不能被模型生成的沖掉。合并之后再去重保證不重復(fù)。4.5 批量處理的性能與限流單篇筆記處理很快但如果你有幾百篇要批量打標(biāo)簽就得考慮限流了。API 一般都有每分鐘請(qǐng)求數(shù)限制硬沖會(huì)被限流甚至封禁。我的做法是加一個(gè)簡(jiǎn)單的隊(duì)列每處理一篇就await sleep(500)也就是每秒兩篇這個(gè)速度對(duì)大多數(shù) API 都安全。另外批量處理的時(shí)候建議分批比如一次處理 20 篇處理完檢查一下結(jié)果沒問題再繼續(xù)。這樣萬一提示詞有問題損失可控。我一般會(huì)先拿 5 篇做測(cè)試確認(rèn)標(biāo)簽質(zhì)量滿意了再全量跑。5. 常見問題與排查技巧實(shí)錄5.1 API 報(bào)錯(cuò)速查表接 API 的過程就是和各種報(bào)錯(cuò)搏斗的過程。我把踩過的坑整理成一張表遇到問題直接對(duì)號(hào)入座。報(bào)錯(cuò)信息根本原因解決辦法401 unauthorized密鑰錯(cuò)誤、過期、格式不對(duì)檢查密鑰首尾空格重新生成密鑰400 maximum context length筆記太長超出模型上下文截?cái)喙P記或分段處理429 too many requests請(qǐng)求頻率超限加 sleep 限流降低并發(fā)500 internal error服務(wù)端臨時(shí)故障重試加重試次數(shù)和退避策略返回非 JSON模型沒按格式輸出強(qiáng)化提示詞加容錯(cuò)解析401 那個(gè)報(bào)錯(cuò)特別典型熱詞里那條incorrect api key provided: sk-svcac****就是密鑰不對(duì)。注意看它把密鑰前幾位打出來了說明請(qǐng)求確實(shí)發(fā)出去了只是密鑰無效。這種情況八成是復(fù)制的時(shí)候帶了空格或者密鑰已經(jīng)作廢。5.2 標(biāo)簽質(zhì)量不穩(wěn)定的排查思路有時(shí)候模型返回的標(biāo)簽很準(zhǔn)有時(shí)候又很離譜這種不穩(wěn)定最讓人頭疼。排查順序是這樣的先看筆記內(nèi)容本身是不是太短或者太雜內(nèi)容質(zhì)量決定標(biāo)簽質(zhì)量再看提示詞有沒有變化溫度參數(shù)是不是被改了最后看是不是命中了模型的偷懶模式返回了一堆泛泛的標(biāo)簽。我的經(jīng)驗(yàn)是筆記內(nèi)容少于 50 個(gè)字的時(shí)候標(biāo)簽質(zhì)量斷崖式下降因?yàn)樾畔⒘坎粔?。這種情況我建議直接跳過或者只打一個(gè)#待補(bǔ)充的標(biāo)簽等筆記寫完整了再處理。還有一個(gè)技巧是在提示詞里給幾個(gè)正例和反例。比如好的標(biāo)簽#API調(diào)用、#錯(cuò)誤處理不好的標(biāo)簽#技術(shù)、#學(xué)習(xí)。模型看到例子之后輸出質(zhì)量會(huì)明顯提升。5.3 標(biāo)簽體系膨脹的治理用了一段時(shí)間之后你可能會(huì)發(fā)現(xiàn)標(biāo)簽數(shù)量爆炸從幾十個(gè)漲到幾百個(gè)。這是自動(dòng)打標(biāo)簽的通病因?yàn)槟Ｐ涂傁矚g造新詞。治理辦法有三個(gè)。第一是定期審查每個(gè)月看一遍標(biāo)簽列表把低頻的、重復(fù)的合并掉。Obsidian 有標(biāo)簽面板能按使用頻率排序很方便。第二是強(qiáng)化映射表每次發(fā)現(xiàn)新的同義詞就加進(jìn)去讓規(guī)范化函數(shù)自動(dòng)合并。第三是限制模型的自由度提示詞里明確列出允許的標(biāo)簽范圍超出范圍的一律不要。我現(xiàn)在的做法是維護(hù)一個(gè)核心標(biāo)簽池大概 50 個(gè)左右模型只能從這個(gè)池子里選實(shí)在沒有合適的才允許造新詞。這樣標(biāo)簽體系能長期保持收斂。5.4 幾個(gè)我踩過的坑第一個(gè)坑是沒做備份就批量跑結(jié)果腳本 bug 把 frontmatter 沖了。教訓(xùn)是任何批量操作前先git commit一次出問題直接回滾。第二個(gè)坑是密鑰寫在了插件源碼里分享給朋友的時(shí)候忘了刪結(jié)果密鑰泄露。教訓(xùn)是密鑰永遠(yuǎn)走配置不進(jìn)代碼。第三個(gè)坑是提示詞里沒限制標(biāo)簽數(shù)量模型返回了 20 多個(gè)標(biāo)簽等于沒打。教訓(xùn)是約束要寫死在提示詞里別指望模型自覺。第四個(gè)坑是沒處理中文標(biāo)簽里的空格導(dǎo)致 Obsidian 識(shí)別不了。教訓(xùn)是規(guī)范化函數(shù)里一定要把空格替換成連字符。6. 進(jìn)階玩法與長期維護(hù)建議6.1 結(jié)合 Dataview 做標(biāo)簽驅(qū)動(dòng)的筆記看板標(biāo)簽打好了接下來就是怎么用。Obsidian 的 Dataview 插件可以根據(jù)標(biāo)簽自動(dòng)生成列表比如你想看所有#狀態(tài)/待整理的筆記寫一段查詢就行。dataview TABLE file.mtime AS 修改時(shí)間 FROM #狀態(tài)/待整理 SORT file.mtime DESC這樣你就有了一個(gè)動(dòng)態(tài)的待辦看板筆記打完標(biāo)簽自動(dòng)出現(xiàn)在列表里整理完把標(biāo)簽一改就消失。這種標(biāo)簽即狀態(tài)的用法比手動(dòng)維護(hù)清單高效得多。 ### 6.2 定期回顧與標(biāo)簽體系迭代 標(biāo)簽體系不是一次設(shè)計(jì)好就完事的它需要跟著你的知識(shí)結(jié)構(gòu)一起進(jìn)化。我建議每個(gè)季度做一次回顧看看哪些標(biāo)簽用得最多哪些從來沒用過哪些該合并。這個(gè)過程本身也是對(duì)知識(shí)的一次梳理經(jīng)常能發(fā)現(xiàn)一些被遺忘的筆記。 回顧的時(shí)候可以借助 Obsidian 的圖譜視圖標(biāo)簽節(jié)點(diǎn)的大小反映了使用頻率一眼就能看出哪些是核心標(biāo)簽?zāi)男┦沁吘墭?biāo)簽。邊緣標(biāo)簽如果長期不用就該考慮合并或者刪除了。 ### 6.3 把打標(biāo)簽接入日常工作流 最后說說怎么讓這套流程真正融入日常。我的做法是設(shè)一個(gè)快捷鍵寫完筆記按一下標(biāo)簽自動(dòng)生成確認(rèn)一下就行。另外在日記模板里預(yù)置一個(gè)待打標(biāo)簽的狀態(tài)每天結(jié)束時(shí)批量處理當(dāng)天的筆記。 這套流程跑順了之后打標(biāo)簽這件事基本不占用額外時(shí)間但帶來的檢索效率提升是巨大的。以前找一篇筆記要翻半天現(xiàn)在輸入標(biāo)簽一過濾就出來了。知識(shí)管理的價(jià)值很大程度上就體現(xiàn)在這種找得到的能力上。 我在實(shí)際使用中最大的體會(huì)是自動(dòng)化工具解決的是量的問題但質(zhì)還是得靠人。模型能幫你打標(biāo)簽但標(biāo)簽體系的設(shè)計(jì)、同義詞的映射、定期的回顧這些還是得自己上心。工具是杠桿不是替代品。把杠桿用好了一個(gè)人也能維護(hù)一個(gè)幾千篇筆記的知識(shí)庫而且越用越順手。