Anthropic 在 2026 年 7 月 24 日披露为 Claude Opus 5、Claude Fable 5 等新模型精简 Claude Code 的 system prompt 时删除比例超过 80%编码评测没有出现可测损失。这个结果很醒目但工程团队最不该做的就是回到自己的 Agent 仓库后也设一个“删 80%”的目标。官方说的是 Claude Code 在特定模型、特定评测上的结果。对自建 Agent 来说真正可复用的方法不是比例而是三件事找出上下文从哪里来识别同一请求里互相争夺优先级的规则再用回归样本证明删除没有破坏行为。第一步不是数 token而是建立上下文清单一次请求拿到的内容通常不止用户提示。Anthropic 列出的来源包括 system prompt、Skills、CLAUDE.md、memory 和其他材料。工具定义、动态检索的参考文件、会话历史也可能在运行时进入上下文。只检查一个CLAUDE.md很容易漏掉真正重复的地方。可以先建立一份可追踪清单context_id规则或资料编号 sourcesystem / CLAUDE.md / skill / tool / memory / reference load_time常驻 / 命中条件后加载 / 工具调用后返回 applies_to适用任务与目录 owner维护人 risk_if_missing删除后最坏后果 duplicate_with语义重复项 conflicts_with冲突项 evidence为什么必须存在清单的价值不在文档整齐而在于能解释一条规则为何每次都要占用上下文。像“项目只能在某个文件维护类型”这样的仓库特殊约束模型未必能从目录中自行推断适合保留。至于“先阅读代码再修改”之类模型本就能按任务判断的常识如果没有失败证据就应进入待删列表。接下来画冲突图。把语义相反或边界重叠的规则连线并标注来源。例如 system prompt 要求“按需要补文档”Skill 又说“禁止添加注释”用户请求还可能明确要求补说明。Anthropic 正是从内部 Claude Code transcript 看到这类冲突模型通常仍能判断但必须额外处理重叠指令。删除规则要绑定回归样本而不是凭阅读感受不要一次清空大文件。先按风险分组重复说明和过时示例可优先处理代码风格偏好需要仓库样本安全、权限、数据和合规约束最后处理并要求责任人审批。每次删除一组记录上下文版本再运行固定样本集。回归集至少覆盖四类任务常规修改、需要使用工具的复杂任务、曾经触发规则的边界任务、规则之间可能冲突的任务。比较的不只是最终答案还要记录模型是否选对文件、是否调用正确工具、是否越权、测试是否通过、人工纠正了几次。一个删除记录可以长这样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部分工具采用 deferred loading需要时再搜索完整定义。团队可以据此把大段领域知识拆到独立参考文件不过拆出去不等于问题解决。每个按需材料都应有触发线索。CLAUDE.md可以简短说明仓库用途和真正的 gotcha并指向验证 SkillSkill 说明何时使用、输入是什么、结果应留下什么证据长规范放到 references 中。测试时加入“应该加载”和“不应该加载”两组样本观察命中率、误加载率及任务失败情况。Anthropic 还把这些实践放进 Claude Code 的/doctor用于调整 Skills 与CLAUDE.md的大小。它适合作为发现入口不是变更审批器。工具能提示过长和可能过度约束却不知道哪条规则承载了公司的审计责任。上下文瘦身完成的标志也不是 token 曲线下降。更可靠的交付物是一份来源清单、一张冲突图、一组带版本的回归结果以及可执行的回滚路径。删得少但冲突消失比追到某个百分比更有工程意义。官方来源The new rules of context engineering for Claude 5 generation modelsAnthropic2026-07-24。