Anthropic删除Claude Code 80%提示词的启示：上下文工程新规则

一个反直觉的动作：删掉80%系统提示词

Anthropic做了一件看起来相当激进的事情：他们把Claude Code的系统提示词删除了80%以上。更让人意外的是，删除之后跑完官方评测，成绩竟然一点没有下降。

这个动作出自Anthropic工程师撰写的一篇文章，主题是Claude 4/5时代模型的上下文工程规则。它与之前那篇《Faber指南：找到你的未知》形成了呼应——上一篇讲的是如何向AI提问、如何把你不知道的能力挖出来；而这一篇讲的恰恰相反：把模型不需要的东西从上下文里删掉，反而能提升Agent的能力。

这两个方向看似矛盾，实则统一：一个是做加法（挖掘），一个是做减法（精简），核心都是让上下文里只保留真正有用的信息。

提示词工程与上下文工程的核心区别

文章首先厘清了一个容易混淆的概念。你发给AI的每一句话，只是它收到内容的一小部分，剩下的大头是系统提示词、CLAUDE.md文件、记忆、Skills等等。这些东西拼在一起，才是AI每次干活真正读到的"全部"，这个整体叫做上下文（Context），而管理这一堆东西的工作，就叫上下文工程。

要理解为什么上下文管理如此重要，需要了解一个技术背景：大语言模型基于Transformer架构中的自注意力机制（Self-Attention）工作，每个token都要与上下文中的所有其他token计算关联权重。当上下文中存在冗余或矛盾信息时，模型需要在这些互相竞争的信号之间分配注意力权重，这相当于在有限的"认知带宽"中引入了噪声。研究表明，当上下文长度增加时，模型对中间段落的关注度会显著下降（即"Lost in the Middle"现象），而矛盾指令更会迫使模型在解码阶段进行额外的"调解"计算，降低输出质量。

它与提示词工程的关键区别在于：

• 提示词工程：只管这一次请求的输入优化
• 上下文工程：跨多次请求通用的信息管理

反过来说，上下文里写错一句话，拖累的是之后的每一次请求。这正是Anthropic敢于大刀阔斧删除提示词的底层逻辑——上下文里的冗余和矛盾，会持续消耗模型的注意力。

为什么要删？因为规则在"互相打架"

Anthropic在读取内部员工使用Claude Code的对话转写记录时发现了一个问题：在同一个请求里，AI会同时收到互相矛盾的指令。

比如一边是"适当保留文档"，一边是"禁止写注释"；系统提示词说一套，Skill说一套，用户又说一套。模型通常能猜出你真正想要什么，但它必须先花费注意力去调解这些矛盾，才能开始干活。

这里有必要解释一下Claude Code的信息分层架构：它的上下文由多层信息构成——最底层是系统提示词（System Prompt），定义了模型的基本行为边界；之上是CLAUDE.md文件，相当于项目级的配置说明；再往上是Skills（技能模块），是可按需加载的专项指令集；最外层才是用户的即时输入。这种分层架构意味着，每一次模型执行任务时，实际读取的token数量远超用户肉眼可见的对话内容，任何一层的臃肿都会在每一次调用中产生复利式的性能损耗。当多个层级的指令互相矛盾时，模型的"调解成本"也会成倍放大。

这些规则的来源，是因为旧模型判断力不够，需要强加约束。但新一代模型（Opus/Sonnet系列）的能力和判断力都已经足够，很多"保险措施"可以直接拆掉，让它根据现场情况自己判断。

这一变化反映了AI工程领域一个深层的范式转变：从规则驱动到能力驱动。早期模型（如GPT-3.5、Claude 2）的指令遵循能力较弱，工程师不得不用大量硬编码规则来约束行为——这本质上是一种"防御性编程"思维。但随着RLHF（基于人类反馈的强化学习）和Constitutional AI等对齐技术的进步，新一代模型已经内化了大量行为规范和判断能力。此时过多的外部规则不仅冗余，还可能与模型内化的判断产生冲突，形成"双重约束"困境，反而降低表现。这与软件工程中"过度配置反而增加系统脆弱性"的经验高度类似。

六条上下文工程新规则详解

文章给出了六条具体的解决办法，可以理解为新时代的上下文工程原则。

规则一：相信模型判断力，少写禁令

旧系统提示词里写满了"默认不写注释""永远不许写多段注释块""不许自建规划决策文档"之类的禁令。但这些禁令在很多场景根本没用——用户可能有自己的文档偏好，复杂代码本就需要多段注释。

新系统提示词把这一整段直接换成一句话：写出来的代码要像周围的代码——注释密度、命名习惯，都根据现场仓库的情况走。

规则二：让工具本身"会说话"

过去教AI使用工具时，我们习惯给示例来引导。但在新模型上，这种示例反而会把模型框死在一个套路里，锁住它本可以探索的空间。

原文的例子很精彩：待办工具的状态只有三个——进行中、已完成，再加一条"同时只能有一项进行中"。状态值本身就告诉了模型该怎么干，不需要再写一堆示例说明什么叫"进行中"。这也解释了为什么在新模型上想让它发散思维时，它有时反而"听不懂"——正是被旧的框架给锁死了。

