ai-native-context-engineering

---
name: ai-native-context-engineering
description: 'AI Native 产品方法论——上下文工程的实操 Skill。

  用户提供任务场景，Skill 自动执行上下文组织流程：

  任务目标识别 → 上下文层选择 → 动态拼装 → 成本与窗口控制 → 结果校验与纠偏 → 输出上下文工程方案。

  基于《AI Native 产品方法论》第14章。

  '
tags: p6, 上下文工程, 产品方法论
- ai-product
- methodology
- context
- prompt-engineering
- input-design
- book-skill
author: Max
source_book: AI Native 产品方法论
version: 1.0.0
homepage: https://github.com/gmaxxxie/ai-native-product-agent-skills/tree/main/skills/p6-context-engineering
stage: p6
source_chapter: 第15章 上下文工程

---


# AI Native 上下文工程 Skill

## 使用场景

- 产品需要组织复杂的输入信息交给模型
- 需要设计可解释、可替换、可治理的上下文组织方案
- 需要避免"上下文太少—AI不知道自己在做什么"或"上下文太多—AI被噪音淹没"

## 核心概念

- **上下文工程（Context Engineering）**：把任务所需信息按正确顺序、粒度和边界组织给模型的产品化能力
- **提示词**：上下文中的一小部分，通常只负责角色、任务或格式约束
- **动态拼装**：根据用户、任务、权限和状态，为每次调用临时组装所需上下文
- **上下文层次**：目标层、规则层、知识层、记忆层和状态层等不同信息层

## 为什么上下文工程是核心能力

传统软件的行为主要由代码逻辑决定，而 AI 系统的行为会显著受到上下文影响。相同的模型，在没有背景资料、缺少角色信息、拿不到历史状态的情况下，很可能给出完全不同的结果。

很多 AI 产品问题的本质，并不是模型不够强，而是上下文组织不对。

## 上下文工程流程

```
任务进入
  → 目标识别
    → 上下文层选择
      → 动态拼装
        → 生成 / 行动
          → 结果校验与纠偏
```

一旦上下文层选择错误，后面的生成质量、工具调用和风险边界都会整体失真。

## 上下文的五个层次

### 1. 目标层

- 用户现在到底想完成什么
- 例如："查询订单状态"、"申请退货"、"了解售后政策"

### 2. 规则层

- 这个任务有哪些约束、边界和权限
- 例如：不能承诺赔付、不能暴露其他用户信息、必须保留人工接管点

### 3. 知识层

- 系统需要引用哪些资料、文档、行业规则
- 例如：售后政策文档、物流规则、商品说明

### 4. 状态层

- 当前流程进行到哪里，已经做过什么
- 例如：当前会话已提供订单号、已解释过的内容

### 5. 记忆层

- 与用户或历史案例相关的长期背景
- 例如：用户偏好某种解释风格、过去类似问题的处理方式

这几层不是每次都全部打开，而是要根据任务动态拼装。

## 上下文工程的四个目标

1. **选择真正相关的信息**：不是把所有信息都塞进去
2. **用模型易于理解的方式组织信息**：顺序、结构、格式
3. **在有限窗口内控制上下文成本**：令牌消耗、延迟
4. **随任务阶段动态更新上下文内容**：不是固定模板

## 动态拼装原则

好的上下文不是固定模板，而是动态拼装：

- 根据用户角色决定哪些规则层可见
- 根据任务类型决定哪些知识层需要
- 根据当前状态决定哪些状态层包含
- 根据历史交互决定哪些记忆层激活

## 常见失败模式

### 上下文太少

- AI 不知道自己在做什么
- 结果偏题、幻觉、给出表面正确但实际不可用的结果

### 上下文太多

- AI 被噪音淹没
- 重要信息被淹没在不相关的内容中
- 成本飞涨、延迟增加

### 层次混乱

- 把规则、知识、状态、记忆混在一起
- AI 无法区分哪些是约束、哪些是参考

### 时效失效

- 使用了过期的规则或状态
- 结果在错误的世界观里工作

## 输出物：上下文工程方案

1. **上下文层次设计**：目标层、规则层、知识层、状态层、记忆层的定义和分工
2. **动态拼装规则**：根据任务类型、用户角色、当前状态决定哪些层激活
3. **窗口与成本策略**：如何在有限窗口内优化信息密度
4. **失败检测规则**：如何判断上下文是否足够、是否过期、是否混乱
5. **更新与维护机制**：上下文模板如何版本化、如何测试、如何回滚

## 使用方式

当用户提供任务场景时，自动执行：

1. 识别任务目标
2. 定义上下文五个层次
3. 设计动态拼装规则
4. 制定窗口与成本策略
5. 设计失败检测规则
6. 设计更新与维护机制
7. 输出上下文工程方案

## 示例

### 示例：AI 客服上下文工程设计

**场景描述**：
AI 客服系统需要为不同咨询类型动态组织上下文，既要包含足够信息，又要避免信息过载。

