上下文工程

用户1208

5月29日修改

最后更新：2026 年 3 月

"上下文工程是一门艺术：在正确的时间，将正确的信息填入上下文窗口。"——Andrej Karpathy​

本指南涵盖从上下文预算的 Token 数学，到构建模块化、团队规模的配置系统的全部内容。它是终极指南中更广泛配置章节的配套文档——那些章节介绍单项技术，本文档则展示如何将它们组合成一个连贯的系统。​

1.
什么是上下文工程​

2.
上下文预算​

3.
配置层级​

4.
模块化架构​

5.
团队配置组装​

6.
上下文生命周期​

7.
质量度量​

8.
上下文缩减技术​

9.
成熟度评估​

10.
Token 审计工作流​

11.
研究模式​

12.
注意力机制与可靠性​

13.
Token 压缩工具​

1. 什么是上下文工程

定义

Andrej Karpathy 创造了这个说法："上下文工程是一门艺术：在正确的时间，将正确的信息填入上下文窗口。"​

这句话包含三个不那么显而易见的要求：

•
填充：上下文窗口应当经过有意识的填充，而非随机堆砌。大部分留空是浪费模型能力；杂乱塞满则浪费 Token 并降低输出质量。​

•
正确的信息：并非所有信息都同等重要。架构决策比代码风格偏好更有价值。负面约束（"永远不要将原始 SQL 错误返回给客户端"）比宏观目标（"写干净的代码"）更具可操作性。​

•
正确的时间：针对后端代码的路径范围规则，在编辑前端组件时毫无价值。凡事都加载的懒惰做法会降低遵循质量。​

提示工程 vs. 上下文工程

这两个术语经常被混淆，但区别很重要：

提示工程是为单一任务设计正确的问题。上下文工程是确保 Claude 在任何任务开始前就具备正确背景知识的系统。即使提示写得再好，底层上下文工程薄弱，结果依然平庸——因为模型缺乏对项目结构、规范和约束的整体理解。​

一个实用的类比：提示工程是给承包商写一封好邮件；上下文工程是确保承包商在读第一封邮件之前就理解项目的入职流程、代码风格指南、架构文档和团队规范。​

上下文工程 vs. 上下文优化

两个术语在文献中都有出现，有时可以互换，但它们并不相同。​

一个有用的心智模型：上下文工程回答"包含什么"，上下文优化回答"删除什么"。​

实践中两者都要做。工程阶段构建完整图景：架构决策、规范、约束。优化阶段进行修剪：去除冗余、压缩冗长规则、归档过时条目、将子系统特定内容限定路径范围。第 8 节中的缩减技术就是优化阶段。​

上下文工程​