context-engineering-advisor

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Purpose

目标

Guide product managers through diagnosing whether they're doing context stuffing (jamming volume without intent) or context engineering (shaping structure for attention). Use this to identify context boundaries, fix "Context Hoarding Disorder," and implement tactical practices like bounded domains, episodic retrieval, and the Research→Plan→Reset→Implement cycle.

Key Distinction: Context stuffing assumes volume = quality ("paste the entire PRD"). Context engineering treats AI attention as a scarce resource and allocates it deliberately.

This is not about prompt writing—it's about designing the information architecture that grounds AI in reality without overwhelming it with noise.

指导产品经理判断自己当前的做法属于上下文填充（无目的地堆砌大量信息）还是上下文工程（为聚焦注意力构建结构化信息）。借助本内容识别上下文边界，解决「上下文囤积症」，并落地诸如有限域、情景检索以及Research→Plan→Reset→Implement循环等实用实践。

核心区别：上下文填充假设「数量=质量」（比如“粘贴完整PRD文档”），而上下文工程将AI的注意力视为稀缺资源，并进行针对性分配。

这与提示词撰写无关——而是关于设计信息架构，让AI基于真实信息开展工作，同时避免被无效信息干扰。

Key Concepts

核心概念

The Paradigm Shift: Parametric → Contextual Intelligence

范式转变：参数化智能 → 上下文智能

The Fundamental Problem:

LLMs have parametric knowledge (encoded during training) = static, outdated, non-attributable
When asked about proprietary data, real-time info, or user preferences → forced to hallucinate or admit ignorance
Context engineering bridges the gap between static training and dynamic reality

PM's Role Shift: From feature builder → architect of informational ecosystems that ground AI in reality

核心问题：

大语言模型（LLM）具备参数化知识（训练阶段编码）= 静态、过时、无法溯源
当被问及专有数据、实时信息或用户偏好时，要么被迫生成幻觉内容，要么承认无知
上下文工程填补了静态训练数据与动态现实之间的差距

产品经理角色转变：从功能构建者 → 信息生态架构师，为AI搭建贴合现实的基础环境

Context Stuffing vs. Context Engineering

上下文填充 vs 上下文工程

Dimension	Context Stuffing	Context Engineering
Mindset	Volume = quality	Structure = quality
Approach	"Add everything just in case"	"What decision am I making?"
Persistence	Persist all context	Retrieve with intent
Agent Chains	Share everything between agents	Bounded context per agent
Failure Response	Retry until it works	Fix the structure
Economic Model	Context as storage	Context as attention (scarce resource)

Critical Metaphor: Context stuffing is like bringing your entire file cabinet to a meeting. Context engineering is bringing only the 3 documents relevant to today's decision.

维度	上下文填充	上下文工程
思维模式	数量=质量	结构=质量
方法	“把所有内容都加上以防万一”	“我要做什么决策？”
持久化方式	保留所有上下文	有目的地检索
Agent链	Agent间共享所有内容	每个Agent使用有限上下文
故障应对	不断重试直到成功	修复结构问题
经济模型	上下文作为存储资源	上下文作为稀缺的注意力资源

关键类比：上下文填充就像把整个文件柜带到会议上，而上下文工程只带与今日决策相关的3份文档。

The Anti-Pattern: Context Stuffing

反模式：上下文填充

Five Markers of Context Stuffing:

Reflexively expanding context windows — "Just add more tokens!"
Persisting everything "just in case" — No clear retention criteria
Chaining agents without boundaries — Agent A passes everything to Agent B to Agent C
Adding evaluations to mask inconsistency — "We'll just retry until it's right"
Normalized retries — "It works if you run it 3 times" becomes acceptable

Why It Fails:

Reasoning Noise: Thousands of irrelevant files compete for attention, degrading multi-hop logic
Context Rot: Dead ends, past errors, irrelevant data accumulate → goal drift
Lost in the Middle: Models prioritize beginning (primacy) and end (recency), ignore middle
Economic Waste: Every query becomes expensive without accuracy gains
Quantitative Degradation: Accuracy drops below 20% when context exceeds ~32k tokens

The Hidden Costs:

Escalating token consumption
Diluted attention across irrelevant material
Reduced output confidence
Cascading retries that waste time and money

上下文填充的五大特征：

下意识地扩大上下文窗口 —— “只管增加token数量！”
无差别持久化所有内容“以防万一” —— 没有明确的保留标准
无边界的Agent链 —— Agent A把所有内容传给Agent B，再传给Agent C
通过添加评估来掩盖不一致性 —— “多试几次总能成功”
重试常态化 —— “运行3次就能正常工作”被视为可接受的情况

失败原因：

推理噪声：数千份无关文件争夺注意力，降低多步推理逻辑的准确性
上下文腐化：无效路径、过往错误、无关数据不断累积 → 目标偏离
中间信息丢失：模型优先关注开头（首因效应）和结尾（近因效应），忽略中间内容
经济浪费：每次查询成本高昂，但准确性并未提升
性能量化下降：当上下文超过约32k token时，准确率降至20%以下

隐性成本：

Token消耗持续攀升
注意力被无关内容分散
输出结果的置信度降低
重试连锁反应浪费时间和资金

Real Context Engineering: Core Principles

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

Five Foundational Principles:

Context without shape becomes noise
Structure > Volume
Retrieve with intent, not completeness
Small working contexts (like short-term memory)
Context Compaction: Maximize density of relevant information per token

Quantitative Framework:

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

Key Finding: Using RAG with 25% of available tokens preserves 95% accuracy while significantly reducing latency and cost.

五大基础原则：

无结构化的上下文就是噪声
结构 > 数量
有目的地检索，而非追求完整性
小范围工作上下文（类似短期记忆）
上下文压缩：最大化每个token的相关信息密度

量化框架：

效率 = (准确率 × 连贯性) / (Token数量 × 延迟)

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

The 5 Diagnostic Questions (Detect Context Hoarding Disorder)

五大诊断问题（检测上下文囤积症）

Ask these to identify context stuffing:

What specific decision does this support? — If you can't answer, you don't need it
Can retrieval replace persistence? — Just-in-time beats always-available
Who owns the context boundary? — If no one, it'll grow forever
What fails if we exclude this? — If nothing breaks, delete it
Are we fixing structure or avoiding it? — Stuffing context often masks bad information architecture

通过以下问题识别上下文填充行为：

这些上下文支持什么具体决策？ —— 如果无法回答，说明你不需要这些内容
能否用检索替代持久化？ —— 按需获取优于始终可用
谁负责定义上下文边界？ —— 如果无人负责，上下文会无限膨胀
如果移除这些内容，会发生什么故障？ —— 如果没有任何影响，就删除它
我们是在修复结构，还是在逃避问题？ —— 上下文填充往往掩盖了糟糕的信息架构

Memory Architecture: Two-Layer System

内存架构：双层系统

Short-Term (Conversational) Memory:

Immediate interaction history for follow-up questions
Challenge: Space management → older parts summarized or truncated
Lifespan: Single session

Long-Term (Persistent) Memory:

User preferences, key facts across sessions → deep personalization
Implemented via vector database (semantic retrieval)
Two types:
- Declarative Memory: Facts ("I'm vegan")
- Procedural Memory: Behavioral patterns ("I debug by checking logs first")
Lifespan: Persistent across sessions

LLM-Powered ETL: Models generate their own memories by identifying signals, consolidating with existing data, updating database automatically.

短期（会话式）内存：

用于存储即时交互历史，支持后续跟进问题
挑战：空间管理 → 对较早的内容进行总结或截断
生命周期：单次会话

长期（持久化）内存：

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

LLM驱动的ETL：模型通过识别信号、整合现有数据、自动更新数据库，生成自己的记忆。

The Research → Plan → Reset → Implement Cycle

Research→Plan→Reset→Implement循环

The Context Rot Solution:

Research: Agent gathers data → large, chaotic context window (noise + dead ends)
Plan: Agent synthesizes into high-density SPEC.md or PLAN.md (Source of Truth)
Reset: Clear entire context window (prevents context rot)
Implement: Fresh session using only the high-density plan as context

Why This Works: Context rot is eliminated; agent starts clean with compressed, high-signal context.

上下文腐化解决方案：

Research（调研）：Agent收集数据 → 生成庞大、混乱的上下文窗口（包含噪声和无效路径）
Plan（规划）：Agent将数据整合为高密度的SPEC.md或PLAN.md文档（唯一可信来源）
Reset（重置）：清空整个上下文窗口（防止上下文腐化）
Implement（落地）：开启新会话，仅以高密度规划文档作为上下文

生效原因：上下文腐化被彻底消除；Agent基于压缩后的高信号上下文重新开始工作。

Anti-Patterns (What This Is NOT)

反模式（本内容不涉及的领域）

Not about choosing AI tools — Claude vs. ChatGPT doesn't matter; architecture matters
Not about writing better prompts — This is systems design, not copywriting
Not about adding more tokens — "Infinite context" narratives are marketing, not engineering reality
Not about replacing human judgment — Context engineering amplifies judgment, doesn't eliminate it

与选择AI工具无关 —— Claude还是ChatGPT并不重要，架构才是关键
与撰写更好的提示词无关 —— 这是系统设计，而非文案撰写
与增加更多token无关 —— “无限上下文”只是营销话术，而非工程现实
与替代人类判断无关 —— 上下文工程是为了强化人类判断，而非取代它

When to Use This Skill

何时使用本技能

✅ Use this when:

You're pasting entire PRDs/codebases into AI and getting vague responses
AI outputs are inconsistent ("works sometimes, not others")
You're burning tokens without seeing accuracy improvements
You suspect you're "context stuffing" but don't know how to fix it
You need to design context architecture for an AI product feature

❌ Don't use this when:

You're just getting started with AI (start with basic prompts first)
You're looking for tool recommendations (this is about architecture, not tooling)
Your AI usage is working well (if it ain't broke, don't fix it)

✅ 适用场景：

你将完整PRD/代码库粘贴到AI中，却得到模糊的回复
AI输出结果不一致（“有时有效，有时无效”）
消耗大量token，但准确性未提升
你怀疑自己在“上下文填充”，但不知道如何解决
你需要为AI产品功能设计上下文架构

❌ 不适用场景：

你刚开始接触AI（先从基础提示词开始）
你正在寻找工具推荐（本内容聚焦架构，而非工具）
你的AI使用效果良好（无需修复正常运行的系统）

Facilitation Source of Truth

引导式交互的可信来源

Use

workshop-facilitation

as the default interaction protocol for this skill.

It defines:

session heads-up + entry mode (Guided, Context dump, Best guess)
one-question turns with plain-language prompts
progress labels (for example, Context Qx/8 and Scoring Qx/5)
interruption handling and pause/resume behavior
numbered recommendations at decision points
quick-select numbered response options for regular questions (include
```
Other (specify)
```
when useful)

This file defines the domain-specific assessment content. If there is a conflict, follow this file's domain logic.

将

workshop-facilitation

作为本技能的默认交互协议。

它定义了：

会话提醒与进入模式（引导式、上下文转储、最佳猜测）
单轮一问的平实语言提示词
进度标签（例如，Context Qx/8和Scoring Qx/5）
中断处理与暂停/恢复机制
决策点的编号建议
常规问题的快速选择编号响应选项（必要时包含“其他（请说明）”）

本文件定义了特定领域的评估内容。若存在冲突，以本文件的领域逻辑为准。

Application

应用

This interactive skill uses adaptive questioning to diagnose context stuffing, identify boundaries, and provide tactical implementation guidance.

本交互式技能通过自适应提问来诊断上下文填充行为、识别边界，并提供实用的落地指导。

Step 0: Gather Context

步骤0：收集上下文信息

Agent asks:

Before we diagnose your context practices, let's gather information:

Current AI Usage:

What AI tools/systems do you use? (ChatGPT, Claude, custom agents, etc.)
What PM tasks do you use AI for? (PRD writing, user research synthesis, discovery, etc.)
How do you provide context? (paste docs, reference files, use projects/memory)

Symptoms:

Are AI outputs inconsistent? (works sometimes, not others)
Are you retrying prompts multiple times to get good results?
Are responses vague or hedged despite providing "all the context"?
Are token costs escalating without accuracy improvements?

