夜雨聆风
///
PART 01
10.1 那个令人窒息的场景，你一定遇到过
想象一下这个场景：
⏰ 30分钟前
你：帮我分析这个10万行的代码库，重点关注用户认证模块
AI：好的，我来逐步分析...
AI：找到了！用户认证在 src/auth/ 目录下，有这些文件...
AI：根据分析，认证流程是这样的...
AI：发现了3个潜在的安全问题...
⏰ 35分钟后（你已经和AI讨论了很多轮）
你：刚才说的第三个安全问题是什么来着？
AI：抱歉，我需要更多上下文才能回答这个问题。
「抱歉，我需要更多上下文」 ——这可能是AI编程工具出现以来最让人窒息的句话。
你明明就在30分钟前和AI讨论过这个问题，它当时还给出了详细的分析。但现在它就像完全失忆了一样，需要你重新开始。
这不是AI变笨了，而是它的「记忆」被清除了。
///
PART 02
10.2 理解AI的「记忆」：上下文窗口
10.2.1 什么是上下文窗口？
AI的「记忆」有一个物理上限，叫做上下文窗口（Context Window）。
类比理解：
| 人类的记忆 | AI的上下文窗口 |
|---|---|
| 短期记忆容量有限 | 上下文窗口有Token数量限制 |
| 信息过多时遗忘旧的 | Token用完时丢掉旧的 |
| 长期记忆需要刻意巩固 | 需要Skill/Summarize等机制 |
不同的AI模型有不同的上下文窗口大小：
| 模型 | 上下文窗口 | 大约能容纳 |
|---|---|---|
| Claude Haiku | 200K Tokens | 一本《战争与和平》 |
| Claude Sonnet | 200K Tokens | 一本《战争与和平》 |
| Claude Opus | 200K Tokens | 一本《战争与和平》 |
| GPT-4o | 128K Tokens | 半本《战争与和平》 |
| GPT-3.5 | 16K Tokens | 一篇中篇小说 |
10.2.2 Token是什么？
Token是AI处理文本的基本单位。一个Token大约等于：
- 英文：一个单词的1/4到1/2
- 中文：一个汉字到两个汉字
举例来说：
"Hello, world!" = 5 Tokens (Hell-o, -, world-!)
"你好，世界！" = 5 Tokens (你-好-，-世-界-！)
上下文窗口的消耗来源：
上下文总消耗 = 输入（你的问题）
+ 输出（AI的回答）
+ 推理过程（thinking）
+ 工具调用结果（read文件、bash输出）
+ 对话历史（之前的问答）
10.2.3 上下文窗口的「隐形杀手」
最容易被忽视的上下文消耗来源是工具调用结果。
看几个真实数据：
| 工具调用 | 输出大小 |
|---|---|
| Playwright页面快照 | 56 KB |
| 20个GitHub Issues | 59 KB |
| 1个访问日志文件 | 45 KB |
| 10个代码文件 | 100-200 KB |
换算成Token：
- 1 KB ≈ 750 Tokens（中文）或 ~750 Tokens（英文）
- 56 KB ≈ 42,000 Tokens
这就解释了为什么你的对话会在30分钟后「失忆」——几次页面快照、几个日志文件的工具输出，就已经把上下文窗口填满了。
///
PART 03
10.3 上下文压缩的两步走：Prune + Summarize
当上下文窗口接近满载时，AI编程工具会自动启动压缩机制，分两步走：
10.3.1 第一步：Prune（剪枝）
Prune的核心逻辑：保留最近40,000 Tokens的工具输出，清除更早的。
为什么是40,000？
因为LLM的推理机制需要「最近的上下文」来保持连贯性。太久远的信息对当前任务贡献度低，优先清除。
┌─────────────────────────────────────────────────────┐
│ 上下文窗口 │
│ │
│ [更早的工具输出 - 被清除] [最近40K Tokens - 保留] │
│ ↑ │
│ 当前任务 │
└─────────────────────────────────────────────────────┘
Prune的问题：它是无差别的清除。
- 如果你在1小时前用Playwright测试了一个页面，那个快照被清除了
- 如果你后来需要参考那个测试的结果，对不起，没了
- 如果你在清除后问AI「刚才测试结果是什么」，AI会说「我不知道」
10.3.2 第二步：Summarize（摘要）
Summarize的核心逻辑：用LLM生成摘要，替换原始对话历史。
原始对话历史（10,000 Tokens）
↓ LLM生成摘要
摘要（500 Tokens）
↓ 替换
原始历史被删除，用摘要替代
Summarize的问题：摘要会丢失细节。
- AI会生成一个「缩水版」的历史记录
- 具体的代码片段、测试数据、调试过程可能被简化或忽略
- 问「上次你读取的那个文件第23行写的什么」，AI可能答不上来
10.3.3 Prune vs Summarize：哪个更痛？
| 操作 | 失去什么 | 保留什么 |
|---|---|---|
| Prune | 更早的工具输出 | 最近40K Tokens |
| Summarize | 对话细节 | 核心主题和结论 |
两种压缩方式的共同问题：
压缩后，你问：「第三个安全问题是什么？」
AI内心OS：我知道我们讨论过安全问题，但我记不清具体是哪三个了
///
PART 04
10.4 /compact命令：正确使用时机
10.4.1 什么是/compact？
/compact是一个手动触发上下文压缩的命令。它的作用是：
- 主动压缩：不等自动触发，用户主动发起
- 智能压缩：根据当前任务状态选择压缩策略
- 可控压缩：用户可以选择压缩的激进程度
10.4.2 正确的使用时机
✅ 应该在这些时候用/compact：
场景1：规划完成后
你让Plan Agent分析了项目架构，生成了一份详细的计划
→ 现在该切换到Build Agent执行了
→ 规划阶段的细节可以压缩，执行阶段的上下文更重要
→ 用/compact
场景2：调试完成后
你花了1小时调试一个bug，终于解决了
→ 调试过程的历史可以压缩
→ bug的root cause和解决方案要保留
→ 用/compact
场景3：里程碑达成后
完成了某个功能的开发，测试全部通过
→ 开发过程的细节可以压缩
→ 完成的成果和下一步计划要保留
→ 用/compact
场景4：阶段性总结前
完成了一个大的开发阶段，需要记录成果
→ 在总结前先压缩
→ 让总结从「干净的」上下文开始
→ 用/compact
10.4.3 错误的压缩时机
❌ 不应该在这些时候用/compact：
场景1：正在调试中
你正在调试一个复杂的bug，已经定位到了大概位置
→ 如果现在压缩，可能丢失关键的调试上下文
→ 等调试完成后再压缩
场景2：实现进行到一半
你让AI写了50%的代码，正在继续
→ 压缩可能导致AI忘记之前的实现细节
→ 等功能完成或一个阶段完成后压缩
场景3：多步骤推理中途
AI正在执行一个复杂的分析推理，已经进行了10步中的第7步
→ 压缩会打断推理链条
→ 等推理完成后再压缩
10.4.4 /compact的正确姿势
/compact [选项]
选项：
--aggressive 激进压缩，最大化上下文节省
--conservative 保守压缩，保留更多细节
--summary-only 只生成摘要，不删除原始内容
--dry-run 预览压缩效果，不实际执行
推荐流程：
# 1. 预览压缩效果
/compact --dry-run
# 2. 查看会保留什么、会丢失什么
# 如果预览结果满意：
# 3. 执行保守压缩
/compact --conservative
///
PART 05
10.5 Context Mode：上下文优化的革命
10.5.1 传统模式的上下文浪费
在传统的AI编程模式中，工具输出的处理方式是这样的：
工具执行
↓
输出原始结果（如56KB的Playwright快照）
↓
全部塞进上下文窗口
↓
上下文窗口被快速填满
↓
触发压缩，丢失重要信息
问题根源：工具输出的原始格式包含了太多冗余信息。
10.5.2 Context Mode的98%压缩原理
Context Mode是ECC提出的上下文优化方案，核心思路是：
不是压缩已有的上下文
而是让工具输出本身就是「压缩版」
原理对比：
| 模式 | 工具输出 | 塞入上下文的实际大小 |
|---|---|---|
| 传统模式 | 原始输出 | 56 KB |
| Context Mode | 沙箱化摘要 | 5.4 KB |
98%压缩率怎么实现的？
原始工具输出（56 KB）
↓
Context Mode沙箱处理
↓
只保留语义关键信息：
- 页面标题
- 关键元素定位器
- 操作结果（成功/失败）
- 异常信息（如有）
↓
压缩后（5.4 KB）
10.5.3 沙箱工具输出 vs 原始输出
原始输出示例（Playwright页面快照的一部分）：
<div class="css-1a8s8j9" data-testid="login-form">
<div class="css-x1jz3q">
<input id="username" type="text"
class="css-2kgf9h"
placeholder="请输入用户名"
value="">
<input id="password" type="password"
class="css-3khf7d"
placeholder="请输入密码"
value="">
<button class="css-4khfr8"
data-testid="login-button"
disabled="">
登录
</button>
</div>
</div>
Context Mode沙箱输出：
{
"type": "page_snapshot",
"title": "登录页",
"key_elements": [
{"id": "username", "type": "input", "label": "用户名"},
{"id": "password", "type": "password", "label": "密码"},
{"id": "login-button", "type": "button", "label": "登录", "disabled": true}
],
"form_action": "/api/login",
"has_captcha": false
}
对比：
| 指标 | 原始输出 | 沙箱输出 |
|---|---|---|
| 大小 | 56 KB | 0.5 KB |
| Token消耗 | ~42,000 | ~375 |
| 语义保留 | 100% | 95% |
10.5.4 Context Mode的四大解决方案
| 方案 | 效果 | 说明 |
|---|---|---|
| Context Saving | 98%压缩 | 沙箱化工具输出，只保留语义 |
| Session Continuity | 断点续接 | SQLite + FTS5 BM25检索 |
| Think in Code | 避免读取 | LLM写脚本分析，不用读取大文件 |
| Output Compression | 65-75%节省 | 技术内容精简 |
///
PART 06
10.6 Think in Code：不用读取，用脚本
10.6.1 传统方式的困境
分析代码库时，传统方式是：
Read file1 → 塞进上下文
Read file2 → 塞进上下文
Read file3 → 塞进上下文
... (重复N次)
上下文窗口被撑爆
实际数字：
- 分析50个代码文件
- 每个文件平均10KB
- 总共500KB原始内容
- 约 375,000 Tokens（超出大多数模型的上下文窗口）
10.6.2 Think in Code的思路
不要读取，让AI写脚本分析：
// 传统方式：47 × Read() = 700 KB上下文消耗
// Think in Code：1 × ctx_execute() = 3.6 KB上下文消耗
ctx_execute("javascript", `
const fs = require('fs');
const path = require('path');
// 递归扫描src目录
function scanDir(dir, depth = 0) {
if (depth > 3) return; // 最多3层
const files = fs.readdirSync(dir);
files.forEach(f => {
const full = path.join(dir, f);
const stat = fs.statSync(full);
if (stat.isDirectory()) {
scanDir(full, depth + 1);
} else if (f.endsWith('.ts') || f.endsWith('.tsx')) {
const content = fs.readFileSync(full, 'utf8');
const lines = content.split('\\n').length;
console.log(full + ': ' + lines + ' lines');
}
});
}
scanDir('src');
`)
上下文消耗对比：
| 方式 | 上下文消耗 |
|---|---|
| 47次Read | 700 KB (~525,000 Tokens) |
| 1次ctx_execute | 3.6 KB (~2,700 Tokens) |
节省 99.5% 的上下文空间！
10.6.3 什么时候用Think in Code？
适合的场景：
- 统计代码行数
- 查找特定模式的代码
- 分析文件结构
- 批量重命名
- 生成报告
不适合的场景：
- 需要AI理解代码逻辑
- 需要AI进行复杂推理
- 需要AI修改代码
///
PART 07
10.7 自动压缩触发阈值配置
10.7.1 为什么需要配置？
不同的任务需要不同的压缩策略：
| 任务类型 | 推荐阈值 | 说明 |
|---|---|---|
| 简单编辑 | 80% | 不需要频繁压缩 |
| 代码审查 | 70% | 需要保留较多上下文 |
| 复杂调试 | 60% | 调试信息重要 |
| 大型重构 | 50% | 重构风险高，需要更多上下文 |
10.7.2 配置方法
在OpenCode配置文件中：
{
"compaction": {
"auto_trigger_threshold": 0.75,
"prune_threshold": 40000,
"summarize_model": "haiku",
"exclude_patterns": [
"*.log",
"**/node_modules/**"
]
}
}
配置说明：
| 字段 | 说明 |
|---|---|
auto_trigger_threshold | 自动触发压缩的阈值（75%） |
prune_threshold | Prune时保留的Token数（40,000） |
summarize_model | 用于生成摘要的模型（便宜模型即可） |
exclude_patterns | 压缩时排除的文件模式 |
10.7.3 自定义压缩策略
对于特定任务，可以临时调整阈值：
# 开启激进压缩模式（用于超长任务）
/compact --aggressive
# 开启保守压缩模式（用于重要任务）
/compact --conservative
# 临时禁用自动压缩
/config set compaction.auto_trigger false
# 恢复自动压缩
/config set compaction.auto_trigger true
///
PART 08
10.8 会话持久化与恢复
10.8.1 为什么需要会话持久化？
即使有压缩机制，长期任务仍然需要跨会话保留上下文。
问题场景：
Day 1：你和AI分析了项目架构，做了很多分析
Day 2：你继续工作时，AI完全不记得昨天的分析
Day 3：你需要重新开始
10.8.2 SQLite + FTS5 BM25检索
OpenCode使用SQLite作为会话存储：
# 查看当前会话数据库位置
/opencode session info
# 会话数据库包含：
# - 对话历史
# - 文件修改记录
# - 工具调用记录
# - 上下文压缩历史
FTS5 BM25检索：
当你问「我们上次讨论的那个安全问题」时，系统会：
- 在会话数据库中搜索相关历史
- 使用BM25算法排序最相关的结果
- 将检索结果注入当前上下文
- AI基于这些上下文回答问题
10.8.3 手动保存关键上下文
当你在对话中获得了重要的分析结果时，手动保存：
# 保存当前上下文到笔记
/opencode context save --title "项目架构分析-20260502"
# 列出已保存的上下文
/opencode context list
# 加载之前的上下文
/opencode context load "项目架构分析-20260502"
保存的内容：
# 项目架构分析-20260502
## 核心发现
1. 用户认证模块在 src/auth/
2. 发现了3个安全问题...
## 关键文件
- src/auth/login.ts
- src/auth/token.ts
...
## 下一步
1. 修复安全问题
2. 添加单元测试
///
PART 09
10.9 上下文压缩的实战策略
10.9.1 预防优于治疗
在上下文快满之前，主动压缩：
不要等到 95% 才压缩
在 70-80% 时主动压缩效果最好
为什么？
- 95%时压缩，内容已经被「挤压」得很紧
- 70-80%时压缩，还有足够的「呼吸空间」
- 主动压缩可以选择保留什么、压缩什么
- 被动压缩（自动触发）是无差别压缩
10.9.2 分阶段任务策略
对于大型任务，使用分阶段+压缩的策略：
阶段1：需求分析
→ 分析完成后 /compact
→ 保留：需求结论
→ 压缩：分析过程
阶段2：架构设计
→ 设计完成后 /compact
→ 保留：架构方案
→ 压缩：讨论过程
阶段3：编码实现
→ 每个功能完成后 /compact
→ 保留：实现细节
→ 压缩：中间调试过程
阶段4：测试验证
→ 测试完成后 /compact
→ 保留：测试结果
→ 压缩：调试日志
10.9.3 用Skill保存结构化知识
不要依赖对话历史来保存知识，用Skill：
❌ 不好：依赖AI记住「我们上次讨论的结论」
✅ 好：创建一个Skill保存结论，下次自动加载
创建结论Skill示例：
---
name: project-auth-analysis
description: 用户认证模块分析结论（2026-05-02）
origin: session-20260502
tags: [project-knowledge, auth-module]
version: 1.0.0
---
# 用户认证模块分析结论
## 核心发现
### 目录结构
- `src/auth/` - 认证模块根目录
- `src/auth/login.ts` - 登录逻辑
- `src/auth/token.ts` - Token管理
### 安全问题
1. **SQL注入风险**：login.ts 第45行使用字符串拼接
2. **密码明文存储**：需要迁移到bcrypt
3. **Token无过期时间**：需要添加expiry
## 关键决策
1. 使用JWT Token方案
2. 密码使用bcrypt hashing
3. Token有效期7天
## 下一步
- [ ] 修复SQL注入（第45行）
- [ ] 添加密码hashing
- [ ] 添加Token过期机制
///
PART 10
10.10 本章小结
核心要点
- 上下文窗口有物理上限：不同的模型有200K、128K等不同的Token限制
- 工具输出是上下文的主要消耗：一次Playwright快照可能消耗42,000 Tokens
- 压缩机制两步走：
- Prune：保留最近40K Tokens，清除更早的
- Summarize：用LLM生成摘要替换原始历史
- /compact的正确时机：
- ✅ 规划后、调试后、里程碑后
- ❌ 调试中、实现中、推理中途
- Context Mode实现98%压缩：沙箱化工具输出，只保留语义关键信息
- Think in Code节省99.5%上下文：让AI写脚本分析，不用读取大文件
- 预防优于治疗：在70-80%时主动压缩，不要等到95%被动触发
实践建议
✅ 养成习惯：每个阶段完成后主动 /compact
✅ 用 Skill 保存结构化知识，不依赖对话历史
✅ 复杂分析时用 Think in Code 代替批量读取
✅ 配置合适的自动压缩阈值（70-80%）
✅ 大型任务分阶段，每个阶段后压缩
❌ 不要等到 95% 才想起来压缩
❌ 不要在调试中途压缩
❌ 不要把所有知识都塞在对话里
下一步
上下文压缩解决了「记忆」问题，但如何选择合适的AI模型来平衡成本和效果？
这就是下一章的主题：Token经济学——月薪3000怎么用出$3000的AI。
THANKS FOR READING
🦐 龙虾 · OpenClaw 技术分享