我的AI協作工作流分享：WorkBuddy建Obsidian知識庫，Codex把開發過程寫進去

開發過程入面有兩個常見嘅痛苦：

代碼寫完咗，知識就唔見咗。

你花咗兩個鐘解決一個 bug，理解咗成個技術邏輯，但係只要唔寫文檔，呢兩個鐘嘅經驗就會永遠消失，等到下次需要嘅時候又要再嚟過。

手動維護文檔嘅成本太高。

大多數人唔係唔想記錄，而係記錄嘅成本太高——寫代碼已經夠攰，仲要再整理一次寫成文檔，中間嘅摩擦足以令大多數人放棄。

我解決呢個問題嘅方法係：等 AI 工具自動協作，每個工具做自己最擅長嘅嘢。

三個工具嘅分工：

WorkBuddy（騰訊嘅 AI 桌面智能體）喺呢套工作流入面扮演「知識管理員」嘅角色。

佢嘅核心能力係創建 Obsidian vault 裏面嘅頁面、更新索引、管理文件結構——呢啲原本要手動做嘅嘢，WorkBuddy 可以用自然語言指令嚟完成。

具體做法：

第一次設定好 vault 路徑之後，跟住嘅工作流係咁樣：

我：幫我創建一個 Obsidian 頁面，記錄今天研究的 RAG 技術方案
WorkBuddy：自動創建來源/RAG-2026-04-30.md，
包含技術方案、決策點、待驗證假設等結構化字段

WorkBuddy 會讀取 vault 結構，瞭解現有嘅知識庫組織方式，然後喺正確嘅位置創建文件。佢唔係隨便創建一個 markdown 文件就算——佢會：

關鍵：WorkBuddy 嘅靈魂文件（SOUL.md）入面可以注入哲學層，決定佢處理知識庫嘅判斷邏輯。例如「存續為體，形式為用」——知識庫嘅價值在於俾人用，唔係為咗完美而存在。所以佢唔會畀你生成一個太複雜嘅 schema，而係服務於可讀性。

Codex（OpenAI 嘅編程 Agent）喺開發過程中扮演「開發日誌寫入器」嘅角色。

Codex 有一個 MCP 插件機制，可以等佢連接到各種外部工具。如果設定好 Obsidian MCP Server，Codex 就可以喺執行開發任務嘅過程中，將關鍵節點直接寫入 Obsidian。

具體做法：

喺 Codex 嘅 agents.md 入面設定好 Obsidian vault 路徑同寫入規則，然後：

我：幫我用這個API重構用戶認證模塊，完成後整理一份開發記錄到 Obsidian
Codex：

呢個比手動寫開發日誌強喺邊？

手動寫 = 開發完咗再回憶 = 漏咗細節 = 最後變成「寫咗都冇人睇」

Codex 自動寫 = 開發過程中即時記錄 = 有具體上下文 = 下次遇到類似問題可以直接查

Obsidian 喺呢套工作流入面係「接收端」同「查詢端」。

佢嘅價值唔在於 AI，在於佢係純文字、本地儲存、唔依賴任何雲服務嘅知識庫。WorkBuddy 寫入去嘅資訊、Codex 記錄嘅開發日誌，最後都會沉澱喺 Obsidian 度，用 `[[雙向連結]]` 連埋一齊。

Obsidian 嘅核心價值：

呢套工作流行順咗之後，Obsidian 裏面嘅內容會隨住時間自然增長。每一次代碼提交、每一個技術決策、每一篇研究筆記——都會自動沉澱落嚟，形成可以查得到嘅知識資產。

場景：研究一個新嘅技術方案，由調研到代碼實現到知識沉澱

第一步：WorkBuddy 創建調研頁

我：幫我研究一下 RAG 和知識圖譜結合的方案，整理到 Obsidian
WorkBuddy：
→ 創建 來源/RAG+知識圖譜-2026-04-30.md
→ 填充技術背景、主流方案對比、關鍵問題列表
→ 更新 index.md 的相關索引

第二步：Codex 執行開發，同時記錄過程

我：用 Codex 實現 RAG + 知識圖譜的混合檢索
Codex：
→ 寫代碼、跑通 demo
→ 同時自動寫入：開發/RAG混合檢索-2026-04-30.md

第三步：Obsidian 沉澱，隨時可以查

我（之後某天）：RAG 混合檢索怎麼做的來着？
Obsidian：
→ 搜索「RAG」→ 找到調研頁 + 開發記錄頁
→ 通過雙向連結導航到相關概念頁
→ 完整還原當時的決策過程

適用：

呢套工作流令我意識到一件事：

知識管理唔係「記筆記」，而係設計資訊嘅流動路徑。

WorkBuddy 負責將外部資訊流入知識庫，Codex 負責將內部生產過程記錄入知識庫，Obsidian 負責令知識產生連接而唔係堆積喺文件夾入面。

三個工具各自做自己最擅長嘅嘢，協作起嚟比任何一個單獨用都要強大。

