夜雨聆风想要降低 Token 消耗，必须理解"上下文窗口"是使用 CodeBuddy 及所有 AI 编码助手的最核心知识点。它直接决定了：AI 能不能理解你的意思、回答质量高不高、你花的钱（token/credit）多不多。
下面我从零开始，一层一层给你讲透。
一、最基础的概念：什么是"上下文窗口"？
1.1 一个生活化的比喻
把 AI 模型想象成一个记忆力有限的专家顾问。
你和他坐在一张桌子前讨论问题。 这张桌子的大小是固定的——比如只能放 200 页纸。 你放在桌上的所有东西（你的问题、之前的对话记录、你给他的代码文件、他的回答），都必须同时摆在这张桌子上。 一旦桌子放满了，最早放上去的纸就会被挤掉桌子，他就"看不见"了，也就"忘了"。
这张桌子 = 上下文窗口（Context Window）桌上的每一张纸 = Token（词元）桌子被挤掉纸 = 上下文溢出/遗忘
1.2 什么是 Token？
Token 不是"字"，也不是"词"，而是模型处理文本的最小单位。
举例说明：
"Hello world" → 大约 2 个 token"你好世界" → 大约 6～8 个 token一个 50 行的 Python 文件 → 大约 500～1500 个 token
为什么你要关心 token？ 因为 AI 服务按 token 计费。你给 AI 看的内容越多（输入 token），AI 回答越长（输出 token），你消耗的 credit 就越多。
1.3 上下文窗口有多大？
不同模型、不同产品的窗口大小不同：
⚠️ 新手常见误区： 模型本身支持 200K，不代表你每次对话都能用 200K。CodeBuddy 等工具在插件层会设一个默认配额（如 8K～16K），这是为了控制成本和响应速度。
二、模型是如何"看"上下文的？（核心机制）
2.1 模型没有"记忆"，只有"当前这一张桌子"
这是新手最容易误解的地方。
你以为的 AI：
"它记得我 10 分钟前说过的话，它有一个大脑在存储信息。"
实际的 AI：
"它什么都没有记住。每次你发一条新消息，系统会把之前所有对话记录 + 你的新消息，全部打包成一大段文本，重新喂给模型。模型每次都是'第一次看'这整段文本。"
举例说明：
假设你和 AI 进行了 3 轮对话：
第 1 轮：你：帮我写一个排序函数AI：好的，这是冒泡排序...（200 token）第 2 轮：你：改成快速排序AI：好的，这是快排...（300 token）第 3 轮：你：加上注释
当你发出第 3 轮消息时，模型实际收到的输入是：
[系统提示词]（约 500 token）[第1轮-你的消息]（10 token）[第1轮-AI的回答]（200 token）[第2轮-你的消息]（8 token）[第2轮-AI的回答]（300 token）[第3轮-你的消息]（6 token） ← 你新发的─────────────────────────────总计约 1024 token 全部重新输入给模型
关键理解： 对话越长，每次请求携带的"历史包袱"就越重，token 消耗呈累积增长。这就是为什么长对话越来越贵、越来越慢。
2.2 模型"看"文本的方式：注意力机制
模型不是像人一样"从头读到尾"。它使用一种叫注意力（Attention） 的机制：
它会同时"看到"桌子上的所有纸。 对于你当前的问题，它会自动判断哪些纸最相关，给予更高的"注意力权重"。 离当前问题越远的内容（比如很早之前的对话），注意力权重越低，模型越容易"忽略"。
举例说明：
[第1轮] 你：帮我写一个用户登录功能[第2轮] 你：数据库用 PostgreSQL[第3轮] 你：加上 JWT 认证...[第50轮] 你：把第2轮说的数据库改成 MySQL
到了第 50 轮，第 2 轮的内容在"桌子"上已经非常靠后了。模型虽然理论上能"看到"，但注意力权重很低，很可能记不清你当时说的是 PostgreSQL，甚至完全忽略。
这就是"上下文遗忘"现象。 不是模型"忘了"，而是那段内容被挤到了注意力边缘。
2.3 Agent 模式下的上下文更复杂
在 CodeBuddy 的 Craft（Agent）模式 下，AI 不仅仅是"聊天"，它还会：
读取你的文件 执行终端命令 搜索代码 修改文件 再读取修改后的结果
每一步操作的结果都会被塞进上下文！
举例说明：
你说："帮我找到项目里所有用了 axios 的文件，改成 fetch。"
Agent 的执行过程：
步骤1：搜索项目 → 返回 15 个文件路径（+500 token）步骤2：读取文件1 → 整个文件内容（+800 token）步骤3：读取文件2 → 整个文件内容（+1200 token）步骤4：读取文件3 → 整个文件内容（+600 token）...步骤15：读取文件15 → 整个文件内容（+900 token）步骤16：修改文件1 → diff 输出（+400 token）...
一个看似简单的任务，上下文可能迅速膨胀到 几万 token。这就是为什么 Agent 模式比纯聊天模式消耗大得多。
三、上下文管理不当会怎样？（反面教材）
3.1 问题一：Token 爆炸，费用飙升
❌ 错误做法：
你在一个对话里，从早上 9 点聊到下午 5 点，中间问了 100 个不同的问题，涉及 20 个不同的文件。
第 1 轮：@fileA.ts 帮我看看这个bug第 2 轮：@fileB.ts 这个函数什么意思第 3 轮：@fileC.ts 帮我重构...第 100 轮：@fileT.ts 加个注释
到了第 100 轮，模型每次回答都要重新"阅读"前面 99 轮的所有内容 + 20 个文件的完整代码。
结果： 第 100 轮的一个简单问题，可能消耗 50000+ token，而实际有用的信息可能只有 200 token。你 99% 的钱花在了"让 AI 重读废话"上。
3.2 问题二：回答质量下降
❌ 错误做法：
你在一个对话里混合了多个不相关的任务：
第 1-10 轮：讨论前端 React 组件第 11-20 轮：讨论后端 Python API第 21-30 轮：讨论数据库设计第 31 轮：你问"帮我优化一下那个组件"
结果： 模型不确定"那个组件"是 React 组件还是 Python 的某个模块。上下文里混了太多不相关信息，模型的注意力被分散，回答变得模糊、不准确。
3.3 问题三：上下文溢出，关键信息丢失
❌ 错误做法：
你 @ 了一个 3000 行的大文件，然后又 @ 了另一个 2000 行的大文件，然后开始提问。
@huge_file_A.ts（3000行 ≈ 30000 token）@huge_file_B.ts（2000行 ≈ 20000 token）"帮我看看这两个文件之间的接口调用有没有问题"
结果： 如果上下文窗口只有 16K token，这两个文件根本放不下。系统会截断，模型只能看到文件的一部分，给出的分析是不完整的、甚至错误的。
四、如何高效管理上下文？（正面做法）
4.1 原则一：一个对话，一个任务
✅ 正确做法：
对话 A（专门处理登录模块）：第1轮：@auth.ts 帮我看看登录逻辑第2轮：加上 JWT 验证第3轮：写单元测试→ 任务完成，关闭对话对话 B（专门处理支付模块）：第1轮：@payment.ts 帮我重构支付流程第2轮：加上错误处理→ 任务完成，关闭对话
解释： 每个对话的上下文都很"干净"，只包含与当前任务相关的信息。模型注意力集中，回答精准，token 消耗也少。
4.2 原则二：精准引用，不要"大水漫灌"
❌ 错误做法：
@整个src文件夹 帮我找bug这会把整个文件夹的所有文件都塞进上下文，可能几万 token，其中 99% 跟你的 bug 无关。
✅ 正确做法：
@src/utils/dateFormatter.ts 这个函数的第 42 行，当输入为 null 时会报错，帮我修复
只引用了一个文件，并且精确指出了位置。上下文可能只有 200 token，模型能 100% 聚焦。
4.3 原则三：利用 @ 引用的"持久性"，避免重复
CodeBuddy 有一个重要特性：
@ 文件或代码块后，内容会一直保留在对话上下文中。模型能够持续看到你之前发送的内容，无需在每条消息中重复 @ 同一文件。
❌ 错误做法（浪费 token）：
第1轮：@config.ts 帮我看看这个配置第2轮：@config.ts 把第3行改成 xxx第3轮：@config.ts 再加一个字段
你每轮都重新 @ 了 config.ts，虽然系统可能做了去重，但你的意图表达是冗余的。
✅ 正确做法（节省 token）：
第1轮：@config.ts 帮我看看这个配置第2轮：把第3行改成 xxx第3轮：再加一个字段
第 1 轮 @ 之后，模型已经"看到"了 config.ts，后续直接说"改哪里"即可。
4.4 原则四：大文件只引用关键片段
❌ 错误做法：
@3000行的文件.ts 帮我看看第 1500 行附近的逻辑✅ 正确做法： 在编辑器中选中第 1480～1520 行代码，然后：
@选中的代码片段 这段逻辑有什么问题？解释： 你只给了模型 40 行代码（约 400 token），而不是 3000 行（约 30000 token）。节省了 98% 的 token，而且模型的注意力完全集中在这 40 行上，分析更准确。
4.5 原则五：善用 /clear 和 /init 命令
在 CodeBuddy Code（CLI 版本）中：
/clear | ||
/init |
✅ 推荐工作流：
> /init ← 项目初始化，建立基础上下文> 帮我分析项目结构 ← 第一个对话> /clear ← 任务完成，清空> 帮我修复登录bug ← 新任务，干净的上下文> /clear ← 任务完成，清空> 帮我写单元测试 ← 又一个新任务
解释：
/init会一次性建立项目的基础认知（目录结构、技术栈、关键配置），后续对话不需要反复解释"我的项目是什么"。/clear则确保每个任务的上下文互不干扰。据官方数据，这种做法可以减少 30%～50% 的上下文 Token 开销。
4.6 原则六：利用记忆文件（Memory），而非对话历史
CodeBuddy Code 支持记忆文件（.codebuddy/memories/），它的工作方式是：
系统提示词中只放一个记忆文件列表摘要（文件名、大小、标题） AI 按需加载相关记忆，而不是把所有记忆塞进上下文
举例说明：
你有 10 个记忆文件：- project-architecture.md（项目架构）- coding-style.md（编码规范）- api-conventions.md（API 约定）- database-schema.md（数据库结构）...当你问"帮我写一个新的 API 接口"时：AI 只加载 api-conventions.md 和 coding-style.md而不是把 10 个文件全部塞进上下文
解释： 这就像专家顾问不需要每次对话都把所有资料摊在桌上，他只需要抽出跟当前问题相关的那几份。大幅节省 token。
五、一个完整的实战对比
假设你的任务是："在 Express 项目中，给用户注册接口加上邮箱格式验证"
❌ 新手做法（高消耗、低质量）
一个从早上开始就没关过的对话（已经有 80 轮历史）：你：@整个server文件夹 帮我加个邮箱验证
问题分析：
80 轮历史 ≈ 40000 token 的"历史包袱" 整个 server 文件夹 ≈ 20000 token 模型需要在 60000 token 中找到"注册接口在哪" 注意力被严重分散，可能找错文件 本次请求消耗：约 60000+ token
✅ 老手做法（低消耗、高质量）
先 /clear 清空对话你：@server/routes/auth.ts在 register 接口中，给 req.body.email 加上正则邮箱格式验证，不合法返回 400。项目用的是 Express + TypeScript。
优势分析：
0 轮历史包袱 只引用了 1 个文件 ≈ 500 token 指令精确到文件、接口、字段、行为、返回码 模型 100% 聚焦 本次请求消耗：约 800 token
对比：60000 token vs 800 token，相差 75 倍！ 回答质量也是天壤之别。
六、总结：新手记住这 6 条黄金法则
| 一对话一任务 | ||
| 精准 @ 引用 | ||
| 引用一次就够 | ||
| 大文件选片段 | ||
| 勤用 /clear | ||
| 指令要具体 |
记住核心原理：模型没有记忆，它每次都在"重新阅读"你给的所有内容。你给的内容越精准、越干净，它就越聪明，你也越省钱。
