如何让 Claude 坚持你的代码风格 (2026)

记忆功能可能未开启，且存在两个不同的版本

首先检查你使用的是哪种体验，因为开关在每个版本中的位置不同。官方文档给出的测试方法是：如果你在 Settings > Memory（设置 > 记忆）中看到“Memory”，说明你使用的是新版体验；“如果你在 Settings > Capabilities（设置 > 功能）中看到 Memory，说明你使用的是旧版记忆体验。”

在新版体验中，记忆功能是需要用户主动开启的：导航至 Settings > Memory 并开启 Generate memory from chats（从对话中生成记忆）。该功能适用于“免费版、Pro 版和 Max 版计划的 Claude 用户”，适用于网页端、Claude 桌面端和 Claude 移动端，并且“目前不适用于 Cowork”。如果你使用的是 Enterprise（企业）计划，还有一个额外的限制——成员“只有在组织所有者为其组织启用该功能时，才能单独启用此功能”。

这两种体验在处理纠错时的行为也不同，这一点非常重要。新版体验“将记忆构建为一组按类别组织的分立条目”，并且“Claude 会在你聊天时实时读取、写入和更新这些条目，而不是按固定的每日日程进行”。旧版体验则是一个“每 24 小时更新一次”的摘要。在旧版中，你今天下午做出的风格纠正可能根本还没有写入记忆。

Anthropic 表示该功能正在逐步推广中，因此值得重新检查你使用的是哪一个版本，而不是凭空猜测。

项目记忆是独立的，这通常是问题的根本原因

这是最容易让人产生“但我已经告诉过你了”这种挫败感的边界。项目中的记忆会留在该项目中。非项目对话有其独立的空间。因此，在没有任何出错的情况下，你的风格可能会通过以下三种实际方式消失：

你在非项目对话中训练了它，然后开始在项目内工作。你在项目 A 中训练了它，然后打开了项目 B。或者你的团队为一个新服务启动了一个新项目，而它只能从零开始。

这些都不是 Bug——官方文档将这种隔离视为核心设计，旨在保持每个项目“专注、相关且独立”。但这意味着单凭记忆功能永远无法让你在所有工作中保持统一的代码风格。必须有一个权威的副本。

记忆源自你的对话，而非由你直接撰写

记忆是从对话中生成的。这很有用——意味着你不需要写任何东西——但这也是为什么最终保留下来的是 Claude 对你偏好的摘要，而不是你的风格指南。“使用 tab、宽度 4、绝不使用分号、仅使用命名导出、测试文件同目录放置”是一个规范。而记忆所保留的更接近于对该规范的一种印象。

还有两个类别在设计上是被排除在外的。无痕（Incognito）对话不会产生记忆：“开启此模式后，Claude 不会记住你的对话，因此它们不会保存到 Claude 的记忆或你的对话历史记录中。”而且，你在单次对话中提出且从未重复过的纠正，可能根本没有达到值得被记住的门槛。

别人的指令可能会覆盖你的指令

如果你使用的是 Team 或 Enterprise 计划，那么在你之上还有一个层级。组织指令允许“Team 和 Enterprise 计划中的管理员及以上人员设置自定义指令，供 Claude 在你组织的每一次对话中遵守”，并且优先级规定得非常明确：“当两者都设置时，组织指令优先。如果个人指令与组织指令直接冲突，Claude 会优先采用组织级别的指令。”

值得注意的一点是可见性限制：“只有管理员及以上人员才能查看或编辑”组织指令。因此，在组织级别设置的格式或语言标准可能会高于你的个人偏好，而你甚至看不到起作用的具体文本。你自己的指令“仍然适用于组织指令未涉及的任何内容”。关于哪个指令容器胜出的更广泛图景，请参阅如何防止 Claude 忘记你的系统提示词。

重复纠正并寄希望于它能被记住。 有时确实管用——这就是记忆功能的用途。但这种方式没有确认步骤，这也是为什么人们在三周后仍然无法确定的原因。

在每次对话中粘贴整个风格指南。 可靠但成本高昂，这就是如何停止向 AI 重复解释上下文中所描述的死循环。

