context-engineering-advisor

目的

引导产品经理诊断自己是在进行上下文堆砌（不考虑意图，只一味塞入大量内容），还是在进行上下文工程（为注意力塑造结构）。借此识别上下文边界，解决“上下文囤积障碍”，并落实有界领域、情景式检索以及 Research→Plan→Reset→Implement 循环等战术实践。

关键区别： 上下文堆砌认为数量 = 质量（“把整份 PRD 都贴进去”）。上下文工程则将 AI 的注意力视为稀缺资源，并有意识地进行分配。

这不是关于编写提示词，而是关于设计信息架构，让 AI 立足现实，同时避免被噪声淹没。

输入

最适用的情况： 描述一个让你觉得臃肿、脆弱或难以引导的 AI 工作流、Agent 或提示词设置。 同样有帮助的信息： 你已经塞进上下文的内容（文档、转录文本、架构），以及输出出错的地方。

随调用本身提供的任何内容——技能名称后的文本、粘贴的上下文转储，或附加的 ARGUMENTS: 行——都视为已经提供的答案。请使用这些内容，并跳过其中已涵盖的问题；不要重复询问。

空手而来也没关系。 顾问会先询问你目前给模型输入什么，以及哪些地方会出问题。

调用示例： 诊断我的设置：我们的支持工单分流 Agent 会为每个工单提供完整的 40 页政策手册，但仍会错误分流边缘情况。

关键概念

范式转变：从参数智能到上下文智能

根本问题：

• 大模型拥有参数知识（在训练期间编码）= 静态、过时、无法追溯来源
• 当被问及专有数据、实时信息或用户偏好时 → 只能被迫产生幻觉或承认不知道
• 上下文工程弥合了静态训练与动态现实之间的鸿沟

产品经理角色的转变： 从功能构建者 → 信息生态系统的架构师，让 AI 立足现实

---

上下文堆砌与上下文工程

维度	上下文堆砌	上下文工程
思维方式	数量 = 质量	结构 = 质量
方法	“把所有内容都加上，以防万一”	“我要做出什么决策？”
持久化	持久化所有上下文	有意图地检索
Agent 链	在 Agent 之间共享所有内容	为每个 Agent 设定有界上下文
失败后的应对	不断重试，直到成功	修正结构
经济模型	将上下文视为存储	将上下文视为注意力（稀缺资源）

关键比喻： 上下文堆砌就像把整个文件柜都搬到会议上。上下文工程则是只带上与今天的决策相关的 3 份文件。

---

反模式：上下文堆砌

上下文堆砌的五种表现：

1. 条件反射般地扩大上下文窗口——“再加点 token 就行！”
2. “以防万一”地持久化所有内容——没有明确的保留标准
3. 不设边界地串联 Agent——Agent A 把所有内容传给 Agent B，再传给 Agent C
4. 用增加评估来掩盖不一致——“我们一直重试到正确为止”
5. 把重试常态化——“运行 3 次就能成功”成了可接受的做法

失败原因：

• 推理噪声： 数千个无关文件争夺注意力，削弱多跳推理能力
• 上下文腐化： 死胡同、过去的错误、无关数据不断累积 → 目标漂移
• 迷失在中间： 模型优先关注开头（首因效应）和结尾（近因效应），忽略中间部分
• 经济浪费： 每次查询都会变得昂贵，却没有精度提升
• 定量退化： 当上下文超过约 32k 个 token 时，准确率会降至 20% 以下

隐藏成本：

• token 消耗不断攀升
• 注意力被无关材料分散
• 输出可信度降低
• 连锁重试浪费时间和金钱

---

真正的上下文工程：核心原则

五项基本原则：

1. 没有形状的上下文会变成噪声
2. 结构 > 体量
3. 有目的地检索，而非追求完整
4. 小型工作上下文（如短期记忆）
5. **上下文压缩：**最大化每个 token 中相关信息的密度

量化框架：

Efficiency = (Accuracy × Coherence) / (Tokens × Latency)

**关键发现：**使用 RAG 和 25% 的可用 token，可以保留 95% 的准确率，同时显著降低延迟和成本。

---

5 个诊断问题（检测上下文囤积症）

通过以下问题识别上下文填塞：

