TL;DR

本文核心观点：

  1. 上下文即一切 — AI输出的质量90%取决于输入的上下文质量
  2. Context as Code — 上下文需要被工程化管理，而不是随意拼凑
  3. 分层架构 — 系统上下文、领域上下文、任务上下文的分层管理
  4. 竞争壁垒 — 高质量上下文是AI时代企业的核心知识产权

上下文：通用知识到专业价值的转换器

💡 Key Insight

LLM的知识是通用的，但价值是具体的。上下文是把通用AI转化为专业AI的转换器。

同一个Prompt，不同的结果

场景：让AI实现一个支付功能

上下文A（贫乏）： 输出： 一个基础的支付函数，缺少错误处理、安全考虑、业务规则。

上下文B（丰富）： 输出： 生产级的支付模块实现，包含完整的错误处理、安全控制、业务逻辑。

差异根源：上下文。

上下文质量公式

维度 低质量上下文 高质量上下文
完整性 碎片化、缺失关键信息 全面覆盖业务/技术约束
结构化 随意组织 分层清晰、易于消费
准确性 包含错误/过时信息 实时更新、经审核
可获取性 分散在各处 集中管理、按需加载
版本一致性 上下文间矛盾 版本对齐、相互兼容

Context as Code：把上下文当作第一等制品

💡 Key Insight

如果Prompt是第一等制品，上下文就是制品的原材料。原材料需要被采购、存储、加工、配送——这就是上下文工程。

上下文的生命周期

上下文的生命周期

上下文的生命周期

上下文即代码（CaC）

在软件工程里，代码是第一等制品——有版本控制、有审查流程、有发布流水线。Context as Code（CaC）把这个逻辑翻转到上下文管理上：上下文不再是每次对话的临时拼凑物，而是需要被规划、建设、审核和维护的工程资产。

类比制造业的供应链，上下文也需要经过完整的生命周期：采购（从代码库、文档、需求中提取上下文）→ 存储（版本化管理，按层级组织）→ 加工（清洗、标注、结构化）→ 配送（按需组装注入）。每个环节都需要标准、工具和质量门禁。

CaC 的核心转变是视角：从”上下文是 prompt 的附属”到”prompt 是上下文的消费端”。当上下文是第一等制品，prompt 的质量就变成了上下文供应链的下游指标——上游质量问题在下游会放大，而不是消失。

上下文版本与依赖

上下文不是静态文档，而是随业务演进不断更新的活制品。系统架构变了，对应的系统上下文必须同步更新；领域模型重构了，领域上下文需要版本跃迁；甚至同一个项目里，不同功能分支可能需要不同版本的上下文。

版本管理解决的是”我的上下文是否与当前任务对齐”的问题。依赖管理则更进一步：任务上下文依赖领域上下文的特定版本，领域上下文依赖系统上下文的特定版本。这种依赖链要求我们在注入上下文时不仅考虑内容，还要考虑版本兼容性——向上回溯检查依赖链，向前预估影响范围。

版本冲突是上下文工程里的隐性 bug。当两个上下文片段引用了互相矛盾的领域规则，LLM 会表现出不确定性和不一致性，而表面上看只是”prompt 需要调优”。建立版本策略（包括版本命名规范、变更日志、废弃规则）是让上下文工程可持续的基础设施。

上下文组装策略

三层上下文不是三条平行线，而是按需组装的嵌套结构。系统上下文提供全系统共识的背景知识；领域上下文在系统背景之上叠加特定业务域的概念、规则和约束；任务上下文则在领域背景之上注入当前任务特有的目标、输入和成功标准。

组装策略解决的是”当前任务需要哪些上下文、以什么顺序组合”的问题。基本原则是先宽后深：先注入系统上下文建立基本语境，再叠加领域上下文引入专业知识，最后在顶部装载任务上下文指定具体目标。三层之间的优先级遵循最近引用原则——任务上下文覆盖领域上下文，领域上下文覆盖系统上下文。

组装时的另一个考量是上下文体积与 token 成本的平衡。LLM 的上下文窗口有上限，上下文总量超出限制后会被截断，导致早期注入的上下文失效。组装策略需要建立优先级规则：在 token 受限的情况下，优先保留哪些上下文片段、裁剪哪些。实践中的经验法则是：任务相关的具体约束优先于通用的领域背景，动态信息（当前 sprint 目标、近期决策）优先于静态信息（基础架构描述）。

分层上下文：按需组装的内存管理

💡 Key Insight

不是把所有的上下文都扔给AI，而是按需分层组装。就像OS的内存管理一样，只加载当前需要的。

三层上下文模型

三层上下文模型

上下文缓存与复用

上下文工程的一大浪费是”每次任务从零构建上下文”。同一个代码库的结构、同一套业务规则、同一个技术栈——这些知识在不同任务间高度重复，却每次都要重新拼凑。缓存机制解决的是”上下文构建的边际成本随任务数量递减”的问题。

缓存策略需要区分两种上下文：静态上下文（系统架构、技术栈、编码规范）变更频率低，适合长期缓存和全局复用；动态上下文（当前迭代目标、最近的技术决策、积压的 bug）随时间变化，适合会话级缓存。静态上下文缓存命中率越高，上下文构建的效率提升越显著。

缓存失效是另一个关键设计点。当系统上下文引用的代码库发生了结构性变化（比如微服务拆分），缓存的系统上下文必须主动失效，否则会引入过时的误导性信息。失效策略可以基于时间（定时刷新）、基于事件（代码库 webhook 触发刷新）或基于版本（依赖链版本检测）。实践中，组合使用时间+事件的混合策略最常见：定时全量刷新保证基线新鲜度，事件触发增量更新保证热点不过期。

