为什么 ChatGPT 会遗忘你的架构决策
决策是约束加上原因
“我们不在服务之间共享数据库”只是半个决策。另一半是因为迁移顺序曾导致两次停机，且负责该模式的团队无法把控每次部署。没有后半部分，前半部分就只是一个偏好——而偏好每次都会输给听起来合理的替代方案。
这正是架构决策记录（ADR）实践存在的原因：ADR 将决策与迫使其做出的上下文以及随之而来的后果结合在一起，这恰恰是因为团队不断发现，一个单纯的决策在面对新成员或新环境时是无法存活的。而助手在每次会话中都是一个新成员。
原因是被总结掉的部分
以下是让这种情况比普通遗忘更糟糕的机制。ChatGPT 保存的记忆在设计上就很短，因为它会随每个提示词一起携带。而且自 OpenAI 在 2026 年 6 月宣布记忆系统重构以来，你得到的是一个记忆摘要——一个关于系统对你得出的结论的合成记录，并随着时间的推移保持更新——而不是你所说内容的抄本。
对于保持小容量记忆的实用性来说，合成是正确的折中方案，但对于决策来说则是错误的。压缩“不要共享数据库，因为迁移顺序导致了两次停机”，自然输出的结果就是“偏好服务自有的数据库”。约束消失了；偏好留下了；而偏好是可以被推翻的。你得到的助手只会把你的架构半记不记地当成一种风格选择。
被拒绝的选项从未被记录下来
架构讨论中最有价值的内容是你排除掉的选项列表及其原因。这也是没有人记录的内容，因为在你排除某件事的那一刻，它显得显而易见，不值得写下来。
聊天工作流中没有任何东西能捕捉到这一点。因此，每季度都会提出相同的三个替代方案，每次你都要花 20 分钟重新推导为什么它们行不通——这就是助手反复提出你已经拒绝的想法背后的模式。
与编码智能体不同，它没有相应的文件
编码智能体通过在每次请求时加载文件解决了这一问题的可用性部分——这就是为什么 Cursor 遗忘架构决策 通常可以通过编写更好的规则文件来修复的原因。
ChatGPT 没有等效的功能。它在回答之前没有可读取的路径。自定义指令（Custom instructions）容量小且是全局的。项目（Project）的附件仅限于该项目。记忆只有一两页。这些都不是决策日志，因此你的架构只能存在于你上次讨论它的那个对话中。
决策会发生变化，而旧决策不会被撤回
无论你是否对其进行版本控制，架构都是有版本的。你在第三季度修改了租户模型，而在第二季度模型下完成的每个设计在当时都是正确的。基于聊天的工作流没有地方记录某个决策在某个日期取代了另一个决策——因此你最终无法解释自己过去的工作，而这正是 ADR 凭借其状态（status）字段旨在防止的失效模式。
人们的尝试
每次都重新解释一遍。 有用，但会退化。你是凭记忆重新陈述的，所以你在 9 月份输入的版本只是你在 7 月份制定的版本中比较有力的那一半——而约束则是无聊的那一半。
将核心决策放入自定义指令中。 对于两三个承重约束来说，这是正确的首选步骤，值得一试。但由于区块很小，你必须选择哪些决策最重要，而且它是全局应用的——当你处理多个系统时，这就不适用了。
将决策保存到记忆中。 对于几个稳定的决策来说还可以，但随后你会遇到两堵墙：空间耗尽——记忆已满并停止接受新条目——而且保留下来的是合成的释义，而不是推理过程。
附加了架构文档的项目（Project）。 最好的内置选项。范围正确，保存的是真实的文档而不是摘要。但它仅限 ChatGPT，在长会话中文件无法可靠地保留在上下文中，而且对于你在普通聊天中提出的快速问题没有帮助。
在仓库中编写 ADR。 这是专业的答案，应该明明白白地写出来，而不是被埋没：一个包含决策、上下文、后果和状态的、经过提交和评审的带编号的 docs/adr/ 目录，才是架构原理应该被保存的方式。它在人员离职后依然存在，可进行差异对比（diffable），且不依赖于任何供应商。如果你的团队还没有这样做，请开始吧——这比本文中的任何其他内容都更有价值。
差距在于，你仓库中的 ADR 对你实际用于思考的助手是不可见的。你写下了推理过程，但 ChatGPT 仍然看不到它，所以你只能把相关的 ADR 粘贴进来，或者更常见的是，你根本不粘贴。
解决方案：给 ChatGPT 一个它每次都会读取的决策记录
两个步骤，按此顺序进行。
即使是非正式的，也要以 ADR 的形式编写决策。 标题、状态、迫使其做出的上下文、决策、排除的内容、你接受的后果以及日期。形式比工具更重要——正是它让原因与约束紧密相连，而这正是本文所讨论的全部失效原因所在。“考虑过的替代方案”不是一个可选章节；它是阻止重新争论的关键部分。
然后让助手能够获取该记录。 不是粘贴——而是检索。一个助手在每次请求时都会读取的存储库，意味着决策会连同其原因、日期和被拒绝的替代方案一起，以你编写的原样（而不是合成后的内容）呈现。
MemoryLake 是为此构建的记忆层——将决策记录、约束和源文档保存在一个存储库中，可通过 API 从 ChatGPT 读取，也可直接从支持 MCP 的工具（如 Claude 和 Codex）中读取。因此，同一个决策可以同时到达设计对话、编写迁移的编码智能体以及 9 月份入职的工程师。
有两个界限值得说明。记忆层并不能取代用于团队治理的已提交 ADR——不在版本控制中的决策记录是无法评审的，而可评审性正是该实践的一半意义所在。此外，可靠地提供决策可以提高其被遵守的频率；但它不能保证助手一定会遵守它，因为那是模型行为。改变的是，约束及其原因现在是存在且最新的，而不是缺失或被转述的。
步骤 1：创建 API 密钥
生成密钥并在大约 30 秒内发出你的第一次请求。将其保留在你的环境变量或机密管理器中，而不是粘贴到聊天中。
步骤 2：上传你的第一批记忆
放入你的决策实际所在的文档、图像和文件：ADR、设计文档、导致约束的事件报告、某人编写且大家都同意的 RFC。上传源文件而不是整理好的摘要——摘要正是“因为两次停机”变成“偏好服务自有的数据库”的地方。
步骤 3：连接你的 AI 和智能体
允许 Claude、Codex、OpenClaw 和其他 AI 智能体通过 MCP 或 API 访问记忆。ChatGPT 没有 MCP 客户端，因此那里的路径是 API：检索相关决策并将其注入到提示词、自定义 GPT 的指令或调用模型的生命周期工作流中。支持 MCP 的工具会直接读取相同的存储库——这很重要，因为编写代码的智能体需要与设计它的助手相同的约束。
这在实践中带来了什么改变
第一个区别是被拒绝的选项会一直保持被拒绝状态。询问报表服务时，共享模式方法会以已被排除的状态返回，并附带停机历史记录，而不是被重新提出来。
第二个区别是设计对话的起点更高了。你不需要花前 15 分钟重新建立约束；而是直接把时间花在实际问题上。这种效应是累加的——记录中积累的决策越多，每次新对话继承的内容就越多。
第三个区别是被取代的决策变得清晰可读，而不是令人困惑。一个带有日期和状态的决策可以让你说出“该服务是在 8 月之前的租户模型下构建的”，而不是纳闷为什么它看起来不对劲。这是让过去的架构具有可解释性的唯一属性。
而且这不再局限于 ChatGPT。租户决策对编码智能体的约束与对设计对话的约束一样多，而一个在没有项目上下文的情况下启动的助手在每个工具中都是相同的问题。一旦记录保存在共享存储库中，它们就都会继承它。
AI 可用决策的最佳实践
务必写下迫使其做出的上下文
“我们对订单使用事件溯源（event sourcing）”会引发争论。而“我们对订单使用事件溯源，因为财务需要可重建的审计追踪，且之前标的可变状态设计未通过第一季度的审计”则终结了争论。上下文是将偏好转化为约束的关键，也是你凭记忆重新陈述时最先丢失的东西。
记录你拒绝了什么，而不仅仅是你选择了什么
每个替代方案写两行：它是什么，为什么不行。这是价值最高、写得最少的部分，也是防止同一个提案每季度重新出现的部分。如果你除了决策本身之外什么都不写，那就写这个。
为所有内容标注日期并保留被取代的决策
给每个决策一个日期和状态，当它发生变化时，添加新决策并将旧决策标记为“已取代”，而不是将其删除。删除旧决策会破坏你理解在其之下编写的代码的能力。不一致且未标注日期的决策比诚实标注日期的决策更糟糕。
保持始终加载的数据集较小
注入到每个请求中的内容应该是你少数的硬性约束——那些会让答案出错，而不仅仅是不够地道的约束。完整的记录应该放在检索中。在每个问题前堆砌一堵架构历史之墙会挤占问题本身的空间。
无论如何都要提交 ADR
即使有了记忆层，也要将记录放在仓库的版本控制中。存储库使你的助手能够获取它们；仓库使你的团队能够评审它们，而未经评审的决策并不是真正的团队决策。发挥两者各自的长处。
结论
ChatGPT 会遗忘你的架构决策，因为它保留的是偏好，而不是约束。它没有可读取的规则文件，它的记忆是随每次请求携带的一两页内容，而且当前的记忆系统会对其存储的内容进行合成——因此，决策背后的原因（使其具有约束力的那一半）恰恰是被压缩掉的部分。
解决方案是老建议加上一个新步骤。以 ADR 的形式编写决策——上下文、决策、被拒绝的替代方案、后果、日期、状态——并提交它们，因为这就是架构原理在人员变动中得以存续的方式。然后将记录放在你的助手在每次请求时都会读取的地方，这样约束及其原因就会一起送达，而不需要等你记住去粘贴它们。这样，你在 7 月份达成的共识在 9 月份依然有效。