迈克·泰勒：所以，每接到一项新任务，我都会重新开一条对话。
迈克·泰勒：旧要求已经不再适用。
把这个问题放到编程Agent的工作流里，会更容易理解。
同一个Claude Code会话中，Agent先按旧架构修改了文件。需求发生变化后，开发者已经明确要求换一种方案，它却仍然沿着之前的假设继续写。等到测试失败，再让它“修正一下”，对话里又多了一份旧代码、一份错误解释和一条纠正意见。
随着任务推进，当前需求、历史方案、错误判断和纠正意见不断叠加。开发者希Agent以最新要求为准，但旧信息并不会因为需求发生变化就自动失去影响。
这不是通常所说的“模型忘了”。
还需要区分两类信息：一类是跨对话保存的用户偏好或其他记忆，另一类是当前会话中持续累积的消息。关闭前者，并不会自动清除当前线程里的旧指令、过时方案和错误结论。
迈克·泰勒表示，他关闭了Claude和ChatGPT的跨对话记忆功能，但他仍然认为，单条对话本身，也可能随着上下文不断累积而变得越来越难以管理。
他把这种现象称为Context Rot，可以理解为上下文退化。
近日，泰勒在 Every 发表文章，解释自己为什么会在切换任务时重新开启对话。
备注：泰勒是Every评估负责人，very成立于2020年，是一家媒体与软件公司，发布科技领域的每日通讯和深度文章，泰勒也是《生成式人工智能的提示工程》（O’Reilly）一书的合著者。他讨论的不只是Claude或ChatGPT的记忆功能，还包括一条长对话怎样改变模型正在处理的任务。
迈克·泰勒文章的标题、作者和发布日期
对开发者来说，问题很具体：同一个会话里，任务目标、项目事实、临时尝试和错误结论常常混在一起。开新对话能清掉噪声，却也可能丢掉项目进度。要解决它，得先分清哪些上下文应该长期保存，哪些只属于当前任务。
以下为原文观点，我们进行了翻译与整理。
旧示例会变成模型的新模板
泰勒用一个命名实验说明了上下文对模型输出的影响。他让ChatGPT模仿乔布斯，给新产品取名字。
只给出任务要求时，模型生成的名字中有21%以“i-”开头。随后，他加入几个以“i-”开头的命名示例，这一比例直接升到了100%。
迈克·泰勒：上下文逐渐变得不可靠。
这个实验说明，模型不仅会理解指令，也会从上下文中寻找模式，并据此调整输出。问题在于，它未必能准确判断哪些内容值得延续，哪些只是当时的尝试。
加入少量“i-”命名示例后，演示结果从21%变为100%
泰勒建议，当语气或任务类型改变时考虑开新线程。对开发者而言，判断标准可以更实际：如果从“解释这段代码”切换到“重构整个服务”，旧对话里的目标和约束可能已经不合用；如果只是继续同一个任务、改刚才讨论的实现，则不必为了形式强行重开。
规则越堆越多，模型越难分清轻重
Every的凯蒂·帕罗特曾把团队使用的写作风格指南从759词扩充到3855词。
规则越来越多后，模型开始把每一条都当成要求；其中一篇文章改了127稿，累计生成超过100万词。后来团队把指南删减到513词。
这个例子不是说短指令一定更好，而是提醒团队检查规则是否还有效、是否互相冲突。一个塞满“必须、禁止、永远”的`CLAUDE.md`或`AGENTS.md`，可能让模型把低优先级偏好和当前任务的硬约束放在同一层处理。
写代码时，可以把稳定规则留在项目文件里，把当前工单单独写清楚。
比如编译命令、代码风格和模块边界适合放在仓库说明；这次任务的改动范围、兼容要求和验收条件则放进任务简报。一次性的排错尝试不要自动升级成长期规范。
关键Bug放在上下文中间，模型可能没看见
长上下文会让重要细节被淹没。
斯坦福研究团队在“Lost in the Middle”论文中测试了多文档问答和信息检索：相关信息放在输入开头或结尾时，模型通常表现较好；移到中间后，表现会明显下降。
泰勒在书中做过一个项目资料演示：给模型9份项目文档，把关键Bug报告放在第6份，再询问项目风险。模型抓住了最前面的项目概述和最后的发布计划，却漏掉中间的Bug报告。
论文Figure 1显示，在这组GPT-3.5多文档问答实验中，答案所在文档越靠近上下文中间，准确率越低
9份资料中的第6份包含关键Bug，模型回答时可能偏向首尾信息
这对Agent开发很重要：把整个仓库、所有日志和历史工单一次性塞进上下文，不等于模型已经理解了它们。任务需要的文件应尽量明确；关键限制要放进简报，最好再转成测试、断言或CI检查，让它们不必只靠模型“记住”。
另一项多轮对话研究分析了20多万个模拟对话，在6类生成任务中，受测模型的多轮表现平均比单轮低39%。
研究者发现，模型容易在信息还不完整时先形成假设，后续对话又继续依赖这个早期答案。它解释了一种常见现象：越早跑错方向，后面补充的信息越难把路线拉回来。
一次错误，可能污染Agent的后续任务状态
最棘手的是错误进入了模型的工作状态。
Google的Gemini 2.5技术报告记录了一次Gemini Plays Pokémon测试：模型把《火红／叶绿》的道具信息带进了《蓝版》，认定要找一个名为TEA的道具才能通过守卫。
报告称，它因此花了很长时间寻找并尝试交出一个在当前版本里不存在的道具。
这不是普通聊天机器人的对照实验，而是一个长程Agent任务案例。报告还指出，错误可能被写进目标和摘要，之后很难撤销。映射到代码库里，就是模型误判了API版本、表结构或服务边界，随后几轮都围绕这个假设继续补代码。
迈克·泰勒：任务目标发生变化。
如果纠正后同一个错误又出现，不妨回到最初的任务说明重新整理，而不是让Agent继续在错的前提上“修补”。对于支持编辑上一条消息或重新生成的聊天产品，也可以先移除错误假设再继续；在Coding Agent里，更稳妥的做法是把确认过的事实写入任务文件，重新启动后让它重新读取。
版本误判写入目标后，Agent会继续搜索不存在的道具
上下文乱了，开发者怎么处理？
重开对话不等于把聊天记录清空后从头猜。项目里长期有效的知识，应该放进Agent每次都能读取的文件，而不是寄希望于模型从旧聊天里记住。
迈克·泰勒：放在Agent能按需读取的本地文件里。
他还建议把长对话整理成一份交接文件，写明事实、决定和下一步。
对一个长期维护的代码库，可以把信息分成三份：
· 项目规则：把构建和测试命令、代码约定、模块边界等稳定信息放进`AGENTS.md`或`CLAUDE.md`。定期删掉过时规则，别把某次排错的临时做法变成永久要求。
· 任务简报：每个新任务单独写目标、改动范围、必须遵守的约束、验收条件和相关文件。尽量一次讲清楚，不要让Agent先按猜测动手，再逐条补充关键条件。
· 交接文件：同一项目要换线程继续时，只带已确认事实、已经作出的决定、完成进度、下一步和未解决问题。删除被推翻的方案、未经验证的推测和无关聊天历史。
稳定项目知识与当前任务分开保存，再通过交接文件延续进度
当Agent重复已经纠正的错误、继续执行旧方案，或把关键约束漏掉时，可以先停下来核对上下文。让它草拟交接内容后，开发者需要逐条检查，确认没有把猜测写成事实，再把交接文件和本次任务简报交给新线程。
可以直接使用这段提示：
请为下一条对话生成任务交接说明，只保留目前仍然有效且已确认的信息。当前目标：已确认的事实：已经作出的决定：必须遵守的约束和验收条件：已经完成的工作：下一步：尚未确认的问题：删除我已经纠正或放弃的方案；不要把猜测写成事实。
简单说，项目规则留在仓库，本次需求写进简报，未完成的进度放进交接文件。新线程只拿完成当前任务所需的信息，不必继承整段试错历史。
写在最后
开发者可以把“是否重开”当成一次上下文检查：Agent是否还在按旧方案做事？刚纠正的错误是否重新出现？关键约束是否埋在一堆日志和旧消息中？如果是，先把当前事实和下一步写进交接文件，再开新线程。
长期有效的项目规则留在仓库，当前需求写进任务简报，试错过程留在聊天记录。模型不需要记住每一轮对话；它需要在开始工作时拿到正确版本的项目事实、清楚的任务边界和可以验证的完成条件。
参考链接
迈克·泰勒，《Context Engineering Is Knowing When to Start Over》，Every，2026年10月16日发布，10月21日更新：原文链接
Nelson F. Liu等，《Lost in the Middle: How Language Models Use Long Contexts》，斯坦福研究团队，2023年：论文链接
Philippe Laban等，《LLMs Get Lost In Multi-Turn Conversation》，2025年：论文链接
Google Gemini团队，《Gemini 2.5: Pushing the Frontier with Advanced Reasoning, Multimodality, Long Context, and Next Generation Agentic Capabilities》：技术报告
Hacker News，《Ask HN: How can I get better at using AI for programming?》：讨论串
——好文链接——
AI让软件进入“一次性消费”时代！Capital One首席软件工程师：有些代码写完就该扔
思维链并不是大模型的内心独白！Anthropic研究员：模型并非逐行写成，它是在训练中“长出来”的
AI永远不会带来就业末日！吴恩达：我的团队不招没用过Coding Agent的工程师
