虽然 A 社最近有些做法确实让人反胃，但
Thariq
写技术文章的能力，我是服的。所以该骂的骂，该借鉴的借鉴。
7 月 24 日，Anthropic 发了一篇 context engineering 文章，文章中一个核心的观点是：
他们为 Claude Opus 5、Claude Fable 5 这类新模型删掉了超过 80% 的 system prompt，然而在编码测评中，却并没有出现明显的损失。
所以，我们以前辛辛苦苦写的那些规则，难道大部分都过时了，或者说在帮倒忙吗？
这篇文章就先从这个疑问开始，然后我带你一起慢慢揭开全貌。
文中说的 context engineering 和上下文工程是一个意思。
Prompt 只是你这一轮与 Claude 的对话。
System prompt、Skills、CLAUDE.md、memory、工具定义、文件内容和终端输出，这些一起才是模型真正拿到的 context。
随着现在很多大模型的能力越来越强，比如 Kimi K3 、Fable 5 、Opus 5、GPT-5.6 Sol，很多时候往往不是 skills 越多越好，相反，还可能成为一种负担。
文章的一个核心观点就是：强模型时代，context engineering 需要做减法。
在对的时机，给模型最有用的信息。
过去的约束和现在的判断
Anthropic 之前在上下文工程指南里提过一个很重要的概念：模型有有限的 attention budget（可以翻译为注意力预算？）。
上下文窗口再长，并不意味着注意力越来越多。
你给模型多加一条无关的规则，模型就会多花一些注意力判断它有没有用；如果你加的是优先级规则，模型它还得判断先听谁的。
导致最后 context 看起来很多很丰富，但其实有效的注意力会被淹没。
所以 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 行以内。
这里还有个挺容易踩的坑：把大段内容拆成几个文件，再通过
@全部 import 进 CLAUDE.md，只是看着清晰了，但启动时照样全部进入 context 中。
真要节省 context 的话，要用按路径加载的 rules，或者把任务流程做成 Skill。
memory 也有了更清楚的分工。
比如一个 JavaScript 项目的 CLAUDE.md，可以这样写：
markdown
- 修改 JavaScript 后运行 `npm test`。
- 安装依赖优先使用 `pnpm`。
- API handler 统一放在 `src/api/handlers/`。这些是你主动定下的规矩，每次工作都要遵守。
auto memory 里则可能出现：
markdown
- 本地 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 以前很像写员工手册，生怕漏掉一条规定。
现在更像给一个聪明的工程师准备工作环境：约束是什么，工具在哪放着，资料在哪能找到，做完之后如何测试和验收。
这就是这篇文章主要想讲明白的东西。
参考链接
- The new rules of context engineering for Claude 5 generation models
- Effective context engineering for AI agents
www.anthropic.com/engineering...
- A field guide to Claude Fable 5: Finding your unknowns
- How Claude remembers your project