System Architecture (if applicable):

Do you have custom AI agents or workflows?
How is context shared between agents?
Do you use RAG, vector databases, or memory systems?

You can describe briefly or paste examples.

Agent会询问：

在诊断你的上下文实践之前，先收集一些信息：

当前AI使用情况：

你使用哪些AI工具/系统？（ChatGPT、Claude、自定义Agent等）
你用AI完成哪些PM任务？（PRD撰写、用户调研整合、需求探索等）
你如何提供上下文？（粘贴文档、引用文件、使用项目/内存功能等）

症状：

AI输出结果是否不一致？（有时有效，有时无效）
你是否需要多次重试提示词才能得到满意结果？
尽管提供了“所有上下文”，AI的回复仍然模糊或模棱两可？
Token成本持续攀升，但准确性未提升？

系统架构（如适用）：

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

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

Step 1: Diagnose Context Stuffing Symptoms

步骤1：诊断上下文填充症状

Agent asks:

Let's assess whether you're experiencing context stuffing. Which of these symptoms do you recognize?

Select all that apply:

"I paste entire documents into AI" — Full PRDs, complete user interview transcripts, entire codebases
"AI gives vague, hedged responses despite having 'all the context'" — Responses like "it depends," "consider these options," non-committal
"I have to retry prompts 3+ times to get usable output" — Inconsistency is normalized
"Token costs are escalating but accuracy isn't improving" — Spending more, getting same or worse results
"I keep adding more context hoping it'll help" — Reflexive expansion without strategy
"My agents pass everything to each other" — Agent A → Agent B → Agent C with full context chain
"I don't have clear criteria for what to include/exclude" — No context boundary definitions
"None of these—my AI usage is working well" — Skip to advanced optimization

User response: [Select symptoms]

Agent analyzes:

Based on your selections:

0-1 symptoms: Healthy context practices; proceed to optimization
2-3 symptoms: Early context stuffing; address before it scales
4+ symptoms: Active Context Hoarding Disorder; immediate intervention needed

Agent proceeds to diagnostic questions.

Agent会询问：

我们来评估你是否存在上下文填充的情况。你是否遇到以下症状？

可多选：

“我会将完整文档粘贴到AI中” —— 完整PRD、完整用户访谈记录、整个代码库
“尽管提供了‘所有上下文’，AI仍然给出模糊、模棱两可的回复” —— 比如“视情况而定”“可以考虑这些选项”等非确定性回复
“我需要重试提示词3次以上才能得到可用结果” —— 不一致性被视为常态
“Token成本持续攀升，但准确性未提升” —— 投入增加，但效果不变或变差
“我不断添加更多上下文，希望能改善结果” —— 无策略地盲目扩大上下文
“我的Agent会将所有内容传递给下一个Agent” —— Agent A→Agent B→Agent C，全程传递完整上下文
“我没有明确的上下文包含/排除标准” —— 无上下文边界定义
“以上都没有——我的AI使用效果良好” —— 直接跳转到高级优化环节

用户回复： [选择症状]

Agent分析：

根据你的选择：

0-1个症状：上下文实践健康；进入优化环节
2-3个症状：早期上下文填充；在问题扩大前解决
4个及以上症状：已出现上下文囤积症；需要立即干预

Agent将进入诊断提问环节。

Step 2: Diagnostic Question 1 — What Specific Decision Does This Support?

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

Agent asks:

Let's start with the most critical question: For each piece of context you're including, what specific decision does it support?

Example Context Analysis:

Imagine you're asking AI to "help with discovery planning." You're providing:

Entire PRD (20 pages)
50 user interview transcripts (full)
Competitive analysis doc (15 pages)
Team meeting notes from last 3 months

Question: What decision are you making right now?

Offer 3 scenarios:

"I'm deciding which user segment to interview first"
- Context needed: User segments from PRD (2 paragraphs), prior interview themes (1 page synthesis), not full transcripts
- Context NOT needed: Meeting notes, full competitive analysis, full PRD
"I'm deciding which discovery questions to ask in interviews"
- Context needed: Research objectives (from PRD), past interview insights (synthesis), Jobs-to-be-Done framework
- Context NOT needed: Full competitive analysis, full meeting notes
"I'm not sure what decision I'm making—I just want AI to 'understand my product'"
- Problem: No specific decision = context stuffing trap
- Fix: Define the decision first, then select context

Agent recommends:

Best Practice: Before adding context, complete this sentence:

"I need this context because I'm deciding [specific decision], and without [specific information], I can't make that decision."

If you can't complete that sentence, you don't need the context.

User response: [Describe their decision + context]

Agent validates: Does the context directly support the stated decision? If not, recommend trimming.

Agent会询问：

从最关键的问题开始：对于你包含的每一部分上下文，它支持什么具体决策？

上下文分析示例：

假设你让AI“协助进行需求探索规划”，并提供了以下内容：

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

问题： 你当前要做什么决策？

提供3种场景：

“我要决定先访谈哪个用户群体”
- 所需上下文：PRD中的用户群体（2段内容）、过往访谈主题（1页整合内容），无需完整访谈记录
- 无需上下文：会议纪要、完整竞品分析、完整PRD
“我要决定访谈中要问哪些需求探索问题”
- 所需上下文：PRD中的调研目标、过往访谈洞察（整合内容）、Jobs-to-be-Done框架
- 无需上下文：完整竞品分析、完整会议纪要
“我不确定要做什么决策——我只是想让AI‘了解我的产品’”
- 问题：没有具体决策 = 陷入上下文填充陷阱
- 解决方案：先明确决策，再选择上下文

Agent建议：

最佳实践：在添加上下文之前，完成这句话：

“我需要这些上下文，因为我要做[具体决策]，如果没有[具体信息]，我就无法做出这个决策。”

如果你无法完成这句话，说明你不需要这些上下文。

用户回复： [描述你的决策和对应的上下文]

Agent验证： 上下文是否直接支持你所述的决策？如果不是，建议精简。

Step 3: Diagnostic Question 2 — Can Retrieval Replace Persistence?

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

