来源：Thariq (@trq212), Claude Code @ Anthropic — “The new rules of context engineering for Claude 5 models” 原文链接：https://x.com/trq212/status/2080710971228918066 分析完成时间：2026-07-25 22:00:00

Claude 5 时代的上下文工程新法则：Anthropic 砍掉 80% system prompt 之后学到了什么

翻译

我之前写过如何最好地 prompt 最新一代 Claude 5 模型，以及如何与它们迭代协作来发现你想构建的东西。

但当你给 Claude 发消息时，prompt 只是它得到的上下文的一小部分。你的大部分上下文是由 system prompt、Skills、CLAUDE.md 文件、memory 和其他来源组装而成的。我们把这叫做上下文工程（context engineering），它对你在使用 Claude Code 或构建自己的 agent 时生成的结果有巨大影响。

与 prompt 不同，上下文是在许多请求中通用使用的，所以它不能那么具体。当你不知道用户的 prompt 可能是什么时，如何为 Claude 构建这些通用 prompt 和指导？

这可能出奇地困难，因为 Claude 自身的能力在演进。最近，我们注意到在 prompt 最新一代 Claude 模型的方式上有一次大跃迁。我们为 Claude Opus 5 和 Claude Fable 5 这样的模型删除了超过 80% 的 Claude Code system prompt，而在我们的编码评估上没有可测量的损失。

以下是我们在 prompt 这一新一代模型时学到的，以及你如何利用它来更新你的上下文工程。我们已把这些最佳实践放进 claude doctor，在 Claude Code 里用 /doctor 命令来给你的 skills 和 CLAUDE.md 文件瘦身。

解除 Claude 的束缚（Unhobbling Claude）

总体上，我们发现我们过度约束了 Claude Code——无论是在 system prompt 里，还是在 CLAUDE.md 文件和 skills 里。

例如，当我们读自己内部使用 Claude Code 的 transcript 时，我们在单个请求里看到几条相互冲突的消息，比如"留下适当的文档"，或者"不要加注释"——我们的 system prompt、skills 和用户请求相互冲突。

通常，Claude 能解读用户意图到达正确答案，但 Claude 必须在决定做什么之前更仔细地思考这些重叠和冲突的消息。

而这些约束曾经是避免 worst case scenario（最坏情况）所必需的，后来我们发现可以删除其中许多，让模型用周围的上下文和判断来代替。

此外，Claude Code 现在有了更多工具。Claude 过去依赖 CLAUDE.md 作为 memory、信息和指导的来源。现在我们有了 memory、artifacts 和 skills，Claude 可以用它们创造跨 session 加载和分享上下文的新方式。

过去与现在（Then and now）

有许多以前的上下文工程最佳实践已经变成了迷思。包括：

过去：给 Claude 规则 / 现在：让 Claude 用判断

当我们最初推出 Claude Code 时，我们需要确保 Claude 避免 worst case scenario，比如删除文件。这意味着我们会给出特别强的指导，而这些指导并不总是正确的。例如，在 system prompt 里我们过去会说：

在写代码时：默认不写注释。永远不要写多段 docstring 或多行注释块——最多一行短注释。除非用户要求，否则不要创建规划、决策或分析文档——从对话上下文工作，而不是中间文件。

但对于某一部分 prompt，这种指导是错的。在文档这件事上，用户可能有自己的偏好，或者非常复杂的代码的某些部分可能需要多行注释块。

尽管如此，没有这些 guardrail，旧模型的 Claude 写的注释在很多情况下会是错的，我们不得不接受这个权衡。但新模型有更好的判断，能在没有显式规则的情况下处理好这些决定。

在新的 system prompt 里我们说：写读起来像周围代码的代码：匹配它的注释密度、命名和惯例。

过去：给 Claude 示例 / 现在：设计接口

工具使用排第一的规则是给 Claude 怎么使用它们的示例。对于最新模型，我们发现给示例实际上会把它们约束在某个探索空间里。

与其用示例，不如多想想你的工具、脚本和文件的设计——Claude 有哪些参数，它们如何能更有表现力？

例如，在 Todo 工具的例子里，只把 status 列成 pending、in_progress、completed 的枚举，就给 Claude 暗示了如何使用它。保留一个 item 为 in_progress 的指令帮助定义了我们请求的行为。

