为什么 ChatGPT 会遗忘你的测试用例
它从一开始就没有你的测试套件
测试套件是一个庞大、结构化且不断演进的产物：包含数百个用例、命名语法、Fixtures、标签规范，以及关于哪些已覆盖、哪些故意未覆盖的隐式映射。除非你把这些内容放入对话中，否则模型根本无法获取。相反，你得到的是一个通用的最佳实践套件——孤立来看很合理，但对你的代码库来说却是错的。
上传的文件在聊天结束时就不复存在了
上传测试套件在当前聊天中是有效的。在对话存续期间，内容是可用的，但随后就消失了——新聊天开始时，完全不知道该文件曾经存在过，这与为什么 ChatGPT 会遗忘你上传的文件中描述的障碍相同。对于每周都在变化的套件，重新上传是一件繁琐的工作，而且还会默默发生偏差：你很少会重新上传当前的最新版本。
内置记忆存储的是偏好，而不是覆盖范围
ChatGPT 的记忆旨在承载你的角色、语气、常用指令等内容。这确实很有用——但它不是一个包含 400 个测试用例及其标签、所有者和原由的索引。让它保存你的覆盖范围图谱，是让一个功能去做它并非为此设计的工作，而且这种失败是悄无声息的：模型会根据过时的印象自信地给出回答。
最有价值的 QA 上下文是历史记录
最重要的测试往往是在某些东西崩溃后编写的。它们的价值在于渊源：之所以存在这个断言，是因为生产环境中的部分退款出现了重复记账；之所以存在那个重试测试，是因为支付网关在 30 秒时静默超时。这些历史记录存在于故障报告、工单讨论组以及当时值班人员的记忆中——而不是你今天早上打开的聊天窗口里。相关的失败表现为 ChatGPT 遗忘项目上下文 以及丢失测试旨在验证的需求，这在 ChatGPT 遗忘产品需求 中有所提及。
QA 团队尝试过的方法
庞大的提示词模板
标准的权宜之计：一个包含技术栈、规范、用户角色和业务规则的可复用文本块，在每个会话开始时粘贴在最上面。它确实有用，但代价高昂。你必须为每次请求的这些 Token 付费，模板会随着时间推移与代码库脱节，而且在命名规则发生变化的 Sprint 之后，没人会去更新它。
每次会话都重新上传套件
比模板更准确，但也更繁琐，并且受限于容量限制以及模型能有效读取的内容。这还会产生错误的激励：因为很麻烦，人们往往只上传一个子集，导致模型对它看不到的覆盖范围进行推理。
自定义 GPTs 或专属 Project
一个真正的改进——将指令和参考文件放在一个地方，并与团队共享。但这仍然是一个需要手动维护的孤岛：当覆盖范围发生变化时，文件不会自动更新，而且那里的任何内容都无法提供给编写实现的编码 Agent 或总结发布的助手。同一个套件存在两个事实来源，正是矛盾产生的根源。
粘贴整个规格说明书
长上下文窗口让这变得很有吸引力。但规格说明书描述的是意图，而不是覆盖范围，它对哪些用例已经存在只字未提。你最终会得到重复的用例，并且这些用例还能通过评审，因为同样没人能在脑子里记住 400 个测试名称。
解决方案：赋予 ChatGPT 持久化的 QA 记忆
结束这种重复循环的模式是：将你的 QA 上下文保存在独立于任何单一聊天的记忆层中，并允许模型从中读取。MemoryLake 正是为此而建：你的规范、覆盖范围图谱和故障历史只需存储一次，即可由任何正在执行任务的助手或 Agent 检索。
步骤 1：创建 API 密钥
生成密钥并在大约 30 秒内发出你的第一次请求。
步骤 2：上传你的第一批记忆
放入定义团队测试方式的文档、图像和文件：命名和标签规范、覆盖范围图谱、测试计划、验收标准、产生回归测试的 Bug 复盘报告，以及不稳定测试（flaky-test）列表及其原因。
步骤 3：连接你的 AI 和 Agent
通过 MCP 或 API 让 Claude、Codex、OpenClaw 以及你的其他 Agent 访问该记忆。对于 ChatGPT，通过 API 检索相关记忆并将其输入到对话或你的 QA 工具中——这样模型就能从你真实的测试套件开始，而不是通用的套件。关键在于它们都读取同一个源：编写代码的 Agent 和编写测试的助手不再对已存在的内容产生分歧。
这在实践中带来了什么改变
算一算你自己在重复工作上花的时间。如果一名 QA 工程师每周在 10 个会话开始时花 5 分钟向模型重新简述背景，那么每人每周就要花将近一个小时来重复说明那些没有发生变化的事情。如果常驻上下文块为 2,500 个 Token，并且全团队每天发送 30 次，那就是每天 75,000 个 Token——每月大约 220 万个——你在为重复自己而付费。
没有显示在账单上的成本更大：重复的用例膨胀了套件的运行时间；由于模型不知道缺失了什么，导致无人注意的覆盖漏洞；以及由于从未记录原因而默默被重新争议的回归测试。记忆并不会让模型成为一个更好的测试设计者。它只是让它成为一个了解你测试套件的测试设计者。
QA 记忆的最佳实践
存储套件的轮廓，而不是每个断言
你不需要在记忆中存储 400 个测试的具体内容。你需要的是图谱：模块及其覆盖级别、命名和标签语法、故意不测试的内容、哪些套件是可信的、哪些是不稳定的。这只有一两页纸，而这正是模型所缺失的。
记录每个回归测试存在的原因
对于源自故障的测试，每个测试记录一行：症状、根本原因、日期。这是最值得存储的高价值内容，因为这是会随着人员离职而流失的知识，也是防止六个月后“冗余”测试被误删的关键。
在更新覆盖范围的同一个 Pull Request 中更新记忆
如果更新记忆是一个独立的仪式，记忆就会腐烂。将其与变更绑定：当规范发生转变或套件退役时，在同一个 PR 中更新存储的事实。宁可替换过时的陈述，也不要追加新的陈述——陈旧的 QA 上下文比没有更糟糕，因为模型和人类都会信任它。这种习惯是可以推广的；这与停止向你的 AI 重新解释上下文背后的原则是一致的。
结论
ChatGPT 会遗忘你的测试用例，是因为它从未真正拥有过它们。它对你的套件没有全局认知，上传的文件会随聊天结束而消失，内置记忆承载的是偏好而不是覆盖范围图谱。更好的提示词无法改变这一点，它们只会让重新简述的过程变得更长。
将套件的轮廓、你的规范以及故障历史放入你的工具可以读取的记忆层中，模型的输出就会从“看起来合理”变为“切实可用”——生成符合你命名风格的用例，针对真正未覆盖的内容，并尊重你们团队已经付出过代价的 Bug。这值得好好写下来，而且只需写一次。