Agent asks:

Second question: Is this information you always need, or something you can retrieve just-in-time?

The Distinction:

Always-Needed (Persist):

Core product constraints (technical, regulatory, strategic)
User preferences that apply to every interaction
Critical definitions (operational glossary)
Non-negotiable rules

Episodic (Retrieve on-demand):

Project-specific details (this epic, this sprint)
Historical data (past PRDs, old interview transcripts)
Contextual facts (competitive analysis, market research)
Temporary decisions

Key Insight: Just-in-time retrieval beats always-available. Don't persist what you can retrieve.

Offer 3 options:

"Most of my context is always-needed (core constraints, user prefs)"
- Assessment: Good instinct; verify with Question 4 (what fails if excluded?)
- Recommendation: Build constraints registry and operational glossary (persist these)
"Most of my context is episodic (project details, historical data)"
- Assessment: Perfect candidate for RAG or retrieval
- Recommendation: Implement semantic search; retrieve only relevant chunks for each query
"I'm not sure which is which—I persist everything to be safe"
- Assessment: Classic Context Hoarding Disorder symptom
- Fix: Apply Question 4 test to each piece of context

Agent recommends:

Rule of Thumb:

Persist: Information referenced in 80%+ of interactions
Retrieve: Information referenced in <20% of interactions
Gray zone (20-80%): Depends on retrieval latency vs. context window cost

User response: [Categorize their context]

Agent provides: Specific recommendations on what to persist vs. retrieve.

Agent会询问：

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

核心区别：

始终需要（持久化）：

核心产品约束（技术、合规、战略层面）
适用于所有交互的用户偏好
关键定义（操作术语表）
不可协商的规则

情景化（按需检索）：

项目特定细节（当前史诗、当前迭代）
历史数据（过往PRD、旧访谈记录）
情境化事实（竞品分析、市场调研）
临时决策

关键洞察：按需检索优于始终可用。不要持久化可以按需检索的内容。

提供3个选项：

“我的大部分上下文是始终需要的（核心约束、用户偏好）”
- 评估：思路正确；用问题4验证（移除后会出现什么故障？）
- 建议：构建约束注册表和操作术语表（持久化这些内容）
“我的大部分上下文是情景化的（项目细节、历史数据）”
- 评估：非常适合使用RAG或检索技术
- 建议：实现语义搜索；针对每个查询仅检索相关片段
“我不确定属于哪一类——为了保险起见，我持久化所有内容”
- 评估：典型的上下文囤积症症状
- 解决方案：对每一部分上下文应用问题4的测试

Agent建议：

经验法则：

持久化：80%以上的交互都会参考的信息
检索：参考占比<20%的信息
灰色地带（20-80%）：取决于检索延迟与上下文窗口成本的权衡

用户回复： [对你的上下文进行分类]

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

Step 4: Diagnostic Question 3 — Who Owns the Context Boundary?

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

Agent asks:

Third question: Who is responsible for defining what belongs in vs. out of your AI's context?

The Ownership Problem:

If no one owns the context boundary, it will grow indefinitely. Every PM will add "just one more thing," and six months later, you're stuffing 100k tokens per query.

Offer 3 options:

"I own the boundary (solo PM or small team)"
- Assessment: Good—you can make fast decisions
- Recommendation: Document your boundary criteria (use Questions 1-5 as framework)
"My team shares ownership (collaborative boundary definition)"
- Assessment: Can work if formalized
- Recommendation: Create a "Context Manifest" doc: what's always included, what's retrieved, what's excluded (and why)
"No one owns it—it's ad-hoc / implicit"
- Assessment: Critical risk; boundary will expand uncontrollably
- Fix: Assign explicit ownership; schedule quarterly context audits

Agent recommends:

Best Practice: Create a Context Manifest

markdown

undefined

Agent会询问：

第三个问题：谁负责定义AI上下文的包含/排除范围？

所有权问题：

如果无人负责上下文边界，它会无限膨胀。每个PM都会添加“再多一件内容”，六个月后，每次查询都会填充100k+ token。

提供3个选项：

“我负责边界定义（独立PM或小团队）”
- 评估：很好——你可以快速做出决策
- 建议：记录你的边界标准（以问题1-5为框架）
“我的团队共同负责边界定义（协作式边界定义）”
- 评估：如果形成规范，这种模式可行
- 建议：创建“上下文清单”文档：明确始终包含的内容、按需检索的内容、排除的内容（及原因）
“无人负责——都是临时/隐性决策”
- 评估：重大风险；边界会不受控制地膨胀
- 解决方案：指定明确的负责人；安排每季度的上下文审计

Agent建议：

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

markdown

undefined

Context Manifest: [Product/Feature Name]

上下文清单：[产品/功能名称]

Always Persisted (Core Context)

始终持久化（核心上下文）

Product constraints (technical, regulatory)
User preferences (role, permissions, preferences)
Operational glossary (20 key terms)

产品约束（技术、合规）
用户偏好（角色、权限、偏好）
操作术语表（20个关键术语）

Retrieved On-Demand (Episodic Context)

按需检索（情景上下文）

Historical PRDs (retrieve via semantic search)
User interview transcripts (retrieve relevant quotes)
Competitive analysis (retrieve when explicitly needed)

历史PRD（通过语义检索获取）
用户访谈记录（检索相关引用）
竞品分析（仅在明确需要时检索）

Excluded (Out of Scope)

排除范围（超出边界）

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

30天以上的会议纪要（不再相关）
完整代码库（改用代码搜索）
营销材料（与决策无关）

Boundary Owner: [Name]

边界负责人：[姓名]

Last Reviewed: [Date]

上次审核日期：[日期]

Next Review: [Date + 90 days]

下次审核日期：[日期 + 90天]


**User response:** [Describe current ownership model]

**Agent provides:** Recommendation on formalizing ownership + template for Context Manifest.

---


**用户回复：** [描述当前的所有权模式]

**Agent提供：** 关于规范所有权的建议，以及上下文清单模板。

---

Step 5: Diagnostic Question 4 — What Fails if We Exclude This?

步骤5：诊断问题4——如果移除这些内容，会发生什么故障？

Agent asks:

