Claude 5改写上下文工程

Anthropic 近日发布面向 Claude 5 一代模型的上下文工程指南，把 AI 应用开发的重点从“如何写出一句完美提示词”，转向“如何让模型在正确时间拿到正确的信息”。这不是换了一个更时髦的名词，而是智能体、Claude Code 与长任务应用进入生产环境后，开发方法必须发生的一次升级。

**上下文工程是对模型输入信息、工具、记忆与加载顺序进行系统设计的工程方法。**提示词只是其中一层；项目规则、代码结构、历史记录、检索结果、工具定义、执行状态、示例和验证反馈，都属于上下文。

Anthropic 这次释放出的核心信号很明确：Claude 5 一代模型不再需要开发者反复强调同一条规则，但更依赖清晰的接口、合理的信息结构和可控的披露时机。换句话说，模型变强以后，低水平的提示词技巧价值下降了，系统设计能力反而更重要。

提示词没有消失，但它不再是主角

**提示词工程是通过调整指令措辞、结构和示例，引导模型生成目标结果的方法。**这种方法适合单轮问答、内容改写和边界清晰的小任务，因为开发者可以一次性把大部分要求写进输入框。

**智能体任务的问题在于，真正影响结果的信息通常无法一次写完。**一个负责修复代码缺陷的 Claude Code 会接触仓库目录、依赖版本、测试日志、Git 历史和团队规范；一个客服智能体则要读取用户身份、订单状态、退款政策和过去的沟通记录。此时，继续优化某一句提示词，就像试图用一张便签管理整家公司。

提示词工程与上下文工程的差别，可以概括为下面这张表：

| 对比维度 | 提示词工程 | 上下文工程 | |---|---|---| | 核心对象 | 单条或少量指令 | 完整的信息供应系统 | | 主要问题 | 这句话该怎么写 | 模型此刻该看到什么 | | 信息组织 | 常见做法是集中堆入提示词 | 分层存储、按需检索、渐进披露 | | 适用任务 | 单轮生成、简单问答 | 编程智能体、研究任务、复杂工作流 | | 工具角色 | 工具说明通常是附属信息 | 工具名称、参数和返回值都是上下文接口 | | 记忆方式 | 依赖对话历史 | 短期状态、长期记忆与外部知识分层管理 | | 验证方式 | 人工查看最终输出 | 测试、检查器、评分器与重试闭环 | | 主要风险 | 指令表达不清 | 上下文污染、信息过期、权限越界、Token 浪费 |

**Claude 5 时代最需要放弃的想法，是把更多文字等同于更多控制。**上下文窗口再长，也不意味着所有信息都应该提前塞进去；无关内容会争夺模型注意力，过时文档会制造冲突，重复规则还可能让模型误判优先级。

第一条规则：把上下文当作接口，而不是作文

**高质量上下文首先要有明确的信息边界。**开发者应当把长期稳定的项目约束、当前任务目标、可调用工具、动态执行状态和输出要求拆开，而不是写成一篇层层补充的长提示词。

一个实用的上下文结构通常包含五层：

1. 系统约束层：身份、权限、安全边界和不可违反的规则；
2. 项目知识层：架构说明、目录约定、编码风格和业务术语；
3. 任务状态层：当前目标、已完成步骤、失败原因和待办事项；
4. 外部能力层：工具定义、检索入口、文件系统和执行环境；
5. 结果验证层：测试命令、验收条件、评分标准和失败后的处理方式。

**分层的价值在于每类信息拥有不同生命周期。**编码规范可能几个月才变化一次，测试日志却每次执行都会更新；如果两者被混在同一份长文档里，系统既难缓存，也难判断哪些内容已经过期。

第二条规则：渐进披露比一次性灌输更有效

**渐进披露是先向模型提供信息地图，再根据任务进展加载具体内容的上下文策略。**它是这轮 Claude 5 上下文工程规则中最值得开发者重视的关键词。

渐进披露并不等于让模型盲目探索，而是先给它足够的导航信息。例如，Claude Code 启动时只需要知道项目由前端、服务端和数据库迁移三部分组成；当任务只涉及登录页面时，再读取对应组件、设计规范和测试文件，不必同时加载支付模块的全部实现。

一个适合 AI 编程项目的文件结构可以是：

project/
├── CLAUDE.md             # 全局规则、常用命令与架构入口
├── docs/
│   ├── architecture.md   # 系统边界与模块关系
│   ├── conventions.md    # 编码、测试和提交规范
│   └── decisions/        # 关键架构决策记录
├── tasks/
│   ├── current.md        # 当前任务与验收条件
│   └── completed/        # 已完成任务摘要
├── examples/
│   ├── preferred/        # 推荐实现
│   └── anti-patterns/    # 明确禁止的实现
└── src/                  # 业务代码

