# 上下文管理 (/zh-CN/docs/verdent-for-vscode/best-practices/context)
> 有效管理上下文以获得更好的结果
***
有效的上下文管理能确保 Verdent 在正确的时间获得正确的信息，同时避免因上下文过载导致的性能下降。
### 你将学到什么 [#你将学到什么]
* 理解上下文窗口及其限制
* 有策略地选择文件以获得最佳上下文
* 识别并应对上下文过载
* 何时重置上下文以获得更好的性能
* 工作区组织方式如何影响上下文
***
## 理解上下文窗口 [#理解上下文窗口]
Verdent for VS Code 的上下文窗口大小取决于所使用的模型。
大多数模型使用标准的 `200K` 上下文窗口：
* **Claude 4.5 Sonnet** —— 适合复杂任务的均衡选择
* **Claude 4.5 Haiku** —— 快速高效
* **GPT-5** —— 推理能力出色（Beta）
* **GPT-5-Codex** —— 为编码优化（Beta）
**容量：**
* 约 `200,000` tokens 的总记忆容量
* 足以应对大多数开发任务和中型项目
**包含的内容：**
* 对话中的所有消息
* 加载进上下文的文件内容
* 工具输出和响应
* 系统提示词和指令
* MCP 服务器定义
**性能：**
* 接近上限时会明显下降
* 注意上下文过载的信号（响应变慢、输出准确度降低）
* 更频繁地重置上下文以获得最佳性能
当显式选择，或输入超过 `200K` tokens 时，Claude Sonnet 4.5 提供扩展上下文（`1M` tokens）。
**容量：**
* `1,000,000` tokens 的总记忆容量
* 比标准模型大 5 倍
**优势：**
* 非常适合无需分块就能加载整个大型代码库
* 消除了大型项目中的大部分上下文管理顾虑
* 在触及上下文上限前可工作更长时间
* 需要重置会话的次数更少
**何时使用：**
* 包含 `1000+` 文件的大型代码库
* 跨整个项目的复杂多文件重构
* 横跨多个相关任务的长时间开发会话
* 当你希望尽量减少上下文管理开销时
***
## 有策略地选择文件 [#有策略地选择文件]
选择文件时要有策略，以优化上下文使用并避免触及上限。
先从较少的文件开始，仅在需要时再添加，Verdent 在对话中随时可以读取更多文件。
### 使用 @ 提及进行显式纳入 [#使用--提及进行显式纳入]
```
@filename.js
```
Verdent 会自动加载相关文件，但 `@-mentions` 能确保精确的上下文。要有选择性——只纳入与当前任务直接相关的文件。
### 监控上下文使用 [#监控上下文使用]
* 注意会话变长时的性能下降
* 留意对话长度和文件数量
* 在可能时从上下文中移除不必要的文件
### 避免上下文过载 [#避免上下文过载]
* 将大任务拆分为更小的部分，每个任务使用更少的文件
* 只关注相关文件——不要一次加载整个代码库
* 使用 MCP 服务器管理来禁用未使用的集成
### 最佳实践 [#最佳实践]
* 只纳入需要修改或引用的文件
* 引用已有的模式，而不是加载示例文件
* 对于大型代码库，一次只处理一个模块
* 使用项目文档（`AGENTS.md`）而不是加载大量文件
* 对于内存密集型任务，避免使用上下文窗口的最后五分之一
### 对于扩展上下文 (1M tokens) [#对于扩展上下文-1m-tokens]
文件选择的重要性大幅降低——你通常可以加载整个项目仓库而不会触及上限。
***
## 识别上下文过载 [#识别上下文过载]
**信号：**
* 响应准确度降低或不完整
* 遗漏对话中较早出现的重要细节
* 难以在长会话中保持一致性
* 对最近的更改或上下文感到困惑
**具体示例：**
* 提出你在本次会话早些时候已经否决的方案
* 忽略你在 `20` 条消息之前确立的编码约定
* 生成与对话早期所做更改相冲突的代码
* 提出与之前讨论过的项目架构不符的实现方案
**主要信号：** Verdent 的响应准确度降低或不一致
**信号：**
* 响应时间明显变慢
* 开始响应前的处理延迟变长
* 消息之间的延迟增加
**具体示例：**
* 通常需要 `5-10` 秒的响应现在需要 `30+` 秒
* 发送消息后，输入指示器出现前有明显延迟
* 流式响应开始得比平常慢得多
* 工具执行（文件读取、搜索）耗时明显变长
**主要信号：** 响应耗时比平常明显更长
**信号：**
* 要求澄清已经提供过的信息
* 忘记之前确立的模式或约定
* 无法引用之前讨论过的文件或代码
* 重复询问项目结构
**具体示例：**
* 在你 `30` 条消息前已说明使用 React 后，仍问"你用的是什么框架？"
* 重复索要你已经 `@-mentioned` 多次的文件路径
* 不记得你在会话开始时确立的命名约定
* 重新解释你已附理由否决的概念或方法
**主要信号：** Verdent 询问已经讨论过的内容
**信号：**
* 接近 `200K` token 上限的最后五分之一（已使用约 `160K+` tokens）
* 包含大量文件读取和工具输出的长对话
* 启用了多个带有大量工具定义的 MCP 服务器
* 反复将大文件加载进上下文
**具体示例：**
* 会话已运行 `2+` 小时，包含 `100+` 条消息
* 你在对话中加载了 `20+` 个文件，`@-mentions`
* 多个大文件（每个 `>1000` 行）都在上下文中
* 你启用了 `5+` 个带有大量工具定义的 MCP 服务器
* 对话包含大量 grep/搜索结果和文件读取
**主要信号：** 伴随大量文件/工具使用的超长会话
**何时采取行动：** 性能下降是你的主要信号。如果 Verdent 的响应变得准确度降低、变慢或不一致——就开启一个全新会话或使用上下文管理策略。
如果 Verdent 的响应变得含糊或重复，可能正在发生上下文过载。重置对话以恢复完整性能。
**注意：** 使用 `1M` token 上下文（Claude Sonnet 4.5）时，这些问题要少见得多。
***
## 何时重置上下文 [#何时重置上下文]
* 响应时间明显变慢
* 响应准确度降低或不一致
* Verdent 遗忘早期的上下文或模式
* 接近上下文窗口上限（注意下降信号）
**行动：** 质量下降时开启全新会话
* 在不相关的功能或模块之间切换
* 完成一个待办事项并转向下一个
* 在内存密集型任务（大型重构、架构工作）之后
* 从研究阶段转向实现阶段
**行动：** 为新的主要任务开启新会话
* 在将完成的功能提交到版本控制之后
* 在开发工作流的逻辑检查点之间
* 在测试-验证-提交循环之后
**行动：** 提交 → 测试 → 新会话
* 在开始重要新功能之前
* 当对话历史变得很长时
* 在完成多文件更改之后
* 在不同类型的工作之间（调试 → 功能开发）
**行动：** 在上下文下降之前主动开启全新会话
**最佳实践工作流：** 完成一个原子工作单元 → 测试 → 提交 → 清除上下文 → 为下一个任务重新开始。
**注意：** 开启新会话即可重置上下文。对于 `1M` token 上下文，需要清除的频率要低得多。
***
## 工作区组织的影响 [#工作区组织的影响]
工作区组织方式直接影响上下文的使用效率，以及 Verdent 浏览代码库的难易程度。
**更小、更聚焦的文件：**
* 许多小文件比少数大文件更高效地利用上下文
* 更容易只加载相关模块
* 对上下文中的内容有更精细的控制
* 减少加载整个大文件的需要
**清晰的目录结构：**
* 合理的组织帮助 Verdent 定位相关文件
* 基于功能或模块的组织改善上下文定位
* 减少加载无关代码的需要
**`Documentation in AGENTS.md:`**
* 项目文档替代了加载大量示例文件的需要
* 架构模式描述一次，反复引用
* 编码规范集中记录
* 减少探索性文件读取带来的上下文开销
**优势：**
* 在不加载整个代码库的情况下处理独立模块
* 清晰的边界使会话更聚焦
* 沿模块边界拆分工作变得自然
**问题：**
* 庞大的单体文件迫使加载整个大型上下文
* 结构不清晰需要加载大量文件才能理解架构
* 同一文件中混杂多种关注点，在无关代码上浪费上下文
**影响：**
* 频繁出现上下文上限问题
* 在无关代码上浪费 tokens
* 难以将工作隔离到特定模块
* 更频繁地需要重置会话
**常见反模式：**
* 单个 `5000+` 行且混杂多种关注点的文件
* 根目录下有 `100+` 个文件的扁平目录结构
* 功能/模块之间没有清晰分离
* 缺乏集中的文档
**重构方法：**
* 将大文件拆分为更小、更聚焦的模块
* 按功能或领域组织（而非按文件类型）
* 创建清晰的目录层级
* 将共享代码提取到独立模块
**文档：**
* 创建包含架构模式的 `AGENTS.md`
* 集中记录编码规范
* 每个模块维护 `README` 文件
* 记录设计决策
**上下文影响：** 对于标准 `200K` token 上下文，组织良好的工作区决定了你是频繁还是很少触及上限。对于 `1M` token 上下文，组织的影响较小，但仍能提升效率。
***
## 上下文优化策略 [#上下文优化策略]
有效的上下文优化结合了监控、策略规划和技术配置。
**注意性能信号：**
* 在整个会话中监控响应质量和速度
* 注意响应何时变慢或准确度降低
* 手动跟踪对话长度和文件数量
* 主动开启全新会话
**需监控的内容：**
* 响应的准确性和一致性
* 首次响应时间（输入指示器延迟）
* 整体响应完成时间
* 对早期对话细节的记忆
**子智能体管理：**
* 不需要时禁用未使用的自定义子智能体
* 每个启用的子智能体都会向系统开销添加定义
* 只保留正在使用的子智能体处于启用状态
* 在特定任务需要时再重新启用
**行动阈值：** 当你注意到 `2-3` 个下降信号时，就该开启全新会话了。
将响应质量作为上下文健康度的领先指标，响应质量下降意味着该重置了。
**分块方法：**
* 将大任务拆分为更小的部分
* 在聚焦的会话中完成相关工作
* 避免在长对话中混合不同类型的任务
* 对于内存密集型工作，避免使用上下文窗口的最后五分之一
**会话管理：**
* 在主要任务之间开启全新会话
* 提交后清除上下文：测试 → 验证 → 提交 → 新会话
* 使用待办事项进行多步骤规划
* 在各自聚焦的会话中处理待办事项
**最佳实践模式：**
1. 在 Plan Mode 中规划任务
2. 在全新会话中执行聚焦的实现
3. 测试并验证更改
4. 提交到版本控制
5. 为下一个任务开启新会话
**任务隔离：** 将调试与功能开发分开，将研究与实现分开。
**策略性纳入：**
* 仅在必要时使用 `@-mentions` 进行显式文件纳入
* 利用 `AGENTS.md` 文档而非加载大量文件
* 对于大型项目，一次只处理一个模块
* 将大文件拆分为更小、更聚焦的组件
**文件选择原则：**
* 只纳入需要修改或直接引用的文件
* 优先使用文档而非加载示例文件
* 不再需要时从上下文中移除文件
* 即时加载文件，而非提前加载
**大文件处理：**
* 考虑拆分超过 `500` 行的文件
* 将工具函数和辅助函数提取到独立文件
* 使用清晰的模块边界
* 在 `AGENTS.md` 中记录文件关系
**优化工作流：**
监控性能 → 识别会话膨胀 → 禁用未使用的子智能体 → 主动开启全新会话 → 专注于任务质量
**日常实践：**
* 每个主要功能都以全新上下文开始
* 频繁提交，并在提交之间重置
* 让每次会话聚焦于单一目标
* 在自然的断点处审视上下文使用情况
**`For Extended Context (1M tokens):`** 借助 Claude Sonnet 4.5 更大的上下文窗口，优化变得不那么关键——专注于任务质量而非激进的上下文管理。不过，良好的实践仍能提升效率和组织性。
***
## 常见问题 [#常见问题]
标准模型（Claude 4.5 Sonnet、Haiku、GPT-5、GPT-5-Codex、MiniMax-M2）拥有 `200K` token 上下文窗口，足以应对大多数任务。Claude Sonnet 4.5 提供扩展的 `1M` token 上下文（大 5 倍），适用于包含 `1000+` 文件的大型代码库、复杂的多文件重构或长时间的开发会话。当输入超过 `200K` tokens 时，`1M` 上下文会自动激活，也可以显式选择。
你必须手动开启新会话来重置上下文——Verdent 不会自动清除上下文。最佳实践：在完成一个原子工作单元、测试并提交到版本控制后再重置。对于 `1M` token 上下文，需要重置的频率要低得多。
没有固定的文件数量限制——这取决于文件大小和总 token 数。对于 `200K` 上下文，避免加载 `20+` 个大文件（每个 `>1000` 行）。专注于与当前任务直接相关的文件。有选择地使用 `@-mentions`，并利用 `AGENTS.md` 文档而非加载大量示例文件。使用 `1M` 上下文时，文件选择的重要性大幅降低。
会话中的所有内容：对话中的全部消息、加载进上下文的文件内容、工具输出（grep/搜索结果、文件读取）、系统提示词和指令，以及 MCP 服务器定义。这些都会消耗你总上下文容量中的 tokens。
不会——重置上下文只会从内存中清除对话历史和已加载的文件。你实际的代码更改、提交和文件修改都会保留。为安全起见，请在重置上下文前始终将工作提交到版本控制。重置 → 开启全新会话 → 继续处理下一个任务。
***
## 另请参阅 [#另请参阅]
编写有效提示词的最佳实践
理解执行模式及其资源影响
监控 token 使用、积分和性能