2026/8/31 17:04:09
FEATURED · 精选文章 
如果你正使用 Claude Code、Codex、Cursor 这类 AI 编程工具写代码大概率会遇到下面这些情况对话前几轮非常顺畅需求越聊越长之后AI 开始忘记最初的约束。明明只改一个文件AI 却反复提到无关目录里的历史代码。正在关键处工具突然提示context is too large或ran out of room in the models context window。换一个新窗口重新描述需求又花掉大量时间而且描述质量参差不齐。这些问题的根源往往不是模型不够聪明而是上下文Context没有被有效管理。在 Vibe Coding 的工作方式下“人机交互”不是一问一答而是围绕一个持续演进的项目展开的高频协作。模型能看见什么、看不见什么直接决定了代码生成的准确度、稳定性和效率。这是“每天一个 Vibe Coding 知识”系列中的一篇主题是Context 上下文管理。本文将先解释 Vibe Coding 和上下文的关系再拆解上下文的三个层次然后给出一套可以落到项目里的上下文管理方案最后整理常见报错与排查思路。无论你是刚开始接触 AI 编程的新手还是已经把 AI 工具接入日常开发的进阶用户都能从这篇文章里找到可复用的方法。1. 背景Vibe Coding 的兴起与上下文难题1.1 什么是 Vibe CodingVibe Coding 是最近两年在 AI 编程领域非常流行的一种开发方式。它的核心是开发者用自然语言描述意图AI 工具负责生成、修改、重构代码人则更多承担“方向定义”和“结果审查”的职责。“Vibe”这个词强调的是一种节奏感。在用 AI 写代码时开发者不需要把每一行代码都敲出来而是用对话的方式推进任务。你可以说“给订单模块增加一个导出 Excel 的功能”也可以说“用仓库里已经封装好的分页组件改造这个列表页面”。AI 会结合你提供的信息、项目里的既有代码和它自身的学习经验生成对应的实现方案。这种开发方式与“手工编程”相比最大的区别在于代码是模型根据上下文生成的而不是人手写出来的。因此模型对上下文的理解质量基本决定了代码质量。如果你给的信息太少模型会自由发挥如果你给的信息过载模型又会抓不住重点甚至直接触发长度限制报错。1.2 为什么“上下文管理”是 Vibe Coding 的核心技能很多初学者会把 Vibe Coding 理解成“会说话就能写代码”这是一个常见的误区。实际上越是在大规模项目中越需要刻意管理输入给模型的信息。原因主要有三点。第一模型的上下文窗口是有限的。不管是商业模型还是本地模型一次请求能接收的 Token 总量都有上限。一旦超过限制工具就会报错或者自动压缩历史压缩失败则直接中断。第二模型的注意力是会被稀释的。即使你的对话总长度还在窗口范围内当上下文里塞进了大量无关文件、无关讨论或重复内容时模型对真正关键信息的关注度也会下降。这一点在长会话里表现得尤其明显前面几轮的效果很好后面越改越偏。第三项目不是一次会话完成的。一个真实的业务功能往往需要跨多个会话、持续几周甚至几个月。如果上下文只存放在对话窗口中那么换一个新会话AI 就“失去记忆”如果上下文过于散乱AI 又会读到过期或互相冲突的规则。所以对 Vibe Coding 来说Context 管理不是“可选优化”而是让 AI 持续发挥价值的基础能力。1.3 一个典型的上下文失控场景我举一个常见的例子。假设你在做一个订单管理系统希望 AI 帮助在订单列表页增加“导出 Excel”的功能。第一轮你会把需求、技术栈、相关文件路径都告诉模型它很快给出了一个基本方案代码也能跑通。第二轮你发现导出的日期格式不对又让它修改。第三轮你顺带问了一个关于分页的问题。到第五轮你想让 AI 继续优化导出性能时它突然开始遗忘之前约定的字段命名规范导出的表头变成了默认英文名再往下走你发现它把改动的范围扩大到了数据库脚本、权限配置甚至开始讨论一个完全不相关的模块。最后当你试图让它一次性总结所有改动时工具抛出了类似context is too large的报错或者要求你开启新的线程。这个场景的本质是对话上下文在持续膨胀而原有约定并没有被持久化到项目里。AI 每次生成时都只能看到最近几轮的局部信息同时上下文占用率越来越高输出的稳定性自然越来越差。2. 理解上下文的三个层次上下文不是一个单一的、静态的概念。在不同场景下“Context”代表的东西完全不同。如果混为一谈管理起来就容易抓错重点。我在实际项目中习惯把它拆成三层来理解模型层面的上下文窗口、交互层面的会话上下文、仓库层面的项目上下文。这三层相互影响但管理策略完全不同。理解了这三层再看报错、写规则文件、优化对话策略思路都会清晰很多。2.1 Context Window模型一次能看到的 Token 范围第一层是模型层面的上下文窗口Context Window。它指的是模型在一次请求中最多可以读取的 Token 数量。Token 是模型处理文本的最小单元英文通常一个单词拆成一到两个 Token中文一个汉字平均接近一个 Token不同分词策略会有差异。上下文窗口的大小通常在几万到几十万 Token 不等部分新模型已经达到百万级。窗口越大模型能“同时看到”的信息就越多但对应的计算成本和单次调用成本也越高。在使用 AI 编程工具时上下文窗口会被以下几部分内容占用系统提示词System Prompt也就是工具内置的角色和指令。用户提供的任务描述。项目文件片段比如工具自动读取的当前文件、相关文件或规则文件。多轮对话的历史记录。因此即使不主动粘贴大量代码工具的一举一动也会消耗 Token。当你手动把一整个项目的源码复制给 AI 时很可能瞬间就触达了窗口上限。2.2 会话上下文多轮对话中的历史信息第二层是会话上下文Conversation
Vibe Coding上下文管理：从窗口到项目的三层策略
如果你正使用 Claude Code、Codex、Cursor 这类 AI 编程工具写代码大概率会遇到下面这些情况对话前几轮非常顺畅需求越聊越长之后AI 开始忘记最初的约束。明明只改一个文件AI 却反复提到无关目录里的历史代码。正在关键处工具突然提示context is too large或ran out of room in the models context window。换一个新窗口重新描述需求又花掉大量时间而且描述质量参差不齐。这些问题的根源往往不是模型不够聪明而是上下文Context没有被有效管理。在 Vibe Coding 的工作方式下“人机交互”不是一问一答而是围绕一个持续演进的项目展开的高频协作。模型能看见什么、看不见什么直接决定了代码生成的准确度、稳定性和效率。这是“每天一个 Vibe Coding 知识”系列中的一篇主题是Context 上下文管理。本文将先解释 Vibe Coding 和上下文的关系再拆解上下文的三个层次然后给出一套可以落到项目里的上下文管理方案最后整理常见报错与排查思路。无论你是刚开始接触 AI 编程的新手还是已经把 AI 工具接入日常开发的进阶用户都能从这篇文章里找到可复用的方法。1. 背景Vibe Coding 的兴起与上下文难题1.1 什么是 Vibe CodingVibe Coding 是最近两年在 AI 编程领域非常流行的一种开发方式。它的核心是开发者用自然语言描述意图AI 工具负责生成、修改、重构代码人则更多承担“方向定义”和“结果审查”的职责。“Vibe”这个词强调的是一种节奏感。在用 AI 写代码时开发者不需要把每一行代码都敲出来而是用对话的方式推进任务。你可以说“给订单模块增加一个导出 Excel 的功能”也可以说“用仓库里已经封装好的分页组件改造这个列表页面”。AI 会结合你提供的信息、项目里的既有代码和它自身的学习经验生成对应的实现方案。这种开发方式与“手工编程”相比最大的区别在于代码是模型根据上下文生成的而不是人手写出来的。因此模型对上下文的理解质量基本决定了代码质量。如果你给的信息太少模型会自由发挥如果你给的信息过载模型又会抓不住重点甚至直接触发长度限制报错。1.2 为什么“上下文管理”是 Vibe Coding 的核心技能很多初学者会把 Vibe Coding 理解成“会说话就能写代码”这是一个常见的误区。实际上越是在大规模项目中越需要刻意管理输入给模型的信息。原因主要有三点。第一模型的上下文窗口是有限的。不管是商业模型还是本地模型一次请求能接收的 Token 总量都有上限。一旦超过限制工具就会报错或者自动压缩历史压缩失败则直接中断。第二模型的注意力是会被稀释的。即使你的对话总长度还在窗口范围内当上下文里塞进了大量无关文件、无关讨论或重复内容时模型对真正关键信息的关注度也会下降。这一点在长会话里表现得尤其明显前面几轮的效果很好后面越改越偏。第三项目不是一次会话完成的。一个真实的业务功能往往需要跨多个会话、持续几周甚至几个月。如果上下文只存放在对话窗口中那么换一个新会话AI 就“失去记忆”如果上下文过于散乱AI 又会读到过期或互相冲突的规则。所以对 Vibe Coding 来说Context 管理不是“可选优化”而是让 AI 持续发挥价值的基础能力。1.3 一个典型的上下文失控场景我举一个常见的例子。假设你在做一个订单管理系统希望 AI 帮助在订单列表页增加“导出 Excel”的功能。第一轮你会把需求、技术栈、相关文件路径都告诉模型它很快给出了一个基本方案代码也能跑通。第二轮你发现导出的日期格式不对又让它修改。第三轮你顺带问了一个关于分页的问题。到第五轮你想让 AI 继续优化导出性能时它突然开始遗忘之前约定的字段命名规范导出的表头变成了默认英文名再往下走你发现它把改动的范围扩大到了数据库脚本、权限配置甚至开始讨论一个完全不相关的模块。最后当你试图让它一次性总结所有改动时工具抛出了类似context is too large的报错或者要求你开启新的线程。这个场景的本质是对话上下文在持续膨胀而原有约定并没有被持久化到项目里。AI 每次生成时都只能看到最近几轮的局部信息同时上下文占用率越来越高输出的稳定性自然越来越差。2. 理解上下文的三个层次上下文不是一个单一的、静态的概念。在不同场景下“Context”代表的东西完全不同。如果混为一谈管理起来就容易抓错重点。我在实际项目中习惯把它拆成三层来理解模型层面的上下文窗口、交互层面的会话上下文、仓库层面的项目上下文。这三层相互影响但管理策略完全不同。理解了这三层再看报错、写规则文件、优化对话策略思路都会清晰很多。2.1 Context Window模型一次能看到的 Token 范围第一层是模型层面的上下文窗口Context Window。它指的是模型在一次请求中最多可以读取的 Token 数量。Token 是模型处理文本的最小单元英文通常一个单词拆成一到两个 Token中文一个汉字平均接近一个 Token不同分词策略会有差异。上下文窗口的大小通常在几万到几十万 Token 不等部分新模型已经达到百万级。窗口越大模型能“同时看到”的信息就越多但对应的计算成本和单次调用成本也越高。在使用 AI 编程工具时上下文窗口会被以下几部分内容占用系统提示词System Prompt也就是工具内置的角色和指令。用户提供的任务描述。项目文件片段比如工具自动读取的当前文件、相关文件或规则文件。多轮对话的历史记录。因此即使不主动粘贴大量代码工具的一举一动也会消耗 Token。当你手动把一整个项目的源码复制给 AI 时很可能瞬间就触达了窗口上限。2.2 会话上下文多轮对话中的历史信息第二层是会话上下文Conversation 
