名称: 上下文工程顾问 描述: 诊断上下文填充与上下文工程。评估实践、定义边界，并就内存架构、检索和研究→计划→重置→实施周期提供建议。 类型: 交互式
目的
指导产品经理诊断他们是在进行上下文填充（无意图地堆砌体积）还是上下文工程（为注意力塑造结构）。使用此技能来识别上下文边界、修复“上下文囤积障碍”，并实施战术实践，如有限域、情景检索和研究→计划→重置→实施周期。
关键区别: 上下文填充假设体积等于质量（“粘贴整个PRD”）。上下文工程将AI注意力视为稀缺资源并有意识地分配它。
这不是关于提示编写——它是关于设计信息架构，使AI基于现实而不被噪音淹没。
关键概念
范式转变: 参数化 → 上下文智能
根本问题:
- LLM具有参数化知识（训练期间编码）= 静态、过时、不可归因
- 当被问及专有数据、实时信息或用户偏好时 → 被迫产生幻觉或承认无知
- 上下文工程弥补静态训练和动态现实之间的差距
PM的角色转变: 从功能构建者 → 信息生态系统的架构师，使AI基于现实
上下文填充 vs. 上下文工程
| 维度 | 上下文填充 | 上下文工程 |
|---|---|---|
| 心态 | 体积 = 质量 | 结构 = 质量 |
| 方法 | “以防万一添加所有内容” | “我在做什么决策？” |
| 持久性 | 持久化所有上下文 | 有意图地检索 |
| 代理链 | 在代理之间共享所有内容 | 每个代理有界上下文 |
| 失败响应 | 重试直到工作 | 修复结构 |
| 经济模型 | 上下文作为存储 | 上下文作为注意力（稀缺资源） |
关键隐喻: 上下文填充就像把整个文件柜带到会议上。上下文工程只带来与今天决策相关的3份文档。
反模式: 上下文填充
上下文填充的五个标志:
- 反射性地扩展上下文窗口 — “就加更多令牌！”
- 持久化所有内容“以防万一” — 无明确保留标准
- 无边界地链接代理 — 代理A将所有内容传递给代理B再到代理C
- 添加评估来掩盖不一致性 — “我们重试直到正确”
- 正常化重试 — “运行3次才工作”变得可接受
为什么失败:
- 推理噪音: 数千个不相关文件竞争注意力，降低多跳逻辑
- 上下文腐化: 死胡同、过去错误、不相关数据积累 → 目标漂移
- 中间丢失: 模型优先处理开头（首因效应）和结尾（近因效应），忽略中间
- 经济浪费: 每次查询变得昂贵而无准确性提升
- 量化退化: 当上下文超过约32k令牌时，准确性降至20%以下
隐藏成本:
- 升级的令牌消耗
- 跨不相关材料的注意力稀释
- 输出置信度降低
- 级联重试浪费时间和金钱
真正的上下文工程: 核心原则
五个基本原则:
- 没有形状的上下文变成噪音
- 结构 > 体积
- 有意图地检索，而非完整性
- 小工作上下文（如短期记忆）
- 上下文压缩: 最大化每个令牌的相关信息密度
量化框架:
效率 = (准确性 × 连贯性) / (令牌 × 延迟)
关键发现: 使用RAG，仅用可用令牌的25%可保持95%准确性，同时显著降低延迟和成本。
5个诊断问题（检测上下文囤积障碍）
使用这些问题来识别上下文填充:
- 这支持什么具体决策？ — 如果无法回答，就不需要它
- 检索能替代持久化吗？ — 及时性胜过始终可用
- 谁拥有上下文边界？ — 如果无人拥有，它将永远增长
- 如果排除这个，什么会失败？ — 如果什么都不中断，删除它
- 我们是在修复结构还是避免它？ — 填充上下文常掩盖糟糕的信息架构
内存架构: 两层系统
短期（对话）内存:
- 即时交互历史用于后续问题
- 挑战: 空间管理 → 旧部分总结或截断
- 寿命: 单次会话
长期（持久）内存:
- 用户偏好、跨会话的关键事实 → 深度个性化
- 通过向量数据库实现（语义检索）
- 两种类型:
- 声明性内存: 事实（“我是素食者”）
- 程序性内存: 行为模式（“我通过先检查日志来调试”）
- 寿命: 跨会话持久
LLM驱动的ETL: 模型通过识别信号、与现有数据整合、自动更新数据库来生成自己的记忆。
研究 → 计划 → 重置 → 实施周期
上下文腐化解决方案:
- 研究: 代理收集数据 → 大而混乱的上下文窗口（噪音 + 死胡同）
- 计划: 代理合成为高密度SPEC.md或PLAN.md（真相源）
- 重置: 清除整个上下文窗口（防止上下文腐化）
- 实施: 新会话，仅使用高密度计划作为上下文
为什么有效: 上下文腐化被消除；代理以压缩、高信号上下文开始清洁。
反模式（这NOT是什么）
- 不是关于选择AI工具 — Claude vs. ChatGPT不重要；架构重要
- 不是关于编写更好的提示 — 这是系统设计，非文案撰写
- 不是关于添加更多令牌 — “无限上下文”叙事是营销，非工程现实
- 不是关于取代人类判断 — 上下文工程放大判断，不消除它
何时使用此技能
✅ 当以下情况时使用:
- 将整个PRD/代码库粘贴到AI并得到模糊响应时
- AI输出不一致（“有时工作，有时不”）
- 令牌消耗增加而无准确性提升
- 怀疑在“上下文填充”但不知如何修复时
- 需要为AI产品功能设计上下文架构时
❌ 当以下情况时不使用:
- 刚开始使用AI（先使用基本提示）
- 寻找工具推荐时（这是关于架构，非工具）
- AI使用良好时（如果没坏，别修）
促进真相源
使用workshop-facilitation作为此技能的默认交互协议。
它定义:
- 会话提醒 + 入口模式（指导式、上下文转储、最佳猜测）
- 单一问题轮次，使用简单语言提示
- 进度标签（例如，上下文Qx/8和评分Qx/5）
- 中断处理和暂停/恢复行为
- 决策点的编号推荐
- 常规问题的快速选择编号响应选项（当有用时包含
其他（指定））
此文件定义领域特定评估内容。如果有冲突，遵循此文件的领域逻辑。
应用
此交互式技能使用自适应提问来诊断上下文填充、识别边界并提供战术实施指导。
步骤0: 收集上下文
代理询问:
在我们诊断您的上下文实践之前，先收集信息:
当前AI使用:
- 使用什么AI工具/系统？（ChatGPT、Claude、自定义代理等）
- 为哪些PM任务使用AI？（PRD编写、用户研究合成、发现等）
- 如何提供上下文？（粘贴文档、引用文件、使用项目/内存）
症状:
- AI输出不一致吗？（有时工作，有时不）
- 重试提示多次以获取好结果吗？
- 尽管提供“所有上下文”，响应模糊或模棱两可吗？
- 令牌成本增加而无准确性提升吗？
系统架构（如果适用）:
- 有自定义AI代理或工作流吗？
- 代理之间如何共享上下文？
- 使用RAG、向量数据库或内存系统吗？
您可以简要描述或粘贴示例。
步骤1: 诊断上下文填充症状
代理询问:
让我们评估您是否正在经历上下文填充。识别哪些症状？
选择所有适用:
- “我将整个文档粘贴到AI” — 完整PRD、完整用户访谈转录、整个代码库
- “AI给出模糊、模棱两可的响应，尽管有‘所有上下文’” — 响应如“取决于”、“考虑这些选项”，非承诺性
- “我必须重试提示3次以上以获取可用输出” — 不一致性正常化
- “令牌成本增加但准确性未提升” — 花费更多，得到相同或更糟结果
- “我继续添加更多上下文希望有帮助” — 无策略的反射性扩展
- “我的代理将所有内容传递给彼此” — 代理A → 代理B → 代理C，完整上下文链
- “我没有明确标准来决定包括/排除什么” — 无上下文边界定义
- “无这些—我的AI使用良好” — 跳至高级优化
用户响应: [选择症状]
代理分析:
基于您的选择:
- 0-1症状: 健康的上下文实践；继续优化
- 2-3症状: 早期上下文填充；在扩大前解决
- 4+症状: 活跃的上下文囤积障碍；需要立即干预
代理继续诊断问题。
步骤2: 诊断问题1 — 这支持什么具体决策？
代理询问:
从最关键问题开始：对于每个包含的上下文片段，它支持什么具体决策？
示例上下文分析:
想象您要求AI“帮助发现规划”。您提供:
- 整个PRD（20页）
- 50个用户访谈转录（完整）
- 竞争分析文档（15页）
- 过去3个月的团队会议笔记
问题: 您正在做什么决策？
提供3个场景:
-
“我正在决定先采访哪个用户细分”
- 所需上下文: PRD中的用户细分（2段）、先前访谈主题（1页合成），非完整转录
- 不需要上下文: 会议笔记、完整竞争分析、完整PRD
-
“我正在决定在访谈中询问哪些发现问题”
- 所需上下文: 研究目标（来自PRD）、过去访谈洞察（合成）、Jobs-to-be-Done框架
- 不需要上下文: 完整竞争分析、完整会议笔记
-
“我不确定在做什么决策—我只是想让AI‘理解我的产品’”
- 问题: 无具体决策 = 上下文填充陷阱
- 修复: 先定义决策，然后选择上下文
代理推荐:
最佳实践: 在添加上下文前，完成此句子:
“我需要此上下文，因为我在决定[具体决策]，而没有[具体信息]，我无法做出该决策。”
如果无法完成此句子，就不需要上下文。
用户响应: [描述决策 + 上下文]
代理验证: 上下文是否直接支持所述决策？如果不是，推荐修剪。
步骤3: 诊断问题2 — 检索能替代持久化吗？
代理询问:
第二个问题：这些信息是您始终需要的，还是可以及时检索的？
区别:
始终需要（持久化）:
- 核心产品约束（技术、监管、战略）
- 适用于每次交互的用户偏好
- 关键定义（操作词汇表）
- 不可协商规则
情景（按需检索）:
- 项目特定细节（此史诗、此冲刺）
- 历史数据（过去PRD、旧访谈转录）
- 上下文事实（竞争分析、市场研究）
- 临时决策
关键洞察: 及时检索胜过始终可用。不要持久化可以检索的内容。
提供3个选项:
-
“我的大部分上下文是始终需要的（核心约束、用户偏好）”
- 评估: 好直觉；用问题4验证（排除什么会失败？）
- 推荐: 构建约束注册表和操作词汇表（持久化这些）
-
“我的大部分上下文是情景的（项目细节、历史数据）”
- 评估: RAG或检索的完美候选
- 推荐: 实施语义搜索；为每个查询仅检索相关块
-
“我不确定哪个是哪个—我持久化所有内容以求安全”
- 评估: 典型上下文囤积障碍症状
- 修复: 对每个上下文片段应用问题4测试
代理推荐:
经验法则:
- 持久化: 在80%+交互中引用的信息
- 检索: 在<20%交互中引用的信息
- 灰色区域（20-80%）: 取决于检索延迟 vs. 上下文窗口成本
用户响应: [分类其上下文]
代理提供: 关于持久化 vs. 检索的具体推荐。
步骤4: 诊断问题3 — 谁拥有上下文边界？
代理询问:
第三个问题：谁负责定义什么属于或不属于您的AI上下文？
所有权问题:
如果无人拥有上下文边界，它将无限增长。每个PM将添加“只是一点”，六个月后，每次查询填充100k令牌。
提供3个选项:
-
“我拥有边界（单独PM或小团队）”
- 评估: 好—可快速决策
- 推荐: 记录边界标准（使用问题1-5作为框架）
-
“我的团队共享所有权（协作边界定义）”
- 评估: 如果正式化可工作
- 推荐: 创建“上下文宣言”文档：始终包括什么、检索什么、排除什么（及原因）
-
“无人拥有—它是临时/隐式的”
- 评估: 关键风险；边界将无法控制扩展
- 修复: 分配明确所有权；安排季度上下文审计
代理推荐:
最佳实践: 创建上下文宣言
# 上下文宣言: [产品/功能名称]
## 始终持久化（核心上下文）
- 产品约束（技术、监管）
- 用户偏好（角色、权限、偏好）
- 操作词汇表（20个关键术语）
## 按需检索（情景上下文）
- 历史PRD（通过语义检索）
- 用户访谈转录（检索相关引用）
- 竞争分析（明确需要时检索）
## 排除（超出范围）
- 超过30天的会议笔记（不再相关）
- 完整代码库（使用代码搜索代替）
- 营销材料（非决策相关）
## 边界所有者: [姓名]
## 最后审查: [日期]
## 下次审查: [日期 + 90天]
用户响应: [描述当前所有权模型]
代理提供: 关于正式化所有权的推荐 + 上下文宣言模板。
步骤5: 诊断问题4 — 如果排除这个，什么会失败？
代理询问:
第四个问题：对于每个上下文片段，如果排除它，会发生什么具体故障模式？
这是证伪测试。如果无法识别具体故障，就不需要上下文。
提供3个场景:
-
“如果我排除产品约束，AI将推荐不可行解决方案”
- 故障模式: 清晰具体
- 评估: 持久化约束的有效理由
-
“如果我排除历史PRD，AI不会理解我们产品演变”
- 故障模式: 模糊假设
- 评估: 当前决策很少需要历史上下文
- 修复: 仅在明确引用过去决策时检索PRD
-
“如果我排除这个，不确定任何东西会中断—我包括它以求彻底”
- 故障模式: 无识别
- 评估: 上下文填充；立即删除
代理推荐:
证伪协议:
对于每个上下文元素，完成此陈述:
“如果我排除[上下文元素]，那么[具体故障]将在[具体场景]中发生。”
示例:
- ✅ 好: “如果我排除GDPR约束，AI将推荐违反欧盟隐私法的功能。”
- ❌ 坏: “如果我排除此PRD，AI可能不完全理解产品。”（模糊）
用户响应: [对其上下文应用证伪测试]
代理提供: 要删除的上下文元素列表（无具体故障识别）。
步骤6: 诊断问题5 — 我们在修复结构还是避免它？
代理询问:
第五个问题：添加更多上下文是在解决问题，还是掩盖更深层的结构问题？
根本原因问题:
上下文填充常掩盖糟糕的信息架构。团队不修复混乱、模糊的文档，而是添加更多文档希望AI“解决”。
提供3个选项:
-
“我添加上下文因为我们的文档结构差/模糊”
- 评估: 您在掩盖结构问题
- 修复: 先清理文档（移除模糊性、添加约束、定义术语）
- 示例: 而不是粘贴5个冲突PRD，将它们调和为1个真相源
-
“我添加上下文因为我们没有共享操作词汇表”
- 评估: 您在补偿缺失基础
- 修复: 构建词汇表（20-30个关键术语）；AI可可靠引用
- 示例: 明确定义“活跃用户”、“流失”、“参与度”
-
“我添加上下文因为我们的约束未文档化”
- 评估: 您在避免约束工程
- 修复: 创建约束注册表（技术、监管、战略）
- 示例: 文档化“我们不会构建移动应用” vs. 在每个提示中解释
代理推荐:
结构健康测试:
如果您添加上下文来补偿:
- 模糊文档 → 修复文档，不要添加更多
- 未定义术语 → 构建操作词汇表
- 未文档化约束 → 创建约束注册表
- 冲突信息 → 调和为真相源
用户响应: [识别结构问题]
代理提供: 优先结构修复列表，然后再添加更多上下文。
步骤7: 定义内存架构
代理询问:
基于您的上下文需求，让我们设计两层内存架构。
您的上下文配置文件（从先前步骤）:
- 始终需要的上下文: [从Q2总结]
- 情景上下文: [从Q2总结]
- 边界所有者: [从Q3]
- 验证必需品: [从Q4]
- 结构修复需要: [从Q5]
推荐架构:
短期（对话）内存:
- 存储什么: 即时交互历史用于后续问题
- 寿命: 单次会话
- 管理: 总结或截断旧部分以避免拥挤
- 您的特定需求: [代理基于用户工作流定制]
长期（持久）内存:
- 存储什么: 用户偏好、核心约束、操作词汇表
- 寿命: 跨会话持久
- 实现: 向量数据库（语义检索）
- 两种类型:
- 声明性内存: 事实（例如，“我们遵循HIPAA规定”）
- 程序性内存: 行为模式（例如，“总是在可用性前验证可行性”）
- 您的特定需求: [代理定制]
检索策略（情景上下文）:
- 检索什么: 历史PRD、用户访谈、竞争分析
- 方法: 语义搜索，由查询意图触发
- 优化: 上下文检索（Anthropic）— 在嵌入前为每个块添加解释性上下文
- 您的特定需求: [代理定制]
代理提供:
您希望我:
- 生成上下文架构蓝图 针对您的特定用例？
- 提供实现指导（工具、技术、最佳实践）？
- 设计检索策略 针对您的情景上下文？
用户响应: [选择]
步骤8: 实施研究 → 计划 → 重置 → 实施周期
代理询问:
现在实施研究 → 计划 → 重置 → 实施周期以防止上下文腐化。
问题: 当代理研究时，上下文窗口变得混乱—充满死胡同、错误和噪音。这稀释注意力并导致目标漂移。
解决方案: 将研究压缩为高密度计划，然后在实施前清除上下文窗口。
四阶段周期:
阶段1: 研究（允许混乱上下文）
- 代理从多个源收集数据
- 上下文窗口变大混乱（这是预期的）
- 死胡同、失败假设和噪音积累
- 目标: 全面信息收集
阶段2: 计划（合成）
- 代理将研究合成为高密度SPEC.md或PLAN.md
- 这成为实施的真相源
- 关键元素:
- 做出的决策
- 支持决策的证据
- 应用的约束
- 后续步骤（排序）
- 格式: 结构化、简洁、明确
阶段3: 重置（清除上下文窗口）
- 关键步骤: 清除整个上下文窗口
- 删除所有研究工件、死胡同、错误
- 这防止上下文腐化毒害实施
阶段4: 实施（仅用计划的新会话）
- 以仅高密度计划作为上下文开始新会话
- 代理具有清洁、专注的执行注意力
- 无研究阶段噪音
代理提供3个选项:
-
“我想要PLAN.md格式模板”
- 代理提供高密度计划的结构化模板
-
“我想看此周期在行动中的示例”
- 代理逐步讲解具体PM用例（例如，发现规划）
-
“我准备好将此实施到工作流中”
- 代理提供逐步实施指南
用户响应: [选择]
代理提供: 基于选择的定制指导。
步骤9: 行动计划与后续步骤
代理合成:
基于您的上下文工程评估，这是您的行动计划:
立即修复（本周内）:
- [删除从Q4无证伪故障模式的上下文]
- [将研究→计划→重置→实施应用于您的下一个AI任务]
- [在上下文宣言中记录上下文边界]
基础构建（下2周内）:
- [构建约束注册表，20+条目]
- [创建操作词汇表，20-30个关键术语]
- [实施两层内存架构]
长期优化（下月内）:
- [为情景上下文设置语义检索]
- [分配上下文边界所有者 + 季度审计计划]
- [为RAG实施上下文检索（Anthropic）]
成功指标:
- 令牌使用减少50%+（减少上下文填充）
- 输出一致性提升（减少重试/再生）
- 响应质量提升（更尖锐、少模棱两可答案）
- 上下文窗口稳定（无无界增长）
代理提供:
您希望我:
- 生成具体实现文档（上下文宣言、PLAN.md模板等）？
- 提供高级技术（上下文检索、LLM驱动的ETL）？
- 审查您当前上下文设置（提供特定提示/工作流反馈）？
示例
示例1: 单独PM上下文填充 → 工程
上下文:
- 早期创业公司的单独PM
- 使用Claude Projects进行PRD编写
- 每次粘贴整个PRD（20页）+ 所有用户访谈（50转录）
- 得到模糊、不一致响应
评估:
- 症状: 模棱两可响应、正常化重试（4+症状）
- Q1（决策）: “我只是想让AI理解我的产品”（无具体决策）
- Q2（持久化/检索）: 持久化所有内容（无检索策略）
- Q3（所有权）: 无正式所有者（单独PM，临时）
- Q4（故障）: 对大部分上下文无法识别具体故障
- Q5（结构）: 避免约束文档化
诊断: 活跃的上下文囤积障碍
干预:
- 立即: 删除所有Q4测试失败的上下文 → 保留原始的20%
- 第1周: 构建约束注册表（10个技术约束、5个战略）
- 第2周: 创建操作词汇表（25个术语）
- 第3周: 为下一个PRD实施研究→计划→重置→实施
结果: 令牌使用减少70%，输出质量显著提升，响应清晰可行动。
示例2: 增长阶段团队带代理链
上下文:
- 5个PM的产品团队
- 自定义AI代理用于发现合成
- 代理A（研究） → 代理B（合成） → 代理C（推荐）
- 每个代理将完整上下文传递给下一个 → 上下文窗口爆炸至100k+令牌
评估:
- 症状: 升级的令牌成本、不一致输出（3症状）
- Q1（决策）: 每个代理有清晰决策，但传递不必要上下文
- Q2（持久化/检索）: 混合持久化和情景无策略
- Q3（所有权）: 无明确所有者；每个PM添加上下文
- Q4（故障）: 代理传递“以防万一”上下文，无证伪故障
- Q5（结构）: 缺失上下文宣言
诊断: 无边界的代理编排
干预:
- 立即: 定义每个代理的有界上下文（代理A仅输出2页合成给代理B，非完整研究）
- 第1周: 分配上下文边界所有者（首席PM）
- 第2周: 创建上下文宣言（什么持久化、检索、排除）
- 第3周: 在代理B和代理C之间实施研究→计划→重置→实施
结果: 令牌使用减少60%，代理链可靠性提升，成本减少50%。
示例3: 企业带RAG但无上下文工程
上下文:
- 大型企业带向量数据库RAG系统
- “填充整个知识库”方法（10,000+文档）
- 检索返回50+块/查询 → 淹没上下文窗口
- 准确性随知识库增长下降
评估:
- 症状: 尽管有“完整知识”，响应模糊、正常化重试（2症状）
- Q1（决策）: 决策清晰，但检索无意图（返回所有内容）
- Q2（持久化/检索）: 好直觉检索，但无过滤
- Q3（所有权）: 工程拥有RAG，产品不拥有上下文边界
- Q4（故障）: 无法识别为什么需要50块 vs. 5
- Q5（结构）: 知识库无结构（扁平文档，无元数据）
诊断: 无意图的检索（RAG作为上下文填充）
干预:
- 立即: 限制检索为每个查询前5块（从50降低）
- 第1周: 实施上下文检索（Anthropic）— 在索引期间为每个块添加解释性上下文
- 第2周: 添加文档元数据（类别、近期性、权威性）
- 第3周: 产品团队按查询类型定义检索意图（发现 = 客户洞察，可行性 = 技术约束）
结果: 准确性提升35%（来自Anthropic基准），延迟减少60%，令牌使用减少80%。
常见陷阱
1. “无限上下文”营销 vs. 工程现实
故障模式: 相信“1百万令牌上下文窗口”意味着应使用所有它们。
后果: 推理噪音降低性能；准确性降至20%以下超过约32k令牌。
修复: 上下文窗口不是免费的。将令牌视为稀缺；优化密度，非体积。
2. 重试而非重构
故障模式: “如果运行3次才工作” → 正常化重试而非修复结构。
后果: 浪费时间和金钱；掩盖更深层上下文腐化问题。
修复: 如果重试常见，您的上下文结构已坏。应用Q5（修复结构，不添加体积）。
3. 无上下文边界所有者
故障模式: 临时、隐式的上下文决策 → 无界增长。
后果: 六个月后，每次查询填充100k令牌/交互。
修复: 分配明确所有权；创建上下文宣言；安排季度审计。
4. 混合始终需要与情景
故障模式: 持久化应检索的历史数据。
后果: 上下文窗口拥挤不相关信息；注意力稀释。
修复: 应用Q2测试：持久化仅80%+交互中需要的内容；检索其余。
5. 跳过重置阶段
故障模式: 在研究→计划→实施周期中从不清除上下文窗口。
后果: 上下文腐化积累；目标漂移；死胡同毒害实施。
修复: 计划后的强制重置阶段；仅用高密度计划作为上下文开始实施。
参考
相关技能
- ai-shaped-readiness-advisor（交互式）— 上下文设计是AI形工作的能力#1
- problem-statement（组件）— 基于证据的框架需要上下文工程
- epic-hypothesis（组件）— 可测试假设依赖于清晰约束（上下文部分）
- pol-probe-advisor（交互式）— 验证实验受益于上下文工程（定义AI需要知道什么）
外部框架
- Dean Peters — Context Stuffing Is Not Context Engineering（Dean Peters’ Substack, 2026）
- Teresa Torres — Continuous Discovery Habits（上下文工程作为5个新AI PM学科之一）
- Marty Cagan — Empowered（AI时代的可行性风险包括理解“AI物理”）
- Anthropic — Contextual Retrieval whitepaper（故障率减少35%）
- Google — 上下文工程白皮书关于LLM驱动的内存系统
技术参考
- RAG（检索增强生成） — 情景上下文检索的标准技术
- 向量数据库 — 长期内存的语义搜索（Pinecone、Weaviate、Chroma）
- 上下文检索（Anthropic） — 在嵌入前为每个块添加解释性上下文
- LLM-as-Judge — 上下文质量的自动化评估