為什麼在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的視圖層，用於查看和管理我的存儲；以及對加載上下文的更細粒度控制。