为什么领域知识在 Claude 中无处安家
首先，区分人们常混为一谈的三件事
混淆这些概念是大多数尝试失败的原因，因为它们各自属于不同的地方：
领域知识是在你所有工作中都保持不变的内容。例如理赔判定如何运作、"cohort"（队列）在你的领域与通用语境中的区别、约束每个项目的法规等。它的生命周期超越了任何单一项目，并会被不断复用。
项目知识是针对某项具体工作的材料——如规格说明书、数据集、合同。它是具体的，并会随项目结束而失效。这正是为什么 Claude 会遗忘你的项目知识中所讨论的情况。
内部规范是你们团队做事的方式——如格式、审核标准、命名规则。这同样有所不同，并在为什么 Claude 会遗忘你的内部规范中有所涵盖。
如果尝试将领域知识作为项目知识存储，你将不得不为每个项目维护一个副本。如果尝试将其作为指令存储，你很快就会达到设置输入框的上限。
账户级字段用于指引方向，而非存储文档
“给 Claude 的指令”（Instructions for Claude）确实是账户级别的：“你在此处添加的任何指令都将应用于你与 Claude 的所有对话。”而且官方文档中的示例对领域材料也算友好——Anthropic 将“你常用的术语或概念”和“你遇到的典型场景”列为可以放在这里的内容。
因此，一个精简的词汇表适合放在这里。将十个术语各用一行进行定义，是一个合理且未被充分利用的技巧。但语料库不适合放在这里。它是一个用于存放常驻指令的文本框，其中的每一个字都会随着你进行的每一次对话（无论什么主题）一起发送。如果把你的领域参考资料塞进去，你就会为了让某一个对话变好，而让所有其他无关的对话体验变差。
项目知识功能强大——但被封闭在单个项目中
项目知识是存放文档的正确容器，而且效果很好。“你上传到此空间的任何内容都将在该项目的所有对话中被使用”，并且在付费计划中，其容量可以扩展：“当你的项目知识接近上下文限制时，Claude 会无缝启用 RAG 模式，在保持回答质量的同时将容量扩大至多 10 倍。”文档中说明，Pro、Max、Team 和 Enterprise 计划均可使用这一增强容量。
问题出在第一个词上。项目“允许你创建独立的（self-contained）工作区，拥有各自的聊天记录和知识库”。“独立”是它们的核心设计——也是你的领域语料库无法存放在其中并服务于其他项目的原因。
项目记忆因同样的设计而被隔离
记忆功能也无法解决这个问题：“每个项目都有自己独立的记忆空间和专用的项目摘要，因此每个项目中的上下文都是专注、相关且与其他项目或非项目对话隔离的。”
而且，记忆本身并不是文档存储库。Claude 的记忆侧重于关于你的工作上下文——你的角色和职业背景、沟通偏好和工作风格、技术偏好和编码风格、项目细节和正在进行的工作。这很有用，但与“该行业的结算时间如何运作”属于完全不同的类别。
在同一领域还有两个较小的陷阱。上下文“除非被添加到项目知识库中，否则不会在项目内的不同对话之间共享”——因此，你在一个对话中解释的定义，在下一个对话中是无法使用的，即使在同一个项目内也是如此。而且，当你创建项目时，“为你的项目提供名称和描述（请注意，Claude 无法访问这些详细信息）”。将项目命名为 Insurance Claims — EU 对 Claude 没有任何提示作用。
将相同的文件上传到每个项目中是一种维护负担
这就是大多数人的做法，而且在第一天确实有效。但到了第三个月，你的法规摘要会分布在五个项目中，其中三个甚至早于法规修订版，你根本无法分辨哪个对话使用了哪个版本。知识并没有腐烂——只是你的副本产生了分歧。
人们尝试过的方法
在每次对话的顶部粘贴背景信息。 有效但无休无止。这就是如何停止向 AI 重复解释上下文中所描述的死循环。
将相同的 PDF 上传到每个项目中。 解决了访问问题，但导致了版本偏差。这也是人们最终陷入永远在重复上传相同文档境地的原因。
为整个领域创建一个庞大的项目。 这样一来，每个无关的任务都会共享同一个记忆空间和同一个摘要，你原本希望为客户工作保留的隔离性也就不复存在了。
在账户级指令字段中塞满参考资料。 这会将你的领域语料库应用到你的每一次对话中，包括那些关于日程安排的对话。
寄希望于通过聊天搜索来找到它。 搜索是按需进行的，且存在文档中说明的边界——项目内的搜索仅限于该项目。这是检索，而不是常驻知识库，这两者之间的区别至关重要：为什么 RAG 不是记忆。
等待记忆功能自动吸纳它。 记忆侧重于关于你和你的项目的与工作相关的上下文。它并非旨在吸收某个领域的参考资料，将其视为文档存储库会导致无形的知识遗漏。
解决方案：单一领域层，叠加项目文件
行之有效的结构是将始终正确的事实与仅对当前工作正确的事实分离开来，不再要求同一个容器同时承担这两项任务。
将项目知识留给项目材料。 不要违背这一点——这是正确的工具。规格说明、数据、合同、当前草案。在付费计划中，它会在需要时自动扩展，并且从 Google Drive 添加的文档会自动同步，因此你使用的是当前版本，而不是陈旧的上传文件。
在你的账户级指令中放入一个简短的词汇表。 包含 10 到 15 个你们领域特有用法的术语，每个术语占一行。Anthropic 明确将常用术语和典型场景列为该字段的合适内容。切忌将其写成 20 页的长篇大论。
为每个项目设定明确的范围，并将上下文放入其中。 每项工作对应一个项目，因为每个项目都承载着自己的记忆和摘要——请记住，项目名称和描述对 Claude 是不可见的，因此任何涉及范围界定的内容都应放入指令或知识库中。
然后，在任何项目之外，为领域本身提供一个归宿。 这正是 Claude 所不具备的部分，也正是 MemoryLake 的用武之地：一个保存你持久知识的记忆层，可供每个项目、每个普通对话以及你使用的其他工具读取。设置只需三个步骤。
步骤 1：创建 API 密钥
登录 MemoryLake 并创建一个 API 密钥。一个凭证即可连接你使用的所有工具。
步骤 2：上传你的第一批记忆
这里容易犯的错误是直接上传文档。可用形式 of 领域知识应该是提炼出来的，而不是被索引的——简短的条目，每条只包含一个断言，且表述清晰、易于核对。需要捕获的内容包括：
与通用含义不同的定义。 每个领域都有一些在内部具有特定含义的词汇。这些词汇比其他任何内容都更容易导致无形的错误，因为模型会非常自信地使用其通用含义。
规则以及产生这些规则的约束条件。 “结算周期为 T+2”是一个事实。“结算周期为 T+2，这就是为什么对账工作无法在当天完成”则是能够防止错误建议的知识。
边界与特例。 常规规则不适用的情况。这是价值最高、且最不可能在任何地方被记录下来的材料。
已被排除的方案及其原因。 你们领域已经放弃的方法。如果没有这些，每次新对话都会重新提出这些方案。
关键数据及其截止日期。 阈值、限制、费率。注明日期，这样陈旧的条目就会一目了然。
合理的提炼比例：一份 40 页的参考文档通常只能提炼出 15 到 30 个条目。如果你整理出了 200 个，那你是在抄写文档，而不是在提炼知识。
步骤 3：连接你的 AI 和智能体
连接你使用的工具。MemoryLake 可以通过 MCP 和 API 访问，因此原生支持 MCP 的智能体（包括 Claude Code、Codex 和 OpenClaw）可以通过指向 MCP 服务器进行连接，而其他助手则可以通过 API 读取相同的记忆。这样，无论你在哪里工作，你的领域层都是可读的，同时每个项目依然保留着各自的文件。
三个客观的局限性。这并不能取代项目知识——项目文件属于项目，而 MemoryLake 并不是一个文档管理系统。它只保存你或你的智能体写入其中的内容，因此步骤 2 是实打实的工作。此外，它也不是一个合规或数据保留系统。
这在实践中带来了什么改变
启动新项目不再意味着要重新构建领域认知。 开启新项目时，领域层已经可以被读取。你只需上传项目规格，而无需上传整个行业背景。
法规修订拥有单一事实来源。 当法规发生变化时，你只需更新一个条目，而不是去更新五个项目知识库（其中还可能包含三个陈旧的副本）。
项目隔离变得纯粹且实用。 你既能保持不同工作之间的隔离性，又无需付出重复解释的代价。
定义不再产生偏差。 在一个地方定义一次的术语，在每个项目和每个工具中都以相同的方式被使用。
你的其他工具也能继承它。 领域知识正是不同助手之间完全相同的上下文。一旦它脱离了 Claude，Cursor 和你的智能体就能读取相同的内容——正如知识工作者的跨工具记忆中所描述的架构。
领域知识的最佳实践
先分类，后存储。 区分领域、项目或规范。它们各自有不同的归宿和生命周期，混淆它们正是导致维护问题的根源。
提炼，而非上传。 文档是用来阅读的，而条目是用来检索的。两者的转化过程正是价值所在。
在规则旁边写明原因。 原因能让 Claude 处理你未曾预料到的情况，而孤立的规则做不到这一点。
为所有数据注明日期。 阈值和费率会发生变化。未注明日期的数据就是未来的错误隐患。
保持一个条目只包含一个断言。 冗长合并的条目检索效果较差，且当其中一半内容失效时，很难进行修正。
记录特例。 边界情况决定了回答是“看似合理”还是“完全正确”。
保持账户级词汇表精简。 它会随你的每一次对话一起发送。十个术语很有用；而一整个章节则是对无关工作的一种负担。
在领域发生任何变化后进行审查。 直接删除描述过去运作方式的条目，而不是在旁边添加注释。两个相互矛盾的条目比一个过时的条目更糟糕——这也是AI 记忆是什么以及不是什么中所探讨的普遍问题。
结语
Claude 拥有良好的上下文容器，但没有一个容器的形态契合领域知识。账户级指令字段用于常驻指引，并会随你的每一次对话一起发送。项目知识是存放文档的正确场所，并且与该项目的记忆一样，被封闭在单个独立的项目中。而记忆本身则侧重于关于你的工作上下文，而非你所处领域的参考资料。
因此，行之有效的配置是进行拆分。项目文件保留在项目中。简短的词汇表放入账户级设置。而领域知识——包括定义、规则、原因、特例以及已被排除的方案——则被一次性提炼到一个每个项目和每个工具都能读取的层中。在这种模式下，新项目启动时就已经理解了你的领域，而法规修订也只需编辑一个条目，无需再去搜寻五个副本。