在使用 Claude Code 进行开发任务时，最直观的消耗莫过于 token。执行一次复杂的代码审查技能（skill），上下文中往往塞满了各类规范文件，一轮对话下来数千 token 便悄然流失——其中大半可能从未被真正使用。
本文聚焦一个核心问题：如何让每一枚 token 都物尽其用，实现高效的成本控制。
Token 都流向了哪里？
Token 的消耗主要分布在三个阶段：
- 知识库初始化 — AI 启动时加载的基础配置
- 上下文构建 — 任务执行过程中需携带的信息集合
- 执行操作 — 实际的工具调用与推理计算
只有明确消耗源头，才能精准制定节省策略。
知识库创建：AI 的“开机自检”环节
这一阶段是每次对话的必经之路，主要有三个区域在耗费 token：
Skill 扫描 — Claude Code 启动时会遍历所有已安装的技能，但仅读取每个 skill 的 description 字段，相当于只查看“目录”而不翻阅正文。因此，描述文字的精炼度至关重要——冗余的描述会在每一次对话中反复占用上下文空间。
CLAUDE.md 加载 — 项目的 CLAUDE.md 会被完整载入，它是 AI 理解项目全貌的“参考手册”。内容过多会造成浪费，过少则导致 AI 盲目搜索文件——如何找到平衡点，后文会详细探讨。
权限模型 — 只授予 AI 执行任务所需的必要权限，避免权限膨胀。例如，代码审查 skill 无需执行命令的权限，发布流程 skill 也无需读写文件的权限。权限越精简，AI 的决策路径越短，token 消耗自然越低。
上下文：越精炼效率越高
人类大脑同时处理的信息块平均约为 7 个，超过这个数量便容易混乱。AI 的情况类似——上下文越长，“注意力”就越分散，处理效率随之下降，token 消耗呈指数增长。
在任务执行过程中，AI 需要反复回顾上下文进行决策。如果上下文中夹杂了大量与当前任务无关的信息，AI 就像在一间堆满杂物的房间里寻找钥匙，翻找得越多，消耗就越大。
保持上下文的精简与相关性，是降低 token 消耗最直接的手段。
执行阶段：全量加载 vs 渐进式加载
知识的投喂方式直接决定了 token 的总体消耗。两种策略各有其适用场景。
全量加载
将所有知识、规范、上下文一次性写入 instructions，AI 从第一步起便拥有完整信息。
启动 Skill→ 加载 SKILL.md（含全部知识内容）→ 所有规范、规则、示例已在上下文中→ 开始执行任务→ 每一步都携带全部知识（无论是否用到）→ 任务完成
这种思路简单直接：AI 无需中途读取外部文件，执行链路干净。缺点也很明显——上下文从一开始就非常“沉重”，随着对话轮次增加，那些从未被用到的知识也在持续消耗 token。
什么情况下适合全量加载？
| 场景 | 原因 |
|---|---|
| 知识总量 < 1000 tokens | 内容太小，拆分反而增加管理成本 |
| 每次执行都必须用到全部知识 | 如 lint 规则，每个文件都需要对照全部规则 |
| 单轮对话、一次性任务 | 不存在多轮累积的浪费 |
| 知识之间高度耦合 | 拆分后缺乏上下文，AI 容易判断失误 |
渐进式加载
只在 instructions 中写入“索引”——即知识的位置与按需加载条件。具体知识存放在外部文件，AI 在执行过程中才按需读取。
启动 Skill→ 加载目录页： SKILL.md（仅含流程 + 知识索引）→ 开始执行任务，执行章节,激活skill。→ 读取附录按需加载： → 遇到 TypeScript 文件？ → 读取 typescript-rules.md→ 遇到 CSS 文件？ → 读取 style-guide.md→ 遇到 API 接口？ → 读取 api-conventions.md→ 查看接口返回数据？ → 读取 api-response-guidelines.json→ 未遇到的类型？ → 对应知识文件从未加载，0 token 消耗→ 任务完成
上下文初始非常“轻”，按需逐步增重。未被触发的知识路径完全不消耗 token。代价是每次读文件有少量额外开销，但与节省的 token 相比微乎其微。
什么情况下适合渐进式加载？
| 场景 | 原因 |
|---|---|
| 知识总量 > 2000 tokens | 全量加载过于庞大，拆分收益显著 |
| 知识可按类型/场景分组 | 按文件类型、业务模块、阶段均可拆分 |
| 多轮对话、复杂任务 | 避免每轮重复携带无关知识 |
| 知识模块相互独立 | 审查 CSS 时无需知晓 TypeScript 规则 |
如何选择？
知识总量 < 1k tokens？
└─ 是 → 全量加载（不值得拆分）
└─ 否 → 每次都用全部知识？
└─ 是 → 全量加载（拆分也无法节省）
└─ 否 → 知识能否按场景分组？
└─ 是 → 渐进式加载
└─ 否 → 全量加载（耦合太强拆不动）
Token ROI：让每一枚 token 都产生回报
理解加载策略后，回归具体实践。从三个维度提升知识的投入产出比：
Skill description 务必精炼 — 这一行文字会常驻在每次对话的上下文中。写成“审查代码变更，检查规范和潜在问题”即可，无需扩写成小作文。
CLAUDE.md 应设计为架构地图 — 不必事无巨细，只需告诉 AI 项目的核心结构与边界。目的是减少 AI 频繁使用 find 和 grep 查找文件所消耗的 token。给出一张清晰的地图，远比让 AI 自行探索更加经济。
本地知识库采用渐进式加载 — 当 skill 需要对接领域知识时，将知识文件放在 skill 自己的目录下，instructions 中仅写入加载条件。知识文件可以是 .md、.json、.txt 等任何文本格式。
实战案例：代码审查 Skill
一个审查 skill，知识库采用按需加载而非全量注入上下文。所有辅助文件均位于 skill 自己的目录内，保持模块化与清晰的边界：
# .github/skills/code-review/SKILL.md
name: code-review
description: "审查代码变更，检查规范和潜在问题"
# 精炼！这行会常驻上下文
instructions: |
## 审查流程
1. 读取变更文件列表
2. 按文件类型加载对应规范（见下方知识库）
3. 逐文件审查并输出建议
## 本地知识库（渐进式加载）
# ❌ 反模式：把所有规范一次性塞进 instructions
# ✅ 正确做法：引用外部文件，需要时再读取
当审查 TypeScript 文件时，读取：
.github/skills/code-review/knowledge/typescript-rules.md
当审查 CSS/样式文件时，读取：
.github/skills/code-review/knowledge/style-guide.md
当审查 API 接口时，读取：
.github/skills/code-review/knowledge/api-conventions.md
当查看接口返回数据时，用返回的 key 查找读取：
.github/skills/code-review/knowledge/api-response-guidelines.json
不要提前加载所有知识文件，只在遇到对应文件类型时才读取。
目录结构如下：
.github/skills/code-review/
├── SKILL.md # 入口，常驻上下文（控制在精炼范围）
└── knowledge/ # 按需加载，不占初始 token
├── typescript-rules.md # ~200 行规范
├── style-guide.md # ~150 行规范
├── api-conventions.md # ~180 行规范
└── api-response-guidelines.json # 数据结构规范，key-value 形式
算一笔账：
- 全量加载：4 个知识文件全部塞入上下文，约占用 ~4000 tokens
- 渐进式加载：每次仅加载相关的 1-2 个文件，节省 50%-70% 的知识库 token 消耗
单个 skill 节省 2000 token 看似不多，但若项目中有 5 个 skill、每天运行 20 轮对话，一个月下来的成本差距便相当可观。
节省 token 并没有万能钥匙，而是在每个环节精打细算：description 少写一句废话，知识库多拆一个文件，权限少给一项。积少成多，最终效果远超预期。