A 社官方：我们删掉了 80% 的 skills

虽然A社最近有操作确实让人不太舒服，但他们在技术文章上的功力，是不得不服的。所以，批评归批评，该学的东西还得学。

7月24日，Anthropic发布了一篇关于上下文工程的文章，其中有一个核心观点相当炸裂：他们为Claude Opus 5、Claude Fable 5这类新模型，删掉了超过80%的system prompt，结果在编码测评中，性能几乎没有下降。

这意味着什么？意味着我们过去辛辛苦苦堆砌的那些规则，一大半可能已经过时了，甚至是在帮倒忙？

这篇文章就从这个问题切入，然后一起把整个逻辑链条理清楚。

现在，随着Kimi K3、Fable 5、Opus 5、GPT-5.6 Sol这些大模型的能力越来越强，很多时候，给模型加技能（Skills）并不见得是越多越好，相反，可能还会成为模型的负担。

文章的核心观点非常明确：在强模型时代，上下文工程的核心思路，是做减法。

在恰当的时机，给模型最有效的信息。

过去的约束和现在的判断

Anthropic之前在上下文工程指南里，提过一个非常重要的概念：模型有有限的attention budget（可以理解为注意力资源）。

上下文窗口再长，并不代表模型的注意力会同步增长。

你每多加一条无关的规则，模型就得花一部分注意力去判断它有没有用；如果加了优先级规则，它还得琢磨先听谁的。

结果就是，上下文看起来内容很丰富，但实际上有效的注意力反而被稀释了。

所以，80%这个数字，真正想说的是：新一代模型的判断力已经强到可以信任了。很多过去需要写死的行为，现在完全可以交给模型自己来判断。

当然，判断的依据是代码库、用户要求和环境信息等。

官方把这次变化总结成了六组“旧做法”与“新做法”的对比：

图源：Anthropic

这六组变化，可以归纳为一句话：以前靠规则来约束模型做决定，现在是把引用来源说清楚，让模型自己做决定。

摆脱束缚的Claude

Anthropic在复盘Claude Code的运行记录时，发现了一个有趣的现象：同一个请求里，经常会出现几种互相矛盾的指令。

比如，System prompt说“不要添加注释”，Skill说“必要时补充文档”，用户又要求“复杂代码需要把文档写清楚”。

图源：Anthropic

Claude通常能猜到用户想要什么，但它得先处理这些上下文之间的冲突。

旧的system prompt倾向于把注释行为写死：不写注释，不写多段文档字符串，不主动创建规划或分析文档。

这种做法确实能纠正旧模型的一些坏习惯，比如过度生成注释，或者替代码编造设计意图。

但代价也很明显：当遇到复杂代码或确实需要记录设计决策的任务时，它反而会阻止模型补充必要的信息。

所以，新的system prompt只保留了一个核心规定：

总结一下：一份有效的、需要长期遵守的规则，应该告诉模型“怎么判断”，而不是替它“做决定”。

模型会自己读代码，自己判断要不要写注释。

Design interfaces

以前教模型使用工具，常见的做法是提供几个调用示例。但Anthropic发现，对于Claude 5这类模型，这样做反而可能限制住它的能力。

他们举了一个TODO工具的例子：

图源：Anthropic

这个TODO工具只做了两件事：把状态限制为pending、in_progress和completed，再规定同时只能有一个in_progress。Claude看到参数，就知道该怎么维护任务状态了。

能写进接口的约束，就别往system prompt里面写了。

context

Claude Code过去把代码审查、验证和工具用法全塞在system prompt里。但问题是，多数任务根本用不到这些内容，它们却每次都在消耗模型的注意力。

现在，这部分内容被拆分到了Skills和延迟加载的工具中。

需要验证时，再加载验证Skill；需要使用某个工具时，先通过ToolSearch找到完整定义，平时只保留名称、用途和文件路径，让Claude知道工具在哪里。

这种策略叫做progressive disclosure，也就是渐进式披露。