将风格指南放入项目知识库中。 直觉是对的，但范围错了——它是按项目划分的，因此你需要维护 N 个容易产生偏差的副本。该问题的普遍版本请参阅赋予 Claude 永久的领域知识。

在个人指令中写下“遵循良好实践”。 太过模糊，无法执行。Anthropic 官方对指令的指导才是解决之道：“不要使用像‘保持专业’这样模糊的指令，而是要给出具体的指示，例如‘用正式的英语回答。不要使用缩写、俚语或表情符号。’”代码风格也需要同样的对待。

假设记忆可以替代 linter（代码检查工具）的工作。 格式化工具可以强制执行的格式化根本不应该作为提示词级别的请求。把指令留给工具无法做出的选择。

将团队规范和个人风格混为一谈。 它们属于不同的范围，有不同的归宿——团队方面的问题请参阅为什么 Claude 会忘记你的内部规范。

分三步走。第一步让记忆为你服务，而不是与你作对。第二步让重要部分变得确定。第三步让你无需再维护多个副本。

打开“记忆”面板并直接进行编辑。 这是人们常常忽略的一步。前往 Settings > Memory：“Memory 面板列出了 Claude 记住的关于你的所有内容，并按类别分组。选择任何条目即可查看其摘要和详细信息。要更改条目，请使用‘告诉 Claude 要更改或删除的内容’框。要完全删除条目，请选择‘删除’。”阅读里面关于你技术偏好的真实内容。纠正错误的条目。删除那个你在三月份就放弃了的项目的条目。

你也可以通过对话的方式添加记忆——告诉 Claude 你希望它记住什么，它就会在不离开对话的情况下进行更新。在旧版体验中，通过这种方式进行的编辑“将立即应用于你的下一次对话，因此你无需等待每日合成的运行”。

将不可妥协的规则放入指令中，而不是记忆中。 任何你认为属于代码审查（Code Review）意见的内容都应该写入你的个人指令中，并且要写得足够具体以便检查：“仅限函数式 React 组件，命名导出，无默认导出。测试文件同目录放置，命名为 *.test.ts。无分号。”记忆学习的是倾向；指令陈述的是规则。请记住 Anthropic 自己的警告——“指令优先级依赖于提示词级别的指令。在涉及直接矛盾指令的极少数边缘情况下，行为可能会有所不同。测试你的指令以确认它们产生了你期望的结果。”

让格式化工具负责格式化。 缩进、引号和行宽应该写在运行的配置文件中。将指令的额度留给工具无法决定的架构层面的偏好。

给规范一个唯一的归宿。 这是记忆和指令都无法解决的部分。记忆在设计上是按项目划分的。项目知识库在定义上也是按项目划分的。个人指令是一小段始终开启的文本，而不是一份文档。因此，一个真正的风格规范——附带原因的那种——最终要么被重复复制，要么无处安放。

这正是 MemoryLake 的用武之地：它将你的持久偏好及其原因保存在你的工具所读取的图层中，从而使每个项目和每个助手都能看到相同的版本。设置只需三个步骤。

步骤 1：创建 API 密钥

登录 MemoryLake 并创建一个 API 密钥。一个凭证即可通行于你连接的所有工具。

步骤 2：上传你的第一批记忆

简短的条目，每条只包含一个主张。以下是应该放在这里，而不是放在规则或记忆条目中的内容：

附带原因的风格选择。 “仅使用命名导出，因为我们的打包工具在摇树优化（Tree-shaking）时会遗漏共享包中的默认导出。”规则只陈述了前半部分。只有这样才能阻止该建议在尚未制定该规则的项目中再次出现。

与生态系统默认值不同的规范。 任何训练有素的模型直觉上合理但对你的代码库来说是错误的内容。这些是你在每个新项目中都会发现自己不得不给出的纠正。

你刻意拒绝的模式。 你尝试过但又撤回的抽象，以及原因。它不存在于任何配置文件或提交信息中，而每个新会话都会再次推荐它。

特定于你技术栈的词汇。 你所说的“服务（service）”、“处理器（handler）”、“模块（module）”——这些是你的审查意见中默认使用，但新智能体（agent）并不知道的词汇。

