为什么“Claude 遗忘了我的系统提示词”通常是范围问题
并非只有一个字段 —— 而是有四个，外加 API
Anthropic 的个性化概述中命名了它们："Claude 提供了几种个性化体验的方法：个人资料指令、项目指令和风格。" 加上 Team 和 Enterprise 计划的组织层级以及 API 的 system 参数，完整的图景是：
Instructions for Claude —— 账户级别。"指令是账户级别的设置，可帮助 Claude 了解 Claude 在回复中应考虑的通用指令，"并且"你在此处添加的任何指令都将应用于你与 Claude 的所有对话。" 通过点击左下角的个人头像缩写，然后选择 Settings（设置）来找到它。
Project instructions（项目指令） —— 范围限于单个项目。"这些指令仅适用于该项目内的聊天。"
Skills（技能） —— 按需启用。它们"为你与 Claude 的对话添加特定的行为或功能"并"定义你按需激活的可重复行为。"
Organization instructions（组织指令） —— 在你之上的层级设置。在 Team 和 Enterprise 计划中，管理员及以上人员可以设置"Claude 在你整个组织的所有对话中遵循的自定义指令。"
API system 参数 —— 唯一一个字面意思上被称为系统提示词的参数。
五个容器，五种行为。几乎每一个“它遗忘了”的报告，都是因为指令放错了容器。
你将它输入到了聊天中，而不是字段中
这是目前为止最常见的情况。你开启了一个对话，写了三段话来规定 Claude 应该如何表现，在这个对话中它运行得很完美。然后你开始了一个新聊天。
对话中的文本仅支配该对话。其中没有任何内容是长期的。它最终可能会间接影响 Claude —— 记忆（memory）确实会捕获"沟通偏好和工作风格" —— 但那是记忆在推断偏好，而不是在存储指令。如果你需要它每次都生效，就必须把它放进字段中。
它的设置层级与你工作的层级不匹配
账户级别的指令适用于你的所有对话。项目指令仅在项目内部生效。这两句话会产生两种相反的失败模式：
你在一个项目的指令中编写了它，然后却在另一个项目或普通聊天中工作。它根本不存在于那里。
或者，你在账户级别编写了它，并期望它在同样带有自身指令和自身知识库的项目中也足够有效。它确实在那里，但它正在与更具体的项目专属指令竞争。
一个值得对照你自己的账户检查的可用性说明：项目文档指出，项目"对所有用户开放，包括免费 Claude 账户的用户，"免费用户限制为五个；而个性化概述则将项目指令描述为付费专属。请打开 Settings 查看哪种情况适用于你，而不是凭空假设。
组织指令胜出，而你却看不到它
从你的角度来看，这确实是隐形的，而且文档中对此有精确的记录。关于这两个层级之间的交互："当两者都设置时，组织指令优先。如果个人指令与组织指令直接冲突，Claude 会倾向于组织级别的指令。" 给出的例子非常确切 —— 组织指令说"始终用正式的英语回复"会击败个人指令说"使用休闲的语气"。
而该表格的可见性列指出：组织指令仅对"管理员及以上"可见。
因此，在工作账户上，你的指令可能会被你无法阅读的文本持续否决。你的个人指令并没有被丢弃 —— "对于组织指令未涉及的任何内容，个人指令仍然适用" —— 但在任何直接冲突的点上，你都会输。对于一家规范 Claude 写作方式的公司来说，这是正确的设计；但这也是单凭个人最难诊断的原因。问问你的管理员设置了什么。
该层级的另外两个细节：组织指令上限为 3,000 个字符，并且"更改可能需要长达一个小时才能在各个 Claude 产品中生效。" 如果你的管理员刚刚更改了某些内容，等待是一个合理的步骤。
在 API 中，系统提示词不会被遗忘 —— 只会被遗漏
如果你正在调用 API，system 参数是请求的一部分。你在每次调用时都发送它，否则它就不存在：
message = client.messages.create(
model="claude-opus-5",
max_tokens=1024,
system="You are a helpful coding assistant specializing in Python.",
messages=[{"role": "user", "content": "How do I sort a list of dictionaries by key?"}],
)因为没有存储，所以没有什么可丢失的。在 API 上下文中，"Claude 遗忘了我的系统提示词"意味着代码路径停止发送它了 —— 比如新客户端、重试助手、流式传输分支，或者一个构建自身请求的框架。记录一次发送的有效载荷，你在一分钟内就会知道原因。
它加载了，但 Claude 仍然没有执行
这是最后一个真实存在的类别，Anthropic 自己也指出了这一点。关于指令优先级："指令优先级依赖于提示词级别的指令。在涉及直接冲突指令的罕见极端情况下，行为可能会有所不同。请测试你的指令以确认它们产生了你期望的结果。"
相关指南："如果你的组织指令相互冲突，Claude 可能无法可靠地遵循其中任何一个，"并且与 Claude 核心训练相冲突的指令将不会被遵循。指令是强上下文（context），而不是保证强制执行的配置文件。关于这一点的更广泛版本 —— 指令文件显得被忽略的四个截然不同的原因 —— 见为什么智能体忽略你编写的指令文件。
人们尝试过的方法
在每次对话的顶部重新粘贴指令块。 可靠且永久，意思是你会永久地重复这样做。
编写更长的指令。 长度并不是解决问题的杠杆，而且在组织级别，这会起到反作用 —— 这些指令会"包含在组织中每个人发送的每条消息中。"
将相同的指令复制到每个项目中。 在第四个副本与第一个副本产生偏差、而你记不清哪一个是最新版本之前，这种方法一直有效。
认为覆盖是一个 Bug 并提交反馈。 可以理解。如果你使用的是 Team 或 Enterprise 计划，在得出任何结论之前，请先与你的管理员核对。
将所有内容都放在账户级别。 然后 Claude 就会把你的代码审查标准应用到你的度假计划中。范围的存在是有原因的。
告诉 Claude “始终记住”该指令。 这是对记忆（memory）的请求，而不是指令字段。记忆可以保存偏好，但它不是一种强制执行机制。
解决方案：将每条指令放在其真正适用的层级
永久解决此问题的规则是一个分类规则，而不是设置的更改：一条指令应该属于它始终适用的最窄层级。
始终适用，无处不在 → Instructions for Claude。 你的头像缩写（左下角）→ Settings → Instructions for Claude。偏好的方法、你使用的术语、通用的沟通方向。保持简短且真正通用。
仅适用于某一项工作 → 项目指令。 打开项目，点击 "Set project instructions"（设置项目指令），编写并保存。Claude "将对该项目内的所有聊天使用这些指令。" 角色、工作流指南、该工作的要求。
仅在调用时适用 → 技能（Skill）。 你按需激活的可重复行为属于这里，而不是放在一个一直开启、与其他所有内容竞争的字段中。
由你的组织设置 → 询问你的管理员。 如果 Claude 在工作账户上总是与个人指令相冲突，则组织指令优先，且只有管理员及以上人员才能查看。一个问题可以省去一周的麻烦。
由你的代码发送 → 记录请求日志。 确认 system 存在于每条路径上。
这种分类解决了放置问题。但它无法解决第五个类别 —— 那些指令不断提及的长期知识。"遵循我们的内部风格"只有在内部风格处于 Claude 可以阅读的地方时才起作用，而指令字段是用于指导方向的，不是用于存放文档的。
这就是 MemoryLake 的作用：将你持久的上下文（context）和规范保存在一个你的助手可以读取的层中，独立于任何单一账户的设置。设置只需三个步骤。
步骤 1：创建 API 密钥
登录 MemoryLake 并创建一个 API 密钥。一个凭证即可跨越你连接的所有工具。
步骤 2：上传你的第一批记忆
将你的指令不断提及的实质内容写成简短的条目 —— 每个条目包含一个主张：
标准本身。 不是"遵循我们的风格指南"，而是具体的规则，以便它们是可以检查的。
每条规则背后的原因。 一条规则只能在一次对话中存活。"不要在发布说明中使用被动语态 —— 客服会在电话中大声朗读它们"则能在工具更换后依然存活。
词汇。 你的团队以特定方式使用的术语，并带有特定的含义。这可以免去你在每个项目中重新解释术语的麻烦。
你已经拒绝的内容以及原因。 这是一个没人记录却每个人都在重新争论的类别。
步骤 3：连接你的 AI 和智能体
连接你使用的工具。MemoryLake 可以通过 MCP 和 API 访问，因此 MCP 原生智能体 —— 包括 Claude Code、Codex 和 OpenClaw —— 可以通过指向 MCP 服务器进行连接，而其他助手则通过 API 读取相同的记忆。
三个真实的限制，其中第一个在这里最重要。记忆层不是强制执行机制。 它使你的标准可用；它不保证模型一定会遵循它们，上面提到的“已加载但未遵循”的类别依然真实存在。它也不会写入 Claude 的设置中 —— 你的指令字段仍由你自行管理 —— 且步骤 2 是手动的。
这在实践中改变了什么
指令变得简短，并保持简短。 方向性的内容放入字段；实质性的内容放入记忆层。指令字段不再是你粘贴文档的地方，而粘贴文档正是它们被忽略的主要原因。
组织覆盖不再神秘。 你仍然看不到它们，但一旦你了解了优先规则，一个莫名其妙的正式语气就变得可以解释了，解决方案是一次沟通，而不是一次调试。
跨项目的重复不复存在。 标准只需存在一次。项目指令只需指向该项目特有的内容。
你的标准比工具更长寿。 指令字段是针对特定供应商的。你写入 Claude 设置的内容在 Cursor 或 Codex 中并不存在 —— 但一个它们都可以读取的记忆层却存在，具体形式在在你的 AI 工具中设置统一的记忆中有所介绍。
“它又忘了”变成了一个两分钟的检查。 哪个字段、哪个范围、哪个层级。几乎总是这三者之一。
Claude 长期指令的最佳实践
在编写之前进行分类。 通用、项目范围、按需或组织。一次性做好这一点可以防止大多数重复发生。
保持指令字段仅用于指导方向，而不是存放文档。 告诉 Claude 如何表现；将参考资料保留在可以检索的地方。
在新对话中进行测试。 针对组织指令的文档建议同样适用于你的指令：保存后，开启一个新聊天并尝试几种不同类型的问题。
不要将 3,000 字符的限制一概而论。 该数字是专门针对组织指令记录的。不要假设它适用于你的个人字段，无论哪种情况，都不要把简短当成可有可无的。
在管理员更改后等待一个小时。 组织指令的更改"可能需要长达一个小时才能在各个 Claude 产品中生效。"
避免自我冲突。 两条相互冲突的指令可能会导致两者都不可靠。将你的字段从头到尾作为一个文档来阅读。
不要试图围绕安全行为进行指导。 这已被证明是无效的，不是一个值得投入精力的方向。
在规则旁边写下原因。 这正是让指令具有可移植性的原因，也是 Claude 机械应用规则与 Claude 将规则正确应用于你未预料到的情况之间的区别 —— 这一通用观点在持久记忆的真正含义中有所阐述。
结论
Claude 应用中没有可以被遗忘的系统提示词。只有账户级别的指令、项目指令、技能（Skills）、Team 和 Enterprise 计划中的组织指令，以及在 API 中你随每次请求发送的 system 参数。一条“消失”的指令几乎总是放错了这些位置之一，或者正在被你看不见的组织层级所否决，或者被输入到了一个已经结束的对话中。
将每条指令分类到它始终适用的最窄层级，保持这些字段简短，并将它们所指的实质内容 —— 标准、词汇、决定、拒绝 —— 移动到你的工具可以读取的层中。这样，指令字段说明 如何表现，记忆层保存 什么是真实的，两者都不必承担对方的工作。如果你的问题与其说是方向问题，不如说是 Claude 丢失了项目材料本身，为什么 Claude 会遗忘你的项目知识涵盖了这种情况。