上下文工程

⚠️ 源单薄性声明 本地素材里，“上下文工程”更多是一个实践命名，而不是 Anthropic 已经写死定义的官方术语页。 本页主要依据旧 wiki 中的上下文管理段落、Claude Code 的 /compact / /clear / CLAUDE.md / subagent 机制说明，以及橙书里的实战观察整理而成。

一句话

上下文工程 = 主动管理 AI 上下文窗口的实践。
核心问题不是“还能塞多少”，而是“当前任务真正该让 AI 看见什么、保留什么、隔离什么、丢掉什么”。

和“上下文”“提示词工程”的边界

• 上下文：对象本体，讲窗口容量和运行机制。
• 上下文工程：session 级内存管理，讲“怎么管这块空间”。
• 提示词工程：单条 prompt 的设计，讲“怎么说得更准”。

一句话压缩：

• 上下文 是容器
• 上下文工程 是容器管理
• 提示词工程 是容器里某段指令的写法

为什么重要

上下文不是免费的。
你不做上下文工程，AI 也会继续跑，但往往会出现三种症状：

• 越跑越慢
• 越跑越贵
• 越跑越忘事

很多“Claude 变笨了”的时刻，根子不是模型推理退化，而是session 里已经堆满了不该长期保留的东西。

核心原则

原则 1：放“当前任务需要长期保留的东西”

适合常驻上下文的通常是：

• 项目规则
• 关键边界
• 当前任务的目标和验收口径
• 已经做出的架构决策

原则 2：不要让一次性垃圾常驻

不适合长期占位的包括：

• 大段 Bash 输出
• 已经过时的中间试错
• 某次调试专用的临时说明
• 与当前任务无关的上一个任务对话

原则 3：重要状态写进稳定层，不赌 compaction

本地 docs 很明确：CLAUDE.md 会在 session 启动时全文加载，compaction 后项目 root CLAUDE.md 还会再注入。
所以，真正要跨轮、跨阶段保住的信息，不该只留在聊天记录里。

原则 4：隔离比硬塞更有效

当一个任务需要读很多文件、跑很多输出时，与其让主 session 吃掉这堆中间产物，不如把它隔离出去。
Claude Code 里最直接的隔离手段就是 [[subagent]]。

具体手段

手段 1：在 CLAUDE.md 里写 Compact Instructions

# Compact Instructions
 
When compacting, always preserve:
- The full list of modified files
- Any test commands
- Current debugging state

这不是在“增加知识”，而是在告诉压缩器：哪些状态绝不能被你压掉。

手段 2：显式 /compact focus

/compact focus on the API changes

当你知道“我要压缩，但某一层信息必须保留”时，这比被动等自动 compaction 更可控。

手段 3：用 “Summarize from here” 做局部压缩

路径：

Esc + Esc -> 选某条消息 -> Summarize from here

它和 /compact 的区别是：
/compact 压整个会话；Summarize from here 只压你选中点之后的部分。

手段 4：一件事一个 session

这是最朴素也最有效的做法。
任务切了，context 需求也切了；继续沿用旧 session，通常只会把噪音一起带过去。

手段 5：用 subagent 做上下文隔离

需要大规模读文件、跑搜索、扫 diff、做专项审查时，让子 worker 去烧自己的 context，主 session 只拿摘要。

本地实践观察

陈彬视角 · 三条实战经验

1. /context 养成习惯，一个 session 每半小时看一次。
2. CLAUDE.md 别写太长，控制在确实值得每次启动都加载的范围。
3. 一件事一个 session，功能写完、bug 修完、材料读完就 /clear 新开。

还有一个反直觉点，旧 wiki 写得很准：
memory 里放太多反而有害。
你每多加一条长期记忆，就在挤掉别的东西；所以“都记住”不是策略，“只记值得常驻的东西” 才是。

场景与反例

场景 1：采访阶段和执行阶段分开

橙书里有个很实用的套路：

1. 先让 Claude 采访你，把需求问透
2. 让它整理成 spec
3. 开一个新会话，把 spec 喂给新的 Claude 去执行

这就是上下文工程。
采访会话积累了大量探索噪音，执行会话则更适合从一份干净 spec 开始。

场景 2：长 session 里定期看 /context

如果你看到 context 里 Bash 输出、历史对话、已触发 skill 占比越来越高，就该意识到：
问题不只是“快满了”，而是当前任务信号已经开始被噪音淹没。

反例：把所有偏好都塞进 MEMORY 或 CLAUDE.md

“我喜欢什么语气”“我常写什么风格”“我偶尔会做什么”全塞进去，看似让 AI 更懂你，实际上会挤掉项目说明和任务边界。
这不是强化上下文，而是在污染上下文。

常见误解

误解 1：上下文工程 = 提示词工程

不对。
提示词工程优化的是一句话怎么说；上下文工程优化的是整个会话该保留什么。

误解 2：context 越多越好

不对。
本地材料反复强调的是“给对的信息”，不是“给全部信息”。

误解 3：有了 /compact 就不用写 CLAUDE.md