1. 这能支持什么具体决策？——如果回答不上来，就不需要它
2. 检索能否取代持久存储？——按需获取胜过随时可用
3. 谁负责划定上下文边界？——如果没有人负责，上下文就会无限增长
4. 排除这项内容会导致什么失败？——如果什么都不会出问题，就删掉它
5. 我们是在改善结构，还是在回避结构？——填塞上下文往往是在掩盖糟糕的信息架构

---

记忆架构：双层系统

短期（对话）记忆：

• 用于回答后续问题的即时交互历史
• 挑战：空间管理 → 较早的内容会被总结或截断
• 生命周期：单次会话

长期（持久）记忆：

• 跨会话保存用户偏好、关键信息 → 实现深度个性化
• 通过向量数据库实现（语义检索）
• 两种类型：
  • **陈述性记忆：**事实（“我是素食主义者”）
  • **程序性记忆：**行为模式（“我会先检查日志来调试”）
• 生命周期：跨会话持久保存

**由大模型驱动的 ETL：**模型通过识别信号、与现有数据整合并自动更新数据库，为自身生成记忆。

---

研究 → 规划 → 重置 → 实施循环

上下文腐化的解决方案：

1. **研究：**Agent 收集数据 → 产生庞大、混乱的上下文窗口（噪声 + 死胡同）
2. **规划：**Agent 将内容综合为高密度的 SPEC.md 或 PLAN.md（唯一事实来源）
3. **重置：**清空整个上下文窗口（防止上下文腐化）
4. **实施：**开启全新会话，仅以高密度计划作为上下文

**为什么有效：**上下文腐化得以消除；Agent 从干净的状态开始，使用经过压缩、信号密集的上下文。

---

反模式（这并不是什么）

• 不是为了选择 AI 工具——Claude 还是 ChatGPT 并不重要，架构才重要
• 不是为了写出更好的提示词——这是系统设计，不是文案写作
• 不是为了添加更多 token——“无限上下文”的说法是营销话术，不是工程现实
• 不是为了取代人类判断——上下文工程能增强判断力，而非消除它

---

何时使用此技能

✅ 适用于以下情况：

• 你把整个 PRD 或代码库粘贴给 AI，却只得到含糊的回答
• AI 的输出前后不一致（“有时有效，有时无效”）
• 你消耗了大量 token，却没有看到准确率提升
• 你怀疑自己在“填塞上下文”，但不知道如何解决
• 你需要为 AI 产品功能设计上下文架构

❌ 不适用于以下情况：

• 你刚开始接触 AI（先从基本提示词入手）
• 你在寻找工具推荐（这里讨论的是架构，而非工具选择）
• 你的 AI 使用效果良好（没坏就别修）

引导流程的事实依据

默认情况下，使用 workshop-facilitation 作为此技能的交互协议。

其中定义了：

• 会话预告和进入模式（引导式、上下文倾倒、最佳猜测）
• 每轮一个问题，并使用通俗易懂的提示词
• 进度标签（例如，上下文问题 Qx/8 和评分问题 Qx/5）
• 中断处理以及暂停／恢复行为
• 决策节点处的编号建议
• 常规问题使用编号快速选择选项（适用时包含 Other (specify)）

此文件定义了特定领域的评估内容。如有冲突，请遵循此文件的领域逻辑。

应用

此交互式技能使用自适应提问来诊断上下文堆砌、识别边界，并提供战术层面的实施指导。

---

步骤 0：收集上下文

Agent 提问：

在诊断你的上下文处理方式之前，我们先收集一些信息：

当前的 AI 使用情况：

• 你使用哪些 AI 工具／系统？（ChatGPT、Claude、自定义 Agent 等）
• 你会使用 AI 处理哪些产品经理（PM）任务？（编写 PRD、综合用户研究、探索等）
• 你如何提供上下文？（粘贴文档、引用文件、使用项目／记忆）

症状：

• AI 的输出是否不一致？（有时有效，有时无效）
• 你是否需要多次重试提示词才能获得满意结果？
• 即使提供了“所有上下文”，回答是否仍然含糊或有所保留？
• Token 成本是否不断上升，却没有提高准确性？

系统架构（如适用）：

• 你是否有自定义 AI Agent 或工作流？
• Agent 之间如何共享上下文？
• 你是否使用 RAG、向量数据库或记忆系统？

