為什麼在AI時代組織知識很糟糕，以及我如何解決這個問題

在個人和職業生活中，我經常在AI聊天會話中度過大量時間，無論是頭腦風暴產品創意、學習將棋，還是構建新功能。然而，隨著使用AI的頻率增加，我開始遇到越來越多的挫折。我發現自己需要翻查對話記錄，才能找到用Claude想出的食譜；我也發現每次想重新討論某個話題時，都必須重新解釋一遍。我真正想要的是能夠儲存和組織來自Claude會話的上下文，並在需要時按需載入，但我很快意識到這比聽起來要困難得多。

我曾嘗試使用Claude Projects來管理營養計劃，但由於無法在聊天中輕鬆編輯專案檔案，這個方案對我並不可行。在Jolli工作期間，我通常將某個功能的所有相關上下文都儲存在一次Claude對話中，但這意味著每次都需要找到正確的對話，而且上下文在壓縮時還可能會被覆蓋。我也試過將所有內容儲存在Linear的問題中，但這相當於把為跟蹤開發問題而設計的工具用作個人上下文儲存。每當我試圖解決這個問題時，總會出現一些缺陷。我決定靜下心來，認真思考這個問題，併為自己找到一個解決方案。

我的第一個關鍵洞察是，部分矛盾源於工具將會話作為組織單位，但這與我們在頭腦中儲存資訊的方式完全不一致。人們有自己的大腦組織系統來管理知識和記憶，我們不會以與Claude的對話為單位來思考。這就是為什麼我常常記得一個食譜卻找不到它：在我的腦海裡，食譜被歸類為“營養”概念，而不是“第165次會話”。我想要的是一種與我的思維模型相一致的方式來組織上下文。

其次，我意識到為什麼將上下文載入到AI中如此令人沮喪，並且似乎總是無法正常工作。一個原因是，即使AI能夠讀取上下文本身，它也不瞭解其中任何元上下文。例如，即使它能讀取隊友的設計文件，它也不知道該文件可能已過時，不應被視為真相來源。即使它能讀取HTML模擬檔案，它也不知道我希望將其作為參考使用。另一個原因是，我無法直接告訴AI我想讓它讀什麼，而必須告訴它內容在哪裡。對於Linear問題，我必須給出確切的編號；對於檔案，我必須給出路徑，而且並非所有相關檔案都在倉庫中。我不以ID或位置來記憶事物，而是以它們的內容來記憶。我透過主題來記憶Linear問題，透過內容來記憶檔案。

接下來，我意識到為自己儲存的內容和為AI儲存的內容之間的關係。有些上下文我儲存僅是為了讓AI日後記住，而非為自己，但大部分（可能大多數）實際上是為了將來我和AI都能使用。在我的用例中，將AI記憶儲存與人類可讀的文件工具分開並無意義。人類和LLM消費相同的媒介——自然語言，因此一個可讀的工件可以同時服務於兩者。提供一種為自己儲存上下文的方式，同時也為AI提供了一種更輕鬆的檢索方式。RAG和向量儲存純粹是為AI記憶構建的，不適合人類閱讀；而Notion和Obsidian等文件平臺是為人類構建的，AI功能只是附加的。

最後，我意識到AI生成內容的一大痛點不僅在於其不準確，還在於你無法判斷其是否準確。LLM有一個壞習慣：既會推斷你從未說過的事情，也會自信地斷言它們只是猜測或憑空捏造的內容。在某種程度上這是不可避免的，隨著模型改進會有所好轉，但我至少想知道任何衍生內容的來源，以及對於生成的任何內容，它是已知確定的還是由AI推斷或猜測的。

據我所知，沒有AI工具能解決所有這些問題。因此，帶著這些想法，我想知道是否能自己構建一個基本版本。如今，做這樣的事情往往出奇地容易，因為很大程度上只需要依賴Claude技能，將AI同時作為介面和作業系統。我目標是加強AI與上下文之間的連線，並縮短用AI捕獲上下文然後重新載入的迴圈。我的MVP理念是保持最小化，自己使用，然後看看缺少什麼或不完整。這意味著一開始不引入自動捕獲、自動載入和自動上下文協調等功能。

基本版本僅僅是：使用資料夾作為“主題”，檔案作為“條目”，並透過CLAUDE.md確保Claude瞭解知識庫；一個create-item Claude Code技能，用於根據對話在知識庫中建立檔案及其元上下文；一個load-topic Claude Code技能，讓Claude讀取主題中每個條目的所有元上下文。

從那時起，我一直使用Claude Code作為主AI介面而非Claude網頁應用，並且每天都在使用這個知識庫（我甚至用它來幫助撰寫本文，因為我在這個專案上的所有工作都儲存在知識庫中）。我學到了很多關於它有幫助的地方和缺失之處，並且很期待繼續完善這個系統。接下來我想新增的功能包括：一個類似Obsidian的檢視層，用於檢視和管理我的儲存；以及對載入上下文的更細粒度控制。