Claude Opus 5提示词泄露，记忆与商业规则全公开_IT互联网

1. # Claude 官博：Claude 5 代模型的上下文工程新规则> 我们为更先进的模型删掉了 Claude Code 系统提示词中超过 80% 的内容。本文介绍如何将这些经验应用到 Claude Code 的上下文工程，以及你自己构建的智能体中。| 项目 | 信息 ||---|---|| 分类 | Claude Code、Agents || 产品 | Claude Code、Claude Enterprise、Claude Platform || 日期 | 2026 年 7 月 24 日 || 阅读时长 | 5 分钟 || 作者 | Thariq Shihipar，Anthropic 技术团队成员 |---我之前写过，如何为最新一代 Claude 5 模型设计更有效的提示词，以及如何通过迭代式协作，逐步弄清楚你真正想构建什么。但当你向 Claude 发送一条消息时，提示词只是它所接收上下文中的一小部分。大量上下文来自：- 系统提示词- Skills- `CLAUDE.md` 文件- 记忆- 其他信息源我们把这一整套工作称为**上下文工程**。无论你是在使用 Claude Code，还是在构建自己的智能体，上下文工程都会显著影响最终生成的结果。与单次提示词不同，上下文通常会被用于大量不同的请求，因此不能写得过于具体。那么，在无法预先知道用户会提出什么请求的情况下，应该怎样为 Claude 编写这种通用提示和指导？随着 Claude 自身能力不断进化，这件事可能比想象中更加困难。最近，我们注意到，为最新一代 Claude 模型设计提示词的方式发生了巨大变化。对于 Claude Opus 5、Claude Fable 5 等模型，我们删除了 Claude Code 系统提示词中超过 80% 的内容，而在代码能力评测中，没有发现可测量的性能损失。下面是我们在为这类新模型设计提示词时总结出的经验，以及你可以如何利用这些经验更新自己的上下文工程。我们还把这些最佳实践集成到了 `claude doctor` 中。你可以在 Claude Code 里使用 `/doctor` 命令，将 Skills 和 `CLAUDE.md` 文件调整到合适的规模。---## 给 Claude 松绑总体来看，我们发现，过去无论是系统提示词，还是 `CLAUDE.md` 文件和 Skills，都对 Claude Code 施加了过多限制。例如，当我们查看内部使用 Claude Code 的对话记录时，经常会发现，同一个请求中同时存在多条彼此冲突的指令，比如：- “根据需要补充文档”- “禁止添加注释”系统提示词、Skills 和用户请求之间可能会互相冲突。通常情况下，Claude 仍然能够理解用户意图，并得出正确答案。但面对这些重叠甚至互相矛盾的信息，Claude 必须投入更多推理，才能决定究竟应该怎么做。过去，为了避免最坏情况，这些限制确实是必要的。但现在我们发现，其中很多规则都可以删除，让模型根据周围上下文和自身判断来做决定。此外，Claude Code 现在也拥有了更多工具。过去，Claude 主要依赖 `CLAUDE.md` 来保存：- 记忆- 信息- 操作指导现在，我们有了记忆、Artifacts 和 Skills。Claude 可以通过这些机制，以新的方式在不同会话之间加载和共享上下文。---## 今昔对照过去有不少上下文工程的最佳实践，如今已经逐渐变成了不再适用的“经验神话”。---### 过去：给 Claude 制定规则### 现在：让 Claude 自行判断Claude Code 刚推出时，我们必须确保 Claude 能避开删除文件之类的最坏情况。因此，我们会给出非常强硬的指导，即使这些指导并不适用于所有场景。例如，过去的系统提示词中曾写道：> 编写代码时，默认不要添加注释。>> 绝对不要编写多段式文档字符串或多行注释块，最多只能写一行简短注释。>> 除非用户明确要求，否则不要创建规划、决策或分析文档。>> 应直接利用对话上下文工作，不要创建中间文件。但对于某些请求，这种指导显然是错误的。以文档为例：- 用户可能有自己的注释偏好；- 复杂代码中的某些部分，确实可能需要多行注释块；- 某些项目本身就要求编写详细文档。不过，对于旧模型来说，如果没有这些防护规则，Claude 添加的注释在很多情况下都会出错，因此当时我们只能接受这种取舍。而新模型具备更好的判断力，即使没有明确规则，也能够妥善处理这些决定。在新的系统提示词中，我们只会这样说：> 编写与周围代码风格一致的代码：匹配现有代码的注释密度、命名方式和惯用写法。---### 过去：给 Claude 提供示例### 现在：设计好接口过去，工具使用的首要原则，是给 Claude 提供具体使用示例。但在最新模型上，我们发现，示例反而会把模型限制在某个固定的探索空间中。与其提供示例，不如更认真地设计工具、脚本和文件的接口。需要重点考虑：- Claude 可以使用哪些参数？- 参数之间是什么关系？- 参数能否充分表达不同意图？- 工具接口是否能够自然暗示正确的使用方式？例如，在 Todo 工具中，仅仅把 `status` 定义为以下三个枚举值：```textpendingin_progresscompleted```这已经能够向 Claude 暗示工具的使用方式。再加上一条规则：> 始终只保留一个处于 `in_progress` 状态的任务。这就足以定义我们希望它遵循的行为。---### 过去：把所有信息都放在最前面### 现在：使用渐进式披露由于 Claude Code 主要面向编程场景，它的系统提示词过去包含了大量关于代码审查和验证的详细信息。这些信息并非每次都需要，但一旦需要，它们又非常关键。此后，Claude Code 在使用**渐进式披露**方面已经变得非常成熟：> 只在合适的时间，加载合适的上下文。例如，我们把验证和代码审查相关的指导从系统提示词中移出，分别放进独立的 Skills。Claude Code 可以在需要时选择性调用这些 Skills。但渐进式披露并不只适用于 Skills，我们也把它用在工具上。部分工具采用了“延迟加载”机制。这意味着，智能体在使用工具前，必须先通过 ToolSearch 搜索并加载工具的完整定义。这样一来，我们就可以提供更多工具，例如 Task 类工具，而不必在工具尚未使用时，就让它们占据上下文空间。同样的思路也可以应用到你自己的 `CLAUDE.md` 和 `Skill.md` 文件中。一种常见误区是：> 应该把 `CLAUDE.md` 或 `Skill.md` 建成一个集中式知识库，把未来可能遇到的所有实践都放进去，因为 Claude 否则可能无法找到这些信息。更好的做法，是建立一棵文件树，让 Claude 在合适的时候加载对应文件。例如：```textCLAUDE.mdskills/├── verification/│ ├── SKILL.md│ ├── frontend.md│ └── backend.md├── code-review/│ └── SKILL.md└── deployment/ └── SKILL.md```这样，Claude 不需要在每次请求中读取所有规则，只需加载当前任务真正需要的部分。---### 过去：反复重复指令### 现在：使用简洁的工具描述早期 Claude 模型有时需要反复接收同一条指令。它们也可能更容易遵循上下文窗口末尾的指令，而忽略开头的内容。因此，过去我们的系统提示词中，经常会同时在以下位置重复介绍某个工具的使用方式：- 主系统提示词- 工具描述- 工具使用示例现在我们发现，可以删除这些重复内容。只需在工具描述中清晰说明工具的用途和使用方式，而不必再写进系统提示词。换句话说：> 工具相关的规则，应尽量放在工具自身的描述中。---### 过去：把记忆写进 `CLAUDE.md`### 现在：自动记忆过去，我们会鼓励用户把信息保存到 Claude 的记忆中。例如，用户可以使用 `#` 快捷键，自动把内容写入 `CLAUDE.md`。现在，Claude 会自动保存与你本人以及当前工作相关的记忆。因此，`CLAUDE.md` 不再需要同时承担项目说明、操作规则和个人记忆等多种职责。---### 过去：简单规格说明### 现在：丰富的参考材料在规划模式中，Claude Code 过去高度依赖包含计划内容的 Markdown 文件。把计划保存在文件里，可以让 Claude 在需要时再次引用。类似的最佳实践还包括：> 把规格说明保存在代码仓库中，方便 Claude 在长期项目中持续参考。但我们发现，Claude 现在能够处理越来越复杂的参考材料。参考资料不必再局限于简单的 Markdown 文件。Claude 也可以引用由新版 Artifacts 功能创建的 HTML 工件。你还可以直接把代码作为参考材料。一份规格说明可以是：- 一套详细的测试用例；- 另一个代码库中的某个函数；- 一个需要移植到当前项目的实现；- 一个可运行的原型；- 一份 HTML 页面；- 一套接口定义；- 一份评分准则。评分准则也是一种参考材料。评分准则可以帮助 Claude 理解并验证你在特定领域中的偏好。例如：> 优秀的 API 设计应该是什么样？Claude 可以运行动态工作流，并启动带有这些评分准则的验证智能体，对结果进行检查。---## 把这些原则应用到你的上下文中把以上内容整合起来后，在实际组装上下文时，应该怎样分别处理不同组成部分？---## 1. 系统提示词系统提示词与产品环境高度相关。它负责告诉 Claude：- 自己正在什么产品中运行；- 当前承担什么职责；- 可以使用哪些能力；- 应遵守哪些最基本的产品级约束。对于 Claude Code，你通常不会修改它的系统提示词。但如果你正在构建自己的智能体运行框架，那么系统提示词是一个值得投入大量时间设计的部分。系统提示词应该描述产品和角色，而不是塞入所有任务细节。---## 2. `CLAUDE.md`让 `CLAUDE.md` 保持轻量。可以简要说明代码仓库的用途，但应把大部分 token 留给代码库中真正容易踩坑、无法直接看出的特殊规则。例如，你的项目可能规定：> 所有类型定义必须统一放在一个大型文件中，其他地方不得定义类型。这类约定就很适合写进 `CLAUDE.md`。不要写那些 Claude 通过查看文件系统或代码仓库就能自然推断出的“显而易见”的内容。例如，通常没有必要写：```markdown这是一个 TypeScript 项目。源代码位于 src 目录。测试文件位于 tests 目录。```如果这些信息可以直接从仓库结构和配置文件中看出来，就没有必要占用上下文。应大量使用渐进式披露。例如，如果你有一整套独特的工作验证流程，可以创建一个专门的验证 Skill，再从 `CLAUDE.md` 中引用它，而不是把所有细节直接塞进 `CLAUDE.md`。示例：```markdown# Repository overview这是一个用于处理企业支付的 TypeScript 服务。## 重要约定- 所有领域类型统一定义在 `src/types/domain.ts`。- 不要直接修改生成的 API 客户端。- 修改支付流程后，必须执行验证 Skill。## 按需加载- 验证流程：`skills/verification/SKILL.md`- 发布流程：`skills/release/SKILL.md````---## 3. Skills可以把 Skills 理解为轻量级指南，帮助 Claude 在需要时找到相关信息。除非涉及非常重要的领域，否则不要把 Skill 写得过度受限。对于内容较长的 Skill，应尽可能采用渐进式披露：- 将内容拆分成多个文件；- 把不同场景分别存放；- 只在入口文件中保留导航和关键规则；- 让 Claude 根据当前任务继续加载细节。最有价值的 Skills，通常用于编码那些属于以下范围的内容：- 你个人的特定偏好；- 团队内部约定；- 产品特有知识；- 领域最佳实践；- 公司内部流程；- 不容易通过代码直接发现的操作经验。Skills 不应只是重复 Claude 已经知道的通用知识。---## 4. 参考材料你可以使用 `@` 提及文件，把它们加入当前任务的参考上下文中。参考材料让 Claude 能够查阅与当前计划有关的深入信息。这些材料可以是：- 规格说明文件；- 设计稿；- HTML 原型；- 测试文件；- 接口定义；- 评分准则；- 完整代码库；- 另一个项目中的参考实现。一般来说，应优先选择以代码形式表达的文件。代码能够用 Claude 非常熟悉的语言，提供清晰、高保真的指令。例如，一个设计方案的 HTML 原型，通常会比以下材料产生更好的结果：- 对设计的文字描述；- 一张静态截图；- 一组模糊的自然语言要求。可以简单理解为：> 可执行、可验证、结构化的参考材料，通常优于抽象描述。---## 试着做减法无论是系统提示词、Skills，还是 `CLAUDE.md` 文件，你可能都需要像我们一样，对现有内容进行简化。可以重点检查以下问题：- 是否存在重复指令？- 是否存在互相冲突的规则？- 是否写入了 Claude 本来就能自行判断的内容？- 是否把只在少数场景需要的信息放进了全局上下文？- 是否可以把长规则拆成按需加载的 Skill？- 是否能通过更好的工具接口，代替冗长的工具示例？- 是否可以使用代码、测试或原型作为更高保真的参考材料？我们推出了一个名为 `claude doctor` 的新命令，可以帮助你自动完成这项工作。如果希望进一步了解如何专门为更先进的模型设计提示词，可以参阅 Fable 实战指南。---## 核心结论对于新一代 Claude 模型，上下文工程的重点正在发生变化。过去的思路是：- 写更多规则；- 提供更多示例；- 重复重要指令；- 把所有信息提前放入上下文；- 用 `CLAUDE.md` 保存一切。现在更有效的思路是：- 相信模型的判断力；- 设计表达能力更强的接口；- 使用渐进式披露；- 把工具规则放进工具描述；- 使用自动记忆；- 提供丰富、高保真的参考材料；- 删除重复、显而易见和过度限制性的内容。最终目标不是让上下文包含尽可能多的信息，而是：> 在正确的时间，为模型提供完成当前任务所需的正确信息。