你可以简要描述，也可以粘贴示例。

---

步骤 1：诊断上下文堆砌症状

Agent 提问：

我们来评估你是否遇到了上下文堆砌。以下哪些症状符合你的情况？

选择所有符合项：

1. “我会把整份文档粘贴给 AI”——完整的 PRD、完整的用户访谈记录、整个代码库
2. “即使 AI 掌握了‘所有上下文’，回答仍然含糊、有所保留”——回答诸如“视情况而定”“可以考虑这些选项”，态度不明确
3. “我得重试提示词 3 次以上才能得到可用输出”——对结果不一致习以为常
4. “Token 成本不断上升，但准确性没有提高”——花费更多，结果却持平或更差
5. “我不断添加更多上下文，希望能有所帮助”——不加思索地扩充上下文，没有策略
6. “我的 Agent 会彼此传递所有内容”——Agent A → Agent B → Agent C，完整传递上下文链
7. “我没有明确的纳入／排除标准”——没有定义上下文边界
8. “以上都不是——我的 AI 使用效果很好”——跳转至高级优化

用户回答：[选择症状]

Agent 分析：

根据你的选择：

• **0-1 项症状：**上下文处理方式健康；继续进行优化
• **2-3 项症状：**初期的上下文堆砌；应在问题扩大前处理
• **4 项以上症状：**已出现上下文囤积障碍；需要立即干预

Agent 继续提出诊断问题。

---

步骤 2：诊断问题 1——这支持什么具体决策？

Agent 询问：

我们先从最关键的问题开始：你纳入的每一项上下文，具体支持什么决策？

上下文分析示例：

假设你要让 AI「协助制定探索计划」。你提供了：

• 完整的 PRD（20 页）
• 50 份用户访谈记录（全文）
• 竞争分析文档（15 页）
• 过去 3 个月的团队会议记录

问题： 你现在正在做什么决策？

提供 3 种情境：

1. 「我正在决定先访谈哪个用户细分群体」

   • 所需上下文： PRD 中的用户细分群体（2 个段落）、过往访谈主题（1 页摘要），而非完整访谈记录
   • 不需要的上下文： 会议记录、完整的竞争分析、完整的 PRD

2. 「我正在决定访谈中要问哪些探索问题」

   • 所需上下文： 研究目标（来自 PRD）、过往访谈洞见（摘要）、待办事项框架
   • 不需要的上下文： 完整的竞争分析、完整的会议记录

3. 「我不确定自己要做什么决策——我只是想让 AI『了解我的产品』」

   • 问题： 没有具体决策 = 陷入堆砌上下文的陷阱
   • 解决方法： 先明确决策，再选择上下文

Agent 建议：

最佳实践： 添加上下文前，先完成这个句子：

「我需要这些上下文，因为我正在决定［具体决策］；如果没有［具体信息］，我就无法做出这个决策。」

如果你无法完成这个句子，就不需要这些上下文。

用户回复：［描述其决策和上下文］

Agent 验证： 这些上下文是否直接支持所述决策？如果不是，建议删减。

---

步骤 3：诊断问题 2——检索能否取代持久化？

Agent 询问：

第二个问题：这是你始终需要的信息，还是可以按需即时检索的信息？

区别：

始终需要（持久化）：

• 核心产品约束（技术、监管、战略方面）
• 适用于每次交互的用户偏好
• 关键定义（操作术语表）
• 不容妥协的规则

阶段性信息（按需检索）：

• 项目特定细节（当前史诗、当前冲刺）
• 历史数据（过去的 PRD、旧的访谈记录）
• 情境性事实（竞争分析、市场研究）
• 临时决策

关键见解： 即时检索胜过始终可用。能够检索的信息就不要持久化。

提供 3 个选项：

1. 「我的大部分上下文都是始终需要的（核心约束、用户偏好）」

   • 评估： 这个判断不错；请通过问题 4（排除后会有什么问题？）进行验证
   • 建议： 建立约束登记表和操作术语表（将这些内容持久化）

2. 「我的大部分上下文都是阶段性信息（项目细节、历史数据）」

   • 评估： 非常适合使用 RAG 或检索
   • 建议： 实现语义搜索；针对每个查询，仅检索相关片段