**用户输入**：
"我们的 AI 客服有时候给出的回答前后矛盾，有时候明明用户已经说了订单号，AI又问一遍"

**Skill 执行流程**：

1. **任务目标识别**

```yaml
用户咨询类型: "物流延误解释"
用户意图: 了解为什么订单还没到，什么时候能到
用户情绪: 轻度焦虑（从用词判断）
```

2. **上下文层选择**

| 层次 | 内容 | 是否包含 | 原因 |
|------|------|----------|------|
| 目标层 | 查询物流状态+解释延误 | ✅ | 核心任务 |
| 规则层 | 物流规则、赔付政策边界 | ✅ | 约束回复 |
| 知识层 | 物流公司合作政策、常见问题 | ✅ | 提供解释素材 |
| 状态层 | 已提供的订单号、已解释的内容 | ✅ | 避免重复询问 |
| 记忆层 | 用户偏好简洁解释 | ✅ | 个性化风格 |

3. **动态拼装示例**

```yaml
# 最终输入给模型的上下文

system_prompt: |
  你是电商平台客服助手。
  任务：帮助用户理解订单物流状态，提供准确的延误解释和预计时间。

目标层:
  用户问题: "我的订单怎么还没到？已经等了一周了"
  咨询类型: 物流延误解释
  用户情绪: 轻度焦虑

规则层:
  - 必须先核实具体的物流信息，不能泛泛而谈
  - 延误超过7天的订单，可主动提供补偿方案
  - 不可承诺具体的送达时间，只能提供预计范围
  - 涉及赔付的必须转人工确认
  - 保持安抚但专业的语气

知识层（检索到的相关资料）:
  [1] 物流合作方延误常见原因说明
  [2] 当前地区物流积压情况（官方公告）
  [3] 历史类似案例的有效安抚话术

状态层（当前会话）:
  订单号: 123456789
  物流状态: 运输中，当前在XX中转站
  最新轨迹: 2024-01-10 到达XX中转站（已停留3天）
  已解释内容: 无（首次询问）
  已提供的安抚: 无

记忆层:
  用户偏好: 简洁直接（基于历史会话）
```

4. **成本与窗口控制**

```yaml
总Token数: 约800 tokens
  - 系统提示: 100 tokens
  - 目标层: 100 tokens  
  - 规则层: 150 tokens
  - 知识层: 300 tokens（检索Top3）
  - 状态层: 100 tokens
  - 记忆层: 50 tokens

优化策略:
  - 知识层只取Top3最相关结果
  - 规则层优先显示高优先级约束
  - 状态层自动去重（避免重复信息）
  
成本控制:
  - 单次调用成本: ~$0.01
  - 响应时间: ~1.5s
```

5. **失败检测规则**

```yaml
检测项:
  - 上下文缺失: 检查是否包含必要的状态信息
  - 信息冲突: 检查规则层是否有矛盾约束
  - 上下文过期: 检查物流信息是否为最新（<24小时）
  - Token超限: 如果>2000 tokens，触发压缩策略
    
自动纠偏:
  - 如果缺少订单号 → 先询问订单号，不进入主流程
  - 如果物流信息过期 → 触发实时查询更新
  - 如果Token超限 → 只保留最核心的规则和知识
```

**输出结果**：

```yaml
# 上下文工程方案：AI 客服

上下文层次定义:
  
  目标层:
    内容: [用户原始问题, 意图识别结果, 情绪分析, 咨询类型]
    来源: 实时分析
    优先级: 最高
    
  规则层:
    内容: [业务规则, 权限边界, 禁用操作, 语气要求]
    来源: 规则引擎（按咨询类型加载）
    优先级: 高
    
  知识层:
    内容: [检索到的相关资料, 案例, FAQ]
    来源: RAG检索（Top K=3）
    优先级: 中
    更新: 实时检索
    
  状态层:
    内容: [订单信息, 会话历史, 已解释内容, 已承诺事项]
    来源: 记忆系统
    优先级: 高
    生命周期: 当前会话
    
  记忆层:
    内容: [用户偏好, 历史问题模式]
    来源: 长期记忆
    优先级: 低

动态拼装策略:
  
  标准咨询（如物流查询）:
    包含: 目标层 + 规则层 + 知识层(Top2) + 状态层
    平均长度: ~600 tokens
    
  复杂咨询（如售后纠纷）:
    包含: 全部5层
    平均长度: ~1000 tokens
    
  简单咨询（如活动规则）:
    包含: 目标层 + 知识层(Top1) + 规则层（简化）
    平均长度: ~400 tokens

质量保证:
  - Token预算: 最大1500 tokens，超预算则压缩知识层
  - 重复检测: 自动去重（如订单号已明确不再重复放入）
  - 时效检测: 物流信息>24小时则触发更新
  - 冲突检测: 规则层如有矛盾，优先显示高优先级规则
```