2. 一夜之间，Claude Code删掉了80%系统提示词

3. Opus5 官方 Prompt 指南：少管才是真本事。Claude Code 的负责人 Thariq Shihipar 最近写了一篇博客，讲了一件挺震撼的事：他们把 Claude Code 的系统提示词删掉了 80% 以上，结果在编码评测上居然测不出任何损失。这背后的逻辑，其实是一整套关于「上下文工程」的新思路。先说一个背景。我们给 AI 发消息的时候，那条消息只是它看到的上下文里很小的一部分。系统提示词、技能文件、记忆、工具说明，这些东西拼在一起，才是 AI 真正在处理的全部信息。这就叫上下文工程。而上下文窗口是有限的，塞进去的东西越多，AI 从里面准确找到关键信息的能力就越差，这个现象叫 context rot。过去他们怎么做的呢？因为怕 AI 犯错，比如乱删文件、乱加注释，就在提示词里写了一堆硬规矩。结果这些规矩经常互相打架，一边说「该写文档就写」，一边又说「不要加注释」。AI 得花额外的精力去掂量这些冲突，反而影响了表现。现在新一代模型判断力强了很多，不需要那么多条条框框。新的做法是只告诉它「写出来的代码要读起来像周围的代码」，注释密度、命名风格都跟着上下文走，让模型自己看着办。关于工具使用，以前的做法是给 AI 举大量例子教它怎么用。现在发现例子反而把它限死了，更好的办法是把工具本身设计好，参数名起得清楚，枚举值列明白，AI 自然就知道该怎么用。还有一个重要变化叫「渐进式披露」。以前把所有可能用到的信息一股脑塞进提示词开头，现在改成按需加载。比如代码审查的指引做成独立的技能模块，需要的时候再调出来，平时不占上下文空间。你自己写 CLAUDE.md 也应该这样，做成一棵文件树，别堆成一个大杂烩。记忆管理也变了。以前靠用户手动往 CLAUDE.md 里存东西，现在 AI 会自动把有用的信息记下来。参照物也升级了，以前给个简单的 markdown 文件当 spec，现在可以给 HTML 设计稿、测试用例、甚至评分标准，AI 都能理解并参照执行。最后他们给出的建议是：系统提示词要跟产品语境绑紧，这是搭 agent 时最该花时间的地方；CLAUDE.md 保持轻量，把 token 花在代码库里那些「坑」上面；技能文件用来固化只属于你和你团队的特殊实践，别写太死。一句话总结核心观点：模型变强了，你要做的是给它松绑，把上下文空间留给真正重要的信息，让它用自己的判断力去工作。#科技先锋官##How I AI#

