我的 Obsidian AI 三層級工作流
更新于:2025-04-11 02:03:24

Matrix 首頁推薦 

Matrix 是少數派的寫作社區,我們主張分享真實的產品體驗,有實用價值的經驗與思考。我們會不定期挑選 Matrix 最優質的文章,展示來自使用者的最真實的體驗和觀點。 

文章代表作者個人觀點,少數派僅對標題和排版略作修改。

本文採用古法手作,從立意到觀點到文本都沒有任何 AI 參與,請放心閱讀。

這是一個 AI 顛覆一切的時代,AI 正在以前所未有的速度重塑人們的生活方式。吳恩達曾在演講中說,AI 會像 100 年前的電力一樣,為我們的生產方式帶來根本性的變革。這一預言似乎已經在知識管理這個小領域中實現了:在區區兩三年時間里,各種 AI 筆記和知識庫產品如雨後春筍一般成長起來,比如 Google 的 NotebookLM、騰訊的 ima 以及開源的 Cherry Studio 等等。它們之中每一個都或多或少被冠以過「革命性」、「顛覆性」這樣的形容詞,似乎 AI 的突進已經不容阻擋。

各家 AI 知識庫產品的體驗報告我暫時還沒動筆,不過細細觀察下來的話其實不難發現,這些產品的賣點基本上可以歸結如下:

  1. AI 總結、智慧寫作、生成腦圖(大語言模型最基本的功能);
  2. AI 搜索(由已經成熟的向量搜索技術支援);
  3. 知識庫問答(由 RAG 技術支援的功能)。

在我看來,這些產品對知識管理的改造尚還有提升空間,沒能很好地考慮現階段知識管理存在的痛點以及大語言模型的長處。早在 GPT 3.5 的時代,我就懷著 100% 的期望嘗試了當時的知識庫問答產品。我將我所有的筆記都存入知識庫供其閱讀,一開始我為一個能流利運用獨家知識的 AI 興奮不已,但是在新鮮感消失之後,其就陷入了無盡的閑置中。後來我承認,我其實不需要一個 AI 替我轉述我自己寫的內容。筆記知識庫問答對我來說是一個純粹的「偽需求」。

AI 到底如何真正改善知識管理?網上針對這個話題的討論不多。在這篇文章里我將介紹一下我的思考以及我的 Obsidian AI 工作流方法。如果有不同想法或對你有所啟發,歡迎在評論區交流。

AI 能解決什麼樣的痛點?

打工人最深重的恐懼就是被 AI 取代,這其實剛好說明瞭現階段大語言模型的本質:模仿了一部分人類智慧,能夠完成一部分過去需要人力完成的任務。這側面反映了 AI 能解決的問題也就是過去需要消耗人力才能完成的任務。基於這個認識去尋找需求,才能找到真正的痛點。

回過來看之前那個案例,我們不難發現其荒謬之處:向 AI 詢問自己筆記中的內容,相當於是雇了一個人來替自己看筆記,然後把其中的內容二手轉述給自己。可是我作為內容的作者,我真的需要一個人來替我看自己寫的筆記嗎?

作為對比,文獻庫問答才是真正有價值的應用。大型文獻庫擁有海量的文獻,這些文獻可能來自不同語言,大概率不適合我閱讀。但是有時候我又需要快速從其中找到我需要的一小部分資訊,這時候我可能會想雇一個助理根據我的問題替我去文獻庫中搜索文獻,整理成報告後給我答案。正因如此,現在的知識庫問答產品抓住了「助理」這一定位,不局限於解析使用者自己寫的筆記,而是花大力氣去支援解析包含網頁、圖像、PDF、Docx 在內的各種各樣的文檔,力圖去成為那樣一個「文獻庫助理」。

基於這樣的思路,我們可以重新思考如何將 AI 結合進知識管理工作流中。按照對 AI 能力要求的不同,AI 的應用也可以分若干等級。接下我會先介紹一下 Obsidian 中的 AI 應用,然後從低等級開始,逐層展示我如何在知識管理中利用 AI。

Obsidian AI 入門

我一向使用 Obsidian 來完成知識管理以及寫作之類的任務。Obsidian 本體並沒有提供 AI 介面,但是有許多外掛程式都實現了 AI 功能。我們只需要安裝 Copilot 插件就可以使用丰富的 AI 功能了:

Copilot 支援的大模型服務很多,但是本身不提供任何大模型服務,都需要有自己的 API key 才能使用。

網上有很多教程教你如何部署自己的本地大模型,但是如果沒有保密需求的話,我還是推薦你直接購買別人的服務。拜 Deepseek 所賜,現在的 API 價格已經低到白菜價。這是在白天(北京時間 08:30-00:30)調用 deepseek 官方服務的價格:

