在 Vibe Coding 里Context上下文管理是最容易被低估的一环。很多人第一次在编程会话里看到“out of room”、“maximum context length is 1048576 tokens”这类报错时第一反应是模型出了问题或者提示词写得不够好。但真正在长项目里跑过 AI 编程的人会告诉你窗口撞满、模型开始“失忆”几乎是一种必然差别只在于你提前意识到了还是没有意识到。举个例子。晚上十一点半你还在一个 AI 编程会话里改第四个文件。两个小时前模型还记得你定义的create_order接口返回什么结构现在你让它修复第一个文件里的小 bug它却像第一次见到这个项目重新定义了一个名字相近但完全不兼容的函数。你的第一反应是“模型变笨了”但更接近真相的解释是这个会话的 Context 已经被消耗得差不多早期决策被挤出了模型的注意力范围。这篇文章想讲清楚三件事Context 在 Vibe Coding 里到底是什么它为什么会在不知不觉中拖垮你的会话以及遇到 context 报错或者模型行为退化时你应该按什么顺序处理。最后会给你一份可以直接用起来的管理检查表。1. 先搞清楚 Context 在你和模型之间扮演什么角色1.1 它不是“聊天记录”而是模型的“即时工作记忆”很多人把 Context 理解成“聊天记录”认为模型只是把历史对话原样保存在某个地方随时可以像人一样翻回去查阅。这个理解只对了一半。从工程实现角度看大语言模型在生成每一个新 token 时都需要基于当前请求里包含的所有文本进行预测。系统提示、用户消息、工具返回、模型历史回复这些内容组合在一起构成模型这一次“看到”的工作台。它可以被粗略理解成一个临时工作记忆。这个记忆的容量上限就是模型的 context window。为什么这个区别很重要因为窗口里面的内容并不是平等的。即使是同一个窗口里的信息模型在不同位置的关注度也不一样。大量长文本实验已经反复验证过一个现象模型更容易记住开头和结尾而中间部分容易被忽略业内常称为 loss in the middle中间丢失。换句话说不是“所有进入窗口的信息都能被同等使用”而是“进入窗口的信息只是获得了被使用的资格”。在 Vibe Coding 场景里窗口里装的东西比普通聊天复杂得多你和模型之间关于需求的反复沟通你贴进来的源码、配置、报错日志、命令行输出编程工具自动读取的文件树、函数签名、相关代码片段模型上一次输出的完整代码块、临时方案讨论这些内容以 token 为单位堆在同一个工作台上却没有任何优先级分层。你需要主动来做这个分层。1.2 为什么编程场景比普通聊天更容易撞上窗口上限普通聊天里一个人一天聊几十条消息可能也才几千 token。Vibe Coding 的会话完全不同一次文件创建可能就输出几百行代码一次重构可能涉及三个文件的交互设计一次报错排查你随手一贴就是几百行日志。从社区反馈里经常能看到三类典型报错类似“api error: 400 this models maximum context length is 1048576 tokens”的硬限制报错类似“codex ran out of room in the models context window. start a new thread”的工具建议类似“context is too large and auto-compaction could not recover this turn”的自动压缩失败提示。这些报错形式虽然不同本质上讲的都是同一件事窗口是一个有上限的容器而编程过程非常容易把它填满。这里要特别提醒一句模型的标称窗口和你用编程工具时的实际可用上下文并不是同一个数。很多编程 agent 为了调用工具、解析文件、输出结构化内容会在系统层预留一部分 token。你真正能“挥霍”的通常比宣传值要小。不同模型的默认窗口差异也很大从 32k、128k、200k 到 1M 都存在。开始一个新的 Vibe Coding 项目之前先确认当前模型的实际窗口配置不要等报错再回头猜。2. 为什么上下文一长模型就开始“行为变形”2.1 遗忘是渐进的坏行为是突然发生的最坑人的问题不是报错而是“没有报错但行为开始走样”。典型表现是你在会话早期明确说过“这个模块不要引入 ORM直接写 SQL”模型当时也执行了。但三十分钟后当你在另一个文件里遇到类似场景时它突然开始建议用 ORM 重构甚至直接生成了你早就排除的方案。你回翻聊天记录发现它前面确实记住了但现在的回复已经不再参考早期约束。这就是长上下文下的注意力摊薄token 总量越多每个 token 获得的有效注意力权重越少早期被否定的方案、关键边界条件、少数的几行规范要求都有可能被后续大量内容淹没。另一个容易被忽略的机制是自动压缩。很多编程 agent 会在上下文接近上限时把历史内容摘要化用“已完成登录模块”这样一句话替换掉整个实现过程。摘要本身是好事但它天然会丢失细节具体命名、参数顺序、边界情况、被否决的原因。如果这些细节没有写进文件或代码注释压缩之后模型就真的“失忆”了。2.2 撞上硬上限时错误本身反而不可怕相比渐进式遗忘硬上限错误其实更直接、更容易理解。你发出去一个请求API 直接拒绝处理或者工具提示当前会话已经超出窗口范围建议开启新线程。这种报错不会让你纠结“模型是不是坏掉了”它只是明确告诉你容器满了。但这里有一个陷阱很多人的第一反应是清空对话重新来也就是“开一个全新的线程”。这在短任务里没问题但在长项目里可能埋雷。因为新线程里模型对你项目的认知全部来自你重新提供的信息。如果你只是简单说一句“继续写项目”它无法知道你刚才已经否决过多少个方案、已经确定过哪些接口设计。所以处理硬上限报错之前最重要的不是“清空”而是“交接”。2.3 自动压缩不是万能保险“让工具自动压缩早期内容”听起来很省心实际使用中至少有两个坑。一是摘要丢细节。自动压缩的目的是节省空间它的默认策略是“保主干、丢枝叶”。在 Vibe Coding 里很多枝叶恰恰是决定成败的细节比如某个字段为什么必须用字符串而不是数字、某个接口为什么不允许返回空数组。二是自动压缩本身可能失败。前面提到过“auto-compaction could not recover this turn”这类报错说明压缩不是一个保证成功的后台操作。当单轮内容过长或压缩摘要本身超出限额时工具可能无法在同一个回合里完成恢复。这意味着你不仅失去了上下文当前这一轮的请求也可能直接失败。把自动压缩当作兜底而不是主策略是一个更稳妥的认知。3. 上下文管理的本质是把记忆从窗口搬到项目里如果只看表面Context 管理像是一个“怎么让模型少占空间”的问题实际上它是“怎么让项目的重要信息不依赖某一个特定会话”的问题。我建议把它拆成三个动作进入会话前的前置压缩、会话过程中的增量喂养、会话结束时的交接卡。这三步可以合并成一个通用流程任何规模的 Vibe Coding 项目都能套用。3.1 进会话之前先做“前置压缩”很多上下文问题在会话开始前就已经注定了。如果你打开一个空会话从“帮我做一个待办事项应用”开始让模型边聊边帮你理需求那么前十几轮对话大多数是在“摸索”。这些摸索内容会一直占着窗口让你后面的真正开发空间越来越小。一个更稳的起步方式把需求先写进一个文档再让模型基于文档开发。文档不需要很长建议包含以下内容项目目标一句话说清楚要做什么。非目标明确不做什么例如“不做登录、不做多用户、不做支付”。技术约束语言、框架、依赖、运行环境。已完成/待完成开发进度的快照。举例来说一个新项目的第一版说明可以长这样# project-brief.md项目简报示例结构 ## 目标 做一个局域网内可访问的 Markdown 笔记服务支持创建和编辑页面。 ## 非目标 不做账号系统不做实时协作不做移动端适配。 ## 技术约束 - 后端Node.js Express - 存储本地 JSON 文件 - 前端服务端渲染尽量少写 JS ## 当前状态 - [x] 初始化项目 - [ ] 页面列表接口 - [ ] 编辑保存接口 - [ ] 简单前端页面每次开始新会话时你把这份简报精简后提供给模型它就有了一个结构化的知识锚点。后面哪怕窗口再涨早期那十几轮摸索对话已经变成了一份清晰的需求文档既节省空间又减少误解。3.2 会话过程中学会“增量喂养”进入会话之后最常见的资源浪费方式是“重复投喂大块内容”。三个具体习惯能省下大量 token第一能用路径引用就不要整段粘贴。很多编程工具支持读取指定文件你只需要说“请查看 src/utils/date.ts 里的 parseDate 函数”它会按需读取而不是把整个仓库都塞进窗口。即使工具不支持自动读取也建议先让模型确认它需要哪部分代码再针对性粘贴。第二修改局部逻辑时只给差异上下文。与其贴一个 300 行的文件让对方改不如给“当前这一段代码 你期望的行为”。比如当前 create_order 里第 38 行附近对库存校验会直接抛异常 我希望改成库存不足时返回可读的 JSON 错误对象并保留 HTTP 400 状态码。 请只给出需要修改的函数片段。第三阶段性存状态。每完成一个模块可以请模型用几行话总结一次请用不超过 5 行总结当前项目状态已完成功能、已确定的关键接口、下一步要做的事。 我会保存进 docs/STATUS.md。这个动作有两个好处它在当前会话里形成可引用的摘要减少以后重复解释它同时为未来开新线程准备了交接材料。还有一个容易被忽略的点大段报错日志的信息密度很低。报错时尽量只贴关键几行加上触发场景而不是把整个控制台复制进来。日志往往占据大量 token但对模型判断问题的帮助其实有限因为真正有用的信息通常只有前几行和最后几行。3.3 会话结束时写一张“交接卡”当工具提示“建议开启新线程”或者你自己感觉会话已经很长时先别急着开新窗口花几分钟生成一张交接卡。交接卡可以理解为“当前会话的压缩备份”内容包括项目当前状态已完成、进行中、待办。关键接口和模块边界模型在旧会话里已经确认过的设计。下一步任务希望新会话从哪里继续。被否决的方案及原因这一条最容易被忽略但特别重要。新会话不知道你曾经否掉过什么如果没有记录很容易重新提出你已经排除的方案。交接卡可以让模型根据当前对话生成然后你做人工复核。生成之后保存为项目文档例如 docs/HANDOFF.md# HANDOFF交接卡示例结构 ## 当前状态 - 已完成后端 API用户模块、订单模块 - 进行中支付回调处理 ## 关键约定 - 订单状态字段统一使用 pending / paid / failed - 所有接口返回格式{ code, data, message } ## 下一步 - 完成支付回调的幂等处理 - 补充订单查询接口的分页 ## 已否决方案 - 曾考虑用 Redis 存订单状态因当前无外部依赖要求改为内存态 数据库落盘有了这样一份文件任何新会话都不必从零重建认知。它相当于把模型窗口里的易失记忆落盘成项目层面的持久记忆。4. 遇到 context 报错按“输入→会话→工具→项目”定位4.1 先看现象判断是哪一类问题遇到问题先分类别急着重发同样的请求。常见的 context 相关现象可以分成三类现象关键词含义硬上限报错maximum context length、out of room、400容器已满请求被拒绝自动压缩失败auto-compaction could not recover压缩机制没能保住当前回合软性退化无报错但遗忘约束、重复定义、答非所问注意力被摊薄关键信息失效前两类是明确的 error第三类最隐蔽也最消耗时间。如果模型开始“不像它自己”建议先检查当前会话大概已经累积了多少轮、最近是否贴过大文件、是否触发了自动压缩摘要。4.2 四层定位不要跳步如果确认遇到了 context 相关问题我一般按下面这个顺序排查不要跳层。第一层输入。最近几轮里有没有贴超过几百行的文件或日志有没有一次性让模型处理某个超大文件如果有优先从这里解决把一次性投喂改成按需读取把大日志改成关键片段。第二层会话。当前会话总共进行了多少轮估算一下已经消耗的 token。如果会话很长且持续产出代码即使没有报错也应该考虑做阶段性总结或准备交接。第三层工具。你用的编程工具是否启用了自动压缩是否支持开新线程并继续使用项目上下文有些工具自带“继续会话”但本质上还是同一个窗口有些工具允许加载文件夹作为上下文。这些能力直接决定你能不能安全地“换线程”。第四层项目。工程项目本身是否过大你每次会话是不是都要重新读取整个目录结构如果项目已经大到模型无法在一个窗口里消化问题就不只是上下文管理而是需要拆模块、写更充分的项目说明文档并让模型遵守“只读当前要改的部分”。多数情况下问题出在输入层和会话层。少部分项目是因为项目结构没有文档化导致每个新会话都在重复探索成本。4.3 一张可以直接使用的地图检查表这张表是我自己跑项目时用的。不一定每条都要做到但每次遇到“模型开始乱来”或者 context 报错时按表过一遍基本能定位到问题检查项判断标准动作建议会话轮数超过 5-10 轮且进展缓慢做一次状态总结考虑交接单次投喂量单次粘贴超过数百行改用文件路径/按需读取自动压缩节点历史里出现摘要替换检查摘要是否丢失关键约束项目简报是否有现成需求/约束文档没有就先补再继续会话交接材料是否生成了 HANDOFF/STATUS至少要有当前状态和下一步注意这张表的目的是“预防”不是“急救”。最好在会话还没明显变长时就主动检查别等模型已经失忆了再回头补材料。5. 要不要换更长的窗口先想清楚三件事5.1 更大的窗口不是免费午餐看到 1M token 的窗口很多人会觉得“那就不用管上下文了”。这个想法有隐患。第一窗口变大不等于注意力均匀。模型在很长的序列里仍然会丢失信息只是“装满”的时间被延后了并没有从机制上解决问题。你以前 20 轮会话开始乱现在可能 60 轮才开始乱但丢失的原因和后果是一样的。第二更长输入意味着更高的推理成本和更慢的响应。每次请求都要重新扫描窗口里的所有内容上下文越长单次生成要花的算力越多、延迟越高。如果你的工作流里习惯反复贴大文件换成超长窗口只会放大开销。我的建议是更大的窗口可以当成“兜底容量”但不能当成“不管理上下文的理由”。把上下文管理理解为磁盘空间管理而不是“空间足够大所以不用清理”。5.2 先交接再开新线程开新线程本身是对的。问题是很多人在没有做好交接的情况下就开。判断标准其实很简单新线程能不能在最少轮次内恢复旧会话的关键记忆场景建议当前任务已完成一个完整单元适合开新线程上下文接近上限但关键决策已写入文档/代码适合开新线程话题发生明显转向例如从写接口切到写测试适合开新线程关键设计约束只存在于旧会话没有落到文件先补交接再开项目还没有结构化说明文档先补简报再开正处在一个长任务中段交接卡还没写先写交接再开换句话说先交接再开启。这不是保守而是让“新线程”真正接得住旧线程的记忆。5.3 长期项目的可靠记忆都在模型窗口之外把这一整篇的内容收拢成一句话Context 管理不是为了把窗口省着用而是为了把记忆从“模型内部”迁移到“项目外部”。为什么外部记忆更可靠因为模型窗口是易失的而文件、代码、注释、git 历史是持久的。窗口清空不代表知识消失只要知识已经落盘新的会话就能快速重建认知。长期项目的可靠知识载体至少包括四类项目文档需求、约束、非目标决定“项目往哪走”。源码注释与命名代码本身就是事实来源好的命名能大幅减少解释成本。git 提交历史每次变更和决策都可以追溯。STATUS / HANDOFF Vibe Coding上下文管理：三招解决模型失忆与窗口溢出
在 Vibe Coding 里Context上下文管理是最容易被低估的一环。很多人第一次在编程会话里看到“out of room”、“maximum context length is 1048576 tokens”这类报错时第一反应是模型出了问题或者提示词写得不够好。但真正在长项目里跑过 AI 编程的人会告诉你窗口撞满、模型开始“失忆”几乎是一种必然差别只在于你提前意识到了还是没有意识到。举个例子。晚上十一点半你还在一个 AI 编程会话里改第四个文件。两个小时前模型还记得你定义的create_order接口返回什么结构现在你让它修复第一个文件里的小 bug它却像第一次见到这个项目重新定义了一个名字相近但完全不兼容的函数。你的第一反应是“模型变笨了”但更接近真相的解释是这个会话的 Context 已经被消耗得差不多早期决策被挤出了模型的注意力范围。这篇文章想讲清楚三件事Context 在 Vibe Coding 里到底是什么它为什么会在不知不觉中拖垮你的会话以及遇到 context 报错或者模型行为退化时你应该按什么顺序处理。最后会给你一份可以直接用起来的管理检查表。1. 先搞清楚 Context 在你和模型之间扮演什么角色1.1 它不是“聊天记录”而是模型的“即时工作记忆”很多人把 Context 理解成“聊天记录”认为模型只是把历史对话原样保存在某个地方随时可以像人一样翻回去查阅。这个理解只对了一半。从工程实现角度看大语言模型在生成每一个新 token 时都需要基于当前请求里包含的所有文本进行预测。系统提示、用户消息、工具返回、模型历史回复这些内容组合在一起构成模型这一次“看到”的工作台。它可以被粗略理解成一个临时工作记忆。这个记忆的容量上限就是模型的 context window。为什么这个区别很重要因为窗口里面的内容并不是平等的。即使是同一个窗口里的信息模型在不同位置的关注度也不一样。大量长文本实验已经反复验证过一个现象模型更容易记住开头和结尾而中间部分容易被忽略业内常称为 loss in the middle中间丢失。换句话说不是“所有进入窗口的信息都能被同等使用”而是“进入窗口的信息只是获得了被使用的资格”。在 Vibe Coding 场景里窗口里装的东西比普通聊天复杂得多你和模型之间关于需求的反复沟通你贴进来的源码、配置、报错日志、命令行输出编程工具自动读取的文件树、函数签名、相关代码片段模型上一次输出的完整代码块、临时方案讨论这些内容以 token 为单位堆在同一个工作台上却没有任何优先级分层。你需要主动来做这个分层。1.2 为什么编程场景比普通聊天更容易撞上窗口上限普通聊天里一个人一天聊几十条消息可能也才几千 token。Vibe Coding 的会话完全不同一次文件创建可能就输出几百行代码一次重构可能涉及三个文件的交互设计一次报错排查你随手一贴就是几百行日志。从社区反馈里经常能看到三类典型报错类似“api error: 400 this models maximum context length is 1048576 tokens”的硬限制报错类似“codex ran out of room in the models context window. start a new thread”的工具建议类似“context is too large and auto-compaction could not recover this turn”的自动压缩失败提示。这些报错形式虽然不同本质上讲的都是同一件事窗口是一个有上限的容器而编程过程非常容易把它填满。这里要特别提醒一句模型的标称窗口和你用编程工具时的实际可用上下文并不是同一个数。很多编程 agent 为了调用工具、解析文件、输出结构化内容会在系统层预留一部分 token。你真正能“挥霍”的通常比宣传值要小。不同模型的默认窗口差异也很大从 32k、128k、200k 到 1M 都存在。开始一个新的 Vibe Coding 项目之前先确认当前模型的实际窗口配置不要等报错再回头猜。2. 为什么上下文一长模型就开始“行为变形”2.1 遗忘是渐进的坏行为是突然发生的最坑人的问题不是报错而是“没有报错但行为开始走样”。典型表现是你在会话早期明确说过“这个模块不要引入 ORM直接写 SQL”模型当时也执行了。但三十分钟后当你在另一个文件里遇到类似场景时它突然开始建议用 ORM 重构甚至直接生成了你早就排除的方案。你回翻聊天记录发现它前面确实记住了但现在的回复已经不再参考早期约束。这就是长上下文下的注意力摊薄token 总量越多每个 token 获得的有效注意力权重越少早期被否定的方案、关键边界条件、少数的几行规范要求都有可能被后续大量内容淹没。另一个容易被忽略的机制是自动压缩。很多编程 agent 会在上下文接近上限时把历史内容摘要化用“已完成登录模块”这样一句话替换掉整个实现过程。摘要本身是好事但它天然会丢失细节具体命名、参数顺序、边界情况、被否决的原因。如果这些细节没有写进文件或代码注释压缩之后模型就真的“失忆”了。2.2 撞上硬上限时错误本身反而不可怕相比渐进式遗忘硬上限错误其实更直接、更容易理解。你发出去一个请求API 直接拒绝处理或者工具提示当前会话已经超出窗口范围建议开启新线程。这种报错不会让你纠结“模型是不是坏掉了”它只是明确告诉你容器满了。但这里有一个陷阱很多人的第一反应是清空对话重新来也就是“开一个全新的线程”。这在短任务里没问题但在长项目里可能埋雷。因为新线程里模型对你项目的认知全部来自你重新提供的信息。如果你只是简单说一句“继续写项目”它无法知道你刚才已经否决过多少个方案、已经确定过哪些接口设计。所以处理硬上限报错之前最重要的不是“清空”而是“交接”。2.3 自动压缩不是万能保险“让工具自动压缩早期内容”听起来很省心实际使用中至少有两个坑。一是摘要丢细节。自动压缩的目的是节省空间它的默认策略是“保主干、丢枝叶”。在 Vibe Coding 里很多枝叶恰恰是决定成败的细节比如某个字段为什么必须用字符串而不是数字、某个接口为什么不允许返回空数组。二是自动压缩本身可能失败。前面提到过“auto-compaction could not recover this turn”这类报错说明压缩不是一个保证成功的后台操作。当单轮内容过长或压缩摘要本身超出限额时工具可能无法在同一个回合里完成恢复。这意味着你不仅失去了上下文当前这一轮的请求也可能直接失败。把自动压缩当作兜底而不是主策略是一个更稳妥的认知。3. 上下文管理的本质是把记忆从窗口搬到项目里如果只看表面Context 管理像是一个“怎么让模型少占空间”的问题实际上它是“怎么让项目的重要信息不依赖某一个特定会话”的问题。我建议把它拆成三个动作进入会话前的前置压缩、会话过程中的增量喂养、会话结束时的交接卡。这三步可以合并成一个通用流程任何规模的 Vibe Coding 项目都能套用。3.1 进会话之前先做“前置压缩”很多上下文问题在会话开始前就已经注定了。如果你打开一个空会话从“帮我做一个待办事项应用”开始让模型边聊边帮你理需求那么前十几轮对话大多数是在“摸索”。这些摸索内容会一直占着窗口让你后面的真正开发空间越来越小。一个更稳的起步方式把需求先写进一个文档再让模型基于文档开发。文档不需要很长建议包含以下内容项目目标一句话说清楚要做什么。非目标明确不做什么例如“不做登录、不做多用户、不做支付”。技术约束语言、框架、依赖、运行环境。已完成/待完成开发进度的快照。举例来说一个新项目的第一版说明可以长这样# project-brief.md项目简报示例结构 ## 目标 做一个局域网内可访问的 Markdown 笔记服务支持创建和编辑页面。 ## 非目标 不做账号系统不做实时协作不做移动端适配。 ## 技术约束 - 后端Node.js Express - 存储本地 JSON 文件 - 前端服务端渲染尽量少写 JS ## 当前状态 - [x] 初始化项目 - [ ] 页面列表接口 - [ ] 编辑保存接口 - [ ] 简单前端页面每次开始新会话时你把这份简报精简后提供给模型它就有了一个结构化的知识锚点。后面哪怕窗口再涨早期那十几轮摸索对话已经变成了一份清晰的需求文档既节省空间又减少误解。3.2 会话过程中学会“增量喂养”进入会话之后最常见的资源浪费方式是“重复投喂大块内容”。三个具体习惯能省下大量 token第一能用路径引用就不要整段粘贴。很多编程工具支持读取指定文件你只需要说“请查看 src/utils/date.ts 里的 parseDate 函数”它会按需读取而不是把整个仓库都塞进窗口。即使工具不支持自动读取也建议先让模型确认它需要哪部分代码再针对性粘贴。第二修改局部逻辑时只给差异上下文。与其贴一个 300 行的文件让对方改不如给“当前这一段代码 你期望的行为”。比如当前 create_order 里第 38 行附近对库存校验会直接抛异常 我希望改成库存不足时返回可读的 JSON 错误对象并保留 HTTP 400 状态码。 请只给出需要修改的函数片段。第三阶段性存状态。每完成一个模块可以请模型用几行话总结一次请用不超过 5 行总结当前项目状态已完成功能、已确定的关键接口、下一步要做的事。 我会保存进 docs/STATUS.md。这个动作有两个好处它在当前会话里形成可引用的摘要减少以后重复解释它同时为未来开新线程准备了交接材料。还有一个容易被忽略的点大段报错日志的信息密度很低。报错时尽量只贴关键几行加上触发场景而不是把整个控制台复制进来。日志往往占据大量 token但对模型判断问题的帮助其实有限因为真正有用的信息通常只有前几行和最后几行。3.3 会话结束时写一张“交接卡”当工具提示“建议开启新线程”或者你自己感觉会话已经很长时先别急着开新窗口花几分钟生成一张交接卡。交接卡可以理解为“当前会话的压缩备份”内容包括项目当前状态已完成、进行中、待办。关键接口和模块边界模型在旧会话里已经确认过的设计。下一步任务希望新会话从哪里继续。被否决的方案及原因这一条最容易被忽略但特别重要。新会话不知道你曾经否掉过什么如果没有记录很容易重新提出你已经排除的方案。交接卡可以让模型根据当前对话生成然后你做人工复核。生成之后保存为项目文档例如 docs/HANDOFF.md# HANDOFF交接卡示例结构 ## 当前状态 - 已完成后端 API用户模块、订单模块 - 进行中支付回调处理 ## 关键约定 - 订单状态字段统一使用 pending / paid / failed - 所有接口返回格式{ code, data, message } ## 下一步 - 完成支付回调的幂等处理 - 补充订单查询接口的分页 ## 已否决方案 - 曾考虑用 Redis 存订单状态因当前无外部依赖要求改为内存态 数据库落盘有了这样一份文件任何新会话都不必从零重建认知。它相当于把模型窗口里的易失记忆落盘成项目层面的持久记忆。4. 遇到 context 报错按“输入→会话→工具→项目”定位4.1 先看现象判断是哪一类问题遇到问题先分类别急着重发同样的请求。常见的 context 相关现象可以分成三类现象关键词含义硬上限报错maximum context length、out of room、400容器已满请求被拒绝自动压缩失败auto-compaction could not recover压缩机制没能保住当前回合软性退化无报错但遗忘约束、重复定义、答非所问注意力被摊薄关键信息失效前两类是明确的 error第三类最隐蔽也最消耗时间。如果模型开始“不像它自己”建议先检查当前会话大概已经累积了多少轮、最近是否贴过大文件、是否触发了自动压缩摘要。4.2 四层定位不要跳步如果确认遇到了 context 相关问题我一般按下面这个顺序排查不要跳层。第一层输入。最近几轮里有没有贴超过几百行的文件或日志有没有一次性让模型处理某个超大文件如果有优先从这里解决把一次性投喂改成按需读取把大日志改成关键片段。第二层会话。当前会话总共进行了多少轮估算一下已经消耗的 token。如果会话很长且持续产出代码即使没有报错也应该考虑做阶段性总结或准备交接。第三层工具。你用的编程工具是否启用了自动压缩是否支持开新线程并继续使用项目上下文有些工具自带“继续会话”但本质上还是同一个窗口有些工具允许加载文件夹作为上下文。这些能力直接决定你能不能安全地“换线程”。第四层项目。工程项目本身是否过大你每次会话是不是都要重新读取整个目录结构如果项目已经大到模型无法在一个窗口里消化问题就不只是上下文管理而是需要拆模块、写更充分的项目说明文档并让模型遵守“只读当前要改的部分”。多数情况下问题出在输入层和会话层。少部分项目是因为项目结构没有文档化导致每个新会话都在重复探索成本。4.3 一张可以直接使用的地图检查表这张表是我自己跑项目时用的。不一定每条都要做到但每次遇到“模型开始乱来”或者 context 报错时按表过一遍基本能定位到问题检查项判断标准动作建议会话轮数超过 5-10 轮且进展缓慢做一次状态总结考虑交接单次投喂量单次粘贴超过数百行改用文件路径/按需读取自动压缩节点历史里出现摘要替换检查摘要是否丢失关键约束项目简报是否有现成需求/约束文档没有就先补再继续会话交接材料是否生成了 HANDOFF/STATUS至少要有当前状态和下一步注意这张表的目的是“预防”不是“急救”。最好在会话还没明显变长时就主动检查别等模型已经失忆了再回头补材料。5. 要不要换更长的窗口先想清楚三件事5.1 更大的窗口不是免费午餐看到 1M token 的窗口很多人会觉得“那就不用管上下文了”。这个想法有隐患。第一窗口变大不等于注意力均匀。模型在很长的序列里仍然会丢失信息只是“装满”的时间被延后了并没有从机制上解决问题。你以前 20 轮会话开始乱现在可能 60 轮才开始乱但丢失的原因和后果是一样的。第二更长输入意味着更高的推理成本和更慢的响应。每次请求都要重新扫描窗口里的所有内容上下文越长单次生成要花的算力越多、延迟越高。如果你的工作流里习惯反复贴大文件换成超长窗口只会放大开销。我的建议是更大的窗口可以当成“兜底容量”但不能当成“不管理上下文的理由”。把上下文管理理解为磁盘空间管理而不是“空间足够大所以不用清理”。5.2 先交接再开新线程开新线程本身是对的。问题是很多人在没有做好交接的情况下就开。判断标准其实很简单新线程能不能在最少轮次内恢复旧会话的关键记忆场景建议当前任务已完成一个完整单元适合开新线程上下文接近上限但关键决策已写入文档/代码适合开新线程话题发生明显转向例如从写接口切到写测试适合开新线程关键设计约束只存在于旧会话没有落到文件先补交接再开项目还没有结构化说明文档先补简报再开正处在一个长任务中段交接卡还没写先写交接再开换句话说先交接再开启。这不是保守而是让“新线程”真正接得住旧线程的记忆。5.3 长期项目的可靠记忆都在模型窗口之外把这一整篇的内容收拢成一句话Context 管理不是为了把窗口省着用而是为了把记忆从“模型内部”迁移到“项目外部”。为什么外部记忆更可靠因为模型窗口是易失的而文件、代码、注释、git 历史是持久的。窗口清空不代表知识消失只要知识已经落盘新的会话就能快速重建认知。长期项目的可靠知识载体至少包括四类项目文档需求、约束、非目标决定“项目往哪走”。源码注释与命名代码本身就是事实来源好的命名能大幅减少解释成本。git 提交历史每次变更和决策都可以追溯。STATUS / HANDOFF