歡迎喺評論區講下你嘅 AI 協作工作流～

如果呢篇文章令你有收穫，唔好唔記得like、分享、推薦～

亦都歡迎關注我嘅公眾號，每日有 AI 最新資訊分享🦐

開發過程中有兩個常見的痛苦：

代碼寫完了，知識丟了。

你花了兩個小時解決一個bug，理解了一整套技術邏輯，但只要不寫文檔，這兩個小時的經驗就永遠消失在下一次需要的時候。

手動維護文檔的成本太高。

大多數人不是不想記錄，是記錄的成本太高——寫代碼已經夠累了，還要再整理一遍寫成文檔，中間的摩擦足以讓大多數人放棄。

我解決這個問題的方式是：讓AI工具自動協作，每個工具幹自己最擅長的事。

三個工具的分工：

WorkBuddy（騰訊的AI桌面智能體）在這套工作流裏扮演"知識管理員"的角色。

它的核心能力是創建 Obsidian vault 裏的頁面、更新索引、管理文件結構——這些本來需要手動操作的事情，WorkBuddy 可以用自然語言指令來完成。

具體做法：

第一次配置好 vault 路徑之後，後續的工作流是這樣的：

我：幫我創建一個 Obsidian 頁面，記錄今天研究的 RAG 技術方案
WorkBuddy：自動創建來源/RAG-2026-04-30.md，
包含技術方案、決策點、待驗證假設等結構化字段

WorkBuddy 讀取 vault 結構，理解已有的知識庫組織方式，然後在正確的位置創建文件。它不是隨便創建一個 markdown 文件就完了——它會：

關鍵：WorkBuddy 的靈魂文件（SOUL.md）裏可以注入哲學層，決定它處理知識庫的判斷邏輯。比如"存續為體，形式為用"——知識庫的價值在於被使用，不是為了完美而存在。所以它不會給你生成一個過於複雜的 schema，而是服務於可讀性。

Codex（OpenAI 的編程 Agent）在開發過程中扮演"開發日誌寫入器"。

Codex 有一個 MCP 插件機制，可以讓它連接到各種外部工具。如果配置好 Obsidian MCP Server，Codex 就可以在執行開發任務的過程中，把關鍵節點直接寫入 Obsidian。

具體做法：

在 Codex 的 agents.md 裏配置好 Obsidian vault 路徑和寫入規則，然後：

我：幫我用這個API重構用戶認證模塊，完成後整理一份開發記錄到 Obsidian
Codex：

這比手動寫開發日誌強在哪裏？

手動寫 = 開發完了再回憶 = 漏掉細節 = 最後變成"寫了也沒人看"

Codex 自動寫 = 開發過程中實時記錄 = 有具體上下文 = 下次遇到類似問題可以直接查

Obsidian 在這套工作流裏是"接收端"和"查詢端"。

它的價值不在於AI，在於它是純文本的、本地存儲的、不依賴任何雲服務的知識庫。WorkBuddy 寫進去的信息、Codex 記錄的開發日誌，最後都沉澱在 Obsidian 裏，用 `[[雙向連結]]` 連接起來。

Obsidian 的核心價值：

這套工作流跑順了之後，Obsidian 裏的內容會隨時間自然增長。每一次代碼提交、每一個技術決策、每一篇研究筆記——都被自動沉澱下來，形成可查詢的知識資產。

場景：研究一個新的技術方案，從調研到代碼實現到知識沉澱

第一步：WorkBuddy 創建調研頁

我：幫我研究一下 RAG 和知識圖譜結合的方案，整理到 Obsidian
WorkBuddy：
→ 創建 來源/RAG+知識圖譜-2026-04-30.md
→ 填充技術背景、主流方案對比、關鍵問題列表
→ 更新 index.md 的相關索引

第二步：Codex 執行開發，同時記錄過程

我：用 Codex 實現 RAG + 知識圖譜的混合檢索
Codex：
→ 寫代碼、跑通 demo
→ 同時自動寫入：開發/RAG混合檢索-2026-04-30.md

第三步：Obsidian 沉澱，隨時可查

我（之後某天）：RAG 混合檢索怎麼做的來着？
Obsidian：
→ 搜索「RAG」→ 找到調研頁 + 開發記錄頁
→ 通過雙向連結導航到相關概念頁
→ 完整還原當時的決策過程

適用：

這套工作流讓我意識到一件事：

知識管理不是"記筆記"，是設計信息的流動路徑。

WorkBuddy 負責把外部信息流入知識庫，Codex 負責把內部生產過程記錄進知識庫，Obsidian 負責讓知識產生連接而不是堆積在文件夾裏。

三個工具各自做自己最擅長的事，協作起來比任何一個單獨用都要強大。

歡迎在評論區聊聊你的AI協作工作流~

如果這篇文章讓你有收穫，別忘了點贊、分享、推薦～

也歡迎關注我的公眾號，每天有AI最新資訊分享🦐