TL;DR

Context 工程不是装个向量数据库就完事。它有 5 个可量化的成熟度阶段：

  1. L1 缓存复用 — 同一问题不打两次 API
  2. L2 语义检索 — 字符串不同但语义相同的问题命中
  3. L3 主动喂 Context — 知道 AI 在”基于什么”回答
  4. L4 防腐烂 — Context 不会越用越糟
  5. L5 企业级分层 — 项目/技术/业务三层架构
  6. 每阶段配一篇锚点 — 给 5 个不同阶段的人不同的入口

写给 Context 工程师

如果你正在做 AI 相关项目，几乎肯定有人问过你：”为什么 AI 答得这么差？”

你大概率回答过：”因为 Context 不够。”

对方大概率会问：”那加 Context 不就行了？”

然后你就陷入了”加什么、怎么加、加在哪”的细节——这是一个没有尽头的兔子洞。本文不是要带你走完整个兔子洞，而是要给你一张地图，告诉你当前在兔子洞的哪一层、下一步该补什么能力。

💡 Key Insight

Context 工程的成熟度评估比”我们用了 RAG”重要 10 倍——前者告诉你接下来 6 个月该做什么，后者只是采购了工具。

5 阶段成熟度模型

我把 Context 工程能力分成 5 个阶段。每个阶段有一个明确的”做到了什么”，也有一个明确的”还没做到什么”。你可以对照看自己在哪一阶段。

阶段 名称 做到了 还做不到
L1 缓存复用 重复问题不重复花钱 相似问题不重复花钱
L2 语义检索 字符串不同但语义相同的问题命中 主动管理该喂什么
L3 主动喂 Context AI 知道”基于什么”回答 知道哪些 Context 烂了
L4 防腐烂 知道 Context 新鲜度 项目/技术/业务分层管理
L5 企业级分层 跨项目复用组织知识 全自动演化

重要：这 5 个阶段不是升级路径，是并列能力。 你可以同时拥有 L1 和 L4，但缺 L2。每个阶段对应一个工程问题，对应一篇锚点文章。

L1：缓存复用（Cost Engineering）

你在这一阶段的特征

  • AI 项目已经上线，每天有几万次调用
  • 月账单在涨，但你说不出哪类问题在重复花钱
  • 团队开始讨论”要不要省钱”

核心问题

重复问题为什么要花两次钱？

这是最朴素的 Context 工程问题。用户问”什么是 Python 的 GIL”，10 分钟后另一个用户问”能解释一下 GIL 吗”——两个问题答案完全一样，但传统精确匹配命中率只有 5%，剩下 95% 都重新调了 API。

锚点文章

语义缓存的经济学：如何用记忆节省 90% 的 API 成本

这篇会教你：向量相似度怎么识别”字符串不同但语义相同”的问题；L1/L2/L3 多层缓存架构怎么把延迟从 500ms 压到 0.1ms；置信度过滤怎么防止低质量答案污染缓存。

读完之后，你应该能用一句话说清楚为什么”Python GIL”和”Python Git”在编辑距离层面很接近，但在语义层面完全不同。

L1 的临界点

当你开始算”语义缓存命中率 30% 等于月省 $X”的时候，就准备好从 L1 进入 L2 了。

💡 Key Insight

L1 解决的问题是”重复”，L2 解决的问题是”相似”。这两者加起来能覆盖 50-70% 的成本浪费——剩下的浪费要靠 L3+。

L2：语义检索（Context Retrieval）

你在这一阶段的特征

  • 已经知道 RAG 这个词
  • 装了向量数据库，但召回率一般
  • 经常遇到”AI 答得不对，但向量检索明明命中了相关文档”的尴尬

核心问题

上下文窗口是有限的 RAM，向量库是无限的磁盘——怎么分页？

2025 年大家都在聊”上下文窗口越来越大”——128K、200K、1M。但窗口大不等于好用。长上下文会引发 TTFT 飙升、成本爆炸、注意力稀释（Lost in the Middle）。把 1000 篇文档全部塞进 prompt 既贵又慢。

真正的工程问题不是”上下文窗口能装多少”，而是”在有限窗口里放什么”。

锚点文章

上下文窗口的”虚拟内存”化：当 RAG 成为分页机制

这篇是 L2 的核心。它把操作系统虚拟内存的思想映射到 LLM 应用：上下文窗口当 RAM，向量库当磁盘，分页、LRU 置换、工作集跟踪——整套内存管理机制都可以迁移过来。

你会学到：

  • 页表（Context Map）怎么设计：page_id、vector、recency、access_count、dirty_flag
  • 分页粒度怎么选：句子级太细（页表爆炸），文档级太粗（信息过载），段落级（~500 tokens）是 sweet spot
  • 预取怎么工作：空间局部性 + 时间局部性
  • 写回 vs 写穿怎么取舍

读完之后，你应该能问自己：我的 RAG 系统有”页错误率”监控吗？ 答不上来，说明 L2 还没真做。

L2 的临界点

当你的 RAG 不只是”向量检索”而是有”工作集跟踪”和”置换策略”的时候，恭喜你从 L2 进入 L3。

L3：主动喂 Context（Context as Product）

你在这一阶段的特征

  • L1 + L2 都做完了，成本降了一半
  • 但你发现”AI 还是不懂我公司的业务”
  • 团队开始讨论”是不是 prompt 写得不好”

核心问题

Prompt 写得好不好不重要，AI “知道什么”才重要。

这是 L2 和 L3 的根本区别。L2 阶段，AI 知道什么取决于用户问了什么；L3 阶段，AI 知道什么由你主动决定。你不再等用户问问题再检索，而是预先把 AI 该知道的背景喂给它。

