上下文工程:AI开发者的第四项核心技能
Site Owner
Published on 2026-05-14
AI编程工具已经足够强大。但一个奇怪的现象在社区里蔓延:明明用了最先进的AI助手,代码质量却没有想象中提升,有时候反而更差了。这不是工具的问题,也不是模型的问题。这是上下文的问题。上下文正在成为AI编程的隐形瓶颈,而一门新的工程学科——上下文工程——正在这个瓶颈上生长出来。

上下文工程: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轮的约定。