| name | ai-native-context-engineering |
| description | AI Native 产品方法论——上下文工程的实操 Skill。
用户提供任务场景，Skill 自动执行上下文组织流程：
任务目标识别 → 上下文层选择 → 动态拼装 → 成本与窗口控制 → 结果校验与纠偏 → 输出上下文工程方案。
基于《AI Native 产品方法论》第14章。
|
| tags | ["ai-product","methodology","context","prompt-engineering","input-design","book-skill"] |
| author | Max |
| source_book | AI Native 产品方法论 |
| version | 1 |
AI Native 上下文工程 Skill
使用场景
- 产品需要组织复杂的输入信息交给模型
- 需要设计可解释、可替换、可治理的上下文组织方案
- 需要避免"上下文太少—AI不知道自己在做什么"或"上下文太多—AI被噪音淹没"
触发条件
当用户提到以下任一场景时触发：
- 需要设计 AI 产品的上下文组织方案
- 模型输出质量不稳定，怀疑是上下文问题
- 需要在有限 token 窗口内优化信息密度
- 设计动态上下文拼装、分层注入或压缩策略
执行步骤
- 任务目标识别：明确用户当前想完成什么任务，确定任务类型和咨询类别。
- 上下文层选择：根据任务类型决定需要激活哪些层次——目标层、规则层、知识层、状态层、记忆层。
- 动态拼装：根据用户角色、任务类型和当前状态，为每次调用临时组装所需上下文。
- 窗口与成本控制：在有限的 token 窗口内优化信息密度，控制单次调用成本和响应延迟。
- 失败检测规则：设计上下文缺失检测、信息冲突检测、时效失效检测和 token 超限检测。
- 输出上下文工程方案：整合上下文层次设计、动态拼装规则、窗口策略和失败检测规则。
核心概念
- 上下文工程（Context Engineering）：把任务所需信息按正确顺序、粒度和边界组织给模型的产品化能力
- 提示词：上下文中的一小部分，通常只负责角色、任务或格式约束
- 动态拼装：根据用户、任务、权限和状态，为每次调用临时组装所需上下文
- 上下文层次：目标层、规则层、知识层、记忆层和状态层等不同信息层
为什么上下文工程是核心能力
传统软件的行为主要由代码逻辑决定，而 AI 系统的行为会显著受到上下文影响。相同的模型，在没有背景资料、缺少角色信息、拿不到历史状态的情况下，很可能给出完全不同的结果。
很多 AI 产品问题的本质，并不是模型不够强，而是上下文组织不对。
上下文工程流程
任务进入
→ 目标识别
→ 上下文层选择
→ 动态拼装
→ 生成 / 行动
→ 结果校验与纠偏
一旦上下文层选择错误，后面的生成质量、工具调用和风险边界都会整体失真。
上下文的五个层次
1. 目标层
- 用户现在到底想完成什么
- 例如："查询订单状态"、"申请退货"、"了解售后政策"
2. 规则层
- 这个任务有哪些约束、边界和权限
- 例如：不能承诺赔付、不能暴露其他用户信息、必须保留人工接管点
3. 知识层
- 系统需要引用哪些资料、文档、行业规则
- 例如：售后政策文档、物流规则、商品说明
4. 状态层
- 当前流程进行到哪里，已经做过什么
- 例如：当前会话已提供订单号、已解释过的内容
5. 记忆层
- 与用户或历史案例相关的长期背景
- 例如：用户偏好某种解释风格、过去类似问题的处理方式
这几层不是每次都全部打开，而是要根据任务动态拼装。
上下文工程的四个目标
- 选择真正相关的信息：不是把所有信息都塞进去
- 用模型易于理解的方式组织信息：顺序、结构、格式
- 在有限窗口内控制上下文成本：令牌消耗、延迟
- 随任务阶段动态更新上下文内容：不是固定模板
动态拼装原则
好的上下文不是固定模板，而是动态拼装：
- 根据用户角色决定哪些规则层可见
- 根据任务类型决定哪些知识层需要
- 根据当前状态决定哪些状态层包含
- 根据历史交互决定哪些记忆层激活
常见失败模式
上下文太少
- AI 不知道自己在做什么
- 结果偏题、幻觉、给出表面正确但实际不可用的结果
上下文太多
- AI 被噪音淹没
- 重要信息被淹没在不相关的内容中
- 成本飞涨、延迟增加
层次混乱
- 把规则、知识、状态、记忆混在一起
- AI 无法区分哪些是约束、哪些是参考
时效失效
输出物：上下文工程方案
- 上下文层次设计：目标层、规则层、知识层、状态层、记忆层的定义和分工
- 动态拼装规则：根据任务类型、用户角色、当前状态决定哪些层激活
- 窗口与成本策略：如何在有限窗口内优化信息密度
- 失败检测规则：如何判断上下文是否足够、是否过期、是否混乱
- 更新与维护机制：上下文模板如何版本化、如何测试、如何回滚
使用方式
当用户提供任务场景时，自动执行：
- 识别任务目标
- 定义上下文五个层次
- 设计动态拼装规则
- 制定窗口与成本策略
- 设计失败检测规则
- 设计更新与维护机制
- 输出上下文工程方案
示例
示例：AI 客服上下文工程设计
场景描述：
AI 客服系统需要为不同咨询类型动态组织上下文，既要包含足够信息，又要避免信息过载。
用户输入：
"我们的 AI 客服有时候给出的回答前后矛盾，有时候明明用户已经说了订单号，AI又问一遍"
Skill 执行流程：
- 任务目标识别
用户咨询类型: "物流延误解释"
用户意图: 了解为什么订单还没到，什么时候能到
用户情绪: 轻度焦虑（从用词判断）
- 上下文层选择
| 层次 | 内容 | 是否包含 | 原因 |
|---|
| 目标层 | 查询物流状态+解释延误 | ✅ | 核心任务 |
| 规则层 | 物流规则、赔付政策边界 | ✅ | 约束回复 |
| 知识层 | 物流公司合作政策、常见问题 | ✅ | 提供解释素材 |
| 状态层 | 已提供的订单号、已解释的内容 | ✅ | 避免重复询问 |
| 记忆层 | 用户偏好简洁解释 | ✅ | 个性化风格 |
- 动态拼装示例
system_prompt: |
你是电商平台客服助手。
任务：帮助用户理解订单物流状态，提供准确的延误解释和预计时间。
目标层:
用户问题: "我的订单怎么还没到？已经等了一周了"
咨询类型: 物流延误解释
用户情绪: 轻度焦虑
规则层:
- 必须先核实具体的物流信息，不能泛泛而谈
- 延误超过7天的订单，可主动提供补偿方案
- 不可承诺具体的送达时间，只能提供预计范围
- 涉及赔付的必须转人工确认
- 保持安抚但专业的语气
知识层（检索到的相关资料）:
[1] 物流合作方延误常见原因说明
[2] 当前地区物流积压情况（官方公告）
[3] 历史类似案例的有效安抚话术
状态层（当前会话）:
订单号: 123456789
物流状态: 运输中，当前在XX中转站
最新轨迹: 2024-01-10 到达XX中转站（已停留3天）
已解释内容: 无（首次询问）
已提供的安抚: 无
记忆层:
用户偏好: 简洁直接（基于历史会话）
- 成本与窗口控制
总Token数: 约800 tokens
- 系统提示: 100 tokens
- 目标层: 100 tokens
- 规则层: 150 tokens
- 知识层: 300 tokens（检索Top3）
- 状态层: 100 tokens
- 记忆层: 50 tokens
优化策略:
- 知识层只取Top3最相关结果
- 规则层优先显示高优先级约束
- 状态层自动去重（避免重复信息）
成本控制:
- 单次调用成本: ~$0.01
- 响应时间: ~1.5s
- 失败检测规则
检测项:
- 上下文缺失: 检查是否包含必要的状态信息
- 信息冲突: 检查规则层是否有矛盾约束
- 上下文过期: 检查物流信息是否为最新（<24小时）
- Token超限: 如果>2000 tokens，触发压缩策略
自动纠偏:
- 如果缺少订单号 → 先询问订单号，不进入主流程
- 如果物流信息过期 → 触发实时查询更新
- 如果Token超限 → 只保留最核心的规则和知识
输出结果：
上下文层次定义:
目标层:
内容: [用户原始问题, 意图识别结果, 情绪分析, 咨询类型]
来源: 实时分析
优先级: 最高
规则层:
内容: [业务规则, 权限边界, 禁用操作, 语气要求]
来源: 规则引擎（按咨询类型加载）
优先级: 高
知识层:
内容: [检索到的相关资料, 案例, FAQ]
来源: RAG检索（Top K=3）
优先级: 中
更新: 实时检索
状态层:
内容: [订单信息, 会话历史, 已解释内容, 已承诺事项]
来源: 记忆系统
优先级: 高
生命周期: 当前会话
记忆层:
内容: [用户偏好, 历史问题模式]
来源: 长期记忆
优先级: 低
动态拼装策略:
标准咨询（如物流查询）:
包含: 目标层 + 规则层 + 知识层(Top2) + 状态层
平均长度: ~600 tokens
复杂咨询（如售后纠纷）:
包含: 全部5层
平均长度: ~1000 tokens
简单咨询（如活动规则）:
包含: 目标层 + 知识层(Top1) + 规则层（简化）
平均长度: ~400 tokens
质量保证:
- Token预算: 最大1500 tokens，超预算则压缩知识层
- 重复检测: 自动去重（如订单号已明确不再重复放入）
- 时效检测: 物流信息>24小时则触发更新
- 冲突检测: 规则层如有矛盾，优先显示高优先级规则
示例：多轮对话上下文管理
场景描述：
企业内部 AI 助手支持员工查询 HR 政策、IT 工单和行政流程。对话经常持续 5-10 轮，中间会切换话题（如从请假政策切到报销流程）。系统需要在有限 token 窗口内维持多轮对话的连贯性，同时避免旧话题的上下文干扰新话题。
用户输入：
"我们的 AI 助手在多轮对话后经常'失忆'——用户第 3 轮问的问题它还记得，但第 7 轮时突然忘记前面说过什么。而且切换话题后，它还会用旧话题的上下文来回答新问题。"
Skill 执行流程：
- 任务目标识别
任务类型: 多轮对话上下文管理
核心问题: 上下文窗口溢出导致早期对话丢失 + 话题切换时旧上下文干扰
用户角色: 企业内部员工
对话特征: 5-10轮/会话，话题频繁切换
- 上下文层选择
| 层次 | 内容 | 是否包含 | 原因 |
|---|
| 目标层 | 当前轮次的用户意图 + 话题标签 | ✅ | 核心任务 |
| 规则层 | 权限边界（员工只能查自己的数据）、回答格式 | ✅ | 约束回复 |
| 知识层 | HR政策文档、IT工单系统、行政流程手册 | ✅ | 按话题动态检索 |
| 状态层 | 当前话题、近3轮摘要、已确认的关键信息 | ✅ | 维持连贯性 |
| 记忆层 | 用户历史偏好（如偏好简洁回答）、常见问题模式 | ⚠️ 可选 | 仅长会话激活 |
- 动态拼装示例
滑动窗口策略:
完整保留: 最近3轮对话原文
摘要压缩: 第4轮之前的对话 → 生成结构化摘要
淘汰规则: 超过8轮且话题已切换的旧对话 → 仅保留关键事实摘要
话题切换检测:
触发条件: 用户意图分类发生变化（如从"请假"切到"报销"）
处理方式:
- 旧话题上下文 → 写入记忆层摘要，从工作上下文移除
- 新话题 → 触发对应知识层检索，注入新话题相关文档
- 保留跨话题的通用状态（如用户身份、已确认的个人信息）
最终上下文组装（第7轮，话题已切换）:
system_prompt: |
你是企业内部AI助手，帮助员工查询HR政策、IT工单和行政流程。
目标层:
当前话题: 报销流程
用户意图: 了解差旅报销的审批流程和时间节点
话题标签: [行政-报销]
规则层:
- 只能查询当前用户的工单和审批记录
- 不可代替用户提交审批
- 涉及金额>5000元需提示需部门经理审批
知识层（当前话题检索结果）:
[1] 差旅报销管理办法（2024版）- 审批流程章节
[2] 报销系统操作指南 - 提交与查询
[3] 常见报销问题FAQ
状态层:
当前轮次: 第7轮
当前话题: 行政-报销
近3轮摘要: |
第5轮: 用户询问报销需要哪些材料 → 已回答（发票、行程单、审批单）
第6轮: 用户确认已有电子发票 → 已确认
第7轮（当前）: 用户询问审批流程
已确认信息:
- 用户姓名: 张三
- 已有电子发票
旧话题摘要（仅保留关键事实）:
- 之前查询过2024年年假余额（剩余5天），话题已结束
记忆层:
用户偏好: 简洁回答，喜欢列表格式
- 成本与窗口控制
Token预算分配（总上限2000 tokens）:
- 系统提示: 80 tokens
- 目标层: 60 tokens
- 规则层: 120 tokens
- 知识层: 800 tokens（当前话题Top3）
- 状态层: 500 tokens（近3轮 + 摘要）
- 记忆层: 40 tokens
压缩策略:
- 当总token > 1800: 将"近3轮"降级为"近2轮"
- 当总token > 2000: 知识层从Top3降为Top2
- 旧话题摘要始终保留（仅占~50 tokens，但避免重复回答）
成本控制:
- 单次调用成本: ~$0.008
- 响应时间: ~1.2s
- 失败检测规则
检测项:
- 上下文缺失: 检查当前话题的知识层是否为空（话题切换后未触发检索）
- 话题漂移: 检查模型回复是否涉及旧话题的内容
- 状态丢失: 检查已确认信息（如订单号、用户姓名）是否仍在上下文中
- Token超限: 总token > 2000时触发压缩
自动纠偏:
- 知识层为空 → 触发当前话题的RAG检索
- 检测到话题漂移 → 注入话题标签提醒，重新生成
- 关键状态丢失 → 从记忆系统恢复已确认信息
输出结果：
上下文层次定义:
目标层:
内容: [当前用户意图, 话题标签, 情绪状态]
来源: 实时意图分类
优先级: 最高
规则层:
内容: [权限边界, 禁用操作, 回答格式要求]
来源: 规则引擎（按话题标签加载）
优先级: 高
知识层:
内容: [当前话题相关文档, FAQ, 操作指南]
来源: RAG检索（按话题触发，TopK=3）
优先级: 中
更新: 话题切换时重新检索
状态层:
内容: [近N轮对话原文, 更早对话摘要, 已确认关键信息, 当前话题]
来源: 会话状态管理器
优先级: 高
生命周期: 当前会话
记忆层:
内容: [用户偏好, 历史交互模式]
来源: 长期记忆系统
优先级: 低
动态拼装策略:
话题未切换（连续对话）:
包含: 目标层 + 规则层 + 知识层(保持) + 状态层(扩展)
完整对话保留: 最近3轮
平均长度: ~1200 tokens
话题已切换:
包含: 目标层 + 规则层(重新加载) + 知识层(重新检索) + 状态层(压缩旧话题)
完整对话保留: 仅当前话题的轮次
平均长度: ~1000 tokens
长会话（>8轮）:
包含: 全部5层（激活记忆层）
旧对话: 全部压缩为摘要
平均长度: ~1500 tokens
质量保证:
- Token预算: 最大2000 tokens，超预算则压缩旧对话和知识层
- 话题漂移检测: 每轮对比回复内容与当前话题标签
- 状态完整性: 每轮检查已确认信息是否仍在上下文中
- 摘要质量: 摘要由模型生成后经结构化校验（必须包含关键事实字段）
示例：RAG 检索上下文组装
场景描述：
企业知识问答产品需要基于内部文档库回答员工问题。文档库包含产品手册、技术规范、合规要求等上万份文档。系统使用 RAG 检索相关内容后，需要将检索结果合理组装进模型上下文——既要提供足够知识支撑回答，又要避免检索噪音和信息冲突。
用户输入：
"我们的知识问答系统接了 RAG，能检索到文档，但回答质量不稳定。有时候检索到了正确文档但回答还是错的，有时候把不相关的文档也塞进去了导致胡说八道。"
Skill 执行流程：
- 任务目标识别
任务类型: RAG检索结果的上下文组装
核心问题: 检索结果质量参差 + 上下文组装策略缺失导致噪音淹没信号
用户角色: 企业员工（按部门区分权限）
文档库规模: ~10000份文档，涵盖产品手册、技术规范、合规要求
- 上下文层选择
| 层次 | 内容 | 是否包含 | 原因 |
|---|
| 目标层 | 用户问题 + 问题分类 + 置信度 | ✅ | 指导检索和生成策略 |
| 规则层 | 回答约束（不可编造、必须标注来源、合规要求） | ✅ | 约束生成行为 |
| 知识层 | RAG检索结果（分优先级排列） | ✅ | 核心知识来源 |
| 状态层 | 用户所属部门、权限级别、已查阅文档 | ✅ | 权限过滤 + 去重 |
| 记忆层 | 用户常查领域、历史满意度反馈 | ⚠️ 可选 | 用于个性化排序 |
- 动态拼装示例
第一步 - 检索:
用户问题: "产品A的退货流程中，特殊商品（定制类）的处理规则是什么？"
检索策略: 混合检索（语义检索 + 关键词检索）
初始召回: Top10
第二步 - 重排序与过滤:
重排序模型: cross-encoder
过滤规则:
- 权限过滤: 移除用户无权访问的文档（如仅限法务部的合规文档）
- 时效过滤: 标记>6个月未更新的文档为"可能过期"
- 相关性阈值: 移除相关性分数<0.6的结果
过滤后结果: Top5
第三步 - 上下文组装:
排列策略: 按相关性分数降序，高置信结果优先
来源标注: 每段检索结果标注文档名、章节、更新日期
冲突处理: 若检索结果之间存在矛盾，标注"⚠️ 以下内容存在差异，请以更新日期较新的文档为准"
最终上下文:
system_prompt: |
你是企业知识问答助手。回答必须基于提供的文档资料，不可编造信息。
每条回答必须标注信息来源（文档名+章节）。
如果提供的资料不足以回答问题，请明确说明"当前资料中未找到相关信息"。
目标层:
用户问题: "产品A的退货流程中，特殊商品（定制类）的处理规则是什么？"
问题分类: 产品-售后-特殊商品退货
置信度: 中（问题较具体，需精确匹配）
规则层:
- 必须基于检索到的文档回答，不可使用模型内部知识
- 每条信息必须标注来源
- 资料不足时明确告知，不可猜测
- 定制类商品涉及特殊条款，需同时引用退货政策和定制商品管理规定
- 回答需标注文档时效（是否可能过期）
知识层（检索结果，已重排序和过滤）:
[1] 《产品A售后政策》第5章-特殊商品退货处理（更新: 2024-03）
相关性: 0.92 | 权限: 全员可见
内容摘要: |
定制类商品退货需满足以下条件：(1) 商品存在质量问题；
(2) 定制规格与订单不符。定制类商品不支持无理由退货。
退货流程需在收货后15个工作日内发起……
[2] 《定制商品管理办法》第3章-退换货规则（更新: 2024-01）
相关性: 0.85 | 权限: 全员可见
内容摘要: |
定制商品分为标准定制和完全定制两类。标准定制（如刻字）
可在7天内申请退货；完全定制（如按客户图纸生产）不支持
退货，仅支持质量问题换货……
[3] 《产品A售后政策》第2章-通用退货流程（更新: 2024-03）
相关性: 0.71 | 权限: 全员可见
内容摘要: |
所有退货申请需通过售后系统提交，审核周期3-5个工作日……
[4] 《2023年退货政策汇编》（更新: 2023-06）
相关性: 0.65 | 权限: 全员可见 | ⚠️ 可能过期（>6个月未更新）
内容摘要: |
旧版退货政策，其中定制商品退货条件与现行版本不同……
状态层:
用户部门: 市场部
权限级别: 普通员工
本次会话已查阅: 无（首次查询）
记忆层: （本次不激活）
- 成本与窗口控制
Token预算分配（总上限3000 tokens）:
- 系统提示: 120 tokens
- 目标层: 80 tokens
- 规则层: 150 tokens
- 知识层: 2000 tokens（Top4，含来源标注）
- 状态层: 100 tokens
- 记忆层: 0 tokens（本次不激活）
检索结果裁剪策略:
- 标准模式: Top3-5，每段摘要≤300 tokens
- 精确模式（问题较复杂）: Top5-8，每段摘要≤500 tokens
- 简洁模式（简单问题）: Top2，每段摘要≤200 tokens
- 模式选择: 根据问题分类和置信度自动判断
成本控制:
- 检索阶段: ~$0.002（向量检索 + 重排序）
- 生成阶段: ~$0.015（上下文较长）
- 总单次成本: ~$0.017
- 响应时间: ~2.5s（含检索1s + 生成1.5s）
- 失败检测规则
检测项:
- 检索结果为空: 没有检索到相关文档 → 不进入生成阶段
- 检索质量低: Top1相关性<0.5 → 提示"未找到高度匹配的资料"
- 信息冲突: 多个检索结果对同一问题给出不同答案 → 触发冲突标注
- 时效风险: 引用的文档>6个月未更新 → 在回答中标注时效提醒
- 权限泄露: 检索结果包含用户无权文档 → 移除并记录异常
- 幻觉检测: 生成的回答中出现检索文档里没有的信息 → 触发重新生成
自动纠偏:
- 检索为空 → 扩大检索范围（降低阈值 / 增加TopK），若仍为空则返回"未找到"
- 信息冲突 → 优先采用更新日期更近的文档，并在回答中标注差异
- 幻觉检测 → 在规则层强化"只基于提供的资料回答"，重新生成
- 检索质量持续低 → 记录问题，触发知识库更新提醒
输出结果：
上下文层次定义:
目标层:
内容: [用户原始问题, 问题分类, 置信度评估, 是否需要精确引用]
来源: 实时分析
优先级: 最高
规则层:
内容: [回答约束, 来源标注要求, 时效提醒规则, 幻觉防护规则]
来源: 固定规则 + 按问题类型动态加载
优先级: 高
知识层:
内容: [RAG检索结果, 重排序后的TopK文档片段, 来源元数据]
来源: 混合检索（语义+关键词）→ cross-encoder重排序 → 权限过滤
优先级: 最高（本场景核心）
更新: 每次查询实时检索
状态层:
内容: [用户部门, 权限级别, 已查阅文档, 会话历史]
来源: 用户系统 + 会话管理
优先级: 高
生命周期: 当前会话
记忆层:
内容: [用户常查领域, 历史满意度, 反馈记录]
来源: 长期记忆
优先级: 低
动态拼装策略:
高置信精确问题（如"产品A退货流程"）:
包含: 目标层 + 规则层 + 知识层(Top3, 精确摘要) + 状态层
知识层处理: 每段标注文档名、章节、更新日期
平均长度: ~1500 tokens
低置信模糊问题（如"公司的规定是什么"）:
包含: 目标层 + 规则层(强化) + 知识层(Top5, 宽泛摘要) + 状态层
知识层处理: 额外标注每段与问题的相关性说明
平均长度: ~2000 tokens
涉及时效的问题（如"最新政策"）:
包含: 全部层（含记忆层用于判断用户历史偏好）
额外规则: 移除>3个月未更新的文档，标注文档时效
平均长度: ~2500 tokens
质量保证:
- Token预算: 最大3000 tokens，知识层超预算时裁剪低相关性结果
- 检索质量评估: Top1相关性<0.5时降级为"建议性回答"
- 幻觉防护: 生成后对比回答与检索内容，移除未被支撑的声明
- 时效管理: 文档>6个月自动标注提醒，>12个月触发知识库更新告警
- 权限校验: 每次检索结果经权限过滤后才进入上下文