过去：全 upfront 放进去 / 现在：用渐进式披露（progressive disclosure）

因为 Claude Code 聚焦于编码，我们的 system prompt 包含了如何做代码审查和验证的详细信息。这些并不总是需要，但需要时是关键信息。

从那以后，Claude Code 变得非常擅长使用渐进式披露——在对的时间加载对的上下文。例如，我们把验证和代码审查移到它们自己的 skills 里，让 Claude Code 选择性地调用。

但渐进式披露不只是给 skills 用的，我们也把它用在工具上。我们的一些工具是"延迟加载（deferred loading）“的，意思是 agent 在使用它们之前必须用 ToolSearch 搜索它们的完整定义。这让我们能拥有更多工具（比如我们的 Task 工具），它们在需要之前不占上下文。

这同样适用于你自己的 CLAUDE.md 和 Skill.md 文件。一个常见的迷思是你想让这些成为你可能遇到的每个已知实践的中央仓库，因为 Claude 否则找不到它。相反，考虑用一棵文件树，在对的时间加载。

过去：重复自己 / 现在：简单的工具描述

早期 Claude 模型有时需要重复指令，或者更倾向于听从上下文窗口末尾的指令而不是开头。这意味着我们的 system prompt 有时在主 system prompt 里引用工具，同时也在工具描述里有指令。

我们发现我们可以删除这些重复示例，把如何使用工具的指令放在工具描述里，而不是 system prompt 里。

过去：CLAUDE.md 里的 memory / 现在：自动 memory

我们过去鼓励用户把东西存到 Claude 的 memory 里，用 # 热键自动写到 CLAUDE.md。相反，Claude 现在会自动保存与工作和与你相关的 memory。

过去：简单的 spec / 现在：丰富的引用（references）

在 plan mode 里，Claude Code 重度依赖带计划的 markdown 文件。把这些文件存为计划帮助 Claude 在需要时引用它们。另一个类似的最佳实践是把 spec 存在代码库里，让 Claude 在跨较长项目工作时引用。

但我们发现 Claude 能处理越来越复杂的引用。除了简单的 markdown 文件，Claude 能引用由我们新 artifacts 功能创建的 HTML artifact。

你也可以用代码的形式给 Claude 引用。一个 spec 也可以是一个详细的测试套件，或者是 Claude 可能移植的另一个代码库里的函数。

**Rubric（评分准则）**是另一种引用形式。Rubric 让 Claude 通过动态工作流和用这些 rubric 启动 verifier agent，来尝试验证你在某个特定领域的品味（比如一个好的 API 设计长什么样）。

把这应用到你的上下文

把这些整合起来，当你组装上下文时长什么样？

System Prompt（系统提示词）

System prompt 与产品上下文紧密绑定。它告诉 Claude 它运行在什么产品里、在做什么。对于 Claude Code，你很可能永远不修改这个，但如果你在构建自己的 agent harness，这是你该花大量时间的地方。

CLAUDE.md

保持你的 CLAUDE.md 轻量，简要描述你的 repo 是干什么的，但把大多数 token 花在代码库内部的 **gotcha（陷阱）**上。例如，你可能组织代码把类型放在一个 monolithic 文件里而不是别处。避免陈述那些 Claude 通过看你的文件系统或 repo 就能知道的"显而易见"的事。

对更多细节用渐进式披露，例如如果你有几条关于如何验证你工作的独特指令，创建一个 verification skill 并从 CLAUDE.md 引用它。

Skills

把 skills 想成轻量级指南，让 Claude 在需要时找到信息。避免过度约束它们，除了在极其重要的领域。

对长 skill，尽量多用渐进式披露——把它分成多个文件拆开。

最好让 skill 编码特定的、属于你、你团队或你产品的观点、知识或最佳实践。

References（引用）

你可以 @ 提及文件把它们作为引用包含进来。引用让 Claude 参考关于当前计划的深入信息。

这可能是 spec 文件、mockup，甚至整个代码库。通常你应该优先用代码里的文件，因为它用 Claude 非常熟悉的语言提供了清晰、高保真的指令。例如，一个设计的 HTML mockup 通常会比设计的描述或截图产生更好的结果。

试着简化

