企业官网建设流程全解析

Vibe Coding 这个概念火起来之后，很多人的第一反应是“把需求描述清楚，AI 就能把代码写好”。实际用 Cursor、Codex CLI、Claude Code 这类工具写两个功能就会撞上同一堵墙：Context 上下文管理。对话越长，模型越容易“失忆”；文件贴得越多，越容易看到上下文超限报错。

如果你在 AI 编程工具里遇到过下面任意一条提示，那这篇就是写给你的：

• api error: 400 this model's maximum context length is 1048576 tokens
• codex ran out of room in the model's context window. start a new thread or ...
• context is too large and auto-compaction could not recover this turn

这些报错不是显卡不够，也不是模型太笨，而是 Context 没管好。这篇文章把 Vibe Coding 里的上下文管理讲透：先看 Context 的运作机制，再拆解五条可落地的管理策略，然后分别讲 Cursor、Codex CLI、Claude Code 的实际操作方式，最后给出接口 API 场景下的裁剪与重试示例，以及一张排查清单。适合正在用 AI 写代码，但经常被“模型忘记需求”“上下文超限”“自动压缩后质量下降”打断的开发者。

1. Vibe Coding + Context 核心概念速览

先把概念对齐，后面讲策略才不会飘。

从当前 Vibe Coding 生态的反馈看，上下文管理已经从“高级技巧”变成了“必备技能”。原因是 AI 编程工具默认会把当前会话里的对话、文件内容、终端输出一起送进模型。会话越长，上下文越大，最后就会撞上模型上限。很多人在同一个会话里连续改十几个文件，不改上下文策略，后面 AI 会一边说“好的”，一边把代码改回旧版本。本质上就是 Context 里最关键的信息被冲掉了。

还有一个容易被忽略的点：不同模型的上下文窗口差异很大。有的模型单次只能处理 32K token，有的模型开放到 128K，甚至出现报错里提到的 1048576 tokens（约 1M）超大窗口。窗口越大，能塞进去的代码越多，但成本也在涨。Vibe Coding 里真正要学的，不是记住每个模型的窗口大小，而是养成“主动控制上下文”的习惯。

2. Vibe Coding 为什么容易撞上 Context 瓶颈

Vibe Coding 的工作方式天然就会膨胀上下文。它和传统 IDE 补全不一样，不是只把光标附近几行代码送给模型，而是把整个会话的“记忆”都带上。这意味着三个叠加的因素：

第一，对话历史是线性增长的。你在会话里说“加一个上传按钮”，AI 做了；你说“按钮放右边”，AI 改了；你说“组件名改成 UploadImage”，AI 又动了。这些来回对话会一直保留，直到把窗口撑满。第二，文件内容是按整文件或者大片段送进去的。一个 500 行的 React 组件可能就要几千 token，一次 @ 三个文件，很快窗口就满了。第三，终端输出和报错堆栈也是个大头。一次编译报错可能就有几千 token，调试三轮，上下文直接爆掉。

从材料里的热词能看出，这是非常普遍的现状：有人遇到 maximum context length 400 错误，有人遇到 codex 提示开新线程，有人遇到 auto-compaction 也救不回来。这些不是个别现象，而是 Vibe Coding 规模化使用后的必然问题。

可以先给膨胀来源做个归类：

理解了膨胀来源，就能理解后面的管理策略：要么减少输入量，要么把历史“压缩”成可复用的摘要，要么干脆开新会话重新开始。这三点是后面所有方法论的底层逻辑。

3. Context 运行机制与常见报错解读

要理解 Context 报错，先理解模型的处理流程。每次请求时，客户端会把消息列表（system 指令 + 历史对话 + 当前用户输入）编码成 token，一起发给模型。模型在上下文窗口内做推理。如果总 token 数超过窗口上限，服务端会返回 400 错误；如果没超限但接近上限，模型的表现也会明显下降，因为注意力被大量无关信息稀释了。

所谓 Auto Compaction（自动压缩），是某些工具在上下文接近上限时，自动把早期对话改写成一段摘要，然后删掉原文。这个机制能延长会话寿命，但有代价：摘要不可能保留所有细节。压缩一两次还能用，压缩三四次之后，模型可能连项目技术栈都记不清了，这时就会出现“context is too large and auto-compaction could not recover this turn”这种无法恢复的情况。

常见报错可以做成一张对照表：

注意最后两类：不是所有带 context 的报错都是上下文窗口问题。容器命令、网络通信也可能报 context 相关错误。排查时要看完整报错，别一看到 context 就去删对话。

4. Context 上下文管理五大策略

4.1 任务拆分：一个会话只做一件事

