2026年7月，Anthropic 发布了一篇关于 Claude 5 上下文工程的最新文章，标题直指核心——《The new rules of context engineering for Claude 5 generation models》。文中一个数据格外引人注目：他们删除了 Claude Code 中超过 80% 的系统提示词，而编码评测成绩丝毫未受影响。

这一结果确实令人印象深刻。但如果团队看完后，回到自己项目中也盲目设定“删除 80%”的目标，那就偏离了方向。

Anthropic 在复盘时发现，那些为旧模型精心调优的提示词，到了新模型上反而成了累赘。因此，真正值得复用的并非那个比例，而是三件事：理清上下文的来源，识别同一请求中相互矛盾的规则，并通过回归样本证明删除后不会引发问题。

上下文工程与编写 Prompt 有着本质区别：Prompt 是单次使用的，而上下文会被反复复用。复用意味着不能写得过于具体，否则在下一个任务中就会变成噪音。Anthropic 提出的核心思路是“瘦提示-厚工件-瘦技能”，让模型自主判断，逐步披露信息，同时保持高保真的参考依据。

第一步：不是数 token，而是建立上下文清单

一次请求所获取的内容，通常远不止用户提示。Anthropic 列出的来源包括 system prompt、Skills、CLAUDE.md、memory 以及其他材料。工具定义、动态检索的参考文件、会话历史，也可能在运行时被纳入。如果只盯着一个 CLAUDE.md 看，很容易遗漏真正重复的部分。

最好的做法是先建立一份可追踪的清单，例如：

这份清单的价值不在于文档的整齐，而在于能清晰说明一条规则为何每次都要占用上下文。像“项目只能在某个文件维护类型”这种仓库特殊约束，模型未必能从目录结构里自行推断，保留下来就很有必要。至于“先阅读代码再修改”这类模型本来就能根据任务判断的常识，如果找不到它失败的证据，就应该放入待删列表。

画冲突图：把互相打架的规则找出来

接下来，绘制一张冲突图。将语义相反或边界重叠的规则用线连接起来，并标注好来源。

Anthropic 在复盘内部 Claude Code 对话记录时，经常发现同一轮请求中同时出现这类冲突指令：

• system prompt 要求“适当补充文档”
• Skill 又说“禁止添加注释”
• 用户请求里可能还明确要求补说明

单看每一条规则，它们都有存在的道理。但来源和层级不同，组合在一起就容易产生冲突。模型并非听不懂，而是需要在互相矛盾的规矩间做取舍，注意力都消耗在“听谁的”上，而不是“把任务做对”。

这些规则在旧模型阶段确实有效，能很好地避免模型随意修改文件、删除内容。这种牺牲部分灵活性的取舍在当时是合理的。但现在模型判断能力提升了，同样的约束反而开始产生负面效应。如今的模型已经能从代码环境、用户目标和项目习惯中判断该如何处理任务，过于硬性的规则反而限制了它做出更恰当选择的空间。

举个例子，过去的约束可能是“默认不要写注释，不要创建多段文档，不要生成规划文件”。现在更合适的写法是：“编写符合当前代码风格的代码，包括注释密度、命名方式和已有的代码习惯”。前者规定了具体行为，后者提供了目标和判断依据。

删除规则要绑定回归样本，而不是凭阅读感受

不要期望一次就把大文件清空。先按风险分组：

• 低风险：重复说明和过时示例，可以优先处理
• 中风险：代码风格偏好，需要用仓库样本验证
• 高风险：安全、权限、数据和合规约束，最后处理，并要责任人审批

每次只删除一组，记录上下文版本，然后运行固定样本集。

回归集至少要覆盖四类任务：

1. 常规修改
2. 需要使用工具的复杂任务
3. 曾经触发过规则的边界任务
4. 规则之间可能冲突的任务

比较的不只是最终答案，还要记录：模型是否选对了文件、是否调用了正确的工具、有没有越权、测试是否通过、人工纠正了几次。

一个删除记录大致如下：

change_id: ctx-2026-07-27-03
removed: system.md 第 42-58 行的三个工具示例
reason: 参数枚举已在工具 schema 中表达
cases: tool-01, tool-07, permission-03
result: 12/12 通过，工具误用 0 次
rollback: 恢复 context-v18

这里体现了官方“从示例转向接口”的提议。新模型不一定需要一组固定的调用示例；清晰的参数名、枚举值和状态约束，本身就能表达使用边界。但如果你的工具接口含糊，直接删除示例只会把接口问题暴露出来。这时候你应该先去改进 schema，而不是指望模型“更聪明一点”。

把常驻说明改成按需加载，还要测能不能找得到

Anthropic 的另一个方向是渐进披露：代码审查、验证等详细材料不再一股脑塞进 system prompt，而是放进可按需调用的 Skills。团队可以据此把大段领域知识拆到独立参考文件里，但拆出去不等于问题解决了。

每个按需材料都应该有触发线索：

• CLAUDE.md 可以简短说明仓库用途和真正的“坑”，并指向验证 Skill
• Skill 要说明何时使用、输入是什么、结果应该留下什么证据
• 长规范放到 references 中

测试时加入“应该加载”和“不应该加载”两组样本，观察命中率、误加载率以及任务失败情况。

Anthropic 还把这类实践放进了 Claude Code 的 /doctor，用于调整 Skills 与 CLAUDE.md 的大小。它适合做发现入口，而不是变更审批器。工具能提示过长和可能过度约束，但它不知道哪条规则承载了公司的审计责任。

Context 与 Harness 的分层：别把闸门和窗口混在一起

讨论精简时，很多人把“给模型看的字”和“卡住模型的闸”混为一谈。这两层目标完全不同：

• Context（上下文工程） 回答的是：这一步它该看见什么。包括仓库说明、任务描述、相关文件、记忆、Skill 索引、工具名。优化目标是：相关、及时、可负担。窗口是工作内存，不是档案室。
• Harness（运行约束） 回答的是：它做完以后，环境凭什么相信它。包括类型检查、测试、lint、沙箱权限、危险命令拦截、人工审批点、失败回流。优化目标是：可重复、难绕开、不依赖模型自觉。

Claude 5 代把大量口头规则撤出 Context，并不代表 Harness 层可以放松。相反，模型判断空间越大，外部校验的确定性就越重要。

上下文瘦身完成的标志

上下文瘦身完成的标志，不是 token 曲线降下来了。

更可靠的交付物是：

1. 一份来源清单——知道每一条规则从哪里来、为什么存在
2. 一张冲突图——识别并解决了规则之间的重叠与矛盾
3. 一组带版本的回归结果——每次变更都有样本证明行为没有退化
4. 可执行的回滚路径——出问题能快速恢复到上一个已知良好状态

删得少但冲突消失了，比追到某个百分比更有工程意义。