Anthropic谈Claude Code上下文规则精简

Anthropic 讲解了随着模型的提升，应该如何更新自己的上下文规则，推荐看看。 随着 Fable 5 和 Opus 5 的发布，他们精简了 80% 的系统提示词，但在编程测评上没有任何损失。 其核心问题在于，Claude 的提示词只是它获取上下文的一小部分，更多的上下文来自于系统提示词、Skills、claude.md 以及 Memory。 这里的难点在于：上下文是跨多个请求通用的，不能像单个提示词那么具体。 他们之前对 Claude Code 的约束过度了，而且经常存在互相矛盾的指令（约束越多，冲突的概率就越大）。 像 Fable 5、GPT 5.6 这种新模型，完全能够靠上下文和自己的判断力处理很多事情，因此没必要过度约束。 他们总结了过去到现在关于上下文转变几条趋势： 1. 从“给规则”到“让 Claude 运用判断力”：比如旧版会写“默认不写注释”，新版可以改成“写出与周围代码一致的代码”，这样它自己就会去匹配周围代码的注释密度、命名和习惯。 2. 从“给具体示例”到“设计接口”：给具体示例容易让模型变得死板。现在可以给一些设计接口（比如脚本文件的设计），让参数更具表达力，以此来引导它，而不是塞给它具体的示例。 3. 从“全部前置的上下文”到“渐进式披露”：把代码审查、验证等相互独立的信息放在不同的 Skills 里面，按需调用。模型可以通过文件搜索去查找，而不需要一次性塞入。 4. 不在系统提示词和工具描述里重复提示：直接把用法写进工具描述里，不再到系统提示词里去强调。 5. 从“手动记录”到“自动记忆”：以前是在 claude.md里存记忆，现在直接由模型自动记忆，不再依赖手写输入。 6. 从“简单规则”到“丰富的引用”：以前规则非常单一，现在可以把图片、HTML 文件、测试文件、测试代码、函数甚至是评分标准，都作为模型的上下文塞进去。 --- 关于如何将这些原则运用到你自己的上下文管理中，有以下几点建议： 系统提示词定位：在系统提示词里明确告诉 Claude 在什么产品里做什么。如果你在构建 Agent，需要投入精力重新编写系统提示词。 保持 [claude.md]或 [agent.md]的轻量：把仓库用途和说明性内容花在最核心的地方（比如已知的坑或缺陷上）。避免把 Claude 一看代码就能懂的事情非要写进 [claude.md]里。 多用 Skills 进行模块化：把需要按需查找的信息打包成 Skills。如果 Skills 过长，需要采用渐进式披露的方式拆分成多个文件。 优先引用代码形式：在使用 @ 引用文件时，优先引用代码。比如引用 HTML 模板的效果，通常比只给设计描述或截图效果更好。 使用自动化工具：他们还提到了 `claude doctor` 这个命令，可以自动帮你精简 Skills 和 [claude.md]文件。  > **引用原帖 Thariq (@trq212):** > We removed ~80% of the Claude Code system prompt for our newest models, this is what we've learned about writing system prompts, skills and Claude.MDs for them. https://t.co/6DZwSrZjE9 > https://x.com/trq212/status/2080710971228918066