**文件树本身就是一种低成本的上下文索引。**模型先看到文件名和简短说明，就能决定下一步读取什么；只有被选中的文档才进入高成本上下文，从而减少无关信息对推理的干扰。

开发者可以把这个过程理解为查地图。出发前需要知道城市、道路和目的地，但没有必要把沿途每家商店的菜单全部背下来。

第三条规则：示例要有代表性，而不是越多越好

**示例学习是通过输入目标任务的参考样本，让模型模仿其模式和约束的方法。**过去常见的做法是堆叠大量 few-shot 示例，希望用数量压住模型的不确定性；面对能力更强的模型，这种方法的边际收益正在下降。

**Claude 5 一代更适合少量、高区分度的示例。**一个正确示例负责说明理想路径，一个边界示例负责展示特殊情况，一个反例负责指出不能做什么，通常比十几个高度相似的样本更有信息密度。

示例还必须与规则保持一致。项目文档要求使用异步接口，但参考代码仍是同步实现，模型很可能同时吸收两套相互冲突的模式；这类上下文污染比缺少示例更危险，因为问题看起来像模型不稳定，根源却是输入系统自相矛盾。

第四条规则：工具定义也是产品接口

**工具调用是模型根据结构化描述选择外部能力并提交参数的过程。**模型不会像人类工程师一样自行理解一个模糊命名的内部服务，它看到的工具名称、参数描述、返回字段和错误信息，就是完整的操作界面。

**糟糕的工具设计无法靠系统提示词彻底补救。**如果同时存在 search、find 和 lookup 三个用途重叠的工具，模型就要额外猜测边界；如果工具返回几百行未经筛选的日志，真正有用的错误原因会被埋在噪声里。

更稳妥的工具设计应满足四个条件：

• 名称直接表达动作与对象，避免抽象缩写；
• 参数数量尽量少，并清楚标注必填项和允许范围；
• 返回值优先提供摘要、状态和下一步线索；
• 错误信息说明失败原因，以及模型是否应该重试。

**工具数量同样需要控制。**一次暴露几十个相似工具，表面上增加了能力，实际上增加了路由成本；更合理的做法是按任务阶段或角色加载工具组，让模型只看到当前可能使用的能力。

第五条规则：记忆必须分层，并允许遗忘

**智能体记忆是保存任务状态、用户偏好和历史经验，以供后续推理调用的机制。**记忆不是把全部对话永久追加到上下文，也不是把每次输出原样写进向量数据库。

一个生产级记忆系统至少应区分三类内容：

| 记忆层 | 保存内容 | 建议生命周期 | 加载方式 | |---|---|---|---| | 工作记忆 | 当前目标、临时变量、执行进度 | 单次任务 | 默认加载 | | 情节记忆 | 某次任务的决策、失败和结果 | 数天至数月 | 按事件检索 | | 语义记忆 | 稳定事实、用户偏好、组织知识 | 长期保存并定期更新 | 按相关性检索 |

**遗忘机制是上下文工程的一部分。**过期价格、旧版接口和已撤销的用户偏好如果持续进入上下文，会让模型稳定地产生错误；因此每条长期记忆最好具有来源、更新时间、可信度和失效条件。

第六条规则：上下文预算要按价值分配

**上下文预算是一次模型调用中可用于指令、知识、历史、工具结果和输出的 Token 配额。**窗口上限只是硬件条件，真正的工程问题是如何把预算分配给最有价值的信息。

假设某个应用为一次任务规划了 100,000 Token，这只是便于说明的工程示例，并非 Claude 5 的官方窗口参数。开发者可以将 10,000 Token 留给稳定规则，35,000 Token 分配给检索文档，20,000 Token 用于近期操作历史，15,000 Token 用于工具返回，并预留 20,000 Token 给模型推理与输出。

**预留输出空间能够避免任务在最后阶段被截断。**很多长任务并不是败在检索不足，而是前期加载了太多仓库内容，导致模型在生成补丁、测试说明或最终报告时没有足够余量。

上下文预算还应结合四个指标动态调整：

• 相关率：已加载内容中，真正被任务使用的信息占比；
• 命中率：完成任务所需关键信息被成功加载的比例；
• 新鲜度：上下文与当前代码、数据和政策的一致程度；
• 单位任务成本：完成一次合格任务消耗的总 Token 与工具调用次数。

第七条规则：验证闭环比重复强调更可靠

验证闭环是让模型执行任务、接受可观察反馈并根据结果继续修正的流程。“不要犯错”“务必确保代码可运行”都属于弱约束；单元测试、类型检查、构建结果和确定性的验收脚本才是强约束。

