当 AI 工作流臃肿、脆弱、难以稳定控制时…

用于诊断 AI 工作流是否在无意图地堆叠上下文，并用结构化上下文、检索和记忆架构提升输出稳定性与成本效率。

适用场景

解决思路

1. 诊断前收集：正在使用的 AI 工具/系统、用 AI 做的 PM 任务、如何提供上下文（粘贴文档、引用文件、项目/记忆）、输出不一致/重试/模糊/成本升高等症状，以及自定义 agent、RAG、向量数据库、记忆系统等架构。
2. 让用户选择上下文填充症状：整篇粘贴文档；有“全部上下文”仍模糊对冲；需重试 3+ 次；token 成本升但准确率不升；不断加更多上下文；agent 之间传递所有内容；没有明确包含/排除标准；若都没有则跳过高阶优化。
3. 识别上下文填充五个标志：反射式扩大上下文窗口；无明确保留标准地持久化一切；无边界地串联 agent；添加评估来掩盖不一致；把“运行 3 次就能用”的重试常态化。
4. 按症状数量判定：0-1 个健康；2-3 个早期上下文填充；4+ 个活跃 Context Hoarding Disorder，需要立即干预。
5. 执行诊断问题 1：对每块上下文问它支持哪个具体决策；要求完成句子：“I need this context because I'm deciding [specific decision], and without [specific information], I can't make that decision.”；若不能完成则不纳入。
6. 若决策是“我只是想让 AI 理解我的产品”：先定义具体决策，再选择上下文，避免上下文填充陷阱。
7. 按场景裁剪上下文：如决定先访谈哪个用户分群，只保留 PRD 中用户分群（2 段）、过往访谈主题综合（1 页），不保留会议笔记、完整竞品分析、完整 PRD；决定访谈问题，只保留研究目标、过往访谈洞察综合、Jobs-to-be-Done 框架，不保留完整竞品分析和会议笔记。
8. 执行诊断问题 2：对每块信息问能否用检索替代持久化；区分 always-needed（核心产品约束、用户偏好、关键定义、不可协商规则）与 episodic（项目细节、历史数据、情境事实、临时决策）。
9. 应用持久化/检索规则：80%+ 交互引用的信息持久化；<20% 交互引用的信息按需检索；20-80% 灰区按检索延迟 vs 上下文窗口成本决定。
10. 若不确定哪些该持久化/检索：对每块上下文应用“排除会失败什么”测试。
11. 执行诊断问题 3：问谁负责定义 AI 上下文边界；若无人负责，边界会无限增长；指派明确所有者并每季度审计。
12. 若个人/小团队拥有边界：记录边界标准，用 1-5 诊断问题作为框架。
13. 若团队共有边界：创建 Context Manifest 文档，定义始终包含、按需检索、明确排除及原因。
14. 创建 Context Manifest：包含 always persisted（产品约束、用户偏好、运营术语表）、retrieved on-demand（历史 PRD、用户访谈记录、竞品分析）、excluded（30 天前会议笔记、完整代码库、营销材料）、boundary owner、last reviewed、next review（+90 天）。
15. 执行诊断问题 4：对每块上下文问排除后会发生什么具体失败；使用 falsification protocol：“If I exclude [context element], then [specific failure] will occur in [specific scenario].”；好例子：排除 GDPR 约束会导致推荐违反 EU 隐私法的功能；坏例子：排除 PRD 可能不完全理解产品；若无法识别具体失败，立即删除该上下文。
16. 执行诊断问题 5：问增加上下文是在解决问题，还是掩盖更深层结构问题；若在补偿模糊文档则先清理文档；未定义术语则建运营术语表；未记录约束则建约束注册表；信息冲突则合并为 Source of Truth。
17. 做结构健康测试：若为补偿模糊文档而加上下文，修复文档而非加更多；若为未定义术语，建立 operational glossary；若为未记录约束，创建 constraints registry；若为冲突信息，协调成 Source of Truth。
18. 根据诊断定义两层记忆架构：短期对话记忆存当前交互历史，用于追问；生命周期单次会话；管理方式为摘要或截断较旧部分以防挤占；长期持久记忆存用户偏好、核心约束、运营术语表；跨会话持久；用向量数据库语义检索实现；分 declarative memory（事实）与 procedural memory（行为模式）。
19. 用 LLM-powered ETL 维护记忆：让模型识别信号、与现有数据合并、自动更新数据库。
20. 为 episodic context 设计检索策略：检索历史 PRD、用户访谈、竞品分析；通过查询意图触发语义搜索；使用 Contextual Retrieval（Anthropic）：嵌入前给每块 chunk 前置解释性上下文；可用 Pinecone、Weaviate、Chroma 等向量数据库；用 LLM-as-Judge 自动评估上下文质量。
21. 实现 Research → Plan → Reset → Implement 周期：Research 阶段允许上下文嘈杂，全面收集数据，接受死胡同和噪音；Plan 阶段将研究综合为高密度 SPEC.md 或 PLAN.md，成为 Source of Truth，包含决策、支持证据、应用的约束、排序后的下一步，格式结构化、简洁、无歧义；Reset 阶段清空整个上下文窗口，删除研究产物、死胡同、错误；Implement 阶段新会话只使用高密度计划作为上下文，干净聚焦执行。
22. 制定行动计划的立即修复（本周）：删除 Q4 中无法给出可证伪失败模式的上下文；对下一个 AI 任务应用 Research→Plan→Reset→Implement；在 Context Manifest 中记录上下文边界。
23. 基础建设（接下来 2 周）：建立 constraints registry，至少 20 条；创建 operational glossary，20-30 个关键术语；实现两层记忆架构。
24. 长期优化（下个月）：为 episodic context 建立语义检索；指派上下文边界所有者并设定每季度审计；为 RAG 实现 Contextual Retrieval (Anthropic)。
25. 用成功指标验证：token 使用量下降 50%+；输出一致性提高（重试/重新生成减少）；响应质量提高（更锐利、更少对冲）；上下文窗口稳定（无边界增长）。
26. 修复常见陷阱：不要相信“无限上下文”营销；把 token 视为稀缺资源，优化密度而非数量；若经常重试，说明上下文结构坏了，应用 Q5 修复结构；没有边界所有者时指派明确所有者、创建 Context Manifest、安排季度审计；不要混用 always-needed 与 episodic，应用 Q2 测试，只持久化 80%+ 交互需要的信息；不要跳过 Reset 阶段，Plan 后强制清空上下文，仅用高密度计划开始实现。
27. 在处理多 agent 链时，为每个 agent 定义 bounded context：例如 Agent A 只输出 2 页综合给 Agent B，而不是完整研究；在 Agent B 与 Agent C 之间实施 Research→Plan→Reset→Implement。
28. 对 RAG 系统：限制每次查询检索 top 5 chunks（从 50 降低）；在索引时给每个 chunk 前置解释性上下文（Contextual Retrieval）；给文档增加 metadata（category、recency、authority）；按查询类型定义检索意图（discovery = customer insights，feasibility = technical constraints）。
29. 使用 RAG 时，可用 25% 可用 token 保持 95% 准确率，同时降低延迟和成本；用 Efficiency = (Accuracy × Coherence) / (Tokens × Latency) 评估上下文效率。
30. 遵循五项原则：没有形状的上下文会变成噪音；结构 > 数量；按意图检索而非追求完整；保持小工作上下文；做上下文压缩以提高每 token 的相关信息密度。
31. 控制上下文长度：上下文超过约 32k tokens 时准确率可能降到 20% 以下；优先密度而非体积。
32. 若运行此交互技能，使用 workshop-facilitation 作为默认交互协议：session heads-up + 入口模式（Guided、Context dump、Best guess）；一次一个问题，用平实语言提示；进度标签（如 Context Qx/8 和 Scoring Qx/5）；中断处理与暂停/恢复；决策点用编号建议；常规问题用编号快速选择（有用时包含 Other (specify)）；若冲突，以本文件领域逻辑为准。

适用边界 · 注意事项

• 刚接触 AI 时：先练习基础提示，不要直接做复杂上下文架构。
• 需要 AI 工具选型或提示词写作建议时：本经验关注信息架构与系统设计，不解决 Claude/ChatGPT 选择或文案写作。
• 现有 AI 使用已稳定高效时：如果没坏就不要改。