为什么 ChatGPT 会遗忘你的设计系统
没有专门的文件存放它
编码 Agent 通过在每次请求时加载文件，解决了这一问题中“可用性”的那一半。这就是为什么 Cursor 遗忘你的编码风格 通常可以通过编写更好的规则文件来解决，以及为什么关于 Lovable 丢失你的设计系统 的相同抱怨可以通过知识文件来解决的原因。
ChatGPT 没有类似的途径。自定义指令是一个很小的全局区块——适用于两三个常驻规则，但不适合组件清单，而且无论你正在开发哪个产品，它都会应用到你所做的一切事情中。Project 会将附加文件限制在该 Project 的范围内，这在正常聊天中问一些快速问题之前确实有帮助。而记忆只有一两页。该产品中没有任何东西的形态是像设计系统那样的。
记忆存储的是关于你的散文，而不是关于你系统的结构化事实
这正是让情况比单纯缺失更糟糕的部分。自 2026 年 6 月记忆功能重构以来，ChatGPT 保留的是一份合成摘要——即系统得出的结论的陈述，并随着时间的推移保持更新——而不是你的原话。第三方对其容量的估计大约在 1000 多个单词或几百个条目左右；OpenAI 并没有公布具体数字，因此只需将其视为数量级参考即可。
对于保存偏好的小容量记忆来说，合成是正确的折中方案，但对于设计系统来说，这恰恰是完全错误的。Token 表很难被压缩。“间距比例为 4, 8, 12, 20, 32；没有 16”变成了“偏好一致的间距”。你所关心的特例恰恰是合成时被丢弃的细节，剩下的只是一种“感觉”（vibe），而不是约束。
你的 Token 是文档，而不是约束
在 2026 年，撰写关于 AI 辅助工作文章的设计系统从业者们得出了一个共同的诊断，而这其实与模型本身无关：在大多数组织中，Token 和组件契约只是作为期望人类遵守的文档而存在，而不是作为某种机制去检查的约束。聊天窗口中的任何东西都无法因为输出使用了调色板之外的颜色而拒绝该输出。
这意味着模型是在依靠记忆和善意来完成这项工作。即使它能完美地回忆起你的调色板，那也不是强制执行——它只是一个信息丰富的建议，由一个其训练数据中包含数百万个看起来都很合理的设计系统的模型提出。
偏离不仅发生在会话之间，也发生在单次会话内部
人们报告最多的失败案例是最令人困惑的那种：在同一个对话中，两个连续的 Prompt 之间一致性断裂。它在线程顶部生成的组件与它现在生成的变体不匹配，而没有人让它更改任何内容。
这就是长上下文（long-context）问题在特定场景下的体现。长输入中间的信息在使用时的可靠性低于开头或结尾的信息——这也是 ChatGPT 遗忘你在同一对话中早些时候说的话 背后的机制。你粘贴的 Token 列表位于顶部；到了第 40 条消息时，它处于输入中最弱的位置，模型便会用一些看起来合理的东西来填补这个空白。
凭空捏造的 Token 名称是最难捕获的错误类型
幻觉产生的 API 会报错。而幻觉产生的 Token 名称只是一个字符串。var(--color-brand-600) 会静默失败，或者回退，或者渲染出足够接近的效果以至于审查时被忽略。根据你的命名规范虚构出来的名称比随机名称更危险，因为它们看起来就像是你自己的一样。
这就是为什么团队将设计系统的偏离描述为“累积”而非“崩溃”：没有任何报错，单独看 Diff 都没问题，但六周后，产品中就出现了四种按钮样式。
人们尝试过的方法
每次都粘贴 Token 和组件列表。 有效，但会衰减。它在线程的前三条消息中效果最好，而且你必须为每次任务的粘贴付出代价。它还会促使线程变得极长，而这正是位置偏离（positional drift）发生的地方。
将核心规则放入自定义指令中。 对于少数关键约束（如间距比例、双字体规则、“绝不凭空捏造 Token”）来说，这是正确的做法。但由于该区块很小且是全局的，你必须在所有工作中挑选出最重要的五个事实，这虽然有用但并不完整。这也不同于设置了但未生效的指令，那是另一种失败情况。
创建一个附加了设计系统文档的 Project。 这是最好的内置选项：范围划分正确，保存的是真实的文档而不是转述。其局限性在于它仅限 ChatGPT 使用、上传的文件在长会话中会脱离上下文，并且对于你在 Project 之外提出的快速问题无能为力。
来自 Figma 的截图。 适合传达布局意图，但对名称毫无用处。一张按钮的图片无法告诉它你的 Prop 签名，更无法告诉它四个视觉上相似的按钮中哪一个已被弃用。
塞入系统的自定义 GPT。 这是一个进步，但难点在于维护：你的设计系统每周都在变化，而除非有人去更新，否则 GPT 的文件不会变。一个被自信应用的过时系统比没有系统更糟糕。
将 AI 连接到真实的组件库。 这是真正闭环的方向，值得大书特书，而不仅仅是作为一个脚注：当生成被限制在已存在的组件中时——通过同步的库、Code-Connect 风格的映射或设计系统 MCP 服务器——不符合规范的输出就不再是记忆力的问题了。如果你的团队能在这方面进行投入，请务必去做。这比聊天窗口能提供的任何东西都更持久。
上述列表中的规律是：所有有效的方法要么是强制执行，要么是检索。所有失败的方法都是靠重复来记忆。
解决方案：将系统交给 ChatGPT，将强制执行交给你的流水线
坦率地拆分这个问题，因为其中有一半根本不是记忆问题。
机械性的那一半属于你的构建（build）。 将 Token 编译到你的代码所消耗的产物中，这样不在系统中的值就无法解析。添加 Lint 规则来拒绝原始十六进制颜色、超出比例的间距以及未知的 Token 名称，并在 CI 中运行它们。保持组件库作为组件的唯一来源。Lint 规则不会遗忘，不会被一个看起来合理的名称所说服，也不在乎你的对话有多长。任何可以通过这种方式表达的内容，都应该通过这种方式表达——而不是放在记忆中。
无法强制执行的那一半需要是可检索的。 没有任何 Linter 知道为什么存在紧凑型表格变体、旧的模态框是在无障碍审计后被弃用的、某个模式因某种原因被拒绝了两次，或者两个看起来都合法的组件中哪一个是当前的。这些知识是散文式的，它们会发生变化，而且正是你目前正在反复解释的内容。它应该存在于你的助手在每次请求时都会读取的存储中，而不是存在于粘贴板缓冲区中。
MemoryLake 是针对这第二半部分的记忆层——将你的设计系统文档、Token 定义、弃用情况以及背后的决策存放在一个存储中，可通过 API 从 ChatGPT 读取，也可直接从支持 MCP 的工具（如 Claude 和 Codex）中读取。需要明确界限的是：它不强制执行任何操作，它也不是一个设计系统。你的流水线负责强制执行；而它负责使系统可用并保持最新。
步骤 1：创建 API 密钥
生成密钥并在大约 30 秒内发出你的第一次请求。将其保存在你的环境变量或机密管理器中，而不是粘贴到聊天窗口中。
步骤 2：上传你的第一批记忆
放入你目前正在粘贴的文档、图像和文件：实际定义的 Token 定义、组件 API 参考、带有日期的弃用列表、无障碍决策、被拒绝的模式及其原因。上传源文件而不是整理好的摘要——摘要正是“没有 16px 步长”变成“偏好一致的间距”的地方。
步骤 3：连接你的 AI 和 Agent
允许 Claude、Codex、OpenClaw 和其他 AI Agent 通过 MCP 或 API 访问记忆。ChatGPT 没有 MCP 客户端，因此需要通过 API 检索系统的相关部分，并将其注入到 Prompt、自定义 GPT 的指令或调用模型的日常工作流中。支持 MCP 的工具会直接读取相同的存储——这很重要，因为编写组件的 Agent 需要与设计组件的助手使用相同的系统。
这在实践中带来了什么改变
第一个区别是，凭空捏造的 Token 名称变得罕见，而那些漏网之鱼也会被捕获。检索在生成时提供真实的名称；Linter 在提交时拒绝任何其他内容。两者缺一不可，结合在一起便实现了闭环。
第二个区别是，线程不再需要变得很长。当系统随请求一起到达时，你不需要在开头塞入 3000 个 Token 的调色板并寄希望于它们能撑到第 40 条消息。短线程是模型最可靠的地方，而无需重新解释你的上下文正是让短线程变得可行的原因。
第三个区别是，弃用机制终于生效了。目前，你上个季度退役的组件仍然存在于模型的认知世界中——它看起来符合你的命名规范，它曾出现在你的代码库中，并且没有任何东西标记它已失效。带有日期和状态的记录是区分当前与历史的唯一依据，这也是为什么架构决策需要附带其原因才能保持约束力的原因。
而且它不再仅限于 ChatGPT。设计系统对编码 Agent 的约束力与对聊天窗口的约束力一样大，而一个在没有项目上下文的情况下启动的助手在每个工具中都是相同的问题。一个存储，服务所有读取者。
AI 与设计系统的最佳实践
强制执行机械性内容，检索上下文内容
数值、名称、比例和组件边界应放入 Token 和 Lint 规则中。基本原理、弃用、特例和被拒绝的模式应放入可检索的记录中。在任何一个方向上搞错这种拆分都是大多数挫败感的根源：团队试图对意图进行 Lint 检查，或者试图去记忆数值。
交付机器可读版本的系统
如果你的 Token 仅存在于 Figma 文件和幻灯片中，那么每个使用者（无论是人类还是模型）都在靠猜测。从单一事实来源生成的 JSON 或 CSS 产物是使强制执行和检索都成为可能的基础，也是此列表中杠杆率最高的事情。
用日期标记弃用并保留旧条目
从文档中删除已退役的组件会破坏你解释仍在使用它的代码的能力。将其标记为已弃用、注明日期，并指明替代组件。与代码库不一致且未注明设计系统日期的系统，比诚实说明“截至 7 月”的系统更糟糕。
将始终加载的内容限制在硬性约束内
无论你在每次请求中注入什么，都应该是那些会导致输出错误（而不仅仅是不合规范）的规则：间距比例、调色板、“绝不凭空捏造 Token 名称”。完整的组件参考属于检索范畴。在每个问题前都堆砌一堵设计系统历史墙会挤占问题本身的空间。
在请求代码之前，先要求返回名称
对于任何实质性的内容，让模型先陈述它计划使用哪些 Token 和组件，检查该列表，然后再让它生成。这是对五个名称进行 30 秒的审查，而不是仔细阅读 90 行 CSS，这能专门捕获“看起来合理的名称”这一失败情况。
不要让 AI 来定义系统
诱人的捷径是让模型提出 Token，然后将它的输出视为标准。这就是你最终得到一个无人决定的系统的原因。模型是你设计系统的消费者，而不是它的作者。
结论
ChatGPT 会遗忘你的设计系统，是因为该产品中根本没有地方可以存放设计系统。没有规则文件，自定义指令空间小且是全局的，Project 范围的文件，以及存储关于你偏好的合成页面而不是 Token 表的记忆。最重要的是，在大多数组织中，Token 是文档而不是约束——因此即使完美回忆也仅仅是一个信息丰富的建议。
解决方案是双管齐下的，且两边都不可或缺。编译你的 Token，对违规行为进行 Lint 检查，并将生成限制在已存在的组件中，因为 Lint 规则不会遗忘。然后将任何 Linter 都无法表达的部分——原因、弃用、特例、你已经拒绝的模式——存放在一个你的助手在每次请求时都会读取的存储中。这样，调色板就不再是你需要粘贴的东西，而是系统本身就知道的东西。