当我们给 Agent 发消息时当前这一次输入的 Prompt只占模型实际读到的上下文中的很小一部分。系统提示词、Skills、CLAUDE.md文件、记忆机制以及运行时加载的各种信息共同构成了模型做判断时的依据。而围绕这部分内容的设计工作Anthropic 将其称为 Context Engineering。上下文工程和写 Prompt 有一个结构性差异那就是 Prompt 面向单次任务而上下文会被大量请求反复使用。要复用就意味着上下文不能写得太具体不然在下一个任务中它会变成噪音甚至干扰。于是问题变成了——在不知道用户接下来会提什么需求的前提下这些通用的指导性信息应该怎么写Anthropic 上周给出了他们的答案。在 Claude 的新一代模型 Claude Opus 5、Claude Fable 5 中Anthropic 删除了 Claude Code 中 80% 以上的提示词而在代码评测上并没有观察到明显的性能下降。这说明过去需要通过大量提示词规则约束模型的部分工作现在可以更多交给模型结合上下文来判断了。约束的代价过去 Claude Code 的上下文分散在系统提示词、CLAUDE.md和各个 Skill 中不同来源的信息会同时影响模型判断。​一个任务中模型可能要同时处理多条来自不同位置的约束适当补充文档不要添加代码注释不要创建额外的规划、决策或分析文件单看每一条规则它们都有存在的合理性。但约束规则的来源和层级不同组合在一起后就容易产生冲突这时候就需要模型在这些冲突中选择执行哪些规则。这些规则在旧模型阶段确实有用。它们能很好地避免模型随意修改文件、删除内容严格的约束能够降低错误率。这种牺牲一部分灵活性的取舍在当时是合理的。但随着模型判断能力的提升同样的约束开始产生负收益。现在的模型已经能够从代码环境、用户目标和项目已有习惯中判断应该如何处理任务过于硬性的规则反而限制了它做出更恰当选择的空间。举个例子过去约束条件可能是“默认不要写注释不要创建多段文档不要生成规划文件”。现在更合适的写法是“编写符合当前代码风格的代码包括注释密度、命名方式和已有的代码习惯”。前者规定了具体行为后者提供了目标和判断依据。两者的区别不在措辞而在于决策方式发生了变化。上下文工程的六个变化​从规则堆叠到模型判断早期使用 Claude Code 时我们需要告诉模型大量“不要做什么”不要随便删文件不要生成多余文档不要加太多注释。这些规则的作用是兜底防止模型在不确定要做什么的时候乱行动。但这些规则并不总是正确。复杂代码中的长注释可能是必要的某些项目也有自己的文档习惯一刀切的限制反而容易与真实项目需求产生冲突。新模型具备更强的情境判断能力因此可以减少固定约束让模型结合项目环境和具体任务自行判断。现在比较优雅的做法是给出目标和上下文而不是列举一份禁止清单。从工具示例到接口设计过去我们要给 Claude 接入工具一般要在提示词中提供大量调用示例去告诉它“这个工具应该如何使用”。多示例确实能帮模型快速理解工具但在新模型上过多的示例反而可能会限制它的探索空间。模型会沿着示例中的固定模式执行任务而忽略当前任务是否存在更合适的调用方式。​相比不断地补充使用示例我们应该更关注下工具本身的接口设计。以一个 Todo 工具为例如果状态字段定义为pending、in_progress、completed新模型几乎不用额外说明就能理解这些状态的含义。我们只用再补充一条约束“同一时刻只能有一个任务处于in_progress”就够了。这样一来就定义清楚了整个行为边界。重点也从“告诉 Claude 如何使用工具”变成“设计一个 Claude 能够直接理解的工具”。从全量加载到渐进式披露过去的 Claude Code 在系统提示词中塞入了大量信息比如如何进行代码 Review、如何验证修改结果、如何执行测试。这些并不是每次任务都需要的内容始终占据着上下文窗口也稀释了真正相关的信息。现在的 Claude Code 会更多依赖 Progressive Disclosure渐进式披露。只在任务需要时Claude 才会加载对应的信息。Claude 将代码验证和 Review 拆成独立的 SkillAgent 判断需要时再主动调用 Skill。这样的思路适用于CLAUDE.md、Skill.md和工具定义。与其把所有经验都塞进一个文件不如建立一棵信息树CLAUDE.md ├── 基础项目说明 ├── 验证 Skill ├── 部署 Skill └── 特殊规则文件这样一来根节点就能保持精简只负责指路让 Claude 在需要的时候能找到对应内容就够了。从重复提醒到工具自描述过去模型有时候需要反复强调同一条规则。系统提示词里说明了工具怎么用又在工具描述中再说一遍。这种冗余在当时能提升遵循率但现在其实可以直接删掉。比较优雅的方式是把使用方式写进工具描述本身让工具自己携带说明。将信息和它作用的对象放在一起也会降低维护成本。从手动记录到自动 Memory过去 Claude Code 靠人工维护长期记忆鼓励用户通过#快捷键把信息保存进CLAUDE.md。现在的 Claude 可以自动保存与当前工作、用户习惯相关的 Memory不需要用户再手动记录所有内容。这也说明CLAUDE.md的定位在变化它适合记录相对不变的项目事实高频变动的工作状态可以交给 Memory。从 md 规划到复合参考资料过去 Plan 模式大量依赖 Markdown 文件项目计划、技术规范、开发说明都以文字形式存在 md 文件中以便 Claude 在长周期任务中保持正确的方向。现在的新模型能够理解复杂得多的参考材料包括不限于 HTML Artifact、测试代码、其他项目中的实现。一份 API 设计规范与其用文字描述不如直接给模型测试用例和已有实现这样模型读到的是可执行的事实而不是对事实的转述。Rubric 也是一种新的参考形式。有了它Claude 能够按照标准做自我验证比如判断一个 API 设计是否合理一个实现是否符合现有的团队习惯。分层设计上下文把上面的变化落到具体实现上每一层的职责要重新划分​System Prompt在整个上下文体系中System Prompt 和具体产品的关系是最紧密的。它主要负责定义 Claude 所处的运行环境以及它要完成的任务类型。对于普通 Claude Code 用户来说一般不用修改这一层。但如果你正在构建自己的 Agent 系统这里就是你最需要投入设计的部分。CLAUDE.mdCLAUDE.md应该保持轻量只要说清楚项目是什么、目标是什么、有哪些特殊注意事项就够了。CLAUDE.md的重点是在代码库中不符合常规预期的那部分内容比如要集中管理哪些类型文件哪些目录有特殊约定以及哪些测试流程和主流做法不同。通过查看项目结构就能获得的信息就不用重复写进 Claude。如果遇到像是“如何验证代码修改”这样的复杂流程推荐做法是单独创建一个 Verification Skill再在CLAUDE.md中引用它。Skills上下文体系中Skills 是 Claude 的能力扩展模块。它负责帮 Claude 找到需要的信息而不是限制它的行为。团队经验、特定领域知识、项目最佳实践都适合放在这里。比较大的 Skill 文件应该拆分成若干个子文件同样还是保持按需加载。References引用文件可以为 Claude 提供更加详细的上下文参考。技术规范、产品设计稿、Mockup甚至完整代码库都能成为参考来源。实际使用中代码形式的参考一般能带来更好的效果。相比文字描述一个 HTML 页面能够提供更高保真的设计信息让模型更准确地理解目标效果。上下文设计的减法把两代实践放在一起对比下过去的做法给更多规则、提供更多示例、把所有信息提前加载、不断重复提醒现在的做法让模型使用判断、设计更好的接口、按需加载信息、提供高质量参考。对于 Claude Code 或任何 Agent 系统来说好的上下文工程很少来自持续添加的内容。更多时候我们要做的是删除那些不必要的信息让真正重要的部分更容易被模型找到。分类:AI Coding,AI Coding / Skill,AI 科普