上下文工程：AI 编程的新兴学科

上下文工程：AI 编程的新兴学科

如果 2023 年是提示工程（Prompt Engineering）的元年，那么 2024-2025 年，社区开始意识到一个更根本的问题：人类与 AI 协作编程的本质，不是「写更好的提示词」，而是「管理AI的上下文」——这正在催生一门全新的工程学科：上下文工程（Context Engineering）。

从"会聊天"到"会设计上下文"

早期的 AI 编程实践，焦点在交互层：怎么问 AI 问题，怎么拆解任务，怎么引导它一步步思考。但随着 Claude Code、Cursor、Github Copilot 等工具深入工程一线，开发者逐渐发现一个苦涩的事实：AI 的表现上限，往往不是由模型决定的，而是由你给它的上下文质量决定的。

给同样的模型，一个糟糕的上下文产生的是 boilerplate 垃圾代码，一个精心设计的上下文可以产生生产级别的系统设计。这之间的差距，不在模型，在人。

于是，一门以「上下文」为核心对象的工程学科悄然成形。

上下文工程不是什么

在深入之前，有必要澄清几个常见误解。

上下文工程 ≠ 提示词工程。 提示词工程关注的是「说什么」（内容），上下文工程关注的是「怎么说」以及「说的时候带什么」（结构与输入）。一个好的上下文工程师，会系统性地思考：代码的哪些部分需要进入上下文？用什么粒度？以什么顺序？要不要分层抽象？

上下文工程 ≠ RAG。 RAG（检索增强生成）是上下文工程的一种技术手段，但上下文工程的范畴远不止检索——它包括：上下文的选择、裁剪、排序、压缩、分层注入，以及上下文与模型注意力机制的适配。

上下文工程的核心命题

我们从实践中提炼出三个核心命题：

1. 上下文是有限资源，必须被管理

大模型的上下文窗口看似很大（200K token 以上已是常态），但实际可用且有效的上下文是另一回事。模型存在「中间丢失」问题（Lost in the Middle）：上下文中间的信息被模型关注的程度低于开头和结尾。这意味着一股脑把所有信息塞进上下文的做法是低效的。

上下文工程师要做的事：选择性暴露——把最相关的信息放在关键位置，用结构化方式组织，让模型能准确理解局部与整体的关系。

2. 上下文有层次，工程师要设计层次

一个成熟的 AI 编程上下文，通常包含以下几个层次：

• 系统层：角色定义、能力边界、行为约束（如 "你是安全审查员，重点关注 XSS 和 SQL 注入"）
• 项目层：架构概述、模块关系、关键决策日志
• 当前任务层：具体目标、文件状态、最近对话历史
• 工具层：可调用工具的能力描述和使用约束

层次不清的上下文是 AI 产生幻觉和无关输出的主要诱因之一。

3. 上下文需要版本化和可复现

传统的提示词是临时性的——每次对话都是新的。成熟的上下文工程实践，开始引入的概念：将项目上下文抽象为可版本化、可复用的结构。这类似于传统软件中的架构决策记录（ADR），但服务于 AI 而非人类读者。