最近在做优化的时候涉及到了这块内容，觉得值得写下来，方便以后翻阅。
🫧个人主页：小年糕是糕手
💫个人专栏：《C++》《数据结构》《Blender 修行笔记》《AI》
🎨你不能左右天气，但你可以改变心情；你不能改变过去，但你可以决定未来！
目录
假设你正在让 AI 帮忙写一个批量重命名工具。
一着手，你把要求说得很清楚：用 Python，只在本地运行，不接外部服务，原文件一定要保留。
前几轮都挺顺利。后来，你们又讨论了文件夹选择、命名规则、界面和报错处理。聊着聊着，AI 突然给出一个新方案：
可以接入一个云端接口，处理完以后删除原文件，避免重复。
你大概会想：前面说了半天，都白说了？
让人烦躁的地方就在这里。它每次都回复“明白了”，下次却可能继续犯同一个错误。你甚至能往上翻出当时的聊天记录，证明自己确实交代过。
这种情况通常被叫作“AI 忘事”。但要解决它，得先弄清楚，究竟是哪一步出了坑。
聊天记录还在，模型这一轮看到了多少？
在常见的大模型应用里，一次回答可以粗略理解为：应用把一份整理好的材料交给模型，模型根据这些材料生成回复。
这份材料可能包括当前坑、历史消息、平台指令、工具返回结果，以及从文件中取出的内容。模型一次能处理的信息有容量限制，也就是常说的上下文窗口。它与训练时获得的知识是不同的概念。Claude 官方上下文说明
这里容易产生一个误会：咱们看到的是完整的聊天页面，模型收到的却取决于应用怎样组织输入。
长对话可能经过摘要、筛选或其他处理。具体采用哪种方式，要看产品的实现。因此，页面上还能翻到某句话，单凭这一点，无法确认它是否原样进入了这一轮输入。
可以拿开会来打个比方。
会议录音完整保存了两个小时，但接手工作的人可能只拿到了一页会议纪要。录音里确实说过某件事，和纪要里有没有保留这件事，是两个坑。
所以，“我明明告诉过你”完全可能是真的；模型这一轮缺少那条信息，也可能同时发生。
信息放进去了，也可能没用好
那是不是只要上下文足够大，把所有聊天记录都放进去，就能解决？
还要考虑模型能不能从大量材料里准确找到相关信息，并在回答时遵守它。
2023 年的论文《Lost in the Middle》研究过信息位置对表现的影响：在论文测试的模型和任务中，相关信息位于长输入的中间位置时，表现往往不如放在开头或结尾。这是特定实验条件下的结果，不能拿来给今天所有模型套一个固定规律，但它说明了一个问题：容得下长文本，与稳定利用其中的细节，是两项能力。论文原文
再看前面的重命名工具。
几十轮对话里，可能同时出现过这些内容：
- 最着手的本地运行方案。
- AI 提过、但被你否掉的云端方案。
- 一段后来废弃的代码。
- 你粘贴的其他工具教程。
- 最新确定的文件保留规则。
“讨论过一个方案”和“决定采用这个方案”，要分清；昨天的代码与刚改完的代码，也要分清。
如果这些状态没有表达清楚，后面的回答就可能重新拾起已经放弃的做法。
还有一种情况更直接：要求确实在输入里，模型也没有正确执行。只凭一次错误回答，通常无法断定它究竟是没看到、理解偏了，还是执行时出了错。
这也是为什么，光让它再说一次“我记住了”，帮助可能很有限。
一份摘要，最容易丢掉的恰好是关键细节
为了让长任务继续进行，一些系统会把早期对话压缩成摘要。比如 Claude 的官方文档就介绍了用摘要替换较早对话的上下文压缩机制。Compaction 官方说明
这个方法很实用，但摘要要决定保留什么。
假设原来的要求是：
做一个本地 Python 工具。只处理用户选中的文件夹，默认保留原文件；重名时跳过，不覆盖，也不要自动添加编号。
压缩后，如果只剩下：
用户需要一个 Python 批量重命名工具。
任务大方向还在，几个关键限制已经消失了。
后面生成的程序可能看起来很完整，处理方式却完全不合你的要求。
因此，给长任务做摘要时，除了记录“在做什么”，还该保留：
已经确定的决定、不能违反的限制、当前版本，以及尚未完成的工作。
“不能覆盖文件”只有几个字，它对结果的影响，可能比前面几千字的讨论都大。
自己整理交接信息时，也可以用这个标准判断：如果删掉这句话，下一个接手的人会不会做错？
“长期记忆”能解决多少？
说到这里，可能有人会问：现在许多 AI 都有记忆功能，为什么还会这样？
因为“记忆”这个词覆盖了不同的东西。为了方便使用，可以把它们分开看：
信息形式适合放什么需要留意什么当前对话上下文正在讨论的问题、当前代码、这轮修改要求内容可能增长，也可能经过筛选或压缩对话摘要阶段进度、关键决定、待办事项摘要可能漏掉细节，需要检查外部记忆或笔记稳定偏好、项目约定、长期任务记录要在合适的时候被读取和使用项目文件或知识库规范、文档、完整资料、实际代码需要找到正确文件、正确版本和相关内容
这是便于理解的分类，具体产品可能把其中几种方式组合使用。
例如，Anthropic 介绍过一种外部笔记思路：把任务状态保存在上下文之外，之后再读取，以便跨阶段继续工作。上下文工程说明
这里有两个环节：保存，以及需要时取出来。
一条偏好写进了笔记，也要在当前任务需要它时被找到。资料存得很全，同样需要确认这次读到了哪些部分。
对使用者来说，可以把稳定偏好和临时状态分开管理。
“回答尽量用中文”属于算是稳定的偏好。
“这个项目今天改用另一套接口，旧接口暂时保留”则是项目当前状态。它需要跟着项目变化，不能长期挂着不更新。
与其反复提醒，不如交接清楚
真遇到 AI 着手跑偏，我建议先暂停继续加功能，把当前状态整理一遍。
尤其是写代码，后续要求往往建立在前面的版本上。如果它连现在以哪份代码为准都没搞清楚，再加五条新要求，只会让问题更难排查。
仍然拿重命名工具举例，可以发一段这样的说明：
先暂停添加新功能，按下面的信息继续。
当前目标：
做一个本地运行的 Python 批量重命名工具。
当前有效要求：
1. 只处理用户选择的文件夹。
2. 默认保留原文件。
3. 遇到重名文件时跳过，并记录原因。
4. 不调用外部服务，不上传文件。
5. 这轮只修改命名规则，不调整界面。
当前版本：
以本轮附上的代码为准。
之前讨论过但没有采用的方案，不作为当前需求。
这轮需要完成：
修复包含多个句点的文件名被错误截断的问题。
请先说明：
你准备修改哪里，以及怎样检查修改结果。
如果缺少当前代码，请直接指出缺少哪些内容。
这段说明的作用，是重新确定当前任务的边界。
它也方便你检查双方有没有对齐。如果 AI 的修改计划里仍然出现“上传云端”或“删除原文件”，就可以在代码被改动之前注意到问题。
不过，复述要求只是一次检查。它能准确复述，不代表接下来的操作一定正确。
程序交付以后，仍然要用几个有代表性的文件验证：原文件是否保留，重名是否跳过，文件名是否按规则处理。最后要检查的是结果。
什么情况下，值得开一个新聊天？
没有必要按固定轮数清空对话。更值得观察的是，当前对话里还剩多少有效信息。
如果只是补充一个相关条件，继续聊通常更方便。
如果已经换了几次目标，混着多个废弃版本，而且 AI 开始频繁引用旧方案，就可以考虑重新整理后开一个新聊天。
开新聊天时，别只留一句：
接着上次的继续。
这相当于把任务交给另一个人，却没告诉他上次做到哪里。
下面这份模板可以直接拿来用：
请根据以下交接信息继续任务。
【目标】
这项工作最终要完成什么：
【当前状态】
已经完成：
尚未完成：
【有效决定】
已经确定并继续采用的方案：
已经放弃的方案：
【必须遵守】
不能改变的内容：
不能执行的操作：
【当前资料】
以哪些文件、代码或文档为准：
版本、日期或文件路径：
【下一步】
这轮只需要完成什么：
怎样判断完成：
如果资料缺失或存在冲突，请先指出。
请区分已确认事实与尚未验证的判断。
填完以后，再检查一遍摘要。
有时 AI 会把“建议这样做”写成“已经这样做了”，或者把“准备验证”写成“验证通过”。这些状态如果带进新对话，后面就会建立在错误前提上。
所以，交接摘要里，“做了什么”和“证实了什么”最好分别写。
资料太多时，可以让 AI 去查，但要查到地方
当一个任务有几十份文档时，每轮都粘贴全文并不方便。知识库、文件搜索和检索增强生成，也就是 RAG，正是可以考虑的方向。
RAG 的基本思路，是在生成回答时利用检索到的外部资料。相关研究将模型已有知识与外部检索结合，用于处理知识密集型任务。RAG 论文
实际使用时，可以把要求写得更具体：
先查找当前版本的项目规范，列出与这次修改有关的条款，再给出方案。
这样算是容易检查：它找到了哪份资料，用的是哪个版本，依据是什么。
如果项目规范已经更新，而搜索结果仍然是旧版，回答再流畅也没有解决问题。文件名、日期、版本号和“当前生效”标记，都是值得维护的信息。
对小任务来说，也不一定非要搭建知识库。一份持续更新的项目说明，加上最新文件，可能就足够了。
下次再遇到 AI“忘事”，可以先检查三个地方：
这条要求有没有进入当前输入？中途有没有被摘要丢掉？它是否已经看到，却没有正确执行？
之后补上当前目标、有效限制和最新资料，让它继续做一件范围明确的事。
要求它“永远记住所有聊天”很难验证。一份经过检查的交接记录，以及能证明任务完成的实际结果，会更让人放心。
以上就是这次整理的全部内容，希望对你有所启发。如果有不同见解，欢迎在评论区交流讨论。
评论 (0)
暂无评论