TL;DR

本文核心观点：

  1. 失忆症困境 — AI只能看到当前输入，无法自动获取散布在Confluence、ADR、README和团队知识中的背景信息
  2. 三层模型 — 企业级AI系统需要处理项目上下文、技术上下文、业务上下文三个层次的上下文
  3. 标准化架构 — Context Layer通过Query Interface、Aggregation Engine、Caching Layer和数据源连接器为AI提供标准化的上下文获取框架
  4. 基础设施定位 — Context Layer不是可选的附加组件，而是企业级AI系统的基础设施，与PRD结构化共同构成AI的”需求+背景”双支柱

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

在上一篇文章中，我们讨论了PRD的结构化转型——将需求从自然语言文档转变为机器可读的语义规格。但这只是第一步。当AI系统需要处理这些规格、理解业务逻辑、生成代码时，它面临一个根本问题：上下文在哪里？Context Layer架构就是为了解决这个问题而生——它为企业级AI系统提供了一个标准化的上下文分层框架。

AI的失忆症

想象这个场景：

你是一个AI编程助手，正在帮助一个开发团队实现一个新功能。你收到了一个结构化的PRD：

你开始生成代码。但很快，你发现自己需要知道：

  • 这个API应该使用REST还是GraphQL？（技术架构决策）
  • 订单数据存储在哪个数据库？（基础设施信息）
  • 这个团队使用的是Python还是Go？（技术栈约束）
  • 这个项目是否遵循特定的安全规范？（合规要求）

这些信息不在PRD里——它们散布在：

  • Confluence文档（如果过时了怎么办？）
  • 架构决策记录（ADR）
  • 代码库的README
  • 团队成员的大脑里
  • 上次会议的备忘录

这就是AI的”失忆症”：它只能看到当前输入，无法自动获取相关的背景知识。

AI的失忆症示意图

💡 Key Insight

AI的失忆症不是模型缺陷，而是结构性问题——背景知识分散在企业各处，AI应用需要主动获取而非被动等待。

为什么这很重要？

对用户的影响：

  • 每次交互都需要重复提供背景信息
  • AI生成的代码不符合团队规范
  • 需要大量人工修正

对企业的影响：

  • AI无法规模化应用（每个项目都要重新”训练”）
  • 知识孤岛——AI无法利用组织积累的经验
  • 幻觉（Hallucination）风险——AI基于不完整信息做出错误假设

Context Layer架构的目标： 为AI系统提供一个标准化的上下文获取框架，让它能够自动、动态地获取完成任务所需的背景知识。

💡 Key Insight

Context Layer不是为每个AI应用单独定制，而是作为企业级基础设施——让所有AI应用共享同一套上下文获取机制。

核心概念：Context Layer

什么是Context Layer？

Context Layer是一个抽象层，位于AI模型和业务系统之间，负责：

  1. 收集来自不同源的上下文信息
  2. 整合异构数据为统一格式
  3. 检索与当前任务相关的上下文
  4. 注入到AI模型的输入中

类比理解：

就像操作系统为应用程序提供了文件系统抽象，屏蔽了底层存储的复杂性；Context Layer为AI应用提供了”知识系统”抽象，屏蔽了企业知识分散在各个系统的复杂性。

三层Context模型

企业级AI系统需要处理三个层次的上下文：

Context Layer三层模型

Layer 1: Project Context（项目上下文）

最贴近具体实现的层次，回答”这个项目是怎么做的”。

包含内容

Project Context的职责是让AI能够像团队成员一样理解具体项目的实现细节。这包括三个核心维度：

编码规范与风格：来自CONTRIBUTING.md的代码格式化要求、来自.editorconfig的缩进和字符集约定、来自代码审查记录的常见问题模式。当AI生成代码时，这些规范直接决定了输出是否符合团队预期——没有这些上下文，AI只能生成”语法正确但风格迥异”的代码。

技术栈信息：来自package.json或requirements.txt的依赖版本、来自Dockerfile的基础镜像选择、来自tsconfig.json或pyproject.toml的编译选项。这些信息回答”这个项目用什么语言、什么框架、什么版本”，是AI理解代码库结构的基础。

命名与测试约定：来自代码库的变量命名习惯（如snake_case vs camelCase）、来自测试目录结构的测试文件组织方式、来自jest.config.ts或pytest.ini的测试框架配置。这些细节决定了AI生成的代码是否能自然融入现有代码库，而非产生命名冲突或测试失效。

💡 Key Insight