锚点文章

为什么 Context Engineering 比 Prompt Engineering 更重要

这篇会帮你完成认知跃迁。Prompt Engineering 解决”怎么说”的问题（占 20%），Context Engineering 解决”基于什么说”的问题（占 80%）。企业 AI 项目的真正瓶颈是后者，不是前者。

它给了一个五层 Context 架构：

  • 数据整合（结构化数据 + 非结构化文档 + 知识图谱 + 实时系统）
  • 索引与检索（向量数据库 + 图数据库 + 缓存层 + 多策略检索）
  • 聚合引擎（格式标准化 + 相关性排序 + 冲突处理）
  • 缓存层（静态长期缓存 / 半静态短期缓存 / 动态不缓存）
  • 注入（结构化 Context 块取代”塞长文本”）

读完之后，你应该能列出当前 AI 功能依赖的所有”上下文源”——如果列不出 5 个以上，说明你的 L3 还没起步。

L3 的临界点

当你开始抱怨”AI 不知道我们公司的规则”时，你正在通往 L4。

💡 Key Insight

L3 的本质是”Context 是产品”——你不再问”怎么让 AI 答对”，而是问”怎么让 AI 该知道的都知道”。这要求你像 PM 一样管理 Context 源。

L4：防腐烂（Context Freshness）

你在这一阶段的特征

  • L3 做得不错，AI 开始”懂业务”了
  • 但过了一个月，你发现 AI 又开始答错老问题
  • 你怀疑”是不是模型降智了”，但其实是 Context 烂了

核心问题

Context 不是越用越好——是越用越烂的。

Context Rot 是 AI-Native 开发中不可避免的代价。架构事实半衰期 3-6 个月，API 规范 2-4 周，代码库状态实时变化，业务规则 1-3 个月——Context 的腐烂是指数加速的，越晚发现，修复成本越高。

锚点文章

为什么你的 AI 助手越用越笨？

这篇给你四层防线：

  • 新鲜度度量：架构事实 / API 规范 / 业务规则 / 代码示例分别有不同的半衰期，绿色/黄色/红色分级
  • 自动刷新机制：时间触发 + 事件触发 + 质量触发
  • 知识沉淀与版本化：每个 Context 片段有版本号和更新时间
  • 人机协作治理：Context 架构师 / 领域专家 / AI 训练师 / 开发者四方分工

读完之后，你应该能回答：上周的那条 Context 现在新鲜度是 80% 还是 60%？ 答不上来，L4 还在路上。

L4 的临界点

当你开始为 Context 设置”过期时间”和”更新机制”时，你已经准备好进入 L5。

L5：企业级分层（Context as Infrastructure）

你在这一阶段的特征

  • L1-L4 都做完了，单项目 AI 跑得很顺
  • 但你开始问”怎么让多个项目共享 Context”
  • 你的 Confluence 里有 500 篇 ADR，没人维护，AI 找不到也用不上

核心问题

Context 不是每个项目独立维护的——它是企业级基础设施。

L5 的标志是你不再”为 AI 应用定制 Context”，而是为整个组织建设 Context Layer——一个抽象层，屏蔽了 Confluence、ADR、GitHub、Jira、Slack 等多个数据源的复杂性。

锚点文章

Context Layer 架构：企业级 AI 系统的上下文分层设计与实现

这篇把 Context 拆成三层：

  • Project Context（项目上下文）：编码规范、技术栈、命名约定
  • Technical Context（技术上下文）：架构决策、ADR、技术栈审批名单
  • Business Context（业务上下文）：领域模型、业务不变性、合规要求

它会教你如何用 Query Interface、Aggregation Engine、Caching Layer 构建一个标准化的 Context 获取框架——和操作系统的文件系统抽象一样的设计思路。

读完之后，你应该能画出来一个 Context Layer 的架构图——画不出来，L5 还是别人的。

你在哪一阶段？

阶段 你在做 锚点文章 投入回报
L1 算语义缓存的 ROI 语义缓存 月省 30-50% 成本
L2 设计分页 RAG 虚拟内存 RAG 延迟降一个数量级
L3 把 Context 当产品 Context Engineering 入门 准确率跳一个台阶
L4 防止 Context 腐烂 Context Rot 减少”AI 突然变笨”事故
L5 企业级 Context Layer Context Layer 架构 跨项目复用组织知识

💡 Key Insight

大多数团队卡在 L2-L3 之间：装了向量数据库，但 Context 还没被当作产品来管理。从 L2 到 L3 的跃迁不是技术问题，是认知问题。

结尾

Context 工程没有银弹。它有的是5 个递进的工程能力——缓存、检索、主动供给、防腐烂、分层架构——每一层都解决前一层的盲区。

不要被”上下文工程博大精深”吓到。先看自己在 L1 还是 L5，再选对应的那一篇——比一次性读完全集高效 5 倍。

最重要的认知转变是：Context 不是”AI 应用的输入”，而是”AI 时代的应用层数据架构”。 用 PM 思维管理它，你会发现自己比 90% 的团队走得更远。

阅读路径（按阶段）

  1. 语义缓存的经济学 — L1 缓存复用
  2. 上下文窗口的”虚拟内存”化 — L2 语义检索
  3. 为什么 Context Engineering 比 Prompt Engineering 更重要 — L3 主动喂 Context
  4. 为什么你的 AI 助手越用越笨？ — L4 防腐烂
  5. Context Layer 架构 — L5 企业级分层

Published on 2026-07-01 深度阅读时间：约 8 分钟（5 篇合计约 90 分钟）

Context-Engineering 子系列 —— 给管理 AI Context 的工程师