Vibe Coding 最常见的错误是“一个会话干完整个项目”。从写接口到改样式到调部署，全在一个会话里，最后上下文必然失控。更好的做法是按任务粒度拆会话：每个会话只解决一个明确问题。

比如开发一个图片上传组件，可以拆成四个独立的会话：

1. 会话一：生成组件基础结构，确认 props 和事件接口。
2. 会话二：实现拖拽上传和进度条逻辑。
3. 会话三：联调后端接口，处理错误状态。
4. 会话四：写单元测试和文档。

每个会话结束时，把结论写进项目文档。这样新会话不需要继承旧对话，也能通过文档恢复上下文。任务拆分的核心收益是：把“长对话依赖”替换成“短对话 + 文档依赖”。

4.2 新会话 + 项目摘要：用文档传承上下文

当会话已经很长，或者模型开始答非所问时，最直接的恢复手段就是开新会话。但单纯开新会话会丢失所有上下文，所以要在开之前做一次“上下文交接”。

交接动作是：把当前进度整理成一段结构化摘要，包含项目技术栈、已完成功能、当前遇到的问题、下一步计划。然后把摘要粘贴到新会话的第一条消息里。这个思路和工程师交接工作是一样的，只是对象从同事换成了 AI。

社区里现在流行把这类摘要沉淀成项目根目录下的 AGENTS.md 或 CLAUDE.md 文件，里面写清楚项目约定、目录结构、常用命令。新会话开始时直接让 AI 读这个文件，相当于把上下文“外置”了。这样即使会话被清空，关键信息也不会丢。

4.3 规则文件固化约定

Vibe Coding 里经常出现一种情况：同一个约束要反复强调。比如“组件用函数式”“样式用 Tailwind”“接口统一走 /api 前缀”。每开一个新会话都要重新说一遍，既占 token，又容易漏。

解决方案是把约定写进规则文件。Cursor 系列工具支持项目级规则文件，Claude Code 支持 CLAUDE.md，其他 agent 工具也陆续支持类似机制。规则文件的内容可以包含：

# 项目固定约定 技术栈: React 18 + TypeScript + Vite 状态管理: zustand 样式: Tailwind CSS 组件规范: 函数组件 + hooks，禁止 class 组件 公共函数统一放在 src/utils 接口请求统一封装在 src/api

规则文件本身是上下文的一部分，但它把“每次都要重复说的内容”变成了“一次写好、长期复用”。这是性价比最高的上下文管理手段之一：既减少了每次会话的 token 消耗，又保证了多会话之间的行为一致性。

4.4 主动裁剪输入：只贴关键片段

很多上下文超限问题，不是模型窗口太小，而是人为塞了太多不必要的内容。常见操作是：把整个 800 行的文件直接粘贴给 AI，只为了改其中 20 行。

正确做法是主动裁剪输入。改一个函数，只贴这个函数和它的调用处；排查一个报错，只贴报错堆栈和附近代码，而不是整个终端输出。如果 AI 需要了解完整文件，再考虑用工具的文件引用功能，让 AI 按需读取，而不是把所有文件一次性塞进去。

这里可以记住一个经验法则：输入给 AI 的每一段内容，都要能回答“这段信息对当前任务有什么用”。回答不上来，就不要贴。主动裁剪不是省 token 的问题，而是让模型把注意力集中在真正重要的事情上，输出质量会明显提升。

4.5 外部记忆与检索：把上下文放到模型外面

还有一种思路是把上下文从会话里挪出去，用外部工具管理。比如把项目文档、接口文档、历史决策记录放在独立目录，AI 需要时再通过检索或文件引用读取，而不是全程放在对话里。

这种方式适合大型项目。一个项目的完整上下文可能超过 100K token，根本无法长期放在会话里。但通过外部检索，可以让 AI 只加载和当前任务相关的片段。比如在 Cursor 里用 Codebase 检索，在终端 agent 里用 grep / rg 查找关键代码，然后再让 AI 基于检索结果工作。这也是“Context Engineering”的方向：不是把上下文变大，而是让模型在正确的时间拿到正确的上下文。

5. 主流 Vibe Coding 工具的上下文管理实践

5.1 Cursor：新对话 + 规则文件

Cursor 是目前 Vibe Coding 使用率最高的编辑器之一。它把 AI 能力和编辑器深度绑定，但这也意味着上下文很容易被代码库体积撑爆。Cursor 里的上下文管理主要靠三个动作：

