Claude 5 之后，上下文工程该做减法了

Anthropic 团队最近披露了一个很有意思的改动。他们为 Claude Opus 5、Claude Fable 5 这类新模型删掉了 Claude Code 系统提示词中超过 80% 的内容，编码评测没有出现可测量的下降。

这个数字很容易被理解成一条新的提示词技巧，仿佛把文件删短，模型就会自动变聪明。更值得开发者留意的是团队为什么敢删，以及那些曾经有效的规则为什么开始妨碍新模型工作。

我把 Anthropic 近来的上下文工程文章、Claude Code 文档和这次分享放在一起看，能看到一条很清楚的变化。模型能力提高以后，开发者给 Agent 准备上下文的方式也要跟着变。过去我们努力把每个动作写死，现在要把有限的注意力留给项目特有的信息、真实约束和当前任务。

删掉 80% 只是一次内部结果。对普通团队更实用的问题，是怎样判断该删什么、该留下什么，以及删完以后如何确认 Agent 没有退步。

Prompt 只是上下文的一部分

很多人用 Claude Code 时，仍把结果好坏归到当前那句话上。任务提示确实重要，模型收到的内容远远更多。系统提示词、CLAUDE.md、Skills、工具定义、记忆、对话历史、代码文件和检索结果都会进入它的工作范围。

Anthropic 对上下文工程的定义很直接。它关心每次推理时，哪些信息应该进入有限的上下文窗口。这里有两个容易忽略的词，一个是有限，另一个是每次。

上下文窗口再大，模型的注意力仍会随着无关内容增加而被摊薄。Anthropic 把这种现象称为 context rot。信息都在窗口里，不等于模型会以同样的精度处理每一条。项目规则写了八千字，其中七千字和当前任务没有关系，那七千字依然要占用注意力。

每次也很重要。同一份 CLAUDE.md 会服务修 Bug、写测试、改文案和排查线上故障。它天然比一次任务提示更笼统。你把某次代码评审总结出的特殊要求永久写进去，几周后它可能在另一个任务里变成错误约束。

这也是上下文工程逐渐取代提示词雕花的原因。开发者面对的工作已经从写一句更聪明的话，变成管理一组会共同影响 Agent 判断的信息。

旧规则为什么开始拖慢新模型

早期编码模型的判断能力有限，团队会用强规则兜住最差结果。禁止删除文件，禁止写长注释，不要创建计划文档，默认不改测试。每一条规则通常都对应一次真实失败。

规则越积越多，冲突也会出现。系统提示词要求按需补文档，团队 Skill 禁止增加注释，用户又明确要求解释复杂算法。Claude 多数时候仍能完成任务，只是它要先花力气判断三层指令怎样兼容。

旧护栏还有一个问题。它把当时模型欠缺的判断力，写成了项目永久需要的规则。模型已经能根据周围代码判断注释密度，系统里却还在逐行规定注释长度。规则继续存在，收益已经消失，限制仍在生效。

Anthropic 新版提示的做法更短。代码应当读起来像周围的代码，命名、习惯和注释密度都跟随现有项目。它给模型一个判断标准，具体动作由模型结合文件决定。

这种改法没有取消约束。约束换了位置，也提高了层级。团队仍然可以规定支付金额必须使用整数、数据库迁移必须可回滚、生产发布需要人工批准。这些要求来自业务、安全和数据风险，模型升级不会让它们过期。

适合删除的是那些替模型代办普通判断的细碎规则。

从规则清单改成判断边界

一份越来越长的 CLAUDE.md 往往长成这样。

- 不要在简单函数上写注释
- 复杂函数可以写一行注释
- 不要写多行注释
- 修改旧代码时保留已有注释
- 发现错误注释时必须更新
- 测试里的注释可以例外

六条都讲注释，模型还得判断什么叫简单，什么叫复杂。更短的版本反而提供了更可靠的依据。

代码风格跟随相邻文件，包括命名、结构和注释密度。只保留能解释非显然约束的注释。

这种写法适合有判断空间的事情。格式、命名、局部实现、注释数量和文件组织，只要项目里已有稳定范例，先让 Agent 阅读现有代码。

有些事情不能交给临场判断。权限边界、密钥处理、不可逆删除、财务计算、生产环境操作和合规要求，需要清楚且可检查的硬约束。删上下文时，先把这些内容圈出来。它们应该更显眼，不该和几十条代码偏好混在一起。