3. 「我不确定该如何区分——为了保险起见，我把所有内容都持久化」

   • 评估： 这是典型的上下文囤积症状
   • 解决方法： 对每项上下文应用问题 4 的测试

Agent 建议：

经验法则：

• 持久化： 在 80% 以上的交互中会引用的信息
• 检索： 在少于 20% 的交互中会引用的信息
• 灰色地带（20–80%）： 取决于检索延迟与上下文窗口成本

用户回复：［对其上下文进行分类］

Agent 提供： 关于哪些内容应持久化、哪些内容应检索的具体建议。

---

步骤 4：诊断问题 3——谁负责划定上下文边界？

Agent 询问：

第三个问题：谁负责定义哪些内容应该纳入 AI 的上下文，哪些不应该？

责任归属问题：

如果没有人负责划定上下文边界，它就会无限扩大。每位 PM 都会再加上“就多加一项”，六个月后，你每次查询都要塞进 100k 个令牌。

提供 3 个选项：

1. “我负责划定边界（独立 PM 或小团队）”

   • 评估： 很好——你可以快速做出决策
   • 建议： 记录你的边界标准（以问题 1–5 为框架）

2. “团队共同负责（协作定义边界）”

   • 评估： 正式化后可行
   • 建议： 创建一份“上下文清单”文档：哪些内容始终纳入、哪些内容按需检索、哪些内容排除（以及原因）

3. “没有人负责——一切临时决定／默认处理”

   • 评估： 存在重大风险；边界会不受控制地扩大
   • 解决方法： 明确指定负责人；安排每季度进行上下文审查

Agent 建议：

最佳实践：创建上下文清单

# Context Manifest: [Product/Feature Name]

## Always Persisted (Core Context)
- Product constraints (technical, regulatory)
- User preferences (role, permissions, preferences)
- Operational glossary (20 key terms)

## Retrieved On-Demand (Episodic Context)
- Historical PRDs (retrieve via semantic search)
- User interview transcripts (retrieve relevant quotes)
- Competitive analysis (retrieve when explicitly needed)

## Excluded (Out of Scope)
- Meeting notes older than 30 days (no longer relevant)
- Full codebase (use code search instead)
- Marketing materials (not decision-relevant)

## Boundary Owner: [Name]
## Last Reviewed: [Date]
## Next Review: [Date + 90 days]

用户回复： [描述当前的责任归属模式]

Agent 提供： 关于如何正式确立责任归属的建议，以及上下文清单模板。

---

步骤 5：诊断问题 4——排除这项内容会导致什么问题？

Agent 询问：

第四个问题：对于每一项上下文，如果将其排除，会出现什么具体故障？

这是证伪测试。如果你无法指出具体故障，就不需要这项上下文。

提供 3 种情况：

1. “如果排除产品约束，AI 就会推荐不可行的解决方案”

   • 故障模式： 清晰且具体
   • 评估： 这是保留约束条件的合理理由

2. “如果排除历史 PRD，AI 就无法理解我们的产品演进过程”

   • 故障模式： 模糊且假设性强
   • 评估： 当前决策很少需要历史上下文
   • 解决方法： 仅在明确引用过往决策时检索 PRD

3. “如果排除这项内容，我不确定会出什么问题——我只是想尽可能周全，所以才把它包括进来”

   • 故障模式： 未发现
   • 评估： 上下文堆砌；立即删除

Agent 建议：

证伪流程：

对于每项上下文，完成以下陈述：

“如果我排除[上下文内容]，那么在[具体场景]中就会出现[具体故障]。”

示例：

• ✅ 好：“如果我排除 GDPR 约束，AI 就会推荐违反欧盟隐私法的功能。”
• ❌ 不好：“如果我排除这份 PRD，AI 可能就无法充分理解产品。”（模糊）

用户回复： [将证伪测试应用于其上下文]

Agent 提供： 应删除的上下文内容清单（未发现具体故障）。

---

第 6 步：诊断问题 5——我们是在修复结构，还是在回避问题？

Agent 提问：

第五个问题：添加更多上下文是在解决问题，还是在掩盖更深层的结构性问题？

根本原因问题：

堆砌上下文往往会掩盖糟糕的信息架构。团队没有修复杂乱、含糊的文档，而是添加更多文档，希望 AI 能“自行理清”。

