为什么在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的视图层，用于查看和管理我的存储；以及对加载上下文的更细粒度控制。