在你的 system prompt、skills 和 CLAUDE.md 文件里，你可能需要像我们一样简化。我们推出了一个叫 claude doctor 的新命令，会帮你自动做这件事。关于 prompt 更高级模型的更多细节，看我们的 Fable field guide。

深度解读

这篇文章回答的问题： 新一代 Claude 5 模型（Opus 5 / Fable 5）时代，system prompt、skills、CLAUDE.md 该怎么写？ 这篇文章应该回答但没回答的问题： 那 80% 被删掉的约束具体是哪些？编码评估（coding eval）无损 ≠ 全场景无损，安全/工具调用/edge case 怎么验证的？

Part 1 · Magazine Article（工程级解读）

80% 删除背后的真实因果：是模型变强了，还是约束本就多余？

Thariq 这篇文章表面在讲"如何写 context”，但真正有信息量的点藏在第一段：为 Opus 5 和 Fable 5 删掉 80% 的 Claude Code system prompt，编码评估无可测量损失。 这句话被社区用一条评论精准戳穿了——

@summeroff：更简单的解释：新模型是用海量文本训练的，这些文本由前代模型 + 长 system prompt + skills 生成。期望的行为已经被烤进权重里了。一旦如此，重述同样的规则就变得冗余（甚至通过冲突信号主动有害）。

这才是因果链的真相。这不是"Anthropic 发现了新的 prompt 哲学"，而是新一代模型在训练阶段就把旧行为内化了。system prompt 里那些"不要写注释"“不要创建文档"的约束，本质是上一代模型能力不足时的脚手架——脚手架拆了，是因为楼盖好了，不是因为脚手架多余。这个区分很关键：如果你还在用上一代模型（Sonnet 4.x / Haiku），照搬"删约束"会翻车。

核心架构：把 context 当成运行时，而不是配置文件

文章最重要的思维转换是：context 不是一份静态配置，而是一个运行时系统（runtime）。它有加载时机、有作用域、有冲突消解逻辑。Thariq 给的 6 个 Then→Now 转变，本质是在说同一件事——把 context 从"一把梭的全局配置"重构成"分层、按需、可路由的运行时”。

运行时模型：你的 context 在哪里跑？

要真正理解这篇文章，必须搞清楚四类 context 的加载时机和作用域——这是 Thariq 没明说但贯穿全文的架构：

这套分层的设计目标只有一个：让每个 token 都出现在"它被需要的那个时刻"，而不是无脑常驻。 Thariq 反复强调的"progressive disclosure"，本质就是把 context 从"内存常驻"改成"惰性加载"。

DIY 对比：手搓版 vs 官方版

在 /doctor 和这套方法论出现之前，社区是怎么手动做"上下文工程"的？

选型决策框架：什么时候该删，什么时候该留？

这是文章最该讲却没讲透的部分。结合评论里 @sabialab 和 @BuiltByEstrada 的实战，我提炼出一条**“写死 vs 交给判断"的分界线**：

@sabialab（实战案例）：编辑部总规范从 29500 字符压到 11900，只留红线加一张路由表，细则全下沉到各域正本，改完子 agent 两跳找正本 4/4 命中。之前最坑的是同一条规则在三份文件里各写一遍，改一处漏一处，模型照旧值执行。现在硬写死的只剩数值型（色值/尺寸/命令逐字照抄），因为那类"差不多"本身就是缺陷。

诚实限制：文章没说的几个坑

1. 编码评估 ≠ 全场景。“无可测量损失"只覆盖编码 eval。@PublicAI_ 的质疑一针见血：“好奇这有多少能迁移到非编码 agent。“工具调用准确性、长程推理、安全性这些维度文章回避了。
2. 领域知识不能靠"判断”。@BuiltByEstrada 的开放问题击中要害：“没有那些规则，代码 agent 怎么知道一个建筑公司到底是什么？draw schedules、lien releases、change orders——这些都不在 repo 里。” 模型判断力的边界 = 训练数据覆盖的边界。你的垂直领域如果在预训练里见得少，老老实实写规则。
3. “自动 memory"是黑盒。文章说 Claude 现在"自动保存相关 memory”，但没说相关性怎么判定、出错怎么纠。这把"我控制记忆"变成了"模型替我决定记什么”——对 power user 是控制力的退步。
4. 利益相关。删 80% system prompt 的一个直接后果是每次请求的 input token 大幅下降——这是真金白银的成本节省。推广 /doctor 让用户也简化自己的 context，进一步降低全平台 token 消耗。这不是阴谋，但读这篇文章时要记住：简化的方向恰好和降本方向一致。