提供 3 个选项：

1. “我添加上下文，是因为我们的文档结构不佳／含糊不清”

   • **评估：**你在掩盖结构性问题
   • **解决办法：**先整理文档（消除歧义、添加约束、定义术语）
   • **示例：**与其粘贴 5 份相互矛盾的 PRD，不如将其协调统一为 1 份唯一事实来源

2. “我添加上下文，是因为我们没有共享的业务术语表”

   • **评估：**你在弥补基础缺失
   • **解决办法：**建立术语表（20-30 个关键术语）；AI 可以可靠地引用它
   • **示例：**明确界定“活跃用户”“客户流失率”“参与度”

3. “我添加上下文，是因为我们的约束尚未记录”

   • **评估：**你在回避约束工程
   • **解决办法：**创建约束登记表（技术、法规、战略方面）
   • **示例：**记录“我们不会开发移动应用”，而不是在每个提示词中都解释一遍

Agent 建议：

结构健康度测试：

如果你添加上下文是为了弥补：

• 文档含糊不清 → 修正文档，而不是添加更多内容
• 术语未定义 → 建立业务术语表
• 约束未记录 → 创建约束登记表
• 信息相互矛盾 → 协调统一为唯一事实来源

用户回答：[指出结构性问题]

**Agent 提供：**在添加更多上下文之前，优先处理的结构性修复清单。

---

第 7 步：定义记忆架构

Agent 提问：

根据你的上下文需求，我们来设计一个双层记忆架构。

你的上下文概况（根据前面的步骤）：

• 始终需要的上下文：[Q2 的摘要]
• 情景上下文：[Q2 的摘要]
• 边界负责人：[来自 Q3]
• 已验证的必要信息：[来自 Q4]
• 需要进行的结构性修复：[来自 Q5]

推荐架构：

短期（对话式）记忆：

• **存储内容：**用于回答后续问题的即时交互历史
• **生命周期：**单次会话
• **管理方式：**对较早的部分进行摘要或截断，以避免上下文过载
• 你的具体需求：[Agent 根据用户的工作流进行定制]

长期（持久化）记忆：

• **存储内容：**用户偏好、核心约束、业务术语表
• **生命周期：**跨会话持久保存
• **实现方式：**向量数据库（语义检索）
• 两种类型：
  • **陈述性记忆：**事实（例如：“我们遵循 HIPAA 法规”）
  • **程序性记忆：**行为模式（例如：“始终先验证可行性，再评估易用性”）
• 你的具体需求：[Agent 进行定制]

检索策略（情景上下文）：

• **检索内容：**历史 PRD、用户访谈、竞争分析
• **方法：**根据查询意图触发语义搜索
• **优化：**上下文检索（Anthropic）——在嵌入每个文本块之前，为其添加解释性上下文
• 你的具体需求：[Agent 进行定制]

Agent 提供：

你希望我：

1. 为你的具体用例生成上下文架构蓝图？
2. 提供实现指导（工具、技术、最佳实践）？
3. 为你的情景上下文设计检索策略？

用户回答：[选择]

---

第 8 步：实现「研究 → 计划 → 重置 → 实施」循环

Agent 询问：

现在，让我们实现研究 → 计划 → 重置 → 实施循环，防止上下文腐化。

问题： Agent 在研究过程中，上下文窗口会变得杂乱无章，充斥着行不通的思路、错误和噪声。这会分散注意力，导致目标偏移。

解决方案： 将研究内容压缩成高密度计划，然后在实施前清空上下文窗口。

四阶段循环：

阶段 1：研究（允许上下文混乱）

• Agent 从多个来源收集数据
• 上下文窗口变得庞大而杂乱（这是预期情况）
• 行不通的思路、失败的假设和噪声不断累积
• 目标： 全面收集信息

阶段 2：计划（综合整理）

• Agent 将研究内容综合整理成高密度的 SPEC.md 或 PLAN.md
• 这将成为实施的事实来源
• 关键要素：
  • 已做出的决策
  • 支持决策的证据
  • 应用的约束
  • 后续步骤（按顺序排列）
• 格式： 结构清晰、简洁明确、毫无歧义

阶段 3：重置（清空上下文窗口）