Project Context的颗粒度直接影响AI生成代码的”一次通过率”——上下文越精确，团队需要的人工修正越少。

使用场景：

  • AI生成代码时遵循项目规范
  • 新成员快速了解项目背景
  • 代码审查时自动检查合规性

Layer 2: Technical Context（技术上下文）

组织级的技术决策，回答”我们如何构建系统”。

包含内容

Technical Context超越单个项目，在组织层面建立统一的技术标准，确保跨项目一致性和长期可维护性。

架构标准与模式：来自架构评审记录的全局设计决策——比如”所有微服务间通信使用gRPC而非REST”、”数据库选型优先PostgreSQL而非MySQL”、”使用事件溯源模式处理订单状态变更”。这些决策往往经历多轮评审才确定，AI若不了解就可能生成违反架构原则的方案。

技术栈审批名单：组织已批准使用的技术清单，包括编程语言版本、框架版本、中间件选型（如Kafka vs RabbitMQ）。这份清单回答”什么可以用、什么不可以用”，是技术选型的边界约束。Context Layer需要持续跟踪这份清单的更新，避免AI推荐已被废弃的技术。

安全与合规策略：来自安全团队的编码安全规范（如SQL注入防护要求、敏感数据加密标准）、来自法务团队的合规要求（如GDPR数据保留期限、PII处理规范）。这些策略通常以内部文档形式存在，AI无法从公开资料中获取，但它们直接影响代码的实现方式。

跨项目共享约定：来自docs/adr/目录下ADR文件的技术决策记录，包括”为什么选择GraphQL而不是REST”、”为什么引入服务网格”。ADR的价值在于记录了决策的背景和权衡，AI理解这些背景后才能在类似场景下做出恰当判断。

💡 Key Insight

Technical Context是组织知识资产的核心载体——ADR记录的技术决策上下文，是AI进行技术判断的主要依据。

使用场景：

  • 架构评审时检查一致性
  • 技术选型时参考组织标准
  • 跨项目共享技术决策

Layer 3: Business Context（业务上下文）

最高层次的领域知识，回答”我们在解决什么业务问题”。

包含内容

Business Context是三层模型中最抽象但也最关键的层次——它决定了AI的理解是否与业务目标对齐。

领域模型（Domain Model）：来自DDD实践的领域概念定义——订单（Order）、账户（Account）、库存（Inventory）等核心实体及其关系。当AI需要理解”为什么订单取消后库存要自动释放”，它需要看到领域模型中定义的业务规则，而不是猜测或假设。这些概念通常存在于Confluence的架构文档或DDD工作坊产出物中。

业务规则与不变性（Business Invariants）：定义系统在任何状态下都必须满足的约束——比如”订单取消必须在发货前发起”、”账户余额不能为负”、”一个用户最多绑定5张信用卡”。这些规则如果不在上下文中，AI可能生成看似合理但违反业务不变性的代码。Context Layer需要将这些规则显式化、可检索化。

监管与合规要求：来自法务或合规团队的硬性规定——数据保留期限（如”订单记录保留5年”）、审计日志要求（如”所有金额变更必须记录操作人、时间戳、变更前后值”）、行业特定的合规标准（如PCI-DSS对支付数据的处理要求）。这些要求通常有法律约束，AI违反后将产生合规风险。

领域术语表（Glossary）：组织内部使用的业务术语定义——”SKU”在这个业务场景下的具体含义是什么、”大客”指的是哪类客户、”GMV”的计算口径是什么。术语不一致导致的沟通成本在人与人的协作中已经很高，对AI来说更是直接决定它对需求的理解是否正确。

💡 Key Insight

Business Context决定了AI的”业务对齐度”——技术实现再优雅，如果违反了业务规则或与领域模型不匹配，都是无效输出。

使用场景：

  • AI理解业务需求时参考领域模型
  • 确保技术实现符合业务规则
  • 合规性自动检查

实现架构

系统架构图

Context Layer三层模型

核心组件详解

1. Query Interface（查询接口）

AI应用通过标准化接口请求上下文。Query Interface的核心职责是接收AI应用的上下文请求、解析请求意图、判断所需上下文类型和范围，并返回结构化的上下文数据。它类似于操作系统的文件系统API——对上层应用屏蔽了底层存储的复杂性，对下层屏蔽了具体的检索实现。设计良好的Query Interface需要考虑：重试逻辑（当上下文获取失败时如何处理）、超时策略（AI应用能等待的最长时间）、优先级机制（当多个请求并发时如何调度）。