Part 2 · Socratic Dialogue（苏格拉底对话）

学生（尾巴）：我看到"删掉 80% system prompt 无损"第一反应是——那我现在的 CLAUDE.md 是不是也该大砍一刀？

老师：先停一下。你注意到没有，Thariq 说的是"为 Opus 5 和 Fable 5 删掉的”。他没说 Sonnet 4.6 也能删。你觉得这个前提意味着什么？

学生：意思是……能不能删，取决于模型版本？

老师：对。更准确地说，取决于模型有没有把那些规则内化进权重。@summeroff 那条评论说破了——新模型训练时就见过大量带旧 system prompt 的数据，行为已经"烤进去"了。你猜，如果你还在用 Sonnet 4.6，照搬"删约束"会发生什么？

学生：旧模型没内化那些行为，删了约束可能 worst case 就回来了——乱删文件、乱写注释？

老师：正是。所以第一性原理不是"该不该删”，而是”这条规则，是这个模型已经知道的事，还是它不知道的事？“你知道的事写一遍是噪声，不知道的事删了是事故。

学生：那我怎么判断模型"知不知道”？这条线很难画。

老师：@sabialab 给了一个可操作的判据——“差不多算不算缺陷”。色值差一点是 bug，所以写死；注释多一行少一行不是 bug，所以交给判断。换句话说：写死的标准是"错了就有客观损失"，交给判断的标准是"错了只是风格差异"。

学生：那领域知识呢？@BuiltByEstrada 说建筑公司的 lien release 这些不在 repo 里，模型也不知道。

老师：这是这篇文章最大的盲区。Thariq 说"let Claude use judgement"，但判断力的天花板是训练数据。垂直领域 = 预训练没见过的东西 = 必须显式写。你的 CLAUDE.md 里那些项目专属的路径、工作流、历史决策——这些不是"规则"，是"知识"。规则可以删，知识不能删。

学生：所以我的 happyclaw 项目里那些"禁止裸启动 node 进程"“pm2 是本地托底”——

老师：——那是用血换来的知识（issue.md 里记着 32GB 内存被挤爆的教训），不是 Anthropic 说的"过度约束"。这种东西删了，下次踩同样的坑。判据很简单：这条 context 背后有没有一个"如果模型不知道就会付出代价"的故事？有，就留。

学生：最后一个问题——Thariq 推 /doctor 自动简化，我能信它吗？

老师：把它当成 code linter，不要当成决策者。它能帮你发现"重复写了三遍的规则"“repo 里显而易见的废话”，这种机械问题是它的强项。但"这条领域知识该不该删"——这种判断它做不了，因为它不知道你的项目故事。自动化的部分交给工具，语义的部分留给人。

Part 3 · Personalized Insights（个性化洞察）

回到你自己的场景——你（尾巴）是重度 Claude Code 用户，CLAUDE.md 已经长到几千字，还有一堆全局 skills。这条文章对你的 5 个直接行动点：

1. 先别动 CLAUDE.md 主体，先跑一次 /doctor 看它指出什么。你 CLAUDE.md 里"诚实规则"“编码行为准则"那些段落，确实有重复（比如"测试声明要实据"和"改代码必须回归全部 testcase"语义重叠）。让 /doctor 当 linter 找冗余，但它建议删的领域知识（happyclaw 启动流程、pm2 托底、RTK proxy 陷阱）你手动 veto——这些都是 issue.md 里有血泪教训的，不能删。

2. 你的 skills 体系已经在做"progressive disclosure"了，但可以更狠。比如 translate-analyze skill 本体已经很长，里面的 references/hn-details.md、references/mermaid-patterns.md 就是文件树拆分。检查点：哪些 skill 的 SKILL.md 超过 5000 字？把"什么时候用"留在主文件，把"具体怎么做"的细节下沉到 references/。/doctor 应该能帮你定位。

