上下文工程：AI开发者的第四项核心技能

2026年，AI编程工具已经足够强大。但一个奇怪的现象在社区里蔓延：明明用了最先进的AI助手，代码质量却没有想象中提升，有时候反而更差了。

这不是工具的问题，也不是模型的问题。这是上下文的问题。

上下文正在成为AI编程的隐形瓶颈。而一门新的工程学科，正在这个瓶颈上生长出来。

---

当上下文成为卡脖子的那个环节

过去两年，业界讨论AI编程时，话题几乎都围绕"模型能力"展开：模型能不能理解复杂逻辑，能不能处理长文件，能不能做多步骤推理。每一代新模型发布，评测分数都会刷新一遍。

但有一个问题几乎没人问：给你一个足够强的模型，它的上下文窗口里应该装什么？

这个问题在2025年之前不重要。那时候的AI助手是"问答式"的——你问一段代码什么意思，它回答；你让它写一个函数，它写。上下文窗口几乎是空的，用完即走。

2026年的AI编程工具已经完全不是这样了。现在的Agent可以：

• 理解你整个代码仓库的结构和依赖关系
• 记住过去三十次对话里你做过的所有决策
• 自主读取Git历史、Issue列表、CI日志来推断下一步该做什么
• 跨文件修改，同时保证几十个文件的语义一致性

做到这些的前提只有一个：上下文窗口里要装正确的东西。

当上下文从"用完即走"变成"核心资产"，一个新的工程问题就出现了——这个问题现在有一个名字：上下文工程（Context Engineering）。

---

上下文工程的三个层次

粗略地分，AI编程中的上下文有三个层次，每个层次都有不同的工程挑战。

第一层：代码上下文

代码上下文是最直观的一层。AI需要知道你当前在什么文件、什么函数、项目的整体结构是什么、依赖关系是怎样的。

但"代码上下文"远不只是"把当前文件内容喂给AI"这么简单。

一个真实项目的代码上下文，包含但不限于：

• 类型定义和接口契约：AI最常见的错误之一是"语义漂移"——修改了一个函数签名，但漏掉了所有调用方。如果把类型定义和接口契约作为上下文，AI就能自动发现这类问题。
• 业务逻辑的非正式约束：代码里写不下的业务规则，比如"这个字段只有管理员才能修改"、"这个流程必须在24小时内完成"。这些信息对AI来说是完全不可见的，除非你显式告诉它。
• 跨文件的依赖图谱：当你让AI修改一个核心模块时，它需要知道哪些模块依赖它、它又依赖谁。这是传统"选中文件→复制→粘贴给AI"模式最大的盲区。

代码上下文的工程挑战是：如何结构化地表达和组织这些信息，让AI能够精确地消费它，而不是被无关信息淹没。

第二层：对话上下文

对话上下文是第二个层次，也是大多数AI编程工具做得最差的一层。

当你在一个会话里跟AI协作了二十个来回，AI很可能已经"忘记"了早期对话里的一些关键决策。更糟糕的是，它可能记得，但那些记忆已经沉到了上下文窗口的深处，被近期对话淹没，检索时权重不够。

一个典型的场景：

第1轮：你告诉AI，这个项目里统一用Zod做数据验证，不允许用Joi。 第5轮：AI开始用Joi写新代码，你指出来，它道歉并修正。 ：AI又在某个犄角旮旯的文件里用了Joi，因为它已经忘了第1轮和第5轮的约定。