2. Aggregation Engine（聚合引擎）

从多个源收集上下文并整合。Aggregation Engine是Context Layer的”编译器”——它将来自不同数据源的异构数据（结构化的数据库记录、半结构化的API响应、非结构化的文档内容）转换为AI应用可以使用的统一格式。这个过程包括：格式标准化（如将Markdown文档转换为纯文本、将Confluence的HTML转换为语义块）、相关性排序（根据当前任务判断不同上下文片段的权重）、冲突处理（当不同数据源给出矛盾信息时如何裁决）。Aggregation Engine的性能直接影响AI应用的响应延迟。

3. Caching Layer（缓存层）

上下文信息变化不频繁，适合缓存。缓存策略需要与上下文的更新频率匹配——根据设计原则表格，静态上下文（如术语表、领域模型）适合长期缓存，半静态上下文（如技术栈、架构决策）适合短期缓存，动态上下文（如项目状态、团队成员）不适合缓存。缓存失效策略同样重要：当数据源更新时，缓存层需要主动失效相关条目，而不是依赖TTL被动过期。常见的实现方式包括Redis（用于高频访问的上下文）和PostgreSQL（用于元数据存储）。

💡 Key Insight

三个组件的组合形成了一个”上下文检索-聚合-缓存”的完整管道，任何一个环节的失败都会导致AI应用无法获得完整上下文。

数据源连接器

GitHub Connector负责从代码托管平台获取项目级上下文。它通过GitHub REST API或GraphQL API读取仓库中的关键文件：README.md提供项目概述和使用方式、package.json或requirements.txt提供依赖和版本信息、CONTRIBUTING.md提供贡献规范和编码约定、docs/目录下的架构文档提供技术决策背景。GitHub Connector还需要处理API速率限制、实现增量同步（只拉取变更的文件而非全量拉取），并对文件内容进行预处理（如提取package.json中的dependencies字段而非返回完整JSON）。

Confluence Connector负责从企业Wiki平台获取技术文档和架构说明。它通过Confluence REST API查询指定空间的文档列表、获取页面内容并解析其中的结构化信息。典型的获取目标包括：架构决策文档（说明系统设计选择）、API设计文档（说明接口规范和错误码定义）、运维手册（说明部署流程和监控指标）。Confluence Connector的挑战在于处理富文本格式（HTML嵌套表格、页面包含关系）、处理附件（如图纸或截图）以及处理权限控制（确保只获取当前用户有权限访问的文档）。

ADR Connector专门解析架构决策记录。ADR通常以Markdown文件形式存储在代码库的docs/adr/目录下，遵循固定的文件命名规范（如0001-use-redis-for-caching.md）。ADR Connector需要解析每个文件的头部元数据（ADR编号、标题、日期、状态）、提取正文中的”背景-决策-后果”结构，并建立ADR之间的关系图谱（哪些ADR被后续ADR替代、哪些ADR与哪些技术选型相关）。ADR的结构化解析使得AI可以精确检索”关于缓存的架构决策是什么”而不是泛泛搜索”缓存”。

💡 Key Insight

每个Connector都是领域特定的——它们不只是”读取文件”，而是理解如何解析和提取每个数据源中的语义内容。

工作流程

场景：AI生成订单查询API

Step 1: AI应用发起请求

Step 2: Context Layer分析需求

Step 3: 并行获取上下文

Step 4: 整合并缓存

Step 5: 注入到AI Prompt

Step 6: AI生成代码

AI现在拥有完整的上下文，可以生成符合所有规范的高质量代码。

Context Layer工作流程

关键设计原则

1. 分层抽象原则

原则：每一层只依赖下层，不依赖上层。

好处：

  • 清晰的依赖关系
  • 便于分层测试
  • 支持跨项目复用上层上下文

2. 最小必要原则

原则：只获取当前任务必需的上下文，避免信息过载。

3. 实时性与一致性权衡

原则：根据上下文类型选择合适的更新策略。

上下文类型 更新频率 缓存策略 示例
静态 很少变化 长期缓存 术语表、领域模型
半静态 定期更新 短期缓存 技术栈、架构决策
动态 实时变化 不缓存 项目状态、团队成员

4. 可观测性原则

原则：所有上下文获取操作都应该可追踪、可审计。

用途：

  • 性能监控（哪些上下文获取慢？）
  • 调试（AI为什么做出了这个决策？）
  • 优化（哪些上下文最常被使用？）

实践案例：从零到一构建Context Layer

案例背景