不对。
/compact 是临时压缩工具；CLAUDE.md 是稳定记忆层。两者职责不同。

误解 4：上下文工程只是 token 节省术

不对。
它不只是省钱，更是在做质量控制。你决定 AI 看什么，也就部分决定了它会怎么判断。

与其他术语的关系

• [[上下文]]：本页操作的对象。
• [[提示词工程]]：局部优化；本页是全局优化。
• [[CLAUDE.md]]：长期稳定上下文层。
• [[skill]]：按需加载，避免一开场就把全部规则塞进启动上下文。
• [[subagent]]：上下文隔离器。
• [[Harness]]：上下文工程是 harness 的“内存管理层”。

延伸阅读

• [[上下文]]
• [[subagent]]
• [[CLAUDE.md]]
• raw/2026-04-18/claude-code-docs/context-window.md
• raw/2026-04-18/claude-code-docs/commands.md

needs_sources（明确待补）

• “Context Engineering” 的更正式定义源
• 非 Claude Code 阵营的上下文管理经验
• /compact、/clear、subagent 的失败案例

---

🎬 3 个场景（读者最可能用到的情境）

场景 1 · 决定 CLAUDE.md 放什么

写作者纠结：“我的写作风格偏好、常用标签、笔名介绍”要不要全写进 CLAUDE.md？上下文工程视角：每条规则都在挤其他条的位置——只留”每次都需要 + 不放就会乱”的，其他挪到专门 skill 或独立 md。

场景 2 · skill 什么时候加载

HR 有 10 个 skill，担心”全加载进去太占位置”。其实 Claude Code 默认只把 skill 的名字+描述注册，正文按需加载。所以上下文工程的关键不是”有几个 skill”，而是”描述写得够不够准，让该触发的时候真能被触发”。

场景 3 · 长文档该全贴还是 RAG

老师让 AI 分析一本 200 页教材。全贴进 prompt 会瞬间吃掉大半 context；更好的做法是：只贴目录+当前章节 → 需要深挖时再用 Read 读指定页，或接 RAG 按语义检索相关段。

⚖️ 和最像的邻居比

术语	本质区别	适用边界
上下文工程	全局可见性设计 · 管”整个窗口里放什么”	整个 session / 项目级
提示词工程	单条指令的表达优化	单轮、一句话怎么说
Harness 内存管理层	上下文工程的落地形态	讨论实现机制时
RAG	一种”按需喂信息”的实现	知识量 > context 容量时

🚫 反例（不该这么用）

反例 1 · 把所有资料都塞进上下文

“反正有 1M 窗口，我把整个 wiki / 整个代码库一次贴进去最省事”。结果信号被噪音淹没，Lost in the Middle 效应让中间内容被忽略。正确做法：给当前任务最相关的 3-5 个文件，其他按需 Read。

反例 2 · 把所有偏好都塞进 MEMORY

“我喜欢的语气、常写的主题、偶尔会做的项目”全塞进 MEMORY.md。结果每次开场都被这些无关偏好占位，项目说明和任务边界被挤。正确做法：只记”跨项目长期稳定”的偏好，项目内的偏好放项目 CLAUDE.md。

❓ 常见误解

• 误解 1：“上下文工程 = 提示词工程” → 实际：提示词优化”这句话怎么说”，上下文工程优化”整个会话里保留什么”；一个局部、一个全局。
• 误解 2：“有了 /compact 就不用写 CLAUDE.md” → 实际：/compact 是临时压缩，CLAUDE.md 是稳定记忆层；前者保不住跨 session 的东西。
• 误解 3：“上下文工程只是省 token” → 实际：它更是质量控制——你决定 AI 看什么，就部分决定了它怎么判断。

---

🧬 历史坐标（最早谁提 · 本质 · 分型 · git）

最早谁提

“Context Engineering” 作为独立术语在 2024-2025 成形。社区通常把它归到 Andrej Karpathy：他把 LLM 类比为一种新的操作系统、context window 类比为 RAM，并把”在下一步塞进恰好合适的信息”命名为 context engineering。Anthropic 2025 年把它正式写进工程博客 “Effective context engineering for AI agents”，作为 prompt engineering 的自然升级。

本质（一句话 · 20 字内）

设计 AI 看见什么、按什么顺序、留下什么。

分型 / 演化（2-4 行主线）

• 2022-2024 prompt engineering 主导 → 关心”这句话怎么说”
• 2024 Karpathy 提出 context engineering → 从”一句话”升到”整个窗口”
• 2025 Anthropic 正式化 → 给 agent 场景的 token 预算、工具说明、记忆层都纳入管理对象
• 分叉：LangChain / LangGraph 偏”编排层”，Anthropic 偏”策展层”

代表 git / 文档

• Effective context engineering for AI agents · Anthropic 2025 · 官方定义 + 策略手册
• Context Engineering for Agents · LangChain blog · agent 视角的系统化总结
• Prompt-Engineering-Guide · DAIR.AI · 社区级指南，已把 context engineering 纳入