第一，善用新对话。发现模型开始“乱改”或“忘需求”，不要继续硬聊，直接开新对话，并把关键需求重新描述一遍。第二，用规则文件固化项目约束，路径通常放在项目的 .cursor/rules 目录下，AI 会自动加载。第三，控制 @ 的粒度。不要一次性 @ 整个目录，而是按需引入具体文件或函数。如果用了代码库索引功能，也要注意检索结果会占用上下文，不要每次对话都无脑触发全库检索。

5.2 Codex CLI：用新线程换干净上下文

Codex CLI 这类终端 agent 的特点是会在会话里累积大量终端输出和执行记录。跑一次测试、执行一条命令，输出都会被记进上下文。所以用 Codex CLI 写代码时，很容易遇到官方报错提示：上下文窗口没空间了，建议开新线程。

从实际使用体验看，Codex CLI 的上下文管理要点有三个：

1. 定期开新线程，不要试图在一个线程里完成所有事。
2. 开新线程前，把当前进度、文件改动、剩余任务整理成一个“交接摘要”粘贴进去。
3. 减少无关命令输出。比如只在需要时让 agent 执行测试，而不是每次都跑全量检查。

5.3 Claude Code：压缩与记忆文件

Claude Code 这类工具提供了/compact这类主动压缩会话的指令，也有/clear清空历史的指令。主动压缩比被动触发 Auto Compaction 更可控：你可以选择在合适的时机压缩，而不是等模型“快撑不住”时才被迫压缩。

但压缩仍然会丢信息，所以 Claude Code 系列工具同样强调项目记忆文件。常见的做法是在项目根目录维护 CLAUDE.md，里面写清项目结构、构建命令、代码规范。每次会话开始，AI 会读取这个文件，相当于用一份几百 token 的文档替代几万 token 的会话历史。这套思路也适合其他支持自定义指令文件的 agent 工具。

5.4 一套通用工作流

把上面的工具实践抽象一下，可以得到一套不依赖具体工具的通用工作流：

1. 会话开始前：检查规则文件和项目文档，确保 AI 能读到最新约定。
2. 会话中：每次只让 AI 做一个小任务，控制输入内容量。
3. 会话结束前：把本次改动和结论追加到项目文档。
4. 会话报错或混乱时：开新会话，用交接摘要继续。
5. 定期审查：看项目文档是否过期，规则文件是否还能覆盖当前项目状态。

这套流程适合所有 AI 编程工具。工具之间的差异只是命令和界面的区别，底层逻辑是一致的。

6. 接口 API 场景下的 Context 管理

如果你不是用现成的 IDE 工具，而是直接调模型接口做代码生成工具，那 Context 管理就需要自己在代码里实现。这里给出一套通用的处理思路和示例代码。

6.1 Token 统计

首先需要能统计消息的 token 数。不同模型有不同 tokenizer，OpenAI 生态可以借助 tiktoken 库做初步估算：

import tiktoken def count_tokens(text: str, model: str = "gpt-4o") -> int: encoding = tiktoken.encoding_for_model(model) return len(encoding.encode(text)) def count_messages_tokens(messages, model="gpt-4o"): total = 0 for msg in messages: total += count_tokens(msg.get("content", ""), model) return total

注意：tiktoken 只能估算 OpenAI 系模型的 token。其他模型需要用各自的 tokenizer 或服务端返回的 usage 字段。

6.2 历史消息裁剪

当消息总 token 数超过阈值时，需要裁剪历史。常见策略是：保留 system 消息，保留最近 N 轮对话，丢弃最旧的中间轮次。如果一轮对话过大，还可以在单轮内继续截断：

def trim_history(messages, max_tokens=6000, model="gpt-4o"): system = [m for m in messages if m["role"] == "system"] history = [m for m in messages if m["role"] != "system"] budget = max_tokens - count_messages_tokens(system, model) trimmed = [] for msg in reversed(history): cost = count_tokens(msg.get("content", ""), model) if budget - cost < 0: break trimmed.append(msg) budget -= cost return system + list(reversed(trimmed))

这里采用“从最新消息往前保留”的顺序，因为对代码生成任务来说，最近的指令通常比最初的寒暄更有价值。

6.3 请求异常重试

上下文超限时报错通常是 400。比较好的做法是捕获这类错误，先裁剪消息，再重试一次。如果裁剪后依然失败，再考虑换模型或彻底缩短任务：

import time from openai import OpenAI, BadRequestError client = OpenAI() def chat_with_context_retry(messages, max_retries=3): for attempt in range(max_retries): try: response = client.chat.completions.create( model="your-model", messages=messages, max_tokens=2048, ) return response.choices[0].message.content except BadRequestError as exc: if "maximum context length" in str(exc): print("上下文超限，裁剪历史后重试") messages = trim_history(messages) else: raise time.sleep(1 * (attempt + 1)) raise RuntimeError("上下文超限且重试失败")