公司：中型SaaS公司，50人工程团队，10个微服务 问题：AI代码助手生成的代码不符合团队规范，每个项目都要重新”调教” 目标：构建Context Layer，让AI自动获取组织级上下文

实施步骤

Phase 1: 上下文盘点（Week 1-2）

  1. 识别现有的上下文源
    • GitHub: 代码库、README、CONTRIBUTING.md
    • Confluence: 架构文档、API文档、运维手册
    • Notion: 团队规范、会议记录
    • 代码库: docs/adr/ 目录下的架构决策记录
  2. 分类整理

Phase 2: 构建最小可行产品（Week 3-4）

  1. 选择技术栈
    • API: FastAPI (Python)
    • Cache: Redis
    • Storage: PostgreSQL (metadata) + S3 (文档)
    • Connectors: GitHub API, Confluence API

  2. 实现核心API

  3. 实现第一个Connector（GitHub）
    • 读取项目README
    • 解析package.json/requirements.txt获取技术栈
    • 读取CONTRIBUTING.md获取规范

💡 Key Insight

MVP阶段优先实现GitHub Connector——它获取的上下文最具体、ROI最高，是验证Context Layer价值的最快路径。

Phase 3: 集成与验证（Week 5-6）

  1. 与AI代码助手集成
    • 修改AI助手的prompt构建逻辑
    • 在生成代码前自动调用Context Layer
  2. A/B测试
    • 对照组：AI助手无上下文
    • 实验组：AI助手使用Context Layer
    • 指标：代码合规率、人工修改率、开发者满意度
  3. 迭代优化
    • 根据反馈调整上下文权重
    • 添加更多数据源
    • 优化缓存策略

Phase 4: 推广与扩展（Week 7+）

  1. 推广到更多项目
    • 模板化配置
    • 自动化 onboarding
  2. 扩展数据源
    • Jira（项目历史）
    • Slack（团队讨论）
    • DataDog（运维上下文）
  3. 建立治理机制
    • 上下文更新流程
    • 质量审核机制
    • 贡献者指南

实施成果

量化指标（实施后3个月）：

  • AI生成代码的一次通过率：35% → 72%
  • 人工修改代码的时间：平均45分钟 → 15分钟
  • 新成员熟悉项目时间：2周 → 3天
  • 架构决策一致性：主观评估 → 可量化检查

定性反馈：

  • “AI终于知道我们在用什么数据库了”
  • “生成的代码风格和我们团队一致”
  • “新成员可以通过Context Layer快速了解项目”

未来演进

短期（6-12个月）

1. 标准化与开源

  • 开源Context Layer框架
  • 标准化Context Schema
  • 社区贡献更多Connectors

2. 与RAG深度集成

  • Context Layer作为RAG的预处理层
  • 结合向量检索和结构化上下文
  • 支持多模态上下文（图表、视频）

中期（1-3年）

1. 智能上下文推断

  • AI自动识别需要的上下文
  • 主动推送相关上下文
  • 预测性上下文加载

2. 跨组织上下文共享

  • 行业标准上下文库
  • 开源项目的上下文共享
  • 上下文的市场化交易

💡 Key Insight

中期来看，”智能上下文推断”是最高价值的方向——让AI主动判断需要什么上下文，而不是被动等待请求。

长期（3-5年）

1. 上下文即服务（Context-as-a-Service）

  • 专门的Context Layer云服务商
  • 按需订阅行业上下文
  • 上下文的实时更新和同步

2. 自主演化的Context Layer

  • 自动发现新的上下文源
  • 自动学习上下文之间的关系
  • 自动优化上下文检索策略

结尾

Context Layer架构的核心洞见是：AI的能力不仅取决于模型本身，更取决于它能获取多少相关上下文。

就像人类专家需要了解背景才能给出高质量建议，AI也需要上下文才能生成符合组织标准的输出。

Context Layer不是可选的附加组件，而是企业级AI系统的基础设施。

💡 Key Insight

上下文是AI的”氧气”——没有足够的背景知识，AI的输出质量受限于它自己能猜测到的范围。

在上一篇文章中，我们讨论了PRD的结构化——这是给AI”明确的需求”。 在这一篇文章中，我们讨论了Context Layer——这是给AI”完整的背景”。

两者结合，才能让AI真正成为企业的”数字员工”，而不仅仅是”高级自动补全”。

深度阅读时间：约 17 分钟

参考来源

*Published on 2025-02-23 阅读时间：约 20 分钟*

本系列文章：