AI工具篇：2_CodeBuddy降低 Token 消耗的实用技巧

想要降低 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 版本）中：

✅ 推荐工作流：

> /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 条黄金法则

记住核心原理：模型没有记忆，它每次都在"重新阅读"你给的所有内容。你给的内容越精准、越干净，它就越聪明，你也越省钱。