6.4 长文档分片

如果是把长文档送给模型总结或改写，一次性发送很容易超限。常规做法是按固定长度分片，再逐片处理：

def split_document(text, chunk_size=2000): encoding = tiktoken.get_encoding("cl100k_base") tokens = encoding.encode(text) chunks = [] for i in range(0, len(tokens), chunk_size): chunks.append(encoding.decode(tokens[i:i + chunk_size])) return chunks

分片后可以并行处理或者串行处理，再把每片的结果合并。这个模式在做代码库文档总结、大型重构分析时非常实用。

7. Context 占用与性能观察

上下文管理不能只靠感觉，需要能估算、能观察。对于 Vibe Coding 来说，主要有四个观察维度。

第一个维度是 token 估算。经验上，1 个英文字符约为 0.25 到 0.33 个 token，1 个中文字符约为 0.75 到 1.5 个 token，具体取决于分词器。实用估算可以按“1000 个中文字符约 1500 到 2000 token”来算。知道了估算值，就能在粘贴大文件前判断是否会导致超限。

第二个维度是服务端用量。调用模型接口时，响应里通常会返回 usage 字段，包括 prompt_tokens、completion_tokens、total_tokens。建议在工具层把每次请求的 token 数打出来，形成日志。这样当上下文超限时，能快速定位是哪一轮请求涨上去的。

第三个维度是生成质量。上下文接近窗口上限时，回复延迟会增加，产生逻辑矛盾的概率也会增加。判断标准很简单：如果模型开始反复修改同一段代码，或者忘记了你十分钟前强调的约束，就该考虑压缩或开新会话了。

第四个维度是成本。Vibe Coding 工具大多是按照 token 计费的，上下文越长，单次请求成本越高。一个完整文件 5000 token，每轮对话都把它带上，十轮就是 50000 token。通过规则文件和裁剪策略把冗余输入降下来，省下的不只有时间，还有真金白银。

8. 常见问题与排查方法

排查时有个原则：先看报错在哪个层。模型层报错优先查上下文体积；工具层报错优先查配置和文件路径；网络层报错优先查连接和证书。不要把问题都归结到“上下文太大”，否则可能浪费时间。

9. 最佳实践与使用建议

把上面的策略落到日常工作中，可以沉淀成几条具体的工程化建议。

第一，小步提交。每次让 AI 完成一个小而明确的改动，然后立刻审查、提交、记录。不要攒着几十个改动一起让 AI 处理。小步提交能减少单次上下文压力，也能在 AI 出错时快速回滚。

第二，维护项目记忆文档。把技术栈、目录约定、命令、常见坑都写到项目文档里，并保持更新。这份文档是 Vibe Coding 项目的“磁盘缓存”，新会话靠它快速恢复。

第三，预先规划会话边界。开始一个任务前，先想清楚这个会话要做到哪一步为止，到边界就主动开新会话。不要让一个会话持续十几个小时。

第四，批量任务要做日志和重试。如果是批量调用 API 生成代码或文档，每个任务都要记录输入、输出、token 消耗和错误信息。失败任务要支持单独重跑，不要让一个超限错误中断整个队列。

第五，注意合规边界。把公司内部代码、客户数据、个人信息发送给云端 AI 工具之前，必须确认数据授权和脱敏要求。涉及敏感代码库时，优先选择可本地部署的模型。AI 生成内容的版权归属也需要按项目要求确认，商用前要做效果复核。

10. 总结与下一步

Vibe Coding 的门槛从来不是“会不会聊天”，而是能不能管住 Context。这篇文章从概念、机制、策略、工具、接口、排查六个层面把上下文管理讲了一遍。值得先记住的结论是：上下文管理不是让模型记住所有东西，而是决定哪些信息该进上下文、哪些不该进。

建议你先验证三件事：

1. 给当前项目补一个规则文件，把技术栈和代码约定写进去。
2. 在下一次会话开始时，用一段结构化摘要替代冗长的历史对话。
3. 在 API 调用场景里接入 token 统计和消息裁剪，观察上下文占用变化。

最容易踩的坑是过度依赖 Auto Compaction：总觉得模型会自动处理长上下文，直到某天报错说压缩也救不回来。宁可主动拆分和裁剪，也不要赌模型的自动摘要能力。

后续可以继续扩展的方向包括：项目级知识库建设、多 agent 协作时的上下文隔离、以及针对特定模型窗口大小做自动化的上下文调度。这些本质上都是 Context Engineering 的延伸。先把基础的五个策略用起来，再谈进阶玩法。