为什么 ChatGPT 会忘记你的代码风格
聊天应用中没有任何东西能起到规则文件的作用
这就是全部的结构性差异，在讨论解决方法之前，这一点值得阐明。Cursor 自己的文档解释了为什么规则文件会存在：“大型语言模型在两次补全之间不会保留记忆。规则在提示词级别提供了持久、可复用的上下文。”
每个看起来能记住你风格的编程工具都在做这件事——在每次请求时，重新提供来自磁盘文件的相同文本。Cursor 读取 .cursor/rules，Claude Code 读取 CLAUDE.md，Codex 读取 AGENTS.md。这就是为什么 Claude 忘记你的代码风格 和 Cursor 忘记它 通常可以通过编写一个更好的文件来修复。
ChatGPT 没有这样的文件。你的机器上没有它在回答前会读取的路径。因此，让风格在其他所有工具中保持持久的机制在 ChatGPT 中根本不可用，而替代方案的容量都小得多。
记忆库的大小是为偏好设计的，而不是风格指南
ChatGPT 保存的记忆在设计上就很短——它随每个提示词一起携带，因此其大小是每次请求的成本。目前没有公布的数据；流传的估计认为总共大约有 1,200 到 1,400 个单词，或者大约 200 个条目，且彼此并不一致。就把它当成一两页纸吧。
一份真正的风格指南是放不进一两页纸里的。如果你尝试这样做，就会遇到上限：一旦记忆库满了，ChatGPT 就会停止添加新的长期事实，直到你删除某些内容——这本身就是一种令人沮丧的体验。OpenAI 在 2026 年 6 月 4 日宣布的重建记忆系统改善了这一点——一个能够随时间保持更新的可读记忆摘要，并且为 Plus 和 Pro 用户提供了两倍的容量——但将一两页纸翻倍依然不是一份风格指南。同样值得注意的是，较新的系统会合成而不是存储你的确切字句，因此表述精准的规范在返回时可能会被改写。
风格是一百个微小的决定，而不是一条指令
“遵循我们的代码风格”听起来像是一条指令。但它实际上包含：布尔值的命名、错误处理的形式、类型定义的位置、是否使用 barrel 导出、如何排序 props、何时需要注释、在不写循环时使用哪个工具函数、测试如何命名。
其中大部分从未被明确说明。你只有在看到违规时才会注意到它们——这意味着你的风格指南是在聊天中被逐步发现的，而且每次发现都只存在于你提出它的那个对话中。十次会话下来，ChatGPT 被告知了十个不同的规范子集，却一个也没记住。
粘贴的内容会逐渐退化
每个人最终都会选择在会话开始时粘贴一段规范块。然后它会变得越来越短。你是凭记忆输入的，而例外情况又是无聊的部分，所以第四周粘贴的内容就成了第一周精简后的一半。风格会发生漂移，因为你自己对它的重新表述也在漂移——这是手动重新解释上下文的常见版本。
有必要将此与一个临近的问题区分开来：如果你确实将规范放在了自定义指令中，但它们仍然被忽略了，那就是指令已设置但未应用的问题——这是另一种失败。本篇讨论的是根本不存在的规范。
人们尝试过的方法
自定义指令（Custom instructions）。 正确的第一步，对少数硬性规则确实有效。这个块很小，所以你必须选择最重要的五个规范，而且它适用于你的所有工作——如果你在公司写 Go，在家里写 TypeScript，这就不合适了。
保存的记忆（Saved memory）。 适用于两三个稳定的偏好（“我使用 TypeScript 严格模式”）。它不适合用来装指南，用风格规则填满它会消耗你本想用于记录关于你的其他信息的预算。
附加了规范文件的项目（Project）。 内置选项中最好的一个：范围限定在该项目中，没有全局溢出，并且是一份真正的文档而不是摘要。限制在于它仅限于 ChatGPT，在长会话中文件无法可靠地保持在上下文中，而且它对你在普通聊天中提出的快速问题没有帮助。
在指令中包含风格指南的自定义 GPT。 有效且是真正的进步，因为其指令比自定义指令块更长。现在你必须为每个项目维护一个单独的助手并记住使用它，而更新指南意味着要编辑一个 GPT。
每次会话都粘贴指南。 原则上可靠，实践中会逐渐退化，并且每次对话都会消耗 token。
Linter 和格式化工具。 针对所有机械化问题的专业答案，它理应获得首要推荐，而不是作为脚注——见下文。
解决方案：给 ChatGPT 一个每次都会读取的风格指南
首先将你的风格一分为二，因为其中有一半根本不应该出现在提示词中。
机械化的那一半属于工具。 引号风格、分号、缩进、导入顺序、行宽、尾随逗号以及大多数命名模式，都可以通过 Prettier、ESLint、Black、gofmt、rustfmt 或你所用语言的同等工具来强制执行——并将配置文件提交到仓库中。格式化工具是不会忘记的。如果你要求 AI 记住你的缩进偏好，你就是在把语言模型当成 linter 来用，而它的表现永远会比 linter 差。这是整篇文章中杠杆率最高的举措，而且它与记忆力毫无关系。
需要判断的那一半需要一个记忆层。 没有任何格式化工具能表达“我们不在服务层中使用继承”、“宁要命名辅助函数，也不要聪明的单行代码”、“我们允许在生成的 API 客户端中使用 any，其他地方都不允许”或“错误消息是面向用户的，请相应地编写”。这些是有原因的规范，而原因正是阻止它们被重新争议的关键。
这第二半才是应该放入 ChatGPT 每次请求都会读取的存储中的内容——而不是你重新输入的粘贴内容，也不是与它竞争的两页纸记忆预算。MemoryLake 就是为此而生的记忆层：你的规范文档存在一个存储中，在相关时被检索，并且也可以被 Claude、Codex 和其他智能体读取——因此风格指南不再是针对单个工具的产物。
一个坦诚的界限。可靠地提供规范可以提高它们被遵循的频率；它不能保证完全合规，因为模型是否根据它读取的内容采取行动属于模型行为。这正是为什么机械化的那一半要交给格式化工具的原因——对于任何你需要强制执行的事情，请使用具有强制力的工具。
步骤 1：创建 API 密钥
生成一个密钥，并在大约 30 秒内发出你的第一次请求。将其保存在你的环境中或机密管理器中，而不是粘贴到聊天中或提交到代码库中。
步骤 2：上传你的第一批记忆
放入保存你实际规范的文档、图像和文件：风格指南、“我们如何编写服务”文档、你团队争论时使用的评审清单、你认为堪称典范的代码示例。写明原因。没有原因的规范在第一次不方便时就会被推翻——无论是被模型还是被你。
步骤 3：连接你的 AI 和智能体
通过 MCP 或 API 授予 Claude、Codex、OpenClaw 和其他 AI 智能体访问记忆的权限。ChatGPT 没有 MCP 客户端，因此那里的路径是 API：检索相关的规范并将其注入到提示词、自定义 GPT 的指令或调用模型的日常工作流中。支持 MCP 的工具会直接读取相同的存储，这就是重点——一个风格指南，适用于所有助手。
这在实践中带来了什么改变
第一个改变是你的规范不再缩水。ChatGPT 看到的是文档，而不是你的回忆，因此第二十周的输出与第一周保持相同的标准。
第二个改变是指南能够正确地成长。当你在评审过程中注意到一个新的规范时，你会向文档中添加一行，而不是向一个即将结束的聊天中添加一句话。几个月下来，这就是真正的风格指南与口头记忆之间的区别。
第三个改变是评审变得有用。“这符合我们的规范吗？”只有在规范可检索时才有意义。目前，答案往往是通用的最佳实践——这也是为什么 ChatGPT 在没有项目上下文的情况下加入 会让它的代码评审显得既自信又答非所问的原因。
而且它不再特定于 ChatGPT。规范是你代码库的属性，而不是你助手的属性。一旦它存在于共享存储中，迁移到不同的工具就不会重新开始教学过程。
让 ChatGPT 保持一致风格的最佳实践
让 linter 成为它可以表达的任何内容的唯一事实来源
提交配置，然后让 AI 的输出接受它的检查，而不是由你的提示词来支配。这缩减了必须记住的内容，只留下真正需要判断的部分，并使违规行为变得可见，而不是引发争论。
将规范写成带有原因的规则
“使用尽早返回”是一种偏好，很容易被推翻。“使用尽早返回——此代码库中的嵌套条件曾导致两个生产环境 bug，因为遗漏了 else 分支”是一条带有防御理由的规则。原因也有助于你注意到规范何时不再适用。
包含一个示例，而不仅仅是文字描述
传达风格最快的方法是一个你认为正确的简短文件。模型从示例中泛化的效果比从形容词列表中泛化的效果更可靠，而且一个示例承载了你从未阐明过的数十个微小决定。
保持始终加载的部分尽可能小
无论每次请求中注入什么——自定义指令、简短的规范头部——都应该是你最常被违反的五条规则，而不是整个指南。其余部分属于检索。在每个问题前堆砌一堵风格规则墙会挤占问题本身的空间。
明确指出例外情况
每个真实的代码库都有“我们在 Y 情况下除外，其他都做 X”。未写明的例外情况是 AI 在完全遵循你声明的规则时看起来最错的地方——也是你最终反复纠正同一件事的地方，因为纠正措施从未写入指南。
结论
ChatGPT 会忘记你的代码风格，是因为在回答之前没有它会读取的文件。编程智能体通过在每次请求时加载规则文件来解决这个问题；聊天应用则提供了一个微小的自定义指令块、一个大小适用于偏好而非指南的记忆库，以及项目范围限定——你的规范最终只能存在于你上次解释它们的对话中。
解决方案是拆分，而不是单一的举措。将所有机械化的内容放入带有已提交配置的格式化工具和 linter 中，因为格式化工具不会忘记，而且语言模型在缩进方面的表现永远不如专门为此构建的工具。将需要判断的那一半——带有原因的规范、例外情况、示例——放入你的助手在每次请求时都会读取的存储中。这样，指南就不会再以你自身记忆衰退的速度退化，也不再属于单一的产品。