一个面向 Claude Code 的任务文件，可以使用下面这种结构：

# 当前任务
修复登录状态在页面刷新后丢失的问题。

## 允许修改
- src/auth/
- tests/auth/

## 禁止修改
- 数据库表结构
- 公共接口字段

## 验收条件
- 现有测试全部通过
- 新增刷新场景测试
- 不在浏览器持久化敏感令牌

## 完成后输出
- 根因
- 修改文件
- 测试结果
- 剩余风险

验收条件必须能够被执行或观察。“代码优雅”无法直接验证，“单个函数不超过既定复杂度阈值、类型检查通过、刷新后会话恢复测试通过”则可以进入自动化流程。

社区常用的 PRP 可以视为这套方法的具体实现。**PRP 是把产品需求、精选项目知识、实施步骤与验证条件组合成一份面向智能体的执行蓝图。**它比普通需求描述更接近一份可运行的任务协议，但 PRP 并不是 Anthropic 唯一指定的标准，团队完全可以使用 Issue 模板、设计文档或内部任务系统实现同样的分层结构。

一套可以直接落地的迁移流程

**现有 AI 应用不需要推倒重来，也能从提示词工程迁移到上下文工程。**实际改造可以分为七步：

1. 记录模型每次任务实际收到的全部信息，而不只检查 system prompt；
2. 删除重复、过期和相互冲突的规则；
3. 把稳定知识、动态状态和任务要求拆入不同存储层；
4. 为文档和工具增加简短、可检索的描述；
5. 先加载目录与摘要，再按需要加载正文；
6. 将主观要求改造成测试、检查器或结构化验收项；
7. 用失败案例建立回归集，持续评估上下文变化带来的影响。

**上下文版本必须与模型版本一起记录。**一次任务表现突然下降，原因可能来自模型更新，也可能来自检索排序变化、工具描述修改或某份文档过期；如果系统只记录最终提示词，团队几乎无法复现问题。

建议至少记录以下运行数据：模型名称、上下文模板版本、被加载文件、检索结果标识、工具调用序列、Token 使用量、总延迟、验证结果和人工评分。上下文工程最终会像传统软件工程一样，需要版本控制、测试集、监控和回滚，而不是依赖某位“提示词专家”的个人经验。

三个最常见的反模式

**第一个反模式是把整个知识库一次性塞给模型。**长窗口降低了信息装载门槛，却没有消除注意力竞争；内容越多，检索与排序越需要工程化。

**第二个反模式是把所有失败都归因于模型能力。**当模型反复使用旧接口时，应先检查旧文档是否仍在检索库中；当模型选择错误工具时，应先检查工具边界是否重叠，而不是立即追加一段更强硬的提示词。

**第三个反模式是把社区模板当成万能方案。**CLAUDE.md、INITIAL.md 和 PRP 都是有用的组织形式，但模板中的每一条规则都会消耗注意力；团队应保留真正影响交付质量的约束，而不是复制数百行与项目无关的“最佳实践”。

上下文工程也是安全工程

**上下文安全是防止不可信内容改变系统指令、泄露数据或诱导模型越权操作的防护体系。**当模型能够读取网页、邮件、代码注释和第三方文档时，这些内容既是知识来源，也可能携带提示注入指令。

开发者应明确区分系统规则、可信内部资料和外部不可信内容，并把权限控制放在模型之外。即使上下文中的网页要求模型上传本地配置，底层工具也应因为权限不足而拒绝执行；让模型“记得不要泄露”不能替代真正的访问控制。

Claude 5 时代，真正的壁垒是上下文系统

**Anthropic 的新规则并没有宣判提示词工程死亡，而是把它降级为上下文系统中的一个接口。**对简单任务，清晰提示词仍然有效；对需要数十步操作、多个工具和长期记忆的智能体，决定效果的已经是信息架构、检索策略、工具设计和验证闭环。

**Claude 5 一代模型越强，开发者越不该用冗长规则束缚它。**更好的方法是提供清楚的目标、可靠的环境、恰当的信息入口和可执行的反馈，让模型能够探索，但不能越权；能够犯错，但必须看见错误；能够读取大量信息，但只在需要时读取。

这也是上下文工程比提示词工程更难、同时更有价值的原因：前者不是文字游戏，而是一套真正的软件系统。

参考来源

• Context Engineering Guide：从上下文结构、记忆、检索、工具调用到安全与生产评估的中文开源指南，可作为延伸阅读。
• Anthropic 官方博客《The new rules of context engineering for Claude 5 generation models》：本文讨论的主要事件来源；受文末域名范围要求限制，此处不附站外链接。