Enivia 最近我读了 Anthropic 发布的关于 Context Engineering 的文章。
文章特别提到，在面向 Opus 5、Fable 5 等新一代模型时，Anthropic 移除了 Claude Code 中超过 80% 的系统提示词。
也就是说，随着模型能力提升，我们可能需要重新审视过去积累下来的提示词经验。
Prompt 只是 Context 的一部分
在执行任务时，我们通常会把大部分注意力放在 Prompt 上，但对于 Claude Code 或一个完整的 Agent 来说，用户消息只是上下文的一小部分。
系统提示词、CLAUDE.md、Skills、记忆、工具定义、项目文件和参考资料，会共同影响模型最终采取什么行动。组织这些信息的过程，就是 Context Engineering。
它和普通 Prompt Engineering 的区别在于，Prompt 通常只服务于一次具体任务，而系统提示词、Skills 和项目规则需要适配于大量未知请求。因此，它们很难写得特别具体，也更容易产生重叠和冲突。
Anthropic 在分析 Claude Code 的内部使用记录时发现，同一个请求中有时会同时出现“根据情况补充文档”和“不要添加注释”之类相互冲突的要求。这些规则可能分别来自系统提示词、Skill 和用户输入。
虽然 Claude 通常仍然可以判断用户真正想要什么，但它不得不先消耗更多的推理去处理这些冲突。
换句话说，上下文越多，不一定意味着信息越充分，也可能只是增加了模型需要处理的干扰信息。
允许模型自主判断
早期的 Agent 需要大量明确规则，以避免删除文件、生成多余文档或者写出冗长注释等问题。
例如，系统可能会规定默认不要写注释，不要写多行文档说明，不要主动创建计划。
这些规则在多数场景中有用，但很难永远正确。复杂代码有时确实需要详细注释，不同项目也有不同的代码风格。如果把某种经验写成绝对规则，模型就会在不适合的场景中继续遵循它。
现在 Anthropic 更倾向于提供统一原则，例如：
编写与现有代码风格一致的代码，匹配项目中的注释密度、命名方式和编程习惯。
这种表达没有规定模型必须写多少注释，而是让它先观察周围代码，再根据项目实际情况做判断。
这也是我从这篇文章中得到的第一个启发：对于能力更强的模型，Context Engineering 的目标不再是提前替模型完成所有判断，而是为它提供足够清晰的判断依据。
少写示例，多进行接口设计
过去设计 Agent 工具时，一个常见做法是提供大量调用示例，详细地告诉模型某个工具应该怎么使用。
但 Anthropic 发现，对于新一代模型，示例有时会把模型限制在示例展示的边界范围里。模型可能会模仿已有路径，而不会主动寻找更合适的调用方式。
相比堆积示例，现在更重要的是设计工具本身的接口。
例如，你可以将一个 Todo 工具的任务状态定义为 pending、in_progress 和 completed，这些参数本身就已经向模型表达了工具的工作方式。只用再加上一条“同一时间只保留一个进行中的任务”，就可以形成清楚的行为约束。
好的工具接口，本身就是一种上下文。
这让我想到，在 Agent 产品中，工具名称、参数类型、枚举值和返回结构都不只是工程实现，它们同时也是模型能够理解的语言。与其在系统提示词里反复解释一个设计模糊的工具，不如直接让工具的结构变得更明确。
不要一次性塞进所有内容
过去 Claude Code 会把代码审查、验证流程等大量说明直接放在系统提示词中。这种做法产生的问题是，这些信息往往只在少数任务中有用，却会占据每一次请求的上下文。
现在 Anthropic 更强调 Progressive Disclosure，也就是渐进式加载。
只有在需要代码验证时，才加载验证 Skill；需要代码审查时，再加载代码审查 Skill。一些工具甚至可以采用延迟加载，Agent 先搜索工具定义，确定需要使用后，再把完整描述放入上下文。
同样的思路也适用于 CLAUDE.md 和 Skill.md。
我们不需要把所有团队规范、技术说明和可能遇到的问题集中写进一个巨大文件。更合理的方式是建立一棵可以按需访问的文件树，让 Agent 根据当前任务加载对应内容。
这可能是 Context Engineering 中非常重要的一个转变：上下文不再是一段预先拼装好的静态文本，而是一个可以被 Agent 动态检索和加载的信息系统。
不要在多个地方重复同一条规则
早期模型有时会忽略上下文开头的指令，或者更重视靠近上下文末尾的内容。因此，开发者习惯在系统提示词和工具描述中重复同一条规则。
随着模型的长上下文理解能力增强，这种重复变得越来越没有必要。
Anthropic 发现，很多工具使用说明都可以从系统提示词中删除，而只在对应的工具描述里保留。这样既减少了上下文长度，也降低了不同版本规则互相冲突的概率。
我认为一个比较实用的判断标准是：一条信息应该放在距离它作用对象最近的位置。
产品层面的信息和目标放进 System Prompt，代码仓库的特殊约定放进 CLAUDE.md，工具调用方式写进工具描述，具体工作流放进 Skill，当前任务的详细要求则作为参考文件提供。
CLAUDE.md 不应该变成知识仓库
过去很多人把 CLAUDE.md 当成 Claude 的长期记忆，把项目中的各种信息不断追加进去。随着自动记忆和 Skills 等机制出现，CLAUDE.md 已经不必承担所有职责。
Anthropic 建议让 CLAUDE.md 保持轻量，只需要简要说明仓库是做什么的，并重点记录那些模型无法通过浏览代码自然发现的特殊约定。
例如，某个项目规定所有类型必须集中放在一个文件中，这是一条值得写入 CLAUDE.md 的信息。至于项目使用什么语言、目录中有哪些文件，Claude 可以直接查看仓库，没有必要再次描述。
复杂的验证流程也不需要完整写入 CLAUDE.md，可以把它拆成独立的验证 Skill，再从 CLAUDE.md 中提供入口。
一个好的 CLAUDE.md 不应该追求完整，而应该追求高信息密度。
用真实参考资料代替抽象描述
随着模型能力提升，Claude 可以理解的参考资料也越来越复杂。
以前我们可能会专门编写一份 Markdown 说明，现在可以直接提供测试套件、现有代码、HTML 原型、另一个代码库中的函数，甚至用于评价结果的 Rubric。
从模型的角度来看，一段真实代码经常比一段自然语言描述更精确。一个 HTML 设计原型，也可能比文字描述或静态截图更清楚地表达布局、结构和交互关系。
上下文并不只是写给模型看的说明文字。代码、测试、接口、原型和评价标准，都可以成为模型理解任务的依据。
相比不断描述我们想要什么，直接给出一个高质量参考物，往往更有效。
新的 Context Engineering 原则
综合来看，Anthropic 对不同上下文组件提出了相对明确的分工。
- System Prompt 用来说明 Agent 所处的产品环境、基本身份和核心职责。
CLAUDE.md应该简短，集中记录仓库中的特殊约定和容易踩坑的地方。- Skills 用来封装团队特有的知识、观点和工作流，并通过渐进式加载控制上下文体积。
- References 则负责提供当前任务需要的规格、代码、测试、原型和其他参考资料。
它们不应该重复承担相同职责，也不应该把所有信息塞给模型。
最后
我认为，这篇文章真正想表达是提示词需要从「规则清单」转向「上下文架构」。
模型能力较弱时，我们必须通过更多限制来换取稳定性。模型能力增强后，继续沿用这种方法，可能会压缩它的判断空间。
而此时更重要的工作，是设计清晰的接口，组织可检索的信息，为任务提供高质量参考，并让模型在需要时找到它们。
Context Engineering 的新规则，可以概括成一句话：
给模型更少的束缚，同时提供给它更好的环境。