跨会话复用则更进一步：同一个任务上下文，如果后续有类似任务，可以直接克隆复用，而不需要重新构建。复用率是衡量上下文工程成熟度的有效指标——成熟的上下文工程体系，任务上下文的复用率应该在 40% 以上。

上下文管理系统：工程化的刚需

💡 Key Insight

上下文管理不是可选的奢侈品，而是AI-Native开发的刚需。没有它，团队会在重复的上下文构建中浪费90%的时间。

上下文管理系统：工程化的刚需

核心功能

上下文管理系统的工程化落地，依赖四个核心功能的实现。它们构成了从”有上下文”到”上下文可用”到”上下文可信”的完整链条。

1. 上下文发现解决的是”需要什么上下文、从哪里获取”的问题。典型失败模式是上下文碎片化——系统架构描述在 wiki，数据库 schema 在另一个文档，编码规范在 conf 对象里，LLM 每次都要自己拼凑，发现效率极低。好的发现机制有统一的上下文注册中心，支持按关键词、技术栈、模块路径检索，返回结构化的上下文片段而非原始文档。

2. 上下文组装解决的是”如何将离散的上下文片段组合成完整的上下文包”的问题。除了简单地拼接，上下文组装还需要处理优先级（当上下文总量超限时保留哪些）、去重（避免同一信息在不同片段中重复出现）和格式统一（Markdown、JSON、纯文本等不同格式的兼容）。组装输出是给 LLM 消费用的，上下文片段之间的衔接自然度直接影响 LLM 对上下文的理解质量。

3. 上下文注入解决的是”如何将组装好的上下文传递给 LLM”的问题。这不只是一个技术对接问题，而是会影响 LLM 对上下文的理解和利用效率。注入时机（Prompt 前/后/穿插）、注入方式（完整上下文包/流式渐进/按需加载）、注入位置（system prompt / user prompt / 专用字段）都是上下文注入设计需要权衡的维度。

4. 上下文验证解决的是”如何确认注入的上下文是正确、完整、一致的”的问题。常见失败模式包括：上下文过期导致 LLM 基于错误信息推理、上游变更引发下游上下文不一致、Token 截断导致关键上下文被截掉。验证机制可以是规则驱动的（检查版本号、引用有效性、长度阈值），也可以是 LLM 驱动的（让一个专门的验证 LLM 检查上下文的内部一致性）。

组织能力建设：上下文工程师新角色

💡 Key Insight

上下文工程师是AI时代的新角色。他们不写业务代码，但决定AI写代码的质量上限。

新角色：上下文工程师（Context Engineer）

职责：

  • 设计和维护组织级上下文架构
  • 建立上下文编写标准和最佳实践
  • 开发上下文管理工具和流程
  • 培训开发者有效使用上下文
  • 监控上下文质量和使用效果

技能要求： | 技能 | 重要性 | 说明 | |——|——–|——| | 领域建模 | ⭐⭐⭐⭐⭐ | 理解业务，抽象领域概念 | | 信息架构 | ⭐⭐⭐⭐⭐ | 组织大规模信息系统 | | Prompt工程 | ⭐⭐⭐⭐ | 理解AI如何消费上下文 | | 技术写作 | ⭐⭐⭐⭐ | 清晰表达复杂概念 | | 工具开发 | ⭐⭐⭐ | 构建上下文管理工具 |

上下文成熟度模型

级别 特征 典型表现
L1 混乱 无上下文管理，每次都从零开始 每次AI对话都重复解释系统背景
L2 个人 个人积累了一些上下文片段 有私人文档，但不共享
L3 团队 团队有共享的上下文库 Confluence/Notion有组织
L4 工程化 上下文即代码，有管理流程 Git管理，CI/CD验证
L5 智能 AI辅助上下文组装和优化 自动发现、自动推荐、自动优化

实施路线图

阶段1：基础建设（1-2月）

  • 建立上下文编写规范
  • 创建核心领域上下文文档
  • 搭建上下文Git仓库

阶段2：工具化（2-3月）

  • 开发上下文管理CLI工具
  • 集成IDE插件
  • 建立上下文发布流程

阶段3：规模化（3-6月）

  • 推广到全团队
  • 建立上下文质量度量
  • 培养上下文工程师

阶段4：智能化（6-12月）

  • AI辅助上下文发现
  • 自动上下文优化建议
  • 上下文使用数据分析

结尾

🎯 Takeaway

无上下文工程 有上下文工程
AI输出不稳定 AI输出可预期
每次从零开始 复用组织知识
个人经验依赖 团队协作基础
隐性知识流失 知识资产化
AI是辅助工具 AI是生产力倍增器

上下文工程是AI-Native开发的隐性基础设施。

它不直接产生代码，但决定了代码的质量上限。不直接创造功能，但决定了功能的实现效率。

在AI时代，组织的核心竞争力不再是”有多少人懂编程”，而是”有多少高质量上下文可以被AI利用”。

“代码可以被复制，模型可以被购买，但上下文的积累是独一无二的护城河。”

📚 延伸阅读

经典案例

  • GitHub Copilot的上下文处理：如何分析代码库提供相关建议
  • Sourcegraph的代码智能：大规模代码库的上下文理解

本系列相关

学术理论

  • 《The Architecture of Open Source Applications》: 理解复杂系统的上下文
  • 《Working Effectively with Legacy Code》(Michael Feathers): 如何在缺乏上下文的代码中工作
  • 《Information Architecture》(Louis Rosenfeld): 信息组织的系统方法

深度阅读时间：约 11 分钟