• 关键步骤： 清空整个上下文窗口
• 删除所有研究材料、行不通的思路和错误
• 防止上下文腐化影响实施

阶段 4：实施（仅使用计划开启全新会话）

• 开启新会话，仅以高密度计划作为上下文
• Agent 可以专注地执行任务
• 不受研究阶段的噪声干扰

Agent 提供 3 个选项：

1. “我想要 PLAN.md 格式模板”

   • Agent 提供用于编写高密度计划的结构化模板

2. “我想看一个实际运行该循环的示例”

   • Agent 展示具体的 PM 使用案例（例如，发现阶段规划）

3. “我准备在工作流中实施这个方法”

   • Agent 提供分步实施指南

用户回应： [选择]

Agent 提供： 根据所选选项量身定制的指导。

---

第 9 步：行动计划和后续步骤

Agent 综合整理：

根据你的上下文工程评估，以下是你的行动计划：

立即修复（本周）：

1. [删除 Q4 中没有可证伪失败模式的上下文]
2. [在下一个 AI 任务中应用「研究 → 计划 → 重置 → 实施」]
3. [在 Context Manifest 中记录上下文边界]

基础建设（接下来 2 周）：

1. [构建包含 20+ 条目的约束注册表]
2. [创建包含 20-30 个关键术语的操作词汇表]
3. [实施双层记忆架构]

长期优化（下个月）：

1. [为情景上下文设置语义检索]
2. [指定上下文边界负责人 + 季度审计计划]
3. [为 RAG 实施 Contextual Retrieval（Anthropic）]

成功指标：

• Token 使用量减少 50%+（更少地填塞上下文）
• 输出一致性提高（减少重试和重新生成）
• 响应质量提高（回答更精准、更少模棱两可）
• 上下文窗口保持稳定（不再无限增长）

Agent 询问：

你希望我：

1. 生成具体的实施文档（Context Manifest、PLAN.md 模板等）？
2. 提供进阶技巧（Contextual Retrieval、LLM 驱动的 ETL）？
3. 审查你当前的上下文设置（针对具体提示词/工作流提供反馈）？

---

示例

示例 1：独立 PM 将上下文塞给工程团队

背景：

• 早期初创公司的独立 PM
• 使用 Claude Projects 编写 PRD
• 每次都粘贴整份 PRD（20 页）和所有用户访谈（50 份记录）
• 得到的回答含糊不清、前后不一

评估：

• 症状：回答模棱两可、重试已成常态（4 种以上症状）
• Q1（决策）：“我只想让 AI 了解我的产品”（没有具体决策）
• Q2（持久化/检索）：将所有内容持久化（没有检索策略）
• Q3（所有权）：没有正式负责人（独立 PM，临时处理）
• Q4（失败）：无法指出大多数上下文会导致哪些具体失败
• Q5（结构）：回避记录约束

诊断： 活跃上下文囤积障碍

干预措施：

1. 立即： 删除所有未通过 Q4 测试的上下文 → 保留原内容的 20%
2. 第 1 周： 建立约束登记表（10 项技术约束、5 项战略约束）
3. 第 2 周： 创建操作术语表（25 个术语）
4. 第 3 周： 在下一个 PRD 中实施 Research→Plan→Reset→Implement

结果： Token 用量下降 70%，输出质量显著提升，回答简洁且可执行。

---

示例 2：采用 Agent 链的成长期团队

背景：

• 有 5 位 PM 的产品团队
• 用于综合分析探索研究的自定义 AI Agent
• Agent A（研究）→ Agent B（综合分析）→ Agent C（建议）
• 每个 Agent 都将完整上下文传给下一个 Agent → 上下文窗口膨胀至 100k+ Token

评估：

• 症状：Token 成本不断上升、输出不一致（3 种症状）
• Q1（决策）：每个 Agent 都有明确的决策，但会传递不必要的上下文
• Q2（持久化/检索）：持久化信息和情景信息混用，且没有策略
• Q3（所有权）：没有明确负责人；每位 PM 都会添加上下文
• Q4（失败）：Agent 传递“以防万一”的上下文，却没有可证伪的失败依据
• Q5（结构）：缺少 Context Manifest

诊断： Agent 编排缺少边界

干预措施：

