Ai native context engineering

Skill gmaxxxie/ai-native-product-agent-skills/skills/ai-native-context-engineering

AI Native Product Methodology — 80 executable skills across P0-P14 stages, covering needs discovery to aesthetic authority. From 8 books.

Install

npx -y skills add gmaxxxie/ai-native-product-agent-skills --skill ai-native-context-engineering

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.

What its author says it does

Copied from the file, not written here

AI Native 产品方法论——上下文工程的实操 Skill。用户提供任务场景，Skill 自动执行上下文组织流程：任务目标识别 → 上下文层选择 → 动态拼装 → 成本与窗口控制 → 结果校验与纠偏 → 输出上下文工程方案。基于《AI Native 产品方法论》第14章。

SKILL.md

24.7 KB, as published. Nobody here has run it

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超限 → 只保留最核心的规则和知识

输出结果：

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

上下文层次定义:
  
  目标层:
    内容: [用户原始问题, 意图识别结果, 情绪分析, 咨询类型]
    来源: 实时分析
    优先级: 最高
    
  规则层:
    内容: [业务规则, 权限边界, 禁用操作, 语气要求]
    来源: 规则引擎（按咨询类型加载）
    优先级: 高
    
  知识层:
    内容: [检索到的相关资料, 案例, 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检索结果（分优先级排列）	✅	核心知识来源
状态层	用户所属部门、权限级别、已查阅文档	✅	权限过滤 + 去重
记忆层	用户常查领域、历史满意度反馈	⚠️ 可选	用于个性化排序

动态拼装示例

# 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检索上下文组装

上下文层次定义:
  目标层:
    内容: [用户原始问题, 问题分类, 置信度评估, 是否需要精确引用]
    来源: 实时分析
    优先级: 最高

  规则层:
    内容: [回答约束, 来源标注要求, 时效提醒规则, 幻觉防护规则]
    来源: 固定规则 + 按问题类型动态加载
    优先级: 高

  知识层:
    内容: [RAG检索结果, 重排序后的TopK文档片段, 来源元数据]
    来源: 混合检索（语义+关键词）→ cross-encoder重排序 → 权限过滤
    优先级: 最高（本场景核心）
    更新: 每次查询实时检索

  状态层:
    内容: [用户部门, 权限级别, 已查阅文档, 会话历史]
    来源: 用户系统 + 会话管理
    优先级: 高
    生命周期: 当前会话

  记忆层:
    内容: [用户常查领域, 历史满意度, 反馈记录]
    来源: 长期记忆
    优先级: 低

动态拼装策略:
  高置信精确问题（如"产品A退货流程"）:
    包含: 目标层 + 规则层 + 知识层(Top3, 精确摘要) + 状态层
    知识层处理: 每段标注文档名、章节、更新日期
    平均长度: ~1500 tokens

  低置信模糊问题（如"公司的规定是什么"）:
    包含: 目标层 + 规则层(强化) + 知识层(Top5, 宽泛摘要) + 状态层
    知识层处理: 额外标注每段与问题的相关性说明
    平均长度: ~2000 tokens

  涉及时效的问题（如"最新政策"）:
    包含: 全部层（含记忆层用于判断用户历史偏好）
    额外规则: 移除>3个月未更新的文档，标注文档时效
    平均长度: ~2500 tokens

质量保证:
  - Token预算: 最大3000 tokens，知识层超预算时裁剪低相关性结果
  - 检索质量评估: Top1相关性<0.5时降级为"建议性回答"
  - 幻觉防护: 生成后对比回答与检索内容，移除未被支撑的声明
  - 时效管理: 文档>6个月自动标注提醒，>12个月触发知识库更新告警
  - 权限校验: 每次检索结果经权限过滤后才进入上下文

One thing to look at

What its author says it does

SKILL.md

AI Native 上下文工程 Skill

使用场景

触发条件

执行步骤

核心概念

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

上下文工程流程

上下文的五个层次

1. 目标层

2. 规则层

3. 知识层

4. 状态层

5. 记忆层

上下文工程的四个目标

动态拼装原则

常见失败模式

上下文太少

上下文太多

层次混乱

时效失效

输出物：上下文工程方案

使用方式

示例

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

示例：多轮对话上下文管理

示例：RAG 检索上下文组装

Keep looking