官方删掉了 Claude Code 系统提示词的 80%

译者说明：本文译自 Anthropic 官方博客，作者 Thariq Shihipar（Anthropic 技术团队成员）， 发表于 2026 年 7 月 24 日。站里用 CLAUDE.md 把你的规矩固化下来那篇写在这篇之前， 其中「写得越具体越好」这条现在需要按本文修正——译后附记里说清楚了改哪几处。

当你给 Claude 发一条消息时，提示词只是它拿到的上下文的一小部分。你的上下文大部分是从系统提示词、Skills、CLAUDE.md 文件、记忆和其他来源组装起来的。我们把这个叫做上下文工程，它对你使用 Claude Code 或构建自己的 agent 时得到的结果影响很大。

与提示词不同，上下文会被用在很多次请求上，所以它没法那么具体。在你不知道用户的提示词会是什么的情况下，怎么为 Claude 构建这些通用的指引？

随着 Claude 自身能力的演进，这件事出人意料地困难。最近我们注意到，给最新一代 Claude 模型写提示词的方式发生了一次大跳跃：

我们删掉了 Claude Code 系统提示词的 80% 以上（针对 Claude Opus 5 和 Claude Fable 5 这类模型）， 在我们的编程评测上没有可测量的损失。

我们已经把这些最佳实践放进了 claude doctor——在 Claude Code 里用 /doctor 命令，可以自动帮你把 Skills 和 CLAUDE.md 调整到合适的尺寸。

我们一直在束缚 Claude

总体上，我们发现自己过度约束了 Claude Code——通过系统提示词，也通过 CLAUDE.md 文件和 Skills。

举个例子。当我们去读自己内部使用 Claude Code 的对话记录时，会在同一次请求里看到好几条互相冲突的消息：一边是「酌情保留文档」，另一边是系统提示词里的「不要加注释」——系统提示词、Skills 和用户请求彼此打架。

一般来说 Claude 能解读出用户的真实意图并给出正确答案，但它必须先更费力地思考这些重叠且冲突的信息，才能决定该做什么。

这些约束曾经是必需的，用来避免最坏的情况。但我们后来发现，可以删掉其中很多条，让模型改用周围的上下文和它自己的判断力。

此外，Claude Code 现在有了多得多的工具。Claude 过去依赖 CLAUDE.md 作为记忆、信息和指引的来源；现在我们有了记忆、artifacts 和 skills，Claude 可以用它们创造新的方式来跨会话加载和共享上下文。

六条已经过时的老经验

有若干条过去的上下文工程最佳实践，已经变成了传说：

从前：给 Claude 定规则 → 现在：让 Claude 用判断力

刚推出 Claude Code 时，我们必须确保 Claude 避开最坏的情况，比如删文件。这意味着我们会给出特别强硬、但并非永远正确的指引。比如系统提示词里曾经这样写：

In code: default to writing no comments. Never write multi-paragraph docstrings
or multi-line comment blocks — one short line max. Don't create planning,
decision, or analysis documents unless the user asks for them — work from
conversation context, not intermediate files.

但对某一部分提示词来说，这条指引是错的。 用户可能有自己的偏好，或者某段特别复杂的代码确实需要多行注释块。

在老模型上，没有这些护栏的话 Claude 写的注释在很多情况下会是错的，我们不得不接受这个取舍。但新模型有更好的判断力，不需要显式规则就能把这些决定处理好。

新的系统提示词里我们这样写：

Write code that reads like the surrounding code: match its comment density,
naming, and idiom.

从前：给 Claude 举例子 → 现在：设计接口

工具使用的头号规则曾经是给 Claude 举例说明怎么用。在我们最新的模型上，我们发现举例反而把它们约束在了某个特定的探索空间里。

与其用例子，不如更多地去想你的工具、脚本和文件的设计——Claude 拿到的是哪些参数，这些参数怎样才能更有表达力？

比如那个待办事项工具，光是把状态列成一个枚举（pending、in_progress、completed），就已经在提示 Claude 该怎么用了。而「保持只有一项处于 in_progress」这条说明，则定义了我们想要的行为。

从前：全部前置 → 现在：渐进式披露

因为 Claude Code 聚焦于编程，我们的系统提示词里包含了关于如何做代码评审和验证的详细信息。这些并不总是需要，但需要的时候至关重要。

后来 Claude Code 已经非常擅长渐进式披露——在正确的时机加载正确的上下文。比如我们把验证和代码评审移进了各自独立的 skill，由 Claude Code 选择性调用。

渐进式披露不只适用于 skill，也适用于工具。 我们有些工具是「延迟加载」的，意思是 agent 必须先用 ToolSearch 搜索它们的完整定义才能使用。这让我们可以拥有更多工具，而它们在被用到之前不占上下文。