这个原则同样适用于CLAUDE.md。它应该只保存每次任务都需要知道的内容，比如项目用途、构建命令、特殊目录和代码库里的坑。

Claude Code现在建议每个CLAUDE.md尽量控制在200行以内。

真要节省context空间，就要用按路径加载的rules，或者把任务流程做成Skill。

memory也有了更清晰的分工。

比如一个Ja vaScript项目的CLAUDE.md，可以这样写：

- 修改 Ja vaScript 后运行 `npm test`。- 安装依赖优先使用 `pnpm`。- API handler 统一放在 `src/api/handlers/`。

这些是你主动定下的规矩，每次工作都要遵守。

而auto memory里则可能出现：

- 本地 Redis 没启动时，集成测试会报 `ECONNREFUSED`。- 修改 schema 后，需要重新生成类型，否则测试会读到旧类型。- 用户喜欢 PR 说明先写风险，再写改动。

这些是Claude在工作过程中发现的经验总结。偶尔遇到一次的报错不用急着写进CLAUDE.md。只有相同问题反复出现，或者团队成员也需要知道时，再把它升级成正式规则。

简单来说：你要求Claude每次遵守的，放在CLAUDE.md里；Claude自己摸索出来的，会进入auto memory。

Reference

另一个重要变化是，reference不再局限于Markdown格式的spec了。

它可以是一份HTML原型、一套测试、另一个仓库里的函数，也可以是一份明确的评分标准。

图源：Anthropic

如果你想Claude做一个页面，给它能运行的HTML，通常比写两页视觉描述更准确。

想让它移植某段行为，直接指向已有代码，比重新解释一遍更直接。

想让它判断什么样的API才算好，就给一套评分标准。比如检查命名、错误格式、权限边界和兼容性，再让另一个Agent按这份标准逐项检查。

Anthropic在Fable 5的使用指南里也给出了相同的判断：在复杂任务中，源代码往往是信息最丰富的reference，因为结构、语义和边界都已经定义好了。

当然，Anthropic原文也保留了边界：Skills在极其重要的领域仍然应该保持严格约束。删除文件、访问敏感数据、对外发送消息、修改生产环境，这类操作不能只靠模型自己判断，必须严格定义。

所以，并不是只要模型判断力强了，所有规则都可以删了。

官方文档说得很明确：CLAUDE.md是上下文，不是强制执行层。真正应该遵守的规定，需要放在permissions、sandbox、hooks和代码里。

可以这样来区分：

涉及代码风格、注释密度、文档习惯，让模型结合项目判断。

涉及权限、合规、资金和不可逆操作，直接强制规定。

总结一下这篇文章的主要内容：

• System prompt：说明Agent拥有什么权限、要完成哪类工作。自己做Agent harness的人，应该主要考虑这块儿。

• CLAUDE.md：只放每次都需要的项目痛点、精确指令和隐蔽的坑。Claude看一眼目录或代码就能知道的内容，要删掉。

• Skills：保存特定任务的操作方法，比如发布、代码审查、前端验证。Skill很长时，把详细reference和脚本拆出去，按需读取。

• Memory：保存工作过程中积累的经验和偏好。

• References：优先给代码、测试、HTML原型和衡量标准。

Claude Code现在把这些做法放进了/doctor命令中，可以先让它检查Skills和CLAUDE.md。

context以前很像写员工手册，生怕漏掉一条规定。

现在更像给一个聪明的工程师准备工作环境：约束是什么，工具在哪放着，资料在哪能找到，做完之后如何测试和验收。

这就是这篇文章主要想讲明白的东西。

参考链接

1. The new rules of context engineering for Claude 5 generation models

claude.com/blog/the-ne…

1. Effective context engineering for AI agents

www.anthropic.com/engineering…

1. A field guide to Claude Fable 5: Finding your unknowns

claude.com/blog/a-fiel…

1. How Claude remembers your project

code.claude.com/docs/en/mem…