1. 立即： 为每个 Agent 定义有界上下文（Agent A 只向 Agent B 输出 2 页的综合分析，而非完整研究内容）
2. 第 1 周： 指定上下文边界负责人（首席 PM）
3. 第 2 周： 创建 Context Manifest（哪些内容持久化、哪些内容检索、哪些内容排除）
4. 第 3 周： 在 Agent B 和 Agent C 之间实施 Research→Plan→Reset→Implement

结果： Token 用量下降 60%，Agent 链可靠性提升，成本降低 50%。

---

示例 3：采用 RAG 却没有上下文工程的企业

背景：

• 使用向量数据库 RAG 系统的大型企业
• 采用“塞入整个知识库”的方式（10,000+ 份文档）
• 每次查询检索 50+ 个文本块 → 淹没上下文窗口
• 随着知识库增长，准确率不断下降

评估：

• 症状：尽管拥有“完整知识”，回答仍然含糊不清；重试已成常态（2 种症状）
• Q1（决策）：决策明确，但检索没有明确意图（什么都返回）
• Q2（持久化/检索）：有检索的良好意识，但没有过滤
• Q3（所有权）：工程团队负责 RAG，产品团队不负责上下文边界
• Q4（失败）：无法说明为什么需要 50 个文本块，而不是 5 个
• Q5（结构）：知识库没有结构（文档平铺，没有元数据）

诊断： 缺乏意图的检索（将 RAG 当作塞入上下文）

干预措施：

1. 立即： 将每次查询的检索数量限制为前 5 个文本块（从 50 个降至 5 个）
2. 第 1 周： 实施 Contextual Retrieval（Anthropic）——在索引期间为每个文本块添加说明性上下文
3. 第 2 周： 为文档添加元数据（类别、时效性、权威性）
4. 第 3 周： 产品团队针对每种查询类型定义检索意图（探索 = 客户洞察，可行性 = 技术约束）

结果： 准确率提升 35%（依据 Anthropic 基准测试），延迟降低 60%，Token 用量下降 80%。

---

常见误区

1. “无限上下文”营销宣传与工程现实

失败模式： 认为“100 万 token 的上下文窗口”意味着应该全部用上。

后果： 推理噪声会降低性能；超过约 32k token 后，准确率会跌至 20% 以下。

解决方法： 上下文窗口并非免费。将 token 视为稀缺资源；优化信息密度，而非数量。

---

2. 一味重试，而不重构

失败模式： “跑 3 次就能成功”→ 习惯性重试，而不是修复结构。

后果： 浪费时间和金钱；掩盖更深层的上下文腐化问题。

解决方法： 如果经常需要重试，说明你的上下文结构有问题。应用 Q5（修复结构，而非增加数量）。

---

3. 没有上下文边界负责人

失败模式： 临时、隐式地决定上下文内容 → 无限制增长。

后果： 六个月后，每次查询都会在每次交互中塞入 100k token。

解决方法： 指定明确的负责人；创建 Context Manifest；安排每季度审核。

---

4. 混淆始终需要的信息与情境性信息

失败模式： 持久保存本应按需检索的历史数据。

后果： 上下文窗口被无关信息挤满；注意力被稀释。

解决方法： 应用 Q2 测试：只持久保存 80% 以上交互中需要的信息；其余内容按需检索。

---

5. 跳过重置阶段

失败模式： 在 Research→Plan→Implement 周期中从不清空上下文窗口。

后果： 上下文腐化不断累积；目标偏移；死胡同污染实施过程。

解决方法： Plan 后必须执行 Reset 阶段；开始实施时，上下文中只保留高密度计划。

---

参考资料

相关技能

• 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 产品经理学科之一）
• Marty Cagan — Empowered（AI 时代的可行性风险包括理解“AI 的物理规律”）
• Anthropic — Contextual Retrieval 白皮书（故障率降低 35%）
• Google — 关于大模型驱动的记忆系统的上下文工程白皮书

技术参考

• RAG（检索增强生成） — 用于检索情境性上下文的标准技术
• 向量数据库 — 用于长期记忆的语义搜索（Pinecone、Weaviate、Chroma）
• Contextual Retrieval（Anthropic） — 在嵌入前为文本块添加说明性上下文
• LLM-as-Judge — 自动评估上下文质量