规则三：按需加载（渐进式披露）

以前"代码审查怎么做""验证怎么做"全部写在系统提示词里，无论这次用不用得上。现在这些被拆成独立的Skill，用到时才加载。官方称之为渐进式披露，本质就是Skills一直强调的"按需加载"。

渐进式披露（Progressive Disclosure）原本是人机交互（HCI）领域的经典设计原则，由IBM研究员在1980年代提出，核心思想是：只在用户需要时才展示复杂信息，避免一次性呈现所有选项导致认知过载。Anthropic将这一原则迁移到AI上下文管理中，意味着他们开始把模型当作一个"有认知负荷上限的智能体"来对待。在实现层面，Skills被拆分为独立文件后，Claude Code的路由机制会根据当前任务类型动态加载相关Skill，而非在每次对话启动时把所有指令一股脑塞进上下文窗口。这种设计不仅节省了宝贵的上下文空间，还避免了无关指令对当前任务的干扰。

值得一提的是，这套"路由规则、hooks、skill分开存放"的做法，已经有实践者提前摸索出来，现在官方等于把它写进了系统提示词。

规则四：重要的话说一遍就够

旧模型有个毛病：开头的指令记不牢，更爱听结尾的指令。所以官方过去写提示词时，喜欢先写一遍用法，再在每个工具里重复一遍。现在这些重复全部删掉——工具怎么用只写在工具里，调用时才读取，不再占用系统提示词的空间。

这一改变的技术基础在于新模型对长上下文的处理能力大幅提升。早期模型受限于位置编码和注意力衰减，对上下文开头和中间部分的信息容易"遗忘"，因此重复强调是一种无奈的工程妥协。而新一代模型通过改进的注意力架构，能够更均匀地关注上下文各个位置的信息，使得"说一遍就够"成为可能。

规则五：自动记忆代替手动笔记

以前需要手动记笔记，现在由模型自己判断什么值得存储。这一条将记忆管理的主动权交给了模型本身，减少了用户的维护负担。

规则六：给丰富的参照物，而非简单文档

以前计划模式靠Markdown存计划和规格。现在模型能吃下复杂得多的参照物：HTML原型、一套测试用例、甚至别的代码库里的现成函数，都可以直接当规格用。

文中还提到一种参照物叫评分标准——把你的品位写成标准，让AI开着验证代理拿这个标准去核对。这种做法在AI工程领域被称为LLM-as-Judge模式，其核心思路是用一个独立的AI代理作为"质检员"，根据预设标准对另一个AI代理的输出进行评估。这种方法最早在学术论文评审自动化中被广泛验证，后来被引入软件开发流程。它的优势在于将主观的"品味"和"偏好"转化为可执行的评估协议，使AI的输出质量具备可复现的验证路径。在Claude Code中，这意味着用户可以把"我喜欢简洁的函数命名""错误处理要覆盖边界情况"等个人偏好写成结构化标准，交给验证代理自动执行，从而实现"审美可编程"。

对普通用户的实操建议

这套上下文工程方法论落到普通用户身上，可以提炼成几条实操建议：

• 系统提示词不用管：只有自建Agent的人才需要在这里下功夫，普通用户感知不强。
• CLAUDE.md要轻量化：简单说清这个仓库是干嘛的，写一些只有你才知道的信息（比如称呼偏好）。AI能从代码里看出来的东西，就别再重复写进去。
• Skills做成轻量指南：别写成条例，最值钱的是装着你自己观点和工作流的那种Skill。长Skill拆成多个文件，继续按需加载。
• 善用参照物：现在可以直接把参照物输入给它——这个功能在Codex、VS Code里早已实现，但这是Claude Code第一次正式提出。

此外，官方还做了一个便捷命令：在对话里输入/doctor，会自动给你的Skills和CLAUDE.md文件做一次"体检"和优化。这个命令背后的逻辑正是本文讨论的上下文工程原则——它会检测你的配置文件中是否存在冗余指令、矛盾规则或可以迁移到Skills中的内容，然后给出精简建议。

核心启示：删掉给旧模型打的补丁

整篇文章的核心，其实可以浓缩成一句话：模型能力足够强大之后，就不需要那么多规则去束缚它。

我们过去写的那些规则，本质上是在给旧模型"打补丁"。模型升级之后，这些补丁不但没用，反而会变成模型的绊脚石——它会占用注意力、制造矛盾、锁死探索空间。

这或许是上下文工程走向成熟的一个重要信号：从"事无巨细地告诉AI怎么做"，转向"给它足够的判断空间和优质的参照物"。这个转变让人联想到管理学中的一个经典命题——微观管理（Micromanagement）与授权管理（Empowerment）的对比。当团队成员能力不足时，事无巨细的指令是必要的；但当成员足够成熟时，过度的指令反而会抑制创造力和判断力。AI模型的演进正在经历同样的阶段跃迁：从需要手把手教的"初级员工"，成长为只需要目标和参照物就能自主交付的"资深专家"。

做减法，有时比做加法更需要功力。

核心要点