考慮到一個 token 大約相當於 1.x 個漢字,而且僅需個位數人民幣就可以買到數以百萬計的 token。可以說購買 token 用來處理筆記基本上造不成什麼消耗。購買之後生成一個 API key,填入對應的地方點擊 verify 即可使用。 

回到主頁,點擊左側的圖示,右側就會出現一個你熟悉的 AI 聊天框,此時你就可以使用 Copilot 豐富的功能了。 `

為了方便,我將 Alt+Q 這個快捷鍵綁定到 CopilotL Apply custom prompt 這個命令上,方便後續調取自定義提示詞。

做好了這一切之後,我們就可以正式開始探索知識管理中的 AI 應用了。

基礎 AI 應用(語言級)

Copilot 自帶功能

大語言模型作為自然語言處理學科的產物,處理語言是其看家本領。基本的語言處理功能主要是這些:

  1. 語言潤色(語法、表達);
  2. 翻譯;
  3. 擴寫、縮寫

潤色和翻譯是最基礎而且也最實用的大模型功能,Copilot 已經直接提供。選中一段話之後,右鍵在功能表中選擇「fix grammar and spelling」或者「Translate to Chinese」即可調用這兩個功能: 

這些基本功能大多是圍繞語言優化方面的,很容易理解以及使用。其中 Emojify 是一個比較有意思的功能,其可以用 emoji 裝點乾巴巴的文本,使其看起來更加「活人」或者抽象。筆記軟體非常喜歡用 emoji 裝點主頁,GPT 在某個版本之後也很喜歡在回答中摻雜大量 emoji。

參考文獻引用格式轉換

語言級的應用看起來雞毛蒜皮,但是實際上可以解決很多過去很讓人煩惱的小問題。比如我寫了個用 Copilot 轉換參考文獻引用格式的提示詞,從此再也不用為轉換引用格式而發愁。將下述範本保存到 copilot-custom-prompts 資料夾下,用命令調用:

請將以下表示參考文獻的文字轉換為GB/T 7714 格式。要求: 1.  嚴格遵循目標格式的規範(如作者名縮寫、標題大小寫、標點符號等); 2.  保留所有原始資訊(作者、標題、期刊、年份等); 3.  若欄位缺失或格式模糊,請標註‘[需補充]’並保留原始內容; 4.  按目標格式的文獻類型(如期刊論文、書籍、會議論文)分類處理; 5.  直接輸出,不要有任何多餘文字。 示例輸入(BibTeX): @article{key,     author = {Author, A. and Coauthor, B.},     title = {An Example Title},     journal = {Journal Name},     year = {2023},     volume = {10},     pages = {100--120}   } 示例輸出(GB/T 7714): AUTHOR A, COAUTHOR B. An example title[J]. Journal Name, 2023, 10: 100-120.   待轉換的文字內容:   {}

不過需要注意的是,我這裏的參考文獻格式僅僅用於筆記內,對格式要求並不嚴格,因此我並沒有寫一個很長的提示詞來精確控制生成效果。如果需要生成精準的引用格式,你需要在提示詞中添加更多規則來指導 AI。

格式優化

沉浸式寫作筆記時我們往往會顧不得觀感,將高濃度知識寫成沒有格式的大段文字,不利於之後閱讀筆記。在過去,我們往往需要事後流覽全文再修改筆記,費時費力。現在這件事可以交給 AI 來完成。使用如下提示詞:

請將以下文字內容轉換為結構化的有序清單(1. 2. 3. ...),要求:   1. **邏輯分層**:按主題或步驟拆解,保持因果關係或時間順序;   2. **簡潔明確**:每點用 1-2 句概括,避免冗長;   3. **關鍵信息優先**:保留核心事實、結論或行動項,可以用**加粗**強調關鍵資訊   4. **若內容複雜**:可嵌套子清單。   待處理文字:   {} **範例輸出格式:**   1. 第一主題/步驟    1. 子要點(可選) 2. 第二主題/步驟   3. 第三主題/步驟  

選中一段文本,再按 Ctrl+P 打開命令面板,選擇 Copilot: Apply Custom Prompt 之後選擇對應的提示詞即可(或使用定義的快速鍵):

可以發現,經過分點、劃重點重新組織之後,文本的可讀性大大提高了。如果你喜歡乘著興致不拘小節地寫完整個筆記,但是又為筆記可讀性差為後續閱讀帶來困難所煩惱,那你可能會需要這一小功能來替你整理筆記內容。

中級 AI 應用(語義級)

語義級的應用不僅要求能夠正確使用語言,還要正確理解文章的意思。比較常見的語義級應用主要是 AI 總結(summarize)。AI 總結是一個應用很廣泛的功能,一般總是用來生成標題、摘要以及 tldr。

比如這是一個生成 tldr 的提示詞:

請根據以下筆記內容,分析並生成一段說明文本,解釋「為什麼會有這篇筆記」。要求: 1. **寫作目的**:總結這篇筆記的核心意圖,比如是為了記錄知識、解決問題、整理靈感還是其他用途。 2. **使用場景**:說明在什麼情況下可以參考或使用這篇筆記(例如學習、寫作、決策等)。 3. **語言風格**:簡潔清晰,避免冗餘,不需要生成格式和所需內容之外的任何文本,直接關聯筆記內容。 **筆記標題**:[[筆記標題]]   **筆記內容**:   {activeNote} **示例輸出結構**: > [!tldr] > 這篇筆記的目的是……(如:系統梳理XX領域的核心概念/記錄XX問題的解決方案)。   > 它可能在以下場景中發揮作用:……(如:當需要快速回顧XX知識時/當遇到XX類問題需參考步驟時)。

但是對於筆記用戶來說,AI 總結還可以解決一個知識管理長久以來的難題,即書寫元數據。

元數據生成

元數據,即用來記錄筆記各種屬性資訊的一組數據。在 Obsidian 中,元數據是一組用 YAML 格式書寫的、放在筆記開頭的屬性數據: 

元數據是知識管理的重要抓手之一,Dataview 檢索以及標籤檢索都需要依賴元數據。但是填寫元數據有時候是一件很費時費力費腦的事情。一個經典的場景是:你思如泉湧,想馬上記一個筆記;當你興沖沖打開一個新檔,你卻得先耐著性子填一個元數據表。

簡單的元數據表很容易填,複雜的就很費時費力。這是我的某個元數據範本: 

在這個元數據範本中,光是標籤就至少有三個(Functions、Projects、Techniques),其他欄位也不太適合用 templater 生成。經常出現的情況是,我填寫元數據的時間超過了寫筆記本身;當我終於寫好了元數據欄位,我的靈感早已消失不見了。

填寫元數據會給人造成壓力,久而久之就會讓記錄這一習慣難以為繼。因此,近些年「無壓筆記」的概念越來越流行。許多筆記軟體都宣導「打開軟體,然後開始記錄」,盡可能掃清橫亙在寫筆記之前的障礙,最好讓用戶在記錄之前連創建檔的工作都不需要做,從而保證使用者能把記錄的習慣保持下去。

相較 flomo 這類面向一般用戶的軟體,Obsidian 仗著自己的使用者普遍愛折騰、不怕麻煩,一直以來都對「無壓筆記」這一概念不甚熱心。但是由於 Obsidian 的元數據是純文本形式,這就給了我們操作空間去自己實現無壓筆記。我們可以:

  1. 先 Ctrl+N 新建檔,然後直接開始寫作;
  2. 寫作完成後,要求 AI 依據文章內容生成所有元數據

就這樣,我們一定程度上也就實現了 Obsidian 無壓記錄,大大減輕了記錄筆記的負擔。比如這是我寫好的筆記:

直接應用提示詞,生成元數據:

複製元數據內容直接粘貼在筆記頂部:

DeepSeek API 並沒有自動獲取日期的功能,因此日期仍然需要手動修改。

生成元數據是 AI 總結在知識管理上的一種應用。在生成元數據過程中,AI 需要總結文章內容,思考文章適合什麼樣的標籤、文章屬於的檔種類、文章是否結構完整以及檔名可能有什麼別名。若你的元數據中還有 title、description 這樣的欄位,則 AI 還需要根據文章內容總結合適的標題以及一句話描述。這一切都需要 AI 擁有理解文章內容並且抓住重點的能力,因此被歸類於中級(語義級)應用。這是本文案例使用的提示詞:

# 元數據生成助手 ## 任務描述 請根據提供的筆記內容,按照以下範本規範生成YAML格式的元數據。 ## 元數據範本 --- tags:  doc_type:  aliases:  finished: creation:  --- ## 生成規則 1. **tags** (標籤):  1. 按照 IAPR標籤法打標籤:   1. Area和Resource標記內容屬於的領域,每個筆記必須至少有一個;Area包含專業領域,比如人工智慧、數學、軟體工程、演算法、英語、科研等;Resource包含其他興趣領域;同一個領域不能同時屬於Area和Resource;   2. Area和Resource用三級標籤表示,第一級為Area或者Resource,第二級為大類,第三級別為具體細分領域,比如 `Area/數學/優化理論`,`esource/寫作/技巧`;   3. Area和Resource標籤可以有多個,你可以按照筆記內容總結並且生成,最後按照重要性排序。 2. **doc_type** (文件類型):     - 從以下類型中選擇最匹配的:      - 知識卡片:具體圍繞一個概念進行介紹的筆記,像維琪百科頁面一樣的筆記;比如筆記名稱為「Kubernetes」的筆記就是一個知識卡片;      - 文章:涉及多個概念的討論,或者教程,或者一個章節的課程筆記;      - 計劃書;      - 記錄:一些整理過的以及未整理的文字,一般是記錄了某些備忘資訊、日誌或者未經整理的實踐記錄; 3. **aliases** (別名):     - 提供1-3個替代標題     - 包含可能的縮寫或英文翻譯 4. **finished** (完成狀態):     - 默認設為 false     - 如果文章已經完整內容可設為 true 5. **creation** (創建時間):     - 自動生成當前日期,格式:YYYY-MM-DD ## 輸出要求 1. 只輸出最終的YAML格式元數據 2. 不要包含任何解釋性文字 3. 確保YAML格式正確 ## 示例輸入 筆記標題:[機器學習基礎](app://obsidian.md/%E6%9C%BA%E5%99%A8%E5%AD%A6%E4%B9%A0%E5%9F%BA%E7%A1%80) 筆記內容:介紹機器學習的基本概念、監督學習和無監督學習的區別,以及常見演算法概述。 ## 示例輸出 --- tags:     - Area/人工智慧/機器學習 doc_type: 文章 aliases:      - ML基礎     - Machine Learning Basics finished:  true creation: 2023-11-15 --- # 你的任務 請根據實際筆記內容生成元數據。筆記內容: {activeNote} 元數據:

高級 AI 應用(思想級)

思想級應用不僅要求 AI 能夠理解語言的含義,還要能理解語義背後的抽象規律,即我們說的「思想」。思想級應用對 AI 能力的要求較高,自行部署的小型模型就大概率不夠看,最好老老實實用 GPT-4o 或者滿血 DeepSeek 模型。

六經注我

一篇良好的議論文或者演講稿往往都會用引經據典的方式來佐證自己的觀點。但是對於文化程度有限的人來說,這件事有時候有些難做。這時候就不妨請出 AI 來幫忙,讓 AI 從經典中找出有利於自己的觀點的證據或者案例,使得文章內容更加充實。相比 AI 代寫這樣的濫觴,利用 AI 搜索證據並沒有減少你創作的參與度,這其實是對讀者和自己都負責任的做法。

使用提示詞直接讓 AI 根據自己掌握的知識就已經可以提供很完善專業的論據了:

提示詞:

請為以下文本提供支持性論據,要求論據類型明確、來源可靠,並標註具體出處。按優先順序排序,優先提供最契合的論據。 可以包含的論據類型(可多選):   □ 典故/歷史事件 □ 學術文獻 □ 名人名言 □ 統計數據 □ 案例研究 □ 其他(請說明_____)   輸出格式要求:   1. 每個論據單獨標註類型(如【典故】、【文獻】等);   2. 直接引用原文時用“引用標記”;   3. 註明出處(如書籍/論文/演講的標題、作者、年份);   4. 簡要說明該論據如何支持目標文本(1-2 句話)。   示例:   【文獻】   引用: "群體智慧在決策中常優於個體專家(Surowiecki, 2004)"    出處:《群體的智慧》,James Surowiecki,2004 年   支援邏輯:該研究直接驗證了目標文本中關於集體決策優勢的論點。   目標文本:   「 {} 」 論據:

蘇格拉底式討論

和搜尋引擎一樣,AI 也可以看作一個資訊來源。和傳統的資訊來源不同的是,AI 是互動式的,可以在討論中為你帶來真知灼見。儘管 AI 並沒有自己的實體,無法從實踐中獲得獨一無二的見解,但是討論本身就已經具有引導思考走向深入的效用,可以有效地幫助我們澄清以及提煉自己的想法。

討論流程主要包含以下四步:

  1. 向對方表達你的想法;
  2. 對方重述你的想法,對你的想法發表評論或者引出一個新的概念;在這個過程中,原來的觀點可能會被擴展或者受到挑戰;
  3. 你根據對方的回應,扩充或者修正自己的想法;
  4. 重複 1~3 步,不斷優化自己的想法。

這樣的討論方法和蘇格拉底宣導的很相似,因此我暫且將其稱之為「蘇格拉底式討論」。

蘇格拉底倡導的討論方法一向以可以給人帶來啟發而著稱。不過考慮到現實中我們往往很難找到具有相似知識背景、永遠有時間而且足夠耐心的討論夥伴,而人類又恰好是很容易因為信仰觀點不同而產生衝突的物種。因此參與一場這樣的討論對大多數人來說可望而不可及的。巧的是,大語言模型顯然剛好解決了上述痛點:

  1. 知識面極寬:了解幾乎所有領域的知識,不存在雞同鴨講的情況;
  2. 極有耐心:沒有情緒,任何時候都能保持溫和與禮貌;
  3. 冷靜客觀:由於數據是從整個互聯網上採樣得來的,如果不做主動要求,大模型的觀點基本上可以看作當下社會人們觀點的最大公約數,不存在偏見。

接下來我將以「AI 寫作」這一爭議話題為例,演示一下這套討論流程。這裡再次提醒:

雖然這是一篇介紹 AI 應用的文章,但是本文使用古法手作,從立意到觀點到文本都沒有任何 AI 參與。

此外,由於本人對保持英語能力有一定執念,會逼迫自己用英語和 AI 交流,因此本文從過去的聊天記錄中挑選得到的案例也用英語書寫。造成不便還望見諒。

我不是一個很喜歡討論技術倫理的人,對於「AI 寫作」,一開始我並沒有太多想法,因此我首先向 AI 徵詢建議: 

AI 列出了 AI 寫作的積極消極兩方面內容,最後拋出了自己的觀點:AI 屬於工具,只是使用者智慧的延伸,AI 創作的內容版權完全可以歸於消費者。

我認為這個思路很有意思,而且確實和現在國內的法律實踐相吻合。於是我開始追問觀點的源頭: 

AI 提到,這種觀點其實來源於「工具理性(instrumental rationality)」,即技術其實是人類身體的延伸,其代表人物是黑格爾和康得。以 OpenAI 為代表的許多公司都持有類似的觀點,但是也有一些思想流派有不同的見解。

將 AI 視作是打字機、語法檢查器這樣的寫作工具在我看來似乎也沒有問題。畢竟現階段的 AI 的輸出內容完全取決於使用者輸入什麼以及隨機數種子,說是用戶的創作也能講得通。但是問題在於 AI 擁有如此高的能力不完全是 AI 公司的功勞,訓練用的海量數據都是互聯網上的其他人創作的,但是這些人卻沒有從中獲益;此外,完全由 AI 創作的內容品質往往不過關,創作者享受了收益卻沒有對讀者負責。因此 AI 寫作才引起了如此大的爭議。於是我將這些思考返回給了 AI: 

AI 更加清晰地重述了我的觀點,然後列了一張表比較 AI 公司、用戶和公眾三方彼此的權利義務。從這裡可以發現,這三方裡面 AI 公司獲得了利潤,使用者享受了服務,而且可能通過服務獲利,只有作為 AI 的基礎的公眾沒有對應的收益。主要矛盾有兩點:

  1. AI 寫作普及之後,許多人用 AI 生成內容批量運營自媒體,使得低品質 AI 生成內容充斥互聯網,影響了公眾的互聯網使用體驗;
  2. 與此同時,公眾創作的內容被無償地供 AI 公司用於訓練模型,但是模型卻被閉源壟斷用於獲利。

分析清楚這些之後,很容易就可以得到一些建議解決方案:

  1. 對於 AI 寫作使用者:仍然可以獲取收益,但是要求其保障內容品質,保證內容對讀者負責,而非禁用 AI;
  2. 對於 AI 公司:使用公開數據訓練的模型必須進行一定的開源(開源權重、開源訓練方法等)或是分享其收益;避免有人損害開源以謀取私利。

到這裡,觀點似乎就開始有一些價值了。如果沿著這兩個方向深入下去調研,應該可以寫成一篇深度還不錯的文章。我們就這樣從無到有地利用和 AI 的討論獲得了新的見解。

結語

大語言模型作為第一個能讓大家看見「智慧」的產品,其龐大應用潛力可能遠還沒有被挖掘。我認為大模型真正的應用生態位應該是過去需要由助理代行的工作,基於這個思路,可以按照需要的智慧等級將 AI 應用分為三級:語言級、語義級、思想級。

我在本文中針對這三個級別都列舉並且實踐了一些 AI 應用。不過我相信這隻是大語言模型應用的冰山一角。本文案例更多應該作為拋磚引玉之用,希望在評論區看到你的見解。

我是@西郊次生林,一個研究自然語言處理的研究生,希望得到你的關注。