这次我们聊一个 Vibe Coding 里最容易被忽略、但一遇到就停工的问题Context也就是上下文管理。Vibe Coding 听起来很自由你用自然语言描述需求AI 帮你写代码。但实际用下来大多数人遇到的最大瓶颈并不是提示词写得好不好而是AI 是否还记得你最开始的需求。比如你让 AI 从零搭一个项目前面几轮它还能严格执行约定到了第 15 轮它突然把之前约定的命名规则改了或者开始重构一个你明确说过不要动的模块。这本质上不是模型变笨了而是上下文窗口里的信息已经超载早期关键指令被压缩甚至丢掉了。这篇文章会围绕 Vibe Coding 过程中的几种真实报错展开包括 api error: 400 this models maximum context length is 1048576 tokens、codex ran out of room in the models context window、context is too large and auto-compaction could not recover this turn。我会把为什么会出现这类问题、底层上下文管理机制是什么、以及一套从写记忆文件到设计项目文档结构再到恢复会话的实践方案一次讲清楚。需要先说清楚如果你的目标只是随手生成几个单文件脚本上下文管理确实不是核心问题。但只要你开始用 Vibe Coding 做大一点的模块或者在一个项目里多次让 AI 修改不同文件这篇文章就比较适合你。下面内容不绑定特定工具尽量用 Codex CLI、Cursor、ChatGPT 桌面应用里都会遇到的现象来说明。1. Vibe Coding 中 Context 上下文管理的核心概念Vibe Coding 的上下文比传统提示工程里的上下文窗口范围更大它至少包含五类信息。最底层是模型的 token 上下文窗口任何一个大语言模型如果一次性收到的输入 token 数量超过上限服务端就会直接拒绝请求典型表现就是 HTTP 400 错误。你在命令行里看到 api error: 400 this models maximum context length is 1048576 tokens 时说明当前请求已经超过模型可接受的最大 token 数这一轮对话直接中断。但 Vibe Coding 中的上下文不只是 token 数量问题还包括整个工作区的可见信息。下面这张表列出了常见的上下文组成部分上下文组成部分例子什么时候失效对话历史你之前说过的需求、AI 的回复、你的修正会话被压缩、新开会话项目文件内容代码、README、配置文件、测试文件文件超长被截断、索引不完整指令约束命名规范、技术栈选型、禁止事项被后续信息覆盖、自动压缩丢失工具输出终端日志、测试结果、lint 反馈单轮 token 上限超长日志被截断外部记忆AGENTS.md、CLAUDE.md、requirements.txt文件不存在或没有自动加载你会发现AI 是否记得一切这句话本身就是伪命题。Vibe Coding 工具不是把整个项目永久加载进模型而是每次请求时把它认为需要的信息组装进上下文。一旦信息量超过窗口或者工具决定压缩旧对话最早期的高价值指令就会被降级。这里有个反直觉的事实上下文窗口越大不代表管理越容易。比如一个模型支持 1048576 tokens看起来已经非常大但如果你真的把接近 100 万 token 的内容全部塞进去模型对最早期约定的注意力会显著下降推理速度变慢输出质量波动长上下文幻觉反而成了新问题。所以 Context 管理从来不是省 token 的财务问题而是保证 AI 输出可控的工程问题。2. 三个最常见的上下文错误场景2.1 API 400上下文长度超限类似错误信息api error: 400 this models maximum context length is 1048576 tokens. howeve...这是最刚性的错误。当你把整个项目代码、对话历史、系统提示、工具结果一次性打包发给模型且 token 总和超过模型上限时API 直接拒绝。出现这种错误第一反应不应该是换一个更大上下文的模型而是检查你这轮请求到底带了什么。常见的元凶包括编辑器把整个项目的全部文件内容注入上下文终端工具把几 MB 的构建日志直接传回模型你手动全选复制粘贴了多个文件工具配置里设置了自动加载所有 Markdown 文档。排查方法也很直接把上下文来源拆开逐个文件排查。哪个文件最大哪个就先优化。实际操作中单文件超过 500 行就要考虑是否只需要其中一部分。代码里往往只有入口函数、类型定义和关键逻辑需要模型看到其余大段代码更像参考文件没必要每次都完整加载。2.2 窗口耗尽需要开启新会话类似错误信息codex ran out of room in the models context window. start a new thread or c...这不是 400 硬报错而是客户端自己检测到上下文接近上限提示你模型上下文窗口空间不足请新开一个线程或者压缩当前会话。从实际使用场景来看Codex CLI 这类工具做的是当前会话的对话历史 当前工作区文件维度管理。当历史积累到一定程度它会提醒你。如果你选择忽略提醒继续在超长对话中硬撑输出质量会迅速下滑经常出现忽略上一轮修改、重复输出已有代码、记错文件路径等情况。正确做法是把这种提示当成重构时机。不是继续硬撑而是把当前已完成的内容固化到代码仓库里清空会话重新开始。你可能会担心新会话里 AI 什么都不记得但只要你把需求和进度写清楚它从文件里重建上下文的速度远比你在一堆半废弃的旧对话里翻找要快得多。2.3 自动压缩失败类似错误信息context is too large and auto-compaction could not recover this turn. try a...这是很多桌面 AI 编程工具的自动压缩机制。当上下文超过窗口时客户端会触发一次压缩把前文摘要化成短文本继续对话。如果压缩后的摘要和当前轮次的问题冲突或者压缩过程本身失败就会出现这个提示。自动压缩失败后AI 往往不知道上一轮改了什么却仍然尝试继续工作。表现是开始胡编已有接口、把不存在的变量当成默认值、修改一个无关文件。这种情况下最快的恢复路径是检查最近一次 Git 提交或保存的状态把当前需求和成果写成一个任务总结然后新开会话让 AI 基于文档继续。不要指望在失败会话里一直点击重试那样大概率只会浪费时间。2.4 隐式遗忘没有报错但输出质量崩了比报错更常见的其实是没有报错但模型忘了。典型特征包括前面几轮约定了src/utils/存放工具函数后续 AI 却创建了utils/你反复强调不要修改测试文件但某次它还是动了项目采用了某个特定 API 版本但 AI 在生成代码时却使用了另一个版本。这种问题不会触发任何错误信息却会持续污染代码库。出现这种问题通常意味着会话里早期指令已经被长对话覆盖模型只能从最近的几轮对话里找线索。这个问题的根源就在于高价值指令没有溢出到长期记忆而 Context 管理要解决的正是这一点。3. 上下文管理核心策略从工程视角看Vibe Coding 的上下文管理可以拆成三个层次记忆层、会话层、项目层。3.1 记忆层让关键指令溢出到文件最重要的策略是把你不希望 AI 忘掉的事情写进项目根目录下的持久化文件。常见的做法是维护一份AGENTS.md或CLAUDE.md。这类文件的作用不是给人类同事看而是让 AI 每轮都能自动读取。工具在启动新会话时经常会自动扫描这类文件并注入系统提示从而替代你每次重复口头约定。一个最小可用的AGENTS.md示例# AGENTS.md ## 项目概述 这是一个 Python 3.11 的 CLI 工具用于批量处理 Markdown 文件的目录结构。 ## 技术栈约定 - Python 3.11 Typer - 测试框架使用 pytest - 生产代码禁止使用 typing.Any - 所有函数必须显式声明返回类型 ## 目录结构 src/ # 源代码 src/utils/ # 工具函数 tests/ # 测试文件 请勿在 tests/ 目录之外创建测试文件。 ## 常见任务 - 新增功能在 src/ 下创建模块并在 tests/ 中添加对应测试。 - 批量重构只重构 src/ 内部文件不调整入口脚本之外的外部接口。 ## 操作禁区 - 不要直接提交到 main 分支。所有修改通过工作流生成的 PR。 - 不要删除其他模块的导出函数除非确认全局搜索没有引用。这个文件本身不需要很长。核心是把你一定会反复强调的约束从对话中剥离固化到文件级。这样即使你新开一个会话AI 打开项目时也能看到这些约定不需要依赖上一场对话的记忆。3.2 会话层上下文预算每个会话一开始你可以先在心里给上下文分配预算用途预算占比经验值例子系统提示与工具说明5% ~ 10%工具自动注入的指令项目文档与 AGENTS.md10% ~ 20%README、AGENTS.md、目录结构需求描述10% ~ 20%本次要做什么、不要做什么对话历史30% ~ 50%之前的需求、修正、评审代码与工具输出20% ~ 40%当前文件、测试输出、终端日志这不是精确公式但能帮你判断如果这轮对话已经超过 30 轮历史预算是不是用得太多。高频操作建议改成一个会话一个目标一个会话只完成一个功能点或修一个 bug。做完之后提交代码新开会话。这种习惯比任何技巧都能显著降低上下文压力。3.3 项目层用结构代替记忆AI 记不住src/utils/formatter.py里面有什么很正常因为它不会每次把所有文件读一遍。解决办法是让项目的结构自解释在README.md里写清楚模块职责使用pyproject.toml、package.json等标准文件让 AI 能快速识别项目类型在关键模块头部保留一行注释写清楚这个模块的职责和注意事项不要把业务逻辑都塞进main.py或app.ts里拆成职责单一的小文件AI 每次只读取需要的部分。只要项目结构清晰AI 每次新开会话时都能通过AGENTS.md、README 和目录结构快速重建上下文而不是依靠上一场对话的模糊记忆。3.4 知识库与索引当项目规模更大时可以考虑外部知识库方案。一种方向是基于知识图谱的上下文组织把项目的入口模块、类型定义、公共函数、业务实体整理成一个索引文件让 AI 在进入具体编码之前先通过一个项目地图建立全局认知。另一种方向是元上下文工程也就是在 AI 的指令模板里规定它自己在长任务中必须定期总结进度、写入进度文件让模型学会自组织上下文减少人工介入。这两种方向都比较重初期不必上。对大多数项目先写好AGENTS.md、做好会话拆分已经能解决大部分上下文问题。4. 实战从报错恢复上下文假设你已经在用某个 Vibe Coding 工具写项目突然遇到context is too large怎么办下面给出一套恢复流程。4.1 第一步检查版本控制状态git status git diff --stat先搞清楚当前代码处于什么状态哪些文件是这次想要保留的哪些是 AI 改乱的。如果你还没有使用 Git现在就开始用。Vibe Coding 场景下Git 就是 AI 的后悔药也是上下文恢复的底座。没有版本控制你很难在报错后安全地清理现场。4.2 第二步整理当前需求把当前会话里最重要的几条需求写成一个任务总结。这个总结要短但要包括当前目标、已完成部分、未完成部分、需要避免的坑、相关文件路径。示例# TASK SUMMARY 目标为 CLI 工具增加批量替换文件后缀功能。 已完成 - 新增类型 FileRenameTask字段 src、dest。 - 增加 rename_batch 函数处理单目录替换。 未完成 - 需要添加目录递归选项 --recursive。 - 需要补充 pytest 用例。 注意 - 替换逻辑必须处理文件名冲突。 - src 和 dest 不能相同。 - 不要修改现有 batch.py 的接口。4.3 第三步新开会话并引用文件新开一个会话然后把AGENTS.md、任务总结和相关源码目录告诉 AI让它回到工作区重新开始。这样做有两个好处一是避免旧会话里大量废对话占用 token二是让 AI 从干净的视角重新审视代码库而不是在旧对话的错误上下文里继续打转。这套流程不仅适用于自动压缩失败同样适用于模型开始频繁说胡话、改错文件、反复输出同一段代码的情况。你不需要每次都把完整历史复制过去只需要把当前状态和下一步目标写清楚。5. 在常见 Vibe Coding 工具中的落地5.1 Codex CLI 风格Codex CLI 这类命令行工具重点观察它的上下文用量提示。当它提示 ran out of room 时不要按继续而是走到上一节的恢复流程。同时工具的工作目录就是上下文扫描的重要来源尽量保持工作目录精简不要把无关项目文件放在同一个目录里否则 AI 会把无关文件也纳入扫描范围。5.2 编辑器插件风格像 Cursor 这类编辑器插件会让你选择哪些文件加入上下文。建议默认不勾选全部文件只加当前编辑文件和关联模块利用项目级配置文件持久化约束不要在一次对话里同时让 AI 改十几个文件拆成多轮会话。尤其是进行跨文件重构时更不要一次性把所有文件都塞进去一定要等模型先梳理出调用关系再分批次修改。5.3 平台 API 风格如果你正在写程序调用某个大模型 API并且遇到 400 上下文超限需要在代码层做上下文窗口预检。示例import tiktoken def count_tokens(text: str, model: str gpt-4o) - int: enc tiktoken.encoding_for_model(model) return len(enc.encode(text)) MAX_CONTEXT_TOKENS 1_048_576 # 按实际模型上限调整 SAFETY_LIMIT int(MAX_CONTEXT_TOKENS * 0.8) def make_payload(system_prompt: str, history: list[dict], prompt: str) - dict: total count_tokens(system_prompt) for msg in history: total count_tokens(str(msg)) total count_tokens(prompt) if total SAFETY_LIMIT: raise ValueError( fcontext too large: {total} tokens, fsafety limit is {SAFETY_LIMIT} ) return { system: system_prompt, messages: history, prompt: prompt, }这只是伪代码具体实现要以你的 SDK 为准但核心思想不变在请求到达 API 之前做一次预算检查而不是等 400 报错出来后再去救火。5.4 长上下文模型的取舍当前很多模型在宣传超长上下文最高可以达到 1048576 tokens 甚至更高。这确实能减少一部分超限错误但它不会消除上下文管理需求。原因很简单你传给模型的内容越多模型在推理时对不同信息段的注意力就越分散。在只剩 10% 上下文的会话里继续工作效果远比一个新会话加完整约束更差。所以即使模型支持 100 万 token也要把它看成不会触底的缓冲区而不是随便喂的垃圾桶。真正可持续的做法仍然是把关键信息放进文件让每次请求保持精简。6. 批量项目的上下文管理实践当你在做一个包含多个模块的长周期项目可以用任务票据的方式组织上下文。6.1 任务票据式上下文在项目根目录建立context/目录context/ AGENTS.md task-001-user-auth.md task-002-file-upload.md task-003-status-page.md每个任务文件里写清楚目标、涉及文件、验收标准、注意事项。开始一个新会话时让 AI 读取当前任务票据而不是凭旧会话记忆。这种做法对多模块项目特别有用因为不同任务之间往往没有太多交集AI 不需要把所有模块的历史都塞进上下文。6.2 自动总结循环更进阶的做法是在工具层面设置阶段性总结。每完成一个任务要求 AI 将关键决策追加到CHANGELOG.md或DECISIONS.md。这样即使在很长的开发周期里AI 打开项目时也能从文档中恢复上下文而不是只能依赖上一次对话。你可以把它理解成给 AI 写工作日志这个日志本身就是项目资产。如果同时处理多个任务建议不要并行开太多会话否则你很难跟踪每个会话的上下文状态。不如一个会话对应一个任务任务完成后结束会话下一个任务再开新会话。这样上下文管理的成本最低。7. 问题排查清单问题现象可能原因排查方式解决方案API 报错 400提示 token 超限请求携带上下文过多检查工具是否自动注入全目录文件减少文件注入、用 token 计数预检工具提示窗口空间不足会话历史太长查看工具状态栏或提示信息新开线程先整理 TASK SUMMARY自动压缩失败上下文过大或摘要冲突检查 Git diff确认当前状态新开会话重新加载 AGENTS.md模型忘记早期约定信息被长对话淹没问模型你还记得哪条约束把约束写进 AGENTS.md会话内尽量少重复生成代码使用旧接口上下文里出现多个版本示例检查项目文档和 API 文档固定 API 版本描述并写入文档模型改乱无关文件上下文覆盖过多文件路径查看 diff 中的非预期修改限定本次任务只允许修改白名单文件输出内容越来越长且重复上下文没有有效压缩查看每轮 token 消耗精简历史重新组织指令这份清单只是排查思路具体到不同工具会有差异但整体逻辑一致先确认上下文来源再固定长期记忆最后用新会话恢复。8. 版权、隐私与合规提醒Vibe Coding 过程中你可能会把项目代码、内部 API 文档、甚至未公开的产品需求粘贴到 AI 工具中。这里有几个需要特别注意的边界。如果是企业内部项目先确认你使用的工具或 API 服务的数据处理协议明确代码是否会上传到外部服务。不要在公共工具中粘贴包含密钥、用户隐私、商业机密的内容。对于开源项目关注生成代码的许可证以及训练数据中可能存在的版权问题。如果涉及他人的代码或素材确保授权范围允许复制、修改或重新分发。上下文管理不仅是技术问题也包含数据边界管理。你给 AI 的上下文越少越精简数据暴露面就越小。所以精简上下文这件事从安全和合规角度也值得做。9. 总结与实践展望Vibe Coding 的上下文管理核心不是让 AI 记得更多而是让 AI 每次只读最关键的信息并且让关键信息沉淀到项目文件里。最值得先做的三件事在项目根目录创建AGENTS.md把最核心的三条约束写进去一个功能点拆成一个独立会话做完就提交并新开会话遇到context is too large或自动压缩失败时先整理 TASK SUMMARY再恢复会话。当你开始按照记忆文件 会话预算 项目管理这套组合运转时AI 的代码变更稳定性会明显提升误改文件、忘记约定这类问题会大幅减少。上下文管理不是一次性配置而是要随着项目规模持续调整。建议收藏这篇下次遇到上下文溢出时回来对照排查。