一个简单判断方法很好用。删掉某条规则以后，Agent 能否从代码、测试、工具权限或任务本身得到同样结论。能得到，就考虑删除。得不到，而且出错代价很高，就留下。

工具设计开始比调用示例更重要

过去写工具说明，常见做法是塞进很多调用示例。模型看完例子，照着已有路径走，成功率通常会提高。新一代模型更擅长理解类型、参数和返回值，过多例子会把探索范围锁在作者预想的几种组合里。

假设一个待办工具只有三个状态。与其写五段完整调用，不如让接口自己表达约束。

{
  "status": "pending | in_progress | completed"
}

再补一句同一时间只保留一个 in_progress，行为边界已经很清楚。模型可以根据任务长度安排条目，无需模仿某个固定示例。

这条经验也有边界。输出格式非常严格、协议容易误用、少数错误会造成高损失时，经过筛选的标准示例依然有价值。Anthropic 早先的上下文工程文章也建议保留少量、多样且典型的示例。Claude 5 带来的变化，是开发者需要重新检查每个例子承担的工作。

接口能表达的约束，交给类型、枚举、必填字段和权限。例子只留下接口无法说明的判断。

渐进披露让上下文按需出现

Claude Code 早期把代码评审、验证方法和工具规则放进系统提示词，因为模型未必知道去哪里找。现在 Agent 能主动读文件、搜索工具，也能在需要时加载 Skill。把所有知识预先塞进上下文，代价已经高过收益。

渐进披露的做法很像一个维护得当的代码库。入口文件只告诉人去哪里找，细节留在对应模块。

CLAUDE.md
skills/
  verification/
    SKILL.md
  database-migration/
    SKILL.md
docs/
  architecture.md
  release.md

根目录的 CLAUDE.md 不再承担团队百科全书的工作。它简要说明仓库用途，写下最容易踩中的项目陷阱，再指向验证、迁移和发布资料。Agent 修一个按钮样式时，不必同时阅读数据库回滚流程。它准备迁移表结构时，再加载迁移 Skill。

工具也可以采用同样思路。常用工具保留简洁定义，低频工具只暴露名称和用途，Agent 确定需要以后再读取完整参数。工具数量增加时，这种延迟加载能省下大量无关上下文。

渐进披露并不等于把文件切得越碎越好。一个 Skill 只有十几行，再拆成五个文件，Agent 会把注意力花在来回导航上。拆分的依据应当是调用时机。经常一起使用的内容放在一起，只有特定任务才需要的内容独立出去。

CLAUDE.md 应该留下哪些内容

Anthropic 给出的方向很克制。文件要轻，先简要说明仓库做什么，主要篇幅留给代码库里的特殊陷阱。

特殊陷阱通常有几个共同点。开发者只看目录结构不容易知道，模型按常见习惯处理会出错，而且这条信息会在多个任务中反复用到。

下面这类内容值得保留。

# 项目

这是一个多租户账单服务。API 位于 apps/api，共享计费逻辑位于 packages/billing。

# 项目约束

- 金额统一用分存储，禁止使用浮点数
- 类型集中在 packages/types，业务目录不新建重复类型
- 集成测试依赖本地 Postgres，运行方法见 skills/verification/SKILL.md
- 生产迁移需要人工批准

下面这些内容通常可以删掉。

• 从目录和 package.json 一眼能看出的技术栈
• 语言本身的常识
• 已由格式化工具和 Linter 强制执行的规则
• 只在单个任务里出现过的临时要求
• 同一条要求在多个文件中的重复版本
• 没人能解释来源，也没有失败案例支撑的禁令

如果某条规则可以变成机器检查，把它放进 Linter、类型系统、测试或 CI。文字提醒要靠模型每次理解和遵守，机器检查能给出稳定结果。上下文也因此空出位置，留给机器无法判断的业务意图。

记忆和项目规则要分开

早期用法会把很多个人偏好写进 CLAUDE.md。文件很快混入项目架构、用户习惯、某次排障记录和临时命令，团队成员看到的是同一份文件，实际需要的信息却不同。

Claude Code 的记忆能力让这几类信息有了不同去处。项目成员都要遵守的稳定事实放在项目规则里。个人工作偏好放在用户记忆里。一次任务的输入留在对话或引用文件中。可复用且只在特定工作出现的方法，放进 Skill。

边界分清以后，维护也轻松很多。项目规则可以随代码评审，个人偏好不会污染仓库，Skill 可以独立更新。Agent 每次拿到的内容更接近眼下要做的事。