Fourth question: For each piece of context, what specific failure mode occurs if you exclude it?

This is the falsification test. If you can't identify a concrete failure, you don't need the context.

Offer 3 scenarios:

"If I exclude product constraints, AI will recommend infeasible solutions"
- Failure Mode: Clear and concrete
- Assessment: Valid reason to persist constraints
"If I exclude historical PRDs, AI won't understand our product evolution"
- Failure Mode: Vague and hypothetical
- Assessment: Historical context rarely needed for current decisions
- Fix: Retrieve PRDs only when explicitly referencing past decisions
"If I exclude this, I'm not sure anything would break—I just include it to be thorough"
- Failure Mode: None identified
- Assessment: Context stuffing; delete immediately

Agent recommends:

The Falsification Protocol:

For each context element, complete this statement:

"If I exclude [context element], then [specific failure] will occur in [specific scenario]."

Examples:

✅ Good: "If I exclude GDPR constraints, AI will recommend features that violate EU privacy law."
❌ Bad: "If I exclude this PRD, AI might not fully understand the product." (Vague)

User response: [Apply falsification test to their context]

Agent provides: List of context elements to delete (no concrete failure identified).

Agent会询问：

第四个问题：对于每一部分上下文，如果移除它，会出现什么具体的故障模式？

这是证伪测试。如果你无法确定具体的故障，说明你不需要这些上下文。

提供3种场景：

“如果移除产品约束，AI会推荐不可行的解决方案”
- 故障模式：清晰具体
- 评估：持久化约束的合理理由
“如果移除历史PRD，AI无法理解我们的产品演进过程”
- 故障模式：模糊且假设性的
- 评估：历史上下文很少用于当前决策
- 解决方案：仅在明确参考过往决策时才检索PRD
“如果移除这些内容，我不确定会有什么问题——只是为了全面才包含进来”
- 故障模式：未识别到任何故障
- 评估：上下文填充；立即删除

Agent建议：

证伪流程：

对于每个上下文元素，完成以下陈述：

“如果我移除[上下文元素]，那么在[具体场景]中会出现[具体故障]。”

示例：

✅ 正确：“如果我移除GDPR约束，AI会推荐违反欧盟隐私法的功能。”
❌ 错误：“如果我移除这份PRD，AI可能无法完全理解产品。”（表述模糊）

用户回复： [对上下文应用证伪测试]

Agent提供： 列出需要删除的上下文元素（未识别到具体故障的内容）。

Step 6: Diagnostic Question 5 — Are We Fixing Structure or Avoiding It?

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

Agent asks:

Fifth question: Is adding more context solving a problem, or masking a deeper structural issue?

The Root Cause Question:

Context stuffing often hides bad information architecture. Instead of fixing messy, ambiguous documents, teams add more documents hoping AI will "figure it out."

Offer 3 options:

"I'm adding context because our docs are poorly structured/ambiguous"
- Assessment: You're masking a structural problem
- Fix: Clean up the docs first (remove ambiguity, add constraints, define terms)
- Example: Instead of pasting 5 conflicting PRDs, reconcile them into 1 Source of Truth
"I'm adding context because we don't have a shared operational glossary"
- Assessment: You're compensating for missing foundations
- Fix: Build the glossary (20-30 key terms); AI can reference it reliably
- Example: Define "active user," "churn," "engagement" unambiguously
"I'm adding context because our constraints aren't documented"
- Assessment: You're avoiding constraint engineering
- Fix: Create constraints registry (technical, regulatory, strategic)
- Example: Document "We won't build mobile apps" vs. explaining it in every prompt

Agent recommends:

The Structural Health Test:

If you're adding context to compensate for:

Ambiguous documentation → Fix the docs, don't add more
Undefined terms → Build operational glossary
Undocumented constraints → Create constraints registry
Conflicting information → Reconcile into Source of Truth

User response: [Identify structural issues]

Agent provides: Prioritized list of structural fixes before adding more context.

Agent会询问：

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

根本原因问题：

上下文填充往往掩盖了糟糕的信息架构。团队不修复混乱、模糊的文档，而是添加更多文档，希望AI能“自行理清”。

提供3个选项：

“我添加上下文是因为我们的文档结构混乱/表述模糊”
- 评估：你在掩盖结构问题
- 解决方案：先清理文档（消除模糊性、添加约束、明确定义）
- 示例：不要粘贴5份相互冲突的PRD，而是将它们整合为1份唯一可信来源文档
“我添加上下文是因为我们没有共享的操作术语表”
- 评估：你在弥补缺失的基础架构
- 解决方案：构建术语表（20-30个关键术语）；AI可以可靠地参考它
- 示例：明确定义“活跃用户”“流失率”“参与度”等术语
“我添加上下文是因为我们的约束没有文档化”
- 评估：你在逃避约束工程
- 解决方案：创建约束注册表（技术、合规、战略层面）
- 示例：记录“我们不会开发移动应用”，而不是在每个提示词中解释

Agent建议：

结构健康测试：

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

模糊的文档 → 修复文档，不要添加更多内容
未定义的术语 → 构建操作术语表
未文档化的约束 → 创建约束注册表
冲突的信息 → 整合为唯一可信来源

用户回复： [识别结构问题]

Agent提供： 在添加更多上下文之前，优先修复的结构问题列表。

Step 7: Define Memory Architecture

步骤7：定义内存架构

Agent asks:

Based on your context needs, let's design a two-layer memory architecture.

Your Context Profile (from previous steps):

Always-needed context: [Summary from Q2]
Episodic context: [Summary from Q2]
Boundary owner: [From Q3]
Validated essentials: [From Q4]
Structural fixes needed: [From Q5]

Recommended Architecture:

Short-Term (Conversational) Memory:

What it stores: Immediate interaction history for follow-up questions
Lifespan: Single session
Management: Summarize or truncate older parts to avoid crowding
Your specific needs: [Agent customizes based on user's workflow]

Long-Term (Persistent) Memory:

What it stores: User preferences, core constraints, operational glossary
Lifespan: Persistent across sessions
Implementation: Vector database (semantic retrieval)
Two types:
- Declarative Memory: Facts (e.g., "We follow HIPAA regulations")
- Procedural Memory: Behavioral patterns (e.g., "Always validate feasibility before usability")
Your specific needs: [Agent customizes]

Retrieval Strategy (Episodic Context):

What it retrieves: Historical PRDs, user interviews, competitive analysis
Method: Semantic search triggered by query intent
Optimization: Contextual Retrieval (Anthropic) — prepend explanatory context to each chunk before embedding
Your specific needs: [Agent customizes]

Agent offers:

Would you like me to:

Generate a Context Architecture Blueprint for your specific use case?
Provide implementation guidance (tools, techniques, best practices)?
Design a retrieval strategy for your episodic context?

User response: [Selection]

Agent会询问：

根据你的上下文需求，我们来设计双层内存架构。

你的上下文概况（来自之前的步骤）：

始终需要的上下文：[步骤2的总结]
情景化上下文：[步骤2的总结]
边界负责人：[步骤3的结果]
已验证的必要内容：[步骤4的结果]
需要修复的结构问题：[步骤5的结果]

推荐架构：

短期（会话式）内存：

存储内容：即时交互历史，用于支持后续跟进问题
生命周期：单次会话
管理方式：对较早的内容进行总结或截断，避免占用过多空间
你的特定需求：[Agent根据用户工作流定制]

长期（持久化）内存：

存储内容：用户偏好、核心约束、操作术语表
生命周期：跨会话持久化
实现方式：向量数据库（语义检索）
两类内存：
- 陈述性记忆：事实信息（例如，“我们遵循HIPAA法规”）
- 程序性记忆：行为模式（例如，“在验证可用性之前，始终先验证可行性”）
你的特定需求：[Agent定制]

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

检索内容：历史PRD、用户访谈、竞品分析
方法：由查询意图触发的语义搜索
优化方式：Contextual Retrieval（Anthropic）—— 在嵌入前为每个片段添加解释性上下文
你的特定需求：[Agent定制]

Agent会提供选项：

你希望我：

为你的特定用例生成上下文架构蓝图？
提供落地指导（工具、技术、最佳实践）？
为你的情景化上下文设计检索策略？

用户回复： [选择]

Step 8: Implement Research → Plan → Reset → Implement Cycle

步骤8：落地Research→Plan→Reset→Implement循环

Agent asks:

Now let's implement the Research → Plan → Reset → Implement cycle to prevent context rot.

The Problem: As agents research, context windows grow chaotic—filled with dead ends, errors, and noise. This dilutes attention and causes goal drift.

The Solution: Compress research into a high-density plan, then clear the context window before implementing.

The Four-Phase Cycle:

Phase 1: Research (Chaotic Context Allowed)

Agent gathers data from multiple sources
Context window grows large and messy (this is expected)
Dead ends, failed hypotheses, and noise accumulate
Goal: Comprehensive information gathering

Phase 2: Plan (Synthesis)

Agent synthesizes research into a high-density SPEC.md or PLAN.md
This becomes the Source of Truth for implementation
Key elements:
- Decision made
- Evidence supporting decision
- Constraints applied
- Next steps (sequenced)
Format: Structured, concise, unambiguous

Phase 3: Reset (Clear Context Window)

Critical step: Clear the entire context window
Delete all research artifacts, dead ends, errors
This prevents context rot from poisoning implementation

Phase 4: Implement (Fresh Session with Plan Only)

Start a new session with only the high-density plan as context
Agent has clean, focused attention on execution
No noise from research phase

Agent offers 3 options:

"I want a template for the PLAN.md format"
- Agent provides structured template for high-density plans
"I want to see an example of this cycle in action"
- Agent walks through concrete PM use case (e.g., discovery planning)
"I'm ready to implement this in my workflow"
- Agent provides step-by-step implementation guide

User response: [Selection]

Agent provides: Tailored guidance based on selection.

Agent会询问：

现在我们来落地Research→Plan→Reset→Implement循环，防止上下文腐化。

问题：在Agent调研过程中，上下文窗口会变得混乱——充满无效路径、错误和噪声。这会分散注意力，导致目标偏离。

解决方案：将调研内容压缩为高密度规划文档，然后在落地前清空上下文窗口。

四阶段循环：

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

Agent从多个来源收集数据
上下文窗口变大且杂乱（这是正常的）
累积无效路径、失败假设和噪声
目标：全面收集信息

阶段2：Plan（规划）（整合）

Agent将调研内容整合为高密度的SPEC.md或PLAN.md文档
这成为落地阶段的唯一可信来源
核心元素：
- 已做出的决策
- 支持决策的证据
- 应用的约束
- 后续步骤（按顺序排列）
格式：结构化、简洁、明确

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

关键步骤：清空整个上下文窗口
删除所有调研工件、无效路径、错误内容
防止上下文腐化影响落地阶段

阶段4：Implement（落地）（仅以规划文档为上下文开启新会话）

开启新会话，仅以高密度规划文档作为上下文
Agent拥有清晰、聚焦的注意力用于执行
没有调研阶段的噪声干扰

Agent提供3个选项：

“我想要PLAN.md格式的模板”
- Agent提供结构化的高密度规划文档模板
“我想看看这个循环的实际应用示例”
- Agent带你走完一个具体的PM用例（例如，需求探索规划）
“我准备在工作流中落地这个循环”
- Agent提供分步落地指南

用户回复： [选择]

Agent提供： 根据选择提供定制化指导。

Step 9: Action Plan & Next Steps

步骤9：行动计划与后续步骤

Agent synthesizes:

Based on your context engineering assessment, here's your action plan:

Immediate Fixes (This Week):

[Delete context with no falsifiable failure mode from Q4]
[Apply Research→Plan→Reset→Implement to your next AI task]
[Document context boundary in Context Manifest]

Foundation Building (Next 2 Weeks):

[Build constraints registry with 20+ entries]
[Create operational glossary with 20-30 key terms]
[Implement two-layer memory architecture]

Long-Term Optimization (Next Month):

[Set up semantic retrieval for episodic context]
[Assign context boundary owner + quarterly audit schedule]
[Implement Contextual Retrieval (Anthropic) for RAG]

Success Metrics:

Token usage down 50%+ (less context stuffing)
Output consistency up (less retry/regeneration)
Response quality up (sharper, less hedged answers)
Context window stable (no unbounded growth)

Agent offers:

Would you like me to:

Generate specific implementation docs (Context Manifest, PLAN.md template, etc.)?
Provide advanced techniques (Contextual Retrieval, LLM-powered ETL)?
Review your current context setup (provide feedback on specific prompts/workflows)?

Agent会整合：

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

立即修复（本周内）：

[删除步骤4中未通过证伪测试的上下文]
[将Research→Plan→Reset→Implement循环应用到你的下一个AI任务]
[在上下文清单中记录上下文边界]

基础架构搭建（未来2周）：

[构建包含20+条目的约束注册表]
[创建包含20-30个关键术语的操作术语表]
[落地双层内存架构]

长期优化（未来1个月）：

[为情景化上下文设置语义检索]
[指定上下文边界负责人 + 每季度审计计划]
[为RAG落地Contextual Retrieval（Anthropic）]

成功指标：

Token使用量下降50%以上（减少上下文填充）
输出一致性提升（减少重试/重新生成）
回复质量提升（更清晰、更少模棱两可的答案）
上下文窗口稳定（无无限制增长）

Agent提供选项：

你希望我：

生成具体的落地文档（上下文清单、PLAN.md模板等）？
提供高级技术（Contextual Retrieval、LLM驱动的ETL）？
评审你当前的上下文设置（对特定提示词/工作流提供反馈）？

Examples

示例

Example 1: Solo PM Context Stuffing → Engineering

示例1：独立PM从上下文填充转向上下文工程

Context:

Solo PM at early-stage startup
Using Claude Projects for PRD writing
Pasting entire PRDs (20 pages) + all user interviews (50 transcripts) every time
Getting vague, inconsistent responses

Assessment:

Symptoms: Hedged responses, normalized retries (4+ symptoms)
Q1 (Decision): "I just want AI to understand my product" (no specific decision)
Q2 (Persist/Retrieve): Persisting everything (no retrieval strategy)
Q3 (Ownership): No formal owner (solo PM, ad-hoc)
Q4 (Failure): Can't identify concrete failures for most context
Q5 (Structure): Avoiding constraint documentation

Diagnosis: Active Context Hoarding Disorder

Intervention:

Immediate: Delete all context that fails Q4 test → keeps 20% of original
Week 1: Build constraints registry (10 technical constraints, 5 strategic)
Week 2: Create operational glossary (25 terms)
Week 3: Implement Research→Plan→Reset→Implement for next PRD

Outcome: Token usage down 70%, output quality up significantly, responses crisp and actionable.

背景：

早期创业公司的独立PM
使用Claude Projects撰写PRD
每次都粘贴完整PRD（20页）+ 所有用户访谈记录（50份）
得到模糊、不一致的回复

评估：

症状：模棱两可的回复、重试常态化（4个及以上症状）
问题1（决策）：“我只是想让AI了解我的产品”（无具体决策）
问题2（持久化/检索）：持久化所有内容（无检索策略）
问题3（所有权）：无正式负责人（独立PM，临时决策）
问题4（故障）：无法为大部分上下文识别具体故障
问题5（结构）：逃避约束文档化

诊断： 已出现上下文囤积症

干预措施：

立即执行：删除所有未通过问题4测试的上下文 → 仅保留原内容的20%
第1周：构建约束注册表（10条技术约束、5条战略约束）
第2周：创建操作术语表（25个术语）
第3周：为下一份PRD落地Research→Plan→Reset→Implement循环

结果： Token使用量下降70%，输出质量显著提升，回复清晰且可落地。

Example 2: Growth-Stage Team with Agent Chains

示例2：成长期团队的Agent链优化

Context:

Product team with 5 PMs
Custom AI agents for discovery synthesis
Agent A (research) → Agent B (synthesis) → Agent C (recommendations)
Each agent passes full context to next → context window explodes to 100k+ tokens

Assessment:

Symptoms: Escalating token costs, inconsistent outputs (3 symptoms)
Q1 (Decision): Each agent has clear decision, but passes unnecessary context
Q2 (Persist/Retrieve): Mixing persistent and episodic without strategy
Q3 (Ownership): No explicit owner; each PM adds context
Q4 (Failure): Agents pass "just in case" context with no falsifiable failure
Q5 (Structure): Missing Context Manifest

Diagnosis: Agent orchestration without boundaries

Intervention:

Immediate: Define bounded context per agent (Agent A outputs only 2-page synthesis to Agent B, not full research)
Week 1: Assign context boundary owner (Lead PM)
Week 2: Create Context Manifest (what persists, what's retrieved, what's excluded)
Week 3: Implement Research→Plan→Reset→Implement between Agent B and Agent C

Outcome: Token usage down 60%, agent chain reliability up, costs reduced by 50%.

背景：

拥有5名PM的产品团队
使用自定义AI Agent进行需求探索整合
Agent A（调研）→ Agent B（整合）→ Agent C（建议）
每个Agent都将完整上下文传递给下一个 → 上下文窗口膨胀至100k+ token

评估：

症状：Token成本攀升、输出结果不一致（3个症状）
问题1（决策）：每个Agent都有明确决策，但传递了不必要的上下文
问题2（持久化/检索）：混合持久化和情景化内容，无策略
问题3（所有权）：无明确负责人；每个PM都添加上下文
问题4（故障）：Agent传递“以防万一”的上下文，无具体可证伪故障
问题5（结构）：缺少上下文清单

诊断： 无边界的Agent编排

干预措施：

立即执行：为每个Agent定义有限上下文（Agent A仅向Agent B输出2页整合内容，而非完整调研数据）
第1周：指定上下文边界负责人（首席PM）
第2周：创建上下文清单（明确持久化、检索、排除的内容）
第3周：在Agent B和Agent C之间落地Research→Plan→Reset→Implement循环

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

Example 3: Enterprise with RAG but No Context Engineering

示例3：已落地RAG但缺乏上下文工程的企业

Context:

Large enterprise with vector database RAG system
"Stuff the whole knowledge base" approach (10,000+ documents)
Retrieval returns 50+ chunks per query → floods context window
Accuracy declining as knowledge base grows

Assessment:

Symptoms: Vague responses despite "complete knowledge," normalized retries (2 symptoms)
Q1 (Decision): Decisions clear, but retrieval has no intent (returns everything)
Q2 (Persist/Retrieve): Good instinct to retrieve, but no filtering
Q3 (Ownership): Engineering owns RAG, Product doesn't own context boundaries
Q4 (Failure): Can't identify why 50 chunks needed vs. 5
Q5 (Structure): Knowledge base has no structure (flat documents, no metadata)

Diagnosis: Retrieval without intent (RAG as context stuffing)

Intervention:

Immediate: Limit retrieval to top 5 chunks per query (down from 50)
Week 1: Implement Contextual Retrieval (Anthropic) — prepend explanatory context to each chunk during indexing
Week 2: Add metadata to documents (category, recency, authority)
Week 3: Product team defines retrieval intent per query type (discovery = customer insights, feasibility = technical constraints)

Outcome: Accuracy up 35% (from Anthropic benchmark), latency down 60%, token usage down 80%.

背景：

大型企业，拥有向量数据库RAG系统
“填充整个知识库”的方法（10,000+文档）
每次检索返回50+片段 → 填满上下文窗口
随着知识库扩大，准确率下降

评估：

症状：尽管“知识完整”但回复模糊、重试常态化（2个症状）
问题1（决策）：决策明确，但检索无目的性（返回所有内容）
问题2（持久化/检索）：有检索的思路，但无过滤机制
问题3（所有权）：工程团队负责RAG，产品团队不负责上下文边界
问题4（故障）：无法说明为什么需要50个片段而非5个
问题5（结构）：知识库无结构（扁平文档，无元数据）

诊断： 无目的性的检索（RAG沦为上下文填充）

干预措施：

立即执行：将每次检索的片段数量限制为前5个（从50个减少）
第1周：落地Contextual Retrieval（Anthropic）—— 在索引前为每个片段添加解释性上下文
第2周：为文档添加元数据（类别、时效性、权威性）
第3周：产品团队为每种查询类型定义检索意图（需求探索=客户洞察，可行性=技术约束）

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

Common Pitfalls

常见陷阱

1. "Infinite Context" Marketing vs. Engineering Reality

1. “无限上下文”营销话术 vs 工程现实

Failure Mode: Believing "1 million token context windows" means you should use all of them.

Consequence: Reasoning Noise degrades performance; accuracy drops below 20% past ~32k tokens.

Fix: Context windows are not free. Treat tokens as scarce; optimize for density, not volume.

故障模式： 认为“100万token上下文窗口”意味着你应该用完所有token。

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

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

2. Retrying Instead of Restructuring

2. 重试而非重构

Failure Mode: "It works if I run it 3 times" → normalizing retries instead of fixing structure.

Consequence: Wastes time and money; masks deeper context rot issues.

Fix: If retries are common, your context structure is broken. Apply Q5 (fix structure, don't add volume).

故障模式： “运行3次就能正常工作” → 重试常态化，而非修复结构问题。

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

解决方案： 如果重试频繁，说明你的上下文结构存在问题。应用问题5的测试（修复结构，不要增加数量）。

3. No Context Boundary Owner

3. 无上下文边界负责人

Failure Mode: Ad-hoc, implicit context decisions → unbounded growth.

Consequence: Six months later, every query stuffs 100k tokens per interaction.

Fix: Assign explicit ownership; create Context Manifest; schedule quarterly audits.

故障模式： 临时、隐性的上下文决策 → 无限制增长。

后果： 六个月后，每次交互都会填充100k+ token。

解决方案： 指定明确的负责人；创建上下文清单；安排每季度审计。

4. Mixing Always-Needed with Episodic

4. 混合始终需要与情景化内容

Failure Mode: Persisting historical data that should be retrieved on-demand.

Consequence: Context window crowded with irrelevant information; attention diluted.

Fix: Apply Q2 test: persist only what's needed in 80%+ of interactions; retrieve the rest.

故障模式： 持久化应按需检索的历史数据。

后果： 上下文窗口被无关信息填满；注意力分散。

解决方案： 应用问题2的测试：仅持久化80%以上交互需要的内容；其余内容按需检索。

5. Skipping the Reset Phase

5. 跳过重置阶段

Failure Mode: Never clearing context window during Research→Plan→Implement cycle.

Consequence: Context rot accumulates; goal drift; dead ends poison implementation.

Fix: Mandatory Reset phase after Plan; start implementation with only high-density plan as context.

故障模式： 在Research→Plan→Reset→Implement循环中从不清空上下文窗口。

后果： 上下文腐化累积；目标偏离；无效路径影响落地阶段。

解决方案： 在规划阶段后强制执行重置阶段；仅以高密度规划文档作为落地阶段的上下文。

References

参考资料

Related Skills

External Frameworks

外部框架

Dean Peters — Context Stuffing Is Not Context Engineering (Dean Peters' Substack, 2026)
Teresa Torres — Continuous Discovery Habits (Context Engineering as one of 5 new AI PM disciplines)
Marty Cagan — Empowered (Feasibility risk in AI era includes understanding "physics of AI")
Anthropic — Contextual Retrieval whitepaper (35% failure rate reduction)
Google — Context engineering whitepaper on LLM-powered memory systems

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白皮书（降低35%的故障率）
Google —— 关于LLM驱动的内存系统的上下文工程白皮书

Technical References

技术参考

RAG (Retrieval-Augmented Generation) — Standard technique for episodic context retrieval
Vector Databases — Semantic search for long-term memory (Pinecone, Weaviate, Chroma)
Contextual Retrieval (Anthropic) — Prepend explanatory context to chunks before embedding
LLM-as-Judge — Automated evaluation of context quality

RAG（Retrieval-Augmented Generation） —— 情景上下文检索的标准技术
Vector Databases（向量数据库） —— 长期内存的语义搜索（Pinecone、Weaviate、Chroma）
Contextual Retrieval（Anthropic） —— 在嵌入前为每个片段添加解释性上下文
LLM-as-Judge —— 上下文质量的自动化评估