同样的做法可以用在你自己的 CLAUDE.md 和 Skill.md 上。一个常见的迷思是：你想把这些文件做成一个中央仓库，装下所有可能遇到的实践，因为不这样 Claude 就找不到。 与其如此，不如考虑做成一棵可以在正确时机被加载的文件树。

从前：重要的话说两遍 → 现在：简单的工具说明

更早的 Claude 模型有时需要重复的指令，或者更容易听从上下文窗口末尾而非开头的指令。这意味着我们的系统提示词有时会在主体里引用工具，同时在工具说明里也放一份指令。

我们发现可以删掉这些重复，把「怎么用这个工具」的指令放进工具说明里，而不是系统提示词里。

从前：把记忆写进 CLAUDE.md → 现在：自动记忆

我们过去鼓励用户用 # 快捷键把东西存进 Claude 的记忆，也就是自动写进 CLAUDE.md。现在 Claude 会自动保存与工作和与你相关的记忆。

从前：简单的规格说明 → 现在：丰富的参考物

在 plan 模式下，Claude Code 一直重度依赖 markdown 格式的计划文件。把这些计划存成文件，有助于 Claude 在需要时回看。另一个类似的实践是把规格说明存在代码库里，供 Claude 在跨越较长项目时参考。

但我们发现 Claude 能处理复杂得多的参考物。 不必是简单的 markdown 文件——Claude 可以引用由 artifacts 功能生成的 HTML 产物。

你也可以用代码的形式给 Claude 参考物。一份规格说明可以是一套详细的测试用例，也可以是另一个代码库里一个待移植的函数。

评分量表（Rubrics）是另一种形式的参考物。 量表让 Claude 能够验证你在某个领域的品味（比如「好的 API 设计长什么样」），方式是用动态工作流启动带着这些量表的验证 agent。

落到你自己的上下文上

把这些合起来，你在组装上下文的时候该是什么样？

系统提示词

系统提示词与产品上下文紧密绑定。它告诉 Claude 它在什么产品里运行、在做什么。

对 Claude Code 来说，你大概永远不需要改它；但如果你在构建自己的 agent 外壳，这里是你该花大量时间的地方。

CLAUDE.md

保持轻量。 简短描述这个代码库是干什么的，然后把大部分 token 花在代码库里的坑上。比如你可能把所有类型定义都放在一个大文件里、别处都没有——这种事要写。

避免陈述那些 Claude 看一眼文件结构或代码库就知道的「显而易见」的东西。

重度使用渐进式披露。 比如你有好几条独特的验证方式说明，就做一个验证 skill，然后从 CLAUDE.md 引用它。

Skills

把 skill 看作轻量的向导，让 Claude 在需要时能找到信息。避免把它们写得过度约束，除非是极其重要的领域。

对很长的 skill，尽量使用渐进式披露——拆成多个文件分开放。

Skill 最好用来编码那些属于你、你的团队或你的产品的特定观点、知识和最佳实践。

参考物

你可以用 @ 提及文件，把它们作为参考物包含进来。

一般来说你应该优先使用代码形式的文件，因为它给 Claude 提供的是清晰、高保真的指令，而且是它非常熟悉的语言。举例来说，一份 HTML 版的设计样稿，通常比一段设计描述或一张截图产生更好的结果。

试着简化

在你的系统提示词、skills 和 CLAUDE.md 文件上，你可能需要像我们一样做一次简化。我们推出了一个新命令 claude doctor（在 Claude Code 里是 /doctor），可以帮你自动完成这件事。

译后附记：我们站里哪几句话要改

这篇直接修正了几条我们此前写过、当时也确实是官方口径的建议。照实说明改在哪里：

对研究咨询读者最实际的一条是「设计接口，而不是举例子」。 换成不写代码的说法：

与其给它三个「好的编码结果长这样」的例子，不如先把编码表的字段和取值范围定清楚。 字段名和取值本身就在告诉它该怎么填——这比例子更不容易把它框死在你举的那三种情况里。

站里结构化输出那篇讲的表头式提示词，正是这条原则的落地。

还有一条值得单独记：官方说「HTML 样稿比文字描述或截图产生更好的结果」。这和站里别让它输出一堵 Markdown 墙是同一位作者写的，两篇可以对照着读——给它 HTML，也让它产出 HTML。

最后，/doctor 这个命令值得你现在就跑一遍。如果你的 CLAUDE.md 是几个月前照着老经验堆起来的，它大概率该减肥了。

出处

本文译自 Anthropic 官方博客，原文 The new rules of context engineering for Claude 5 generation models， 作者 Thariq Shihipar，发表于 2026 年 7 月 24 日。译文与译后附记由 HiBridge 撰写。