你的AI助手已经忘记了你告诉它的一半内容

本文是AI驱动开发系列文章的第七篇。在上一篇文章中，我讨论了上下文及其管理，并承诺提供一些实用的技巧。最初，这篇文章旨在介绍我在构建Octobatch和Quality Playbook（两个开源项目）时使用的具体上下文管理技术——在这些项目中，我与AI协作规划并编排所有工作，每一行代码都由Claude Code和Cursor等AI工具编写。但在撰写过程中，我发现自己将这些技术应用到了编写文章的工作中，这让我感到惊讶！

我一直在努力寻找帮助AI开发者改进上下文管理的方法，以使他们的技能运行更高效。结果发现，同样的技术也适用于任何使用AI工具的人，即使你使用的是像Claude.ai或ChatGPT这样的聊天机器人。

完全披露：我使用多种AI工具来管理这个系列文章。我的主要工具是Claude Cowork（用于头脑风暴和管理文章研究、笔记和待办事项）以及Gemini的移动应用（用于朗读草稿并在离开办公桌时做笔记）。我想告诉你我在使用这些工具时发生的一件事，因为它很好地说明了为什么上下文管理不仅仅是开发者面临的问题。

在撰写本文时，我使用Gemini的移动应用朗读草稿并做笔记。在会话中途，我要求它回去检查是否有未纳入的早期笔记。它告诉我无法访问之前的笔记，这看起来既奇怪又不可思议，因为那些笔记是在会话中前几个提示中刚刚记录的。我可以向上滚动并在之前的对话中看到它们，但不知何故它却“不知道”它们。

原来，Gemini在不告知我的情况下压缩了对话，而会话前半部分的笔记就这样……消失了。如果你曾经遇到过网页聊天AI似乎忘记了你早些时候谈论的内容，那么你就像我一样经历了上下文压缩。即使只了解上下文和上下文窗口的基本知识，也能大大有助于防止这种挫折感。

这一切让我想起了二十多年前在《应用软件项目管理》（2005年）中写下的内容：“在讨论过程中发现的重要信息，团队在开发过程中需要回头参考，如果这些信息没有被记录下来，团队将不得不重新进行讨论。”我和Jenny Greene当时是针对人类团队和项目会议写的这段话，但它同样适用于AI会话。

这让我回到了上下文的话题——我在上一篇文章中写到了它，并将在下一篇中继续深入，因为它是与AI合作时最重要的概念之一。

**上下文丢失可能是无形的，但这并不意味着它不那么令人沮丧**

上下文是AI在对话期间持有的所有工作记忆：你告诉它的内容、它告诉你的内容、它读取的任何文件或指令，以及系统沿途所做的任何内部笔记。所有这些都存在于一个固定大小的上下文窗口中——可以将其视为AI的短期记忆，即它当前正在思考的内容——当窗口填满时，AI不得不开始舍弃一些东西。不同的工具处理方式不同：有些截断较旧的消息，有些将对话压缩为摘要（这意味着即使摘要看起来完整，细节也会丢失），有些则开始表现不一致，以至于你无法判断AI是忘记了某件事还是从一开始就未能理解。结果是一样的：AI会丢失你告诉它的内容、你们共同做出的决定或它在会话早期注意到的细节。而且它不会告诉你它忘记了。它只会基于仍然保留的内容继续生成看似自信的输出。

在深入探讨之前，我想快速澄清一些术语。如果你看到“技能”和“代理”这些术语但不确定它们是什么，可以将技能视为AI的库，将代理视为可交互的可执行文件。这些定义并不完全精确，但如果你是一位开发者，它们足以用于本文的讨论。

当你编写技能和代理时，会很快遇到上下文问题。你要求AI完成的工作通常足够复杂，以至于上下文窗口很快填满，AI不得不开始压缩：压缩或丢弃对话的较旧部分，以给新内容腾出空间。压缩似乎总是在最令人沮丧和最不合时宜的时候发生——想想也是，当你刚刚投入最多信息时，却恰恰达到了上下文限制，此时丢失信息的代价最高。

这就是为什么我认为将AI视为具有与人类团队相同的缺点，但因其AI特性而被放大，通常会有所帮助。一个人忘记了上周会议中的某件事，在你提醒时可能会想起来。但一个因上下文压缩而丢失信息的AI则不会，因为信息已经消失。不过，你可以采取措施，而且事实证明，无论你是在构建自主AI技能，还是仅仅试图让聊天机器人记住你20分钟前告诉它的内容，这些技巧同样有效。

我总结了自己反复使用的四种技巧。每一种技巧的存在都是因为在某个时候AI忘记了重要信息，而我通过将该信息放入一个文件来应对，这样它就不会被遗忘。这些技巧都不需要特殊工具。令我惊讶的是，所有这些技巧对于构建软件和管理像本文这样的写作项目都同样有用，无论我是与Claude、ChatGPT、Gemini聊天，还是使用像Claude Cowork或Codex这样的桌面工具。以下是我认为最有价值的技巧：