3. “数值型必须写死"这条铁律直接可用。你 CLAUDE.md 里飞书 open_id（ou_c4d77609d5fba99f3edb9a2fba1e14bc）、路径（/Users/zhiwei/wiki_workspace/）、端口号（7270）——这些是"差不多就是 bug"的硬约束，绝对不能交给模型判断。但"沟通风格直接利落"这种——可以删，让模型自己判断语气。用 @sabialab 的 29500→11900 砍法做一次审计：把 CLAUDE.md 里的规则分成"数值/路径/ID/安全红线”（留）和"风格/习惯/偏好”（可简化）两类。

4. 别被"自动 memory"忽悠着删掉手动记忆。文章说 Claude 现在自动保存 memory，但你现在的 .claude/projects/.../memory/ + MEMORY.md 索引体系是显式、可审计、跨 session 稳定的。自动 memory 是黑盒（相关性模型决定）。建议：双轨并行——让自动 memory 跑着，但你的全局 CLAUDE.md + issue.md + 日期记忆这套手动体系别拆，那是你的"知识主权"。

5. 最反直觉的一点：这篇文章本身的"工程级解读"方法论，就是你 CLAUDE.md 里"deep-analysis skill + 多信源交叉验证"的产物。Thariq 给的是官方"正确答案"，但真正的价值在评论区——@summeroff 的因果修正、@sabialab 的数字案例、@BuiltByEstrada 的领域知识质疑。这印证了你"区分「大家都这么做」和「这么做是对的」“的规则：删 80% prompt 是"大家都这么做”（官方背书），但"能不能迁移到你的场景"才是"对不对"的问题。

精选评论

@summeroff（因果修正，最关键的反面观点）：更简单的解释：新模型是用海量文本训练的，这些文本由前代模型 + 长 system prompt + skills 生成。期望的行为已经被烤进权重里了。一旦如此，重述同样的规则就变得冗余（甚至通过冲突信号主动有害）。

原文：Simpler explanation: the new models were trained on massive amounts of text generated by previous models + long system prompts + skills. The desired behaviors got baked into the weights.

@sabialab（中文，最有价值的实战案例）：过度约束这条我们前两天刚撞上：编辑部总规范从 29500 字符压到 11900，只留红线加一张路由表，细则全下沉到各域正本，改完子 agent 两跳找正本 4/4 命中。之前最坑的是同一条规则在三份文件里各写一遍，改一处漏一处，模型照旧值执行。现在硬写死的只剩数值型（色值/尺寸/命令逐字照抄），因为那类"差不多"本身就是缺陷。

原文：过度约束这条我们前两天刚撞上：编辑部那份总规范从 29500 字符压到 11900…

@BuiltByEstrada（击中文章盲区）：花了几个月做相反的事，往 agent 文件里塞更多规则。隔夜运行变得更嘈杂而不是更干净。最终砍到只剩模型从 repo 猜不到的 gotchas，把长流程移到只在需要时加载的 skills 里。每次 ship 前仍然读每个 diff。开放问题：没有那些规则，代码 agent 怎么知道一个建筑公司到底是什么？draw schedules、lien releases、change orders——这些都不在 repo 里。

原文：Spent months doing the opposite… Open question though: without those rules, how does a code agent learn what a construction company actually is?

@PublicAI_（点出沉默证据）：砍掉 80% 还能保持性能，说明老 prompt 有多少只是噪声。好奇这有多少能迁移到非编码 agent。

原文：Cutting 80% and keeping performance says a lot about how much of the old prompt was just noise, curious how much of this carries over to non-coding agents.

@ZetsubosenseiG（AeroDefense CTO，战略洞察）：很受启发。直接回答了我一直在想的问题：该投入更多精力设计统一健壮的 orchestrator，还是先聚焦领域知识和真实工作流？随着模型快速变得能处理更复杂任务，答案越来越清晰。

原文：It directly answers a question I’ve been thinking about: should we invest more effort in designing a unified, robust orchestrator, or focus first on building domain knowledge and real workflows?

@seeligmx（/doctor 真实用户反馈）：试过 /doctor 了，确实有用。砍了很多 repo 显而易见的噪声，没丢有用指导。

原文：Tried /doctor already, and it genuinely helped. Cut a lot of repo-obvious noise without losing useful guidance.