05 — 核心概念：会话、上下文窗口与 Token 经济学

潮海

261人浏览 · 2026-05-27 07:53:08

潮海 · 2026-05-27 07:53:08 发布

本节目标

完成本节后，你将能够：

理解 Claude Code 会话的完整生命周期
精确描述上下文窗口的四个组成部分及其占比
掌握 Token 经济学基础，理解输入/输出/缓存的价格差异
在正确的时机使用 /compact 管理上下文
运用"两改原则"控制任务的复杂度和成本

核心知识点

会话（Session）的生命周期

在 Claude Code 中，从你启动 claude 到退出，就是一个"会话"。理解会话的生命周期是高效使用 Claude Code 的基础。

阶段 1：启动（Startup）

当你输入 claude 时，发生以下事情：

Claude Code 初始化 Node.js 运行时
加载全局 CLAUDE.md（~/.claude/CLAUDE.md）
扫描当前目录，加载项目 CLAUDE.md（./CLAUDE.md）
读取目录下的关键配置文件（package.json、.gitignore 等）
展示欢迎信息，等待你的第一条消息

阶段 2：对话循环（Conversation Loop）

这是会话的核心阶段。每一条你的消息和 Claude Code 的回复构成一个"回合"。在每个回合中：

你发送一条消息
Claude Code 读取需要了解的文件（自动搜索）
Claude Code 推理并生成回复（可能包含文件修改、命令执行）
你对修改进行审批或拒绝
下一回合开始

阶段 3：上下文饱和（Context Saturation）

随着对话的持续，上下文窗口逐渐被填满。当接近上限时：

Claude Code 会发出警告提示
响应速度可能变慢
你需要执行 /compact 或 /clear

阶段 4：退出（Exit）

输入 Ctrl+D 或 /exit 退出会话。注意：会话退出后对话历史会丢失（除非你使用了会话恢复功能）。重要的讨论结果应该已经在你的代码中体现。

上下文窗口的解剖

每次 Claude Code 向 Claude 模型发送请求时，都会包含以下内容：

┌────────────────────────────────────────────────┐
│ System Prompt（系统提示，约 3000-5000 token）    │  ← 固定开销
│ - Claude Code 的角色定义                        │
│ - 可用工具列表及使用说明                         │
│ - 权限模型和安全规则                             │
├────────────────────────────────────────────────┤
│ CLAUDE.md 内容（约 1000-2000 token）            │  ← 你的项目规则
├────────────────────────────────────────────────┤
│ 对话历史（动态增长，每次会话从头累积）             │
│ - 第 1 回合：你的问题 + AI 回复 + 工具调用结果     │
│ - 第 2 回合：...                                │
│ - 第 N 回合：...（持续增长）                     │
├────────────────────────────────────────────────┤
│ 当前文件内容（AI 主动读取的文件）                 │  ← 按需加载
│ - 你要求修改的文件                               │
│ - AI 自动搜索读取的相关文件                      │
├────────────────────────────────────────────────┤
│ 工具输出（命令执行结果等）                        │  ← 按需加载
└────────────────────────────────────────────────┘

关键理解：System Prompt 和 CLAUDE.md 在每个回合中都被重复发送（这就是 prompt caching 的价值所在）。对话历史只增不减。文件内容和工具输出只在相关回合中出现。

Token 经济学基础

Token 是 Claude Code 计费的基本单位。一个 token 大约等于 0.75 个英文单词或 0.5-0.8 个中文字符。

输入 vs 输出 vs 缓存 — 价格差巨大

以 Claude Code 默认使用的 Sonnet 4 为例（2026 年 5 月定价）：

类型	单价（每百万 token）	说明
标准输入	$3.00	每次对话中发送给模型的内容
缓存输入	$0.30	被 prompt caching 命中的输入（10 倍便宜）
输出	$15.00	模型生成的内容（5 倍于标准输入）

这意味着什么？

System Prompt 和 CLAUDE.md 因为被缓存，实际成本只有 $0.30/百万 token ——几乎可以忽略
输出是最贵的——所以鼓励 Claude Code 生成精简的回复，而不是长篇大论
对话历史是输入中最大的开销——因为它随会话增长且不会被缓存（每次都不同）

一个典型的开发会话成本估算：

假设你使用 Sonnet 4，一个 30 分钟的开发会话中：

对话了 20 个回合
每次输入约 15K token（含缓存和非缓存部分）
每次输出约 2K token
总费用大约：$0.5 - $2.0

对于日常开发来说，Claude Code 的成本通常低于一杯咖啡。

`/compact` 的工作原理

当上下文窗口接近饱和时，/compact 是救命稻草。它会：

保留 System Prompt 和 CLAUDE.md（不变）
将之前的对话历史压缩成一段摘要
保留最近几轮对话的完整上下文（通常是最近 3-5 轮）
丢弃被压缩的对话的详细内容

何时使用：

Claude Code 提示"上下文窗口接近上限"
你发现 AI 的回复质量明显下降
对话已经超过 30 轮

不要在以下情况使用：

AI 正在处理一个复杂任务的中途
你需要引用 10 轮之前讨论过的某个细节

"两改原则"——新手最重要的任务管理法则

这是经过大量实践总结出的经验法则：

对于任何任务，最多只给 Claude Code 两次修改机会。如果两次都改不对，说明你的描述不够清晰或任务本身太复杂。