1. **将探索与文档编写分离**：不要要求AI在同一轮次中同时完成“弄清楚某件事”和“生成格式化的输出”。

1. **使用交接文档，而非延续提示**：在关闭旧会话之前，让AI写下下一个会话需要知道的一切。

1. **给AI设定验收标准，而非具体步骤**：告诉它“完成”的状态是什么，而不是详细说明执行步骤。

1. **使用规范文档作为AI工具之间的桥梁**：创建一个共享文档作为所有工具读取的单一事实来源。

**将探索与文档编写分离**

当你要求AI完成复杂任务时，你往往在不知不觉中要求它同时做两件事：既要弄清楚某件事，又要生成格式化的输出。问题在于，弄清楚事情需要注意力，生成输出也需要注意力，而模型的注意力有限。当你在同一个提示中将这两个任务结合起来时，模型会开始在其中一个任务上偷工减料，而且你无法判断它忽略了哪一个。

我在构建Quality Playbook（一个开源的AI编码技能，用于对任何代码库进行结构化代码审查）时遇到了这个问题。它的功能之一是从源代码中推导出需求：它读取代码，识别代码承诺要完成的内容（我称之为行为契约），然后生成一个需求文档。最初，这一切都在一次遍历中完成。问题是，单次遍历的需求生成在大约70个需求后就用尽了注意力。模型忘记了之前在代码中注意到的行为契约，而且这种遗忘完全不可见。没有堆栈跟踪或错误信息，只有不完整的输出，而且无法知道遗漏了什么。我通过将工作分解为两个独立的提示来解决这个问题：

• 读取每个源文件，并将你观察到的每个行为契约以简单列表形式写入CONTRACTS.md。
• 读取CONTRACTS.md和文档，然后从它们推导出需求并写入REQUIREMENTS.md。

然后进行第三次检查，确保每个契约都有对应的需求，如果有缺口，则对有缺口的文件返回第一步。关键是，CONTRACTS.md是外部存储器。当模型“忘记”它之前注意到的某个行为契约时，这种遗忘通常是不可见的。但有了契约文件，每个观察结果都在需求工作开始前被记录下来，因此未覆盖的契约是一个可见的、可搜索的缺口。你可以看到被遗忘的内容并进行修复。

原则：不要要求AI在同一个遍历中同时确定存在什么并编写格式化的输出。模型试图同时做这两件事时会耗尽注意力。每当你要求AI完成复杂任务时，考虑一下你是否实际上要求它同时做两件事。“分析这个代码库并写一份报告”是两项任务。“阅读这份文档并提出改进建议”是两项任务。将它们分开，让第一次遍历将其观察结果写入文件，然后第二次遍历再开始处理它们。

**使用交接文档，而非延续提示**

任何经历过长时间AI编码会话的人都曾感受到上下文开始变得陈旧的那一刻。AI不再追踪一小时内还能很好处理的细节，或者它之前说过的话自相矛盾。会话变得缓慢，你常常不得不重新开始，因为AI似乎陷入了困境，填满了你告诉它的内容。你感觉如果继续下去，你会花费更多时间纠正它而不是取得进展。

大多数开发者对于会话过长有两种反应：要么硬着头皮继续，要么开启新会话并尝试从头重新解释一切。这两种方法都可能导致AI丢失上下文：第一种通过压缩丢失，第二种通过不完整的重新解释丢失。两者都令人沮丧！特别是因为你刚刚花了这么多时间与AI建立所有上下文。

还有第三种选择。在关闭会话之前，要求AI编写一份交接文档：一个文件，捕获下一个会话需要知道的所有信息，并且是在当前会话仍拥有完整上下文时编写的。关键是在相关细节仍在工作上下文中时要求AI编写这份文档，并且以它可以被自身或其他AI读取的方式编写。

我在Quality Playbook中将此构建为各阶段通信的核心部分。当我把Playbook从单个提示拆分为独立阶段时，我需要每个阶段作为完全独立的会话运行，且没有上下文继承。因此，每个阶段都有自己独立的启动提示文件。每个启动提示都遵循以下结构：编写一个交接文档，使新会话能够冷启动这项工作，包括需要知道的所有内容。每个启动提示都以之前阶段完成的内容开头，包括关于哪些内容已冻结的明确边界，并指明哪一未来阶段拥有剩余工作的每个部分，因为没有这一点，AI会在你仍处于第二阶段时好心地开始做第三阶段的工作。每个阶段还以一个必需的向前看的交接结束，其中完成任务的代理写下下一个会话需要知道的内容。

原则：每个交接都是一个完整的状态快照。进入的AI代理永远不需要阅读之前的启动提示或聊天历史记录。它需要的一切都在当前的交接文件中：当前状态、未提交的变更等。

（由于文章较长，此处仅呈现核心内容，原文还讨论了“给AI设定验收标准”和“使用规范文档”两种技巧，以及总结。）