自动记忆也不能代替团队规范。记忆可能来自个人历史，项目规则则需要版本控制和共同确认。凡是会影响其他开发者、生产环境或数据安全的要求，仍应放在团队可见、可审查的位置。

规格文件正在变得更接近成品

过去给 Agent 写规格，开发者会尽量把它压成一份简单 Markdown。现在模型可以处理更丰富的参考物，代码、测试、HTML 原型和完整的相邻实现都能成为规格。

要做一个页面，HTML 原型通常比一段视觉形容更准确。要移植一个函数，原仓库里的实现比重新复述算法更可靠。要约束 API 行为，一组覆盖边界的测试往往比十条自然语言规定更清楚。

参考物的价值来自信息保真度。截图告诉模型页面长什么样，HTML 还告诉它层级、尺寸和交互结构。文字说"兼容旧接口"很含糊，测试能明确哪些输入必须继续通过。

这不意味着所有需求都要先做一份原型。已有高保真材料就直接引用，别再把它翻译成一份损失细节的摘要。只有口头想法时，简单规格仍然够用。

一次可执行的上下文瘦身

想整理现有项目，可以从一次四十分钟的清理开始。不要先追求 80% 这个数字，那是 Anthropic 在特定模型和评测上的结果，不能当成通用 KPI。

先列出当前会进入 Agent 上下文的来源，包括系统提示词、仓库规则、子目录规则、Skills、工具说明、记忆和自动加载文件。很多团队做到这里才发现，同一条测试要求出现了三遍。

接着给每段内容标一个去向。

内容	处理方式
安全、权限和不可逆操作	保留硬约束
项目特有且反复出现的陷阱	留在 CLAUDE.md
特定任务才需要的方法	移到 Skill
类型或工具参数能表达的规则	移到接口
Linter、测试和 CI 能检查的规则	交给机器检查
代码中已经很清楚的事实	删除
单次任务偏好	留在任务提示里

然后检查冲突。同一件事只有一个权威位置，其他文件通过引用找到它。发布流程写在发布 Skill，CLAUDE.md 只负责告诉 Agent 何时读取，不再复制一遍。

最后用真实任务做对照。挑十到二十个团队常见任务，覆盖改 Bug、加功能、写测试、做重构和处理高风险操作。旧上下文跑一轮，精简版再跑一轮，比较任务是否完成、改动是否越界、测试是否通过以及人工修正次数。

没有这一步，删文件只是一次审美活动。Anthropic 能说编码评测没有可测量损失，前提正是他们有评测。普通团队不需要搭一套庞大平台，保留一组真实任务和检查清单已经能看出方向。

80% 这个数字不能照抄

这次改动最容易带来另一个极端。有人会把长规则全部删掉，只留一句"请使用你的最佳判断"。这样的上下文很短，也很可能缺少项目知识。

Anthropic 在上下文工程文章里给出的原则，是寻找能提高目标行为概率的最小高信号信息集合。这里同时要求小和高信号。只追求短，会让模型猜测业务背景。只追求全，会让模型在重复与冲突里分配注意力。

模型越强，越适合把局部实现交给它判断。业务边界仍由人提供。一个 Agent 可以读懂周围代码的命名习惯，却无法凭空知道退款超过五千元必须由两个人审批。它能选择合理的重构方式，也不知道团队下周要停用哪个旧服务。

上下文工程最后处理的是分工。代码和工具负责表达能被机器确定的事实，Skill 保存按需调用的方法，记忆保存个人且可复用的偏好，项目规则写下仓库独有的约束，当前任务则说明这一次究竟要完成什么。

当每类信息回到合适的位置，CLAUDE.md 会自然变短。Agent 少读一些无关规则，也少猜一些没写出来的项目事实。删掉多少已经不太重要。每一段留下来的文字，都应该能解释自己为什么必须在这里。

发布前可直接检查

• 同一条规则是否写了两遍
• 这条信息能否从代码或目录直接读出
• Linter、类型、测试或权限能否稳定执行它
• 它是否只在一种任务中需要
• 它和其他规则有没有冲突
• 删除以后，模型是否仍能从现有材料得出正确判断
• 出错会影响安全、资金、数据或生产环境吗
• 精简前后是否跑过同一组真实任务

第一次清理时，可以先删重复规则，再把只服务特定任务的内容移进 Skill。完成这两步，通常就能看到上下文轻了多少，也能看出哪些项目约束确实不能少。