具体操作：

第一次修改 → 审查结果 → 如果不对，给出更具体的反馈
第二次修改 → 如果还不对 → 停止，重新描述你的需求

为什么是两次？

第三次修改时，上下文已经被之前的失败尝试污染
AI 可能陷入了"越改越乱"的循环
此时最好的做法是 /clear 然后重新用更精确的语言描述需求

实操步骤

步骤 1：观察上下文窗口的增长

启动 Claude Code 并开始一个较长的任务：

mkdir ~/claude-context-demo
cd ~/claude-context-demo
echo '{"name": "context-demo"}' > package.json
claude

在交互模式中，有意识地进行多轮对话：

第 1 轮：

请创建一个简单的 Node.js HTTP 服务器（server.js），监听 3000 端口，返回 "Hello World"

第 2 轮：

现在添加一个 /api/time 路由，返回当前服务器时间

第 3 轮：

添加请求日志中间件，记录每个请求的方法、URL 和响应时间

每完成一轮，输入 /cost 观察 token 消耗的增长。你会发现：

第 1 轮的输入 token 最少（对话历史为空）
随着轮次增加，每轮消耗的输入 token 逐渐增多
输出 token 相对稳定

步骤 2：体验 `/compact`

继续上面的对话，到第 8-10 轮时：

/compact

观察现象：

之前的详细对话历史被压缩为摘要
Claude Code 仍然记得之前做了什么（摘要中保留了关键信息）
但不记得每个回合的具体细节
后续对话的输入 token 显著减少

步骤 3：验证"两改原则"

设计一个有意的实验：

请在 server.js 中添加一个 /api/stats 路由，返回服务器启动以来的统计信息，包括总请求数、平均响应时间、各路由的请求次数。

如果 Claude Code 的实现第一次不够理想（比如没有正确计算平均响应时间），给出一次具体反馈。如果第二次仍然有问题——注意：这就是"两改原则"的场景。不要做第三次修改，而是：

/clear

然后用更精确的语言重新描述。例如：

请在 server.js 中添加一个 /api/stats 路由，要求如下：
1. 返回 JSON 格式：{totalRequests: number, avgResponseTime: number, routeStats: {[route: string]: number}}
2. totalRequests 是所有请求的累计数
3. avgResponseTime 是最近 100 个请求的平均响应时间（毫秒）
4. routeStats 是每个路由的请求次数（用 Map 存储）
5. 所有计数器在服务器启动时重置

你会发现：清空上下文后的第一次尝试通常比第三次修补要好得多。

步骤 4：理解 Prompt Caching 的效果

在同一个会话中，输入两轮相同结构但不同内容的问题：

请给 server.js 中的每一个函数添加 JSDoc 注释

请给 index.js 中的每一个函数添加 JSDoc 注释

执行 /cost 对比两次的输入 token。你会发现第二次的输入 token 略少——因为 System Prompt 和 CLAUDE.md 部分被缓存命中了。重复结构的问题越多，缓存节省越明显。

避坑指南

坑 1：在一个会话中处理太多不相关的任务

很多新手的习惯是：启动 Claude Code → 啥都往里塞。修完前端 Bug 接着问后端 API 设计，然后又让它写文档。30 轮对话后，上下文窗口已经被填满了各种各样的内容碎片，AI 的回复质量断崖式下降。

正确做法：一个会话聚焦一个主题。前端问题一个会话，后端问题另一个会话，文档工作再一个会话。

坑 2：不知道什么时候用 `/clear` 而不是 `/compact`

/compact 适合"我还需要之前的内容，但不需要所有细节"的场景。 /clear 适合"之前的内容已经完全没用，我要全新开始"的场景。

判断标准：如果你接下来要做的事情和之前做的事情没有关联，用 /clear。如果有关联但不需要细节，用 /compact。

坑 3：忽视输出成本

Claude Code 的输出成本是标准输入的 5 倍。如果你让 AI 生成一个 500 行的完整代码文件作为"参考"，你就是在花冤枉钱。

正确做法：让 Claude Code 直接修改目标文件，而不是先生成一段代码让你复制粘贴。直接修改文件通常输出更短、更精准、更便宜。

坑 4：认为 token 消耗大 = 不好的会话

有些新手看到 /cost 显示消耗了很多 token 就开始焦虑。实际上，token 消耗大通常意味着 Clode Code 为你做了很多工作——读取了大量文件、执行了多次搜索、进行了深度推理。一个 $3 的会话如果能帮你完成一个本来需要半天的手动工作，那是非常划算的。

判断标准：不是 token 花了多少，而是输出质量是否值得这个价格。

课后作业

成本追踪：在接下来一周中，每次使用 Claude Code 后用 /cost 记录消耗。周末汇总，分析哪些类型的任务最费 token，哪些性价比最高。
两改原则实践：找一个你之前反复让 AI 修改了很多次才满意的任务，用"两改原则"的方法重新执行——两次改不对就 /clear 重来。对比两种方式的最终结果和时间成本。
上下文观察：启动 Claude Code，做一个需要 15 轮以上对话的任务。每 5 轮用 /cost 记录一次。画出"轮次-输入 token"的曲线图，观察增长速度。
压缩测试：在一个长会话中，执行 /compact 前后各问一个需要引用早期对话内容的问题。测试压缩后的信息保留程度。