上下文工程：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写新代码，你指出来，它道歉并修正。 第20轮：AI又在某个犄角旮旯的文件里用了Joi，因为它已经忘了第1轮和第5轮的约定。
这不是模型的记忆力问题。这是上下文工程的问题：早期的重要决策需要被更显眼地嵌入上下文中，而不是混在一大段普通对话里。
第三层：项目记忆
项目记忆是第三个层次，也是最容易被忽视的一层。
一个运行了两年的项目，积累了大量的隐性知识：为什么当初选了PostgreSQL而不是MySQL、哪个bug曾经让团队折腾了三天、Cultural-ADD里对多时区的特殊处理方式是什么……这些东西从未被文档化，但对代码的正确性至关重要。
在传统开发中，这些知识存在于资深工程师的脑子里，是他们不可替代性的来源。在AI编程时代，这些知识必须被提取、编码、注入到上下文中，否则AI写出来的代码迟早会踩到这些坑。
这就是项目记忆工程要做的事：把散落在Git历史、Issue讨论、PR Review、Slack对话里的隐性知识，转化为AI可消费的显性上下文。
从RAG到上下文工程：一条正在汇合的路
有趣的是，在AI应用开发的另一个领域——大模型知识问答——人们早已在解决类似的问题。
RAG（检索增强生成）在2023-2024年被大规模采用，本质上就是把外部知识注入模型的上下文。向量数据库负责检索，检索结果拼接进Prompt，模型基于这些上下文生成答案。
RAG的核心思想可以直接迁移到代码领域：
| RAG（知识问答） | 上下文工程（AI编程） |
|---|---|
| 文档Chunk检索 | 代码模块检索 |
| 知识库 | 项目记忆库 |
| 检索相关性排序 | 上下文重要性排序 |
| 检索质量决定生成质量 | 上下文质量决定代码质量 |
但上下文工程比RAG更难。原因是：代码上下文的精度要求远高于文本问答。
在RAG场景里，检索到一篇稍微相关的文章，模型可以自己判断和过滤。但在代码场景里，上下文错一个字可能就导致AI写出类型不匹配或逻辑错误的代码。上下文工程需要更高的检索精度、更细粒度的chunk策略、以及对"什么算相关"的更精确建模。
上下文工程的工程实践
说了这么多概念，上下文工程在日常开发中到底怎么做？以下是几个被验证有效的实践。
实践一：在代码库里建一个"AI契约层"
与其让AI自己去Git历史里挖掘接口变更，不如主动维护一个契约文档，用结构化的格式记录关键的接口约定和数据模型约束。
一个简单的例子：
# AI_CONTEXT.md
## 全局约束
- 所有API请求参数使用Zod进行schema验证（禁止使用Joi）
- 日期时间统一使用UTC存储，前端展示时转换
- 禁止直接操作数据库，所有数据访问必须通过repository层
## 核心领域规则
- Order状态机：pending → paid → shipped → delivered（单向，不可逆）
- 用户密码使用bcrypt哈希，禁止在日志中打印任何用户敏感字段
- 跨境支付必须经过KYC校验，未KYC用户单笔限额$100
## 已知技术债务
- /legacy 模块将在Q3废弃，所有新功能禁止在此目录开发
- payment-gateway/v1存在并发问题，高并发场景使用v2
这个文件不需要写得像设计文档那样详尽，但需要高信号、低噪音——只写AI在代码里无法自己发现的约束。
实践二：让关键对话决策进入长期记忆
团队里用AI编程时，建议定期做一件事：把对话中产生的关键决策dump到一个共享文件中。
这个文件不需要多正式：
# AI_DECISIONS.md
## 2026-03-15
- 确定使用tRPC而非REST作为BFF层通信协议
- 原因：类型安全、前后端类型共享
## 2026-04-02
- 图片存储改用S3而非本地文件系统
- 注意：测试环境mock S3使用localstack
## 2026-05-10
- 全面启用Feature Flag，所有对外功能默认关闭，按需开启
这听起来很原始，但它的效果是惊人的：它让AI在处理任何新任务前，都能先读到"这个项目过去做过什么决策、为什么"。
实践三：上下文窗口的"分层消费"策略
不是所有上下文都需要同时出现在AI眼前。更好的策略是分层暴露：
- 基础层（始终存在）：项目结构、全局约束、核心数据模型
- 任务层（按需加载）：当前任务相关的文件、最近的Git变更
- 历史层（显式查询）：项目记忆文档、早期的技术决策
MCP协议（Model Context Protocol）在这个方向上迈出了重要一步——它让AI能够主动从各种数据源里拉取上下文，而不是被动等待你把所有东西塞进Prompt。
上下文工程为什么重要
回到最初的问题：为什么用了最先进的AI助手，代码质量却没有提升？
答案可能是：你只优化了模型，却没有优化上下文。
在Scaling Law的语境里，上下文工程做的事是提升"有效参数"的数量。当你的模型有100B参数，但上下文里只有2B tokens的相关信息，模型实际能调用的能力就只有2B。
上下文工程把上下文的质量从"随机"变成"精心设计"，相当于把有效tokens从2B提升到10B——这个效果有时候比换一个大一号的模型更显著。
更重要的是，上下文工程是一种可以积累的资产。模型会过时，但你对代码上下文的管理经验、项目记忆的组织方式、关键决策的编码格式——这些知识会随着团队和项目一起成长。
AI编程的竞争，在2026年已经开始从"模型竞争"转向"上下文工程能力竞争"。你所在团队，有多少工程时间花在了上下文工程上？
这个问题的答案，可能比模型选型更能预测你最终的代码质量。
这篇是对《Spec已死，Skills万岁》那篇文章的延续和深化。如果你对Skills和Context这两个新范式感兴趣，欢迎在评论区交流你团队里的上下文管理实践。