把每项事实放进正确的上下文
上下文是暂时的注意力，知识是持续维护的证据，记忆负责延续，缓存负责复用。混在一起，就会产生自信却过时的答案。
类型： Learn 语言： Python 前置要求： 把请求变成可测试的合约、上下文工程预计时间： 约 105 分钟
学习目标
- 区分聊天上下文、Project 指令、Project 知识、记忆、连接器、检索和 API prompt 缓存。
- 判断哪些内容应持久保存、检索、总结、刷新或丢弃。
- 建立包含权威性、负责人、敏感度和新鲜度元数据的来源登记表。
- 在不删除必需证据的前提下减轻上下文过载。
- 说明哪些 Claude 产品行为可能变化，必须在当前文档中核验。
问题所在
某团队为季度规划创建了一个 Claude Project。他们上传政策文件、会议记录、销售导出数据和一份旧产品路线图，还添加了一条 Project 指令：“使用最新获批计划。”
三个月后，Claude 根据旧路线图推荐了发布日期。这个日期存在于 Project 知识中，也出现在多份历史会议记录里，却与连接器中保存的较新决策冲突。由于上下文反复提供错误答案的证据，回复听起来非常确定。
团队把它称作幻觉。这其实是知识管理失败：他们把 Project 当成文档仓库，把记忆当成权威来源，还把检索当成事实保证。
增加上下文不会自动改善结果。可信系统知道哪些事实只是临时信息、哪些具有权威性，以及谁负责让它们保持最新。
核心概念
七种机制，七种职责
Claude 可以通过多种机制接收或复用信息。确切可用性、限制和名称可能随套餐和产品变化，长期有效的区别在于各自职责。
| 机制 | 主要职责 | 主要风险 |
|---|---|---|
| 当前聊天上下文 | 承载当前对话 | 旧轮次占用注意力或产生冲突 |
| Project 指令 | 设置可复用行为和约束 | 宽泛指令变得过时或含糊 |
| Project 知识 | 提供一组持续维护的参考资料 | 文件缺少负责人或新鲜度控制 |
| 记忆 | 跨对话保留有用的延续信息 | 把记住的偏好错当成获批事实 |
| 连接器 | 在当前权限下访问外部系统 | 误解来源权限、同步状态或新鲜度 |
| 检索 | 从大型语料库中选择相关片段 | 看似相关的文本不完整或权威性低 |
| Prompt 缓存 | 高效复用稳定的 API prompt 前缀 | 缓存动态内容或忽略失效机制 |
一项功能可以承担多种职责，但区分职责能避免类别错误。记忆可以提醒 Claude 你偏好简洁报告，却不应悄悄成为当前退款政策的来源。连接器可以暴露最新文件，却不能证明该文件已经获批。
上下文有注意力预算
更大的上下文窗口只提高容量，不能保证结果更确定。每增加一份文档，都会加剧注意力竞争，也多一次产生矛盾的机会。
可以把上下文分成四层：
context package = governing instructions
+ task-specific input
+ retrieved authoritative evidence
+ minimal continuity让稳定指令保持稳定。只添加当前决策必需的任务输入。使用元数据和权威规则检索证据。只有先前对话会改变当前任务时，才继续携带它。
长对话往往会积累已经放弃的计划、纠正过的事实和格式实验。与其无限延续，不如用一份经过核验的简报重新开始，这通常更安全。只有把决策与讨论分开后，才能做总结。
检索负责选择，验证另行处理
检索系统通常按相关性对片段排序。相关性无法回答：
- 这个来源获批了吗？
- 它是最新的吗？
- 它覆盖整条规则，还是只截取了一部分？
- 是否有权威性更高的来源与之冲突？
- 当前用户可以访问该来源吗？
为每个来源添加元数据，并在语义相关性排序之前或同时执行过滤。最小登记表包括：
| 字段 | 问题 |
|---|---|
| 来源 ID | 主张能否追溯到它？ |
| 负责人 | 谁对准确性负责？ |
| 权威性 | 它是政策、流程、笔记还是草稿？ |
| 生效日期 | 它从何时开始有效？ |
| 复核日期 | 何时必须再次检查？ |
| 敏感度 | 谁可以处理或查看？ |
| 取代对象 | 哪个早期来源不再具有权威性？ |
| 检索标签 | 它覆盖哪些任务和地区？ |
没有负责人或复核日期的文档，应先隔离，不能自动摄取。
指令与知识各有职责
指令描述行为，知识提供证据。
指令可以这样写：
For refund questions, cite the governing section and expose regional conflicts.知识中则应包含实际获批的退款政策。把政策正文塞进行为指令会增加维护难度；把行为规则藏在任意知识文件中，则容易被忽略。
Project 指令与用户请求或提供的来源冲突时，解决方式取决于产品的指令层级和组织政策。不要凭空发明层级。应测试实际载体，并记录预期优先级。
记忆用于延续上下文
记忆适合保存稳定偏好和持续上下文，例如偏好的语气、长期目标，或某个项目确实存在。把记住的主张当成当前运营事实时，它就会变得危险。
依赖记忆前先问三个问题：
- 这项事实可能已经变化吗？
- 是否有核验成本很低的权威来源？
- 如果记忆中的事实错误，后果是什么？
如果有漂移可能，而且后果重要，就应核验。在工作流中标注来自记忆的上下文，并保留指向实际记录来源的引用。
Prompt 缓存是一种经济机制
API prompt 缓存可以减少对稳定前缀的重复处理。它不会提高真实性，也不会创造长期记忆。
如果当前 API 的缓存行为支持这种模式，应把可复用内容放在动态内容之前：
stable prefix: system rules + tool definitions + approved reference corpus
dynamic suffix: user request + fresh retrieval + current state适合缓存的内容体积大、重复出现且保持稳定。不合适的内容每个请求都变化，或包含不应超出获批边界持久保存的数据。
缓存生命周期、最小大小、价格、模型支持和失效行为都属于可能变化的产品事实，应在当前官方文档中核验。系统正确性不能依赖过时缓存。
上下文质量需要生命周期负责人
知识有自己的生命周期：
flowchart LR
A["Source created"] --> B["Classified and approved"]
B --> C["Indexed or uploaded"]
C --> D["Retrieved for a task"]
D --> E["Claims validated"]
E --> F["Reviewed on schedule"]
F -->|"still valid"| C
F -->|"superseded"| G["Archived and removed from active retrieval"]难点在批准、刷新和退役。
动手构建
第 1 步：盘点上下文
为一项重复工作流列出每个信息来源，并进行分类：
Behavioral instruction:
Task input:
Authoritative knowledge:
Reference knowledge:
Conversation continuity:
External connected data:
Temporary calculation:如果同一项内容出现在多个类别中，应决定哪个副本具有权威性，以及如何移除重复项。
第 2 步：创建来源登记表
为每个来源建立简单表格或 JSON 记录：
{
"source_id": "refund-policy-uk",
"owner": "customer-operations",
"authority": "approved-policy",
"effective_date": "2026-07-01",
"review_date": "2026-10-01",
"sensitivity": "internal",
"supersedes": "refund-policy-uk-2025"
}这些日期仅作说明，请使用实际记录。拒绝或标记复核日期已经过期的来源。
第 3 步：设计带弃答机制的检索
定义检索合约：
- 按用户权限、地区、产品和启用状态过滤。
- 获批政策优先于讨论笔记。
- 检索足够的周边文本，以保留例外情况。
- 随片段返回来源 ID 和生效日期。
- 缺少必需权威来源时弃答。
- 暴露冲突，而不是暗中合并。
测试正常案例、过时来源、权限不匹配、来源冲突和超出范围的问题。
第 4 步：分配 prompt 预算
测量或估算每个上下文部分。如果 prompt 过载，按以下顺序削减：
- 移除重复和已被取代的材料。
- 排除无关对话轮次。
- 检索范围更窄、但保留足够周边上下文的权威章节。
- 用经过核验的决策记录替代讨论历史。
- 在验证边界拆分任务。
不要一开始就删除安全约束或必需证据。
第 5 步：建立维护机制
指定负责人和节奏：
| 资产 | 负责人 | 复核触发条件 | 退役规则 |
|---|---|---|---|
| Project 指令 | 工作流负责人 | 流程变化 | 替换旧版本 |
| 政策知识 | 政策负责人 | 批准或复核日期 | 移除已被取代的副本 |
| 检索索引 | 平台负责人 | 来源更新 | 重新索引并核验 |
| 评估集 | 质量负责人 | 出现新失败类别 | 添加代表性案例 |
知识管理需要纳入产品设计，不能留到上线后再清理。
交互实验
使用上下文缓存图调整稳定前缀大小、请求量、缓存命中率、来源新鲜度和失效行为。比较节省的成本与正确性边界：只有复用前缀仍获批准时，缓存命中才有价值。
04-context-cache实践实验
运行上下文规划器。尝试缓存动态账号来源、在未重新批准时启用已被取代的政策，或让内容超出 prompt 预算。运行器必须把正确性和生命周期规则放在缓存收益之前。
交付产物
outputs/context-registry.json 是填写完成的退款工作流来源登记表。它区分行为指令、获批政策、已被取代的草稿、对话延续信息和动态连接数据，还包含 prompt 预算与明确的缓存政策。
验证
验证登记表：
cd certifications/claude/lessons/04-context-knowledge-memory-and-caching/code
python3 main.py
python3 -m unittest discover tests -v验证器会检查来源 ID 是否唯一、日期是否为 ISO 格式、负责人、权威性、启用与取代状态、预算总额，以及只有稳定且不含秘密的来源才能进入缓存前缀。
综合项目关联
测验会检查来源权威性、检索限制、缓存适配度和上下文重置决策。把登记表与缓存政策用于第 29 至 32 课的综合项目，作为来源追踪和上下文预算产物。
上手使用
考试决策模式
场景涉及重复工作、过时答案或上下文缺失时：
- 判断缺失项属于行为、证据、延续信息还是外部数据。
- 把它放进为该职责设计的机制。
- 加入权威性、新鲜度、敏感度和负责人控制。
- 测试检索与权限失败。
- 只有建立正确性后才使用缓存。
常见坑
- 上传所有内容： 数据量会增加矛盾和维护成本。
- 把记忆当事实： 把延续信息错当成记录来源。
- 把连接器当批准： 把文件访问能力错当成权威性。
- 把检索当证明： 没有检查来源和完整性，就接受相关片段。
- 一个永不结束的聊天： 已纠正和已放弃的上下文仍然有效。
- 把缓存当记忆： 误以为 API 优化会保存长期用户状态。
- 没有退役路径： 已被取代的文件永远可以被检索。
练习
- 把真实工作流中的十项内容分到七种机制中。
- 为五个来源创建登记表，并找出哪些不应进入主动检索。
- 使用四层上下文结构重写一个过载的 prompt。
- 设计五个检索失败测试，包括过时证据和未授权访问。
- 决定项目一周结束时应持久保存、总结或丢弃哪些内容，并逐项解释。
关键术语
- 上下文： 当前请求中模型可以使用的信息。
- Project 指令： 与 Claude Project 关联的可复用行为指导。
- Project 知识： 与 Project 关联的参考资料。
- 记忆： 产品支持的跨对话延续信息，具体取决于当前功能行为。
- 连接器： 在配置权限下提供外部数据或能力的集成。
- 检索： 为请求从大型语料库中选择相关材料。
- Prompt 缓存： 复用符合条件的 prompt 内容，减少 API 重复处理。
- 记录来源： 某项事实所依据的权威系统或文档。
- 新鲜度： 信息对预期用途而言是否足够新。
延伸阅读
- Anthropic 帮助中心：Projects 是什么？
- Anthropic 帮助中心：使用 Claude 的聊天搜索和记忆延续先前上下文
- Anthropic 帮助中心：用连接器扩展 Claude 的能力
- Anthropic：Prompt 缓存
- AI Engineering from Scratch：检索增强生成
- AI Engineering from Scratch：仓库记忆与状态
Projects、记忆、连接器、检索模式和 prompt 缓存的名称、可用性、限制、保留行为与价格都可能变化。这些来源于 2026-08-08 核验。部署或备考前，请核对当前官方产品与隐私文档。