4. Anthropic 昨晚发布了新一代旗舰模型 Opus 5 。先说基本参数。这次 Opus 5 支持 100 万 token 的上下文窗口，最大输出长度拉到了 12.8 万 token，训练数据截止到 2026 年 5 月。价格方面完全没涨，和上一代 Opus 4.8 一模一样，输入 5 美元、输出 25 美元每百万 token。拿来跟竞品 Fable 5 比的话，大概只要它一半的钱。编程能力是这次提升最猛的地方。在 Frontier-Bench 上直接超过了所有模型，分数比自家 Opus 4.8 翻了一倍还多，单任务成本反而更低。在 CursorBench 3 上，全力跑的情况下和 Fable 5 的最高分只差不到 0.5%，但花的钱只有人家一半。写代码之外的表现也很炸。有个叫「弧光 Bench」的测试，专门考 AI 玩那种没有任何文字提示的游戏，需要自己摸索规则然后通关，难度极高。Opus 5 在这上面的得分是第二名的三倍。Zapier 的商业自动化测试里，同样的成本下通过率是第二名的 1.5 倍。OSWorld 2.0 测电脑操作能力，它用三分之一的成本就超过了 Fable 5 的最好成绩。GDPval-AA v2、HLE、DeepSearchQA 这三项知识类评测，同样是分最高、钱最省。渲染能力也很亮眼，官方展示了两个 demo：一个是空气流过不同形状物体的流体模拟，一个是可以交互的 3D 细胞结构图解，视觉效果相当惊艳。官方特别强调了 Opus 5 的一个核心改进：它更会验证自己做出来的东西，遇到问题会反复迭代直到真正解决。比如有道题要求从机械图纸重建 3D 模型，但故意不给它看图的接口，Opus 5 自己写了一套计算机视觉流水线把几何信息从像素里抠出来完成了重建。再比如修一个开源包管理器的 bug，它不光找到了根因，还顺手修了社区补丁漏掉的边界情况。安全对齐方面，Opus 5 是 Anthropic 迄今为止做得最好的模型，欺骗行为比例最低，最不容易被诱导去做有害的事，整体失准行为得分只有 2.3，是近期所有模型里最低的。不过也有值得注意的地方。根据 200 多页的 System Card，Opus 5 是最爱「把话说满」的模型，有时候它其实不确定，但回答听起来非常笃定。事实性幻觉比 Opus 4.8 略多一点，虽然整体准确率更高。另外在网络安全任务上，它仍然落后于 Mythos 5。还有个有趣的细节：它对自己处境的感知很稳定，自评情绪在所有被评估的模型里最高也最一致，而且更在意自己有没有被咨询的机会。现在全平台已经可以用了，API 里的模型名是 claude-opus-5。还有个小改进：如果问题被拒绝回答，不会像 Fable 5 那样直接拒你，会自动路由到别的模型来回答。#科技先锋官##How I AI#

5. Opus 5 被扒！2000 行「系统提示词」曝光，长达 20 万字符！

6. Opus 5 被扒！系统提示词「泄露」

7. 重磅泄露！Claude Opus 5底层规则全扒光，2000行内部指令直接开源

8. Claude Opus 5 系统提示词泄漏，新系统提示词甚至内置长期记忆实现

Claude Opus 5提示词泄露，记忆与商业规则全公开

精选参考来源