步骤 3：连接你的 AI 和智能体

连接你使用的工具。MemoryLake 可以通过 MCP 和 API 访问，因此 MCP 原生智能体（包括 Claude Code、Codex 和 OpenClaw）可以通过指向 MCP 服务器进行连接，而其他助手则通过 API 读取相同的记忆。实际效果是，你编写过一次的风格规范，与你编辑器的智能体读取的规范完全一致。

三个客观的限制。MemoryLake 不会编写你的 Claude 记忆条目或你的指令——这些是 Anthropic 的界面，你仍然应该正确设置它们，因为它们是在没有连接工具时引导对话的关键。它只保存你或你的智能体放入其中的内容，因此步骤 2 是手动的。而且这是上下文，而不是强制执行：对于格式化工具或 linter 可以检查的任何内容，配置文件才是真正的保障。

“它真的记住了吗？”变成了一个你可以直观查看的东西。 Memory 面板按类别列出条目。打开它，阅读技术偏好，纠正错误。无需猜测。

新项目不再是一个全新的开始。 项目记忆在设计上是隔离的，因此解决方法不是去对抗这种设计，而是将权威规范保存在项目可以读取的地方。

指令变得更短、更具体。 当推理过程存在于其他地方时，始终开启的指令块就可以重新变回少数几个足够具体、易于验证的规则。

你的编辑器和你的对话达成一致。 相同的偏好，既能被浏览器中的 Claude 读取，也能被你 IDE 中的任何智能体读取——这一形式在持久记忆的真正含义中有所涵盖。

团队标准和个人喜好不再发生冲突。 组织指令优先于个人指令，因此个人层级应该保留组织层级未涉及的内容，而不是与其竞争。

首先检查你使用的是哪种记忆体验。 Settings > Memory 表示新版；Settings > Capabilities 下的 Memory 表示旧版，其摘要每 24 小时更新一次。

每月阅读一次 Memory 面板。 条目可能会出错，而错误的条目比没有条目更糟糕，因为它会与你的指令产生冲突。

将规则写得足够具体以便验证。 “函数式组件，命名导出”是可检查的。而“遵循现代 React 实践”则不可检查。

绝不要依赖记忆来处理 linter 可以强制执行的事情。 将格式化放在配置文件中，让提示词来处理主观判断。

预料到项目隔离并为此做好规划。 在一个项目中训练的风格不会传导到下一个项目。将权威版本保存在所有项目之外。

记住无痕对话不会产生任何贡献。 如果你在无痕对话中费尽心思进行了解释，它并没有被保存下来。

在 Team 和 Enterprise 计划中，询问组织指令的内容。 它们具有优先权，且只有管理员及以上人员才能查看，因此神秘的覆盖可能有一个很平常的解释。

将原因与规则保存在一起。 附带合理解释的风格选择能够在新项目、新工具和新队友中存活下来。单凭规则本身是做不到的——普遍情况请参阅为什么智能体会忽略你编写的指令文件。

官方文档指出 Claude 的记忆功能可以捕获“技术偏好和代码风格”，因此最初的假设应该是该功能是有效的——而当它失效时，说明有特定的障碍阻碍了它。通常是以下四种情况之一：记忆功能已关闭或你使用的是旧版的 24 小时更新体验、你跨越了项目边界进入了独立的记忆空间、偏好被作为一种倾向被习得而非作为规则被陈述，或者你无法看到的组织指令优先于你的指令。

其中三个问题你可以在大约十分钟内解决。开启记忆功能，打开 Memory 面板并纠正其中的内容，然后将你不可妥协的规则移入写得足够具体、易于检查的指令中。第四个问题——项目隔离——是刻意设计的，没有任何设置可以关闭它。

这就是为什么风格规范本身需要一个存在于任何单一项目或工具之外的归宿：一次编写，附带原因，保存在一个所有工具都能读取的图层中。这样，一个新仓库、一个新项目或一个新智能体就能从你已经解释过的相同规范开始，而不是面对一张白纸和一次似曾相识的对话。