![](https://developer.qcloudimg.com/http-save/yehe-7353521/95479f216b4bb3410c6c6d58cbaa1623.jpg)

## TL;DR

Anthropic 砍掉了 Claude Code 系统提示词的 80% 以上，编码评测没有可测量的损失。

但这句话真正证明的，是那 80% 本来就没在传递信息——它是给弱模型打的补丁，不是知识。

一个团队能删掉多少提示词，度量的不是模型有多强，是他们之前写了多少废话。

模型学到的是世界的公共部分。你的规则里装的是私有部分——“我们周五不发版”、“这个库禁用”、“这个仓库的类型全在一个文件里”。这些从没进过任何语料库，模型再强也补不上。

该薄的是公共部分，该厚的是私有部分。而按 token 数砍，砍掉的往往正好是后者。

## 一、一份被当成指引的实验报告

Anthropic 最近发了一篇文章——[The new rules of context engineering for Claude 5 generation models](https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models)，讲他们如何为新一代模型重做上下文工程。核心事实只有一句：他们把 Claude Code 的系统提示词删掉了 80% 以上，在自己的编码评测集上没有观察到可测量的损失。

文章顺势列了六条“已经过时的最佳实践”：

给模型定死规则，改成让模型自己判断；给工具用法示例，改成把语义设计进接口；把信息全部前置塞满，改成按需分批加载；重要的话说三遍，改成说一次并放进工具描述；记忆写进 CLAUDE.md，改成让模型自动存取；用简单的 markdown 写规格，改成给它测试套件、代码、评分标准这类更丰富的引用。

这六条单独看都不难接受。真正值得停下来的地方，是他们删掉的**具体是什么**。

文章自己举了旧提示词的原文：*“写代码时默认不加注释。绝不要写多段式文档字符串或多行注释块——最多一行。不要创建计划、决策或分析文档，除非用户明确要求。”*

新版本把这一整段换成了一句：*“写出和周围代码读起来一致的代码：注释密度、命名、惯用法都对齐。”*

而这里有个绕不过去的问题：**没有人拿得到那 80% 的清单。** HN 上有人直接问了——删掉 80% 是个很大的数字，能不能列出到底改了什么？我们需要知道哪些是模型训练里本来就会的、哪些是我们不该过度指定的。“让模型用判断力”这种说法，对真正在实现 agent 的人来说太含糊了。

这个追问没有得到回答。所以这篇文章的可操作性天然是低的：它给了一个结论和一个数字，但没给出得到这个数字的过程。你只能拿着“80%”这个锚点，去猜自己该删什么。

## 二、删掉的是补丁，不是知识

先把那句“绝不要写多行注释”拆开看：它到底在传递什么信息？

答案是——什么都没传递。

模型知道什么是注释，知道注释该怎么写，知道什么时候该多写、什么时候该少写。这些在训练语料里到处都是。那句禁令没有告诉模型任何它不知道的事，它只做了一件事：**压制一种不稳定的行为**。

老一代模型在注释这件事上的表现方差很大，有时会生成大段无意义的文档字符串。于是加一条强硬的禁令，用“一刀切的错”去换“随机的错”。文章自己也承认了这个取舍：没有这些护栏，模型写的注释在很多情况下是不对的，当时只能接受这个代价。

这类东西不是知识，是**补丁**。补丁的寿命和模型能力直接挂钩——能力上来了，方差收窄了，补丁自然就冗余了。删掉它不掉分，一点也不意外。

现在把这个观察翻个面。

“删了 80%，评测没掉分”——同一组数据，可以讲成两个故事：

一个是：**我们的模型已经强到不需要那么多指导了。**

另一个是：**我们之前写的东西里，有 80% 本来就没在传递信息。**

这两句话在数据上完全一致，含义却相反。第一个是能力叙事，暗示这是通用规律，别人也该跟着删。第二个是自查叙事，说的是他们自己那份提示词的冗余度。

而关键在于：**第二个才是这次实验能支撑的结论，而且它不可推广。** 他们的补丁比例高，不代表你的高。一个团队能删掉多少提示词，衡量的是这个团队之前往里塞了多少废话，跟模型强弱的关系比想象中小得多。

## 三、模型学的是世界的公共部分

上一节留了个问题：什么样的内容不是补丁？

判据不在“这条规则有多重要”，也不在“它写得有多长”，而在一个更朴素的地方——**这份知识是从哪来的。**

模型学到的是世界的公共部分。训练语料里有的，是被写下来、被公开、被反复讨论过的东西：语言、算法、框架用法、常见的坑、社区里吵过几百遍的最佳实践。模型在这些东西上确实越来越强，而且会继续强下去。

但下面这些，从来没进过任何语料库：

- 我们周五不发版
- 这个库我们内部禁用，用另一个替代
- 这个仓库的类型定义全部集中在一个文件里，别的地方没有
- 改这块要先过某个人
- 我们说“简洁”的时候，指的是不要用专业黑话，不是指少写字

这不是模型能力不足的问题。**是它物理上不可能知道。** 这些信息只存在于你的团队内部、你的代码库里、你自己的脑子里，从未被写成公开文本，也就从未有机会进入任何一次训练。

所以“把规则删掉、期待模型自己补上”这个期望之所以不切实际，不是因为模型不够强——**是再强也没用。** 变强发生在公共知识这条线上，私有知识根本不在这条线上。你可以等模型继续变强，但等到天荒地老，它也猜不出你们周五不发版。

这也顺带解释了一个之前想不通的现象：为什么 Anthropic 能删 80%，而你照着删就出事？

不是因为你的模型弱。是因为**你的规则里私有含量更高。**

他们删的是 Claude Code 这个产品级系统提示词。那份东西面向的是所有用户、所有代码库、所有场景——它按定义就只能写公共内容，写不了任何一家公司的特殊约定。所以它里面补丁比例极高，删起来当然安全。

而用户的 CLAUDE.md 和 skill 里装的是什么？恰恰相反，几乎全是私有的：这个项目的坑、这个团队的约定、这个人的偏好。**两者从来不是同一种东西。** 把前者的实验结论包装成“上下文工程的新规则”推给后者，这一步就是越界发生的地方。

## 四、代价都是迟到的

假设你还是照着删了。会发生什么？

答案是：**当场什么也不会发生。** 这正是最麻烦的地方。

删掉几条私有规则，模型照样能跑，任务照样能完成，输出看起来也没什么不对。你会很自然地得出结论——看，果然是冗余的。

代价在两个地方，而且都是迟到的。

**第一处，是你换模型那天。**

写在文件里的知识可以带走。你把 CLAUDE.md 复制到另一个 harness、另一个模型下面，它还在工作。但如果这份知识没被写下来，而是靠模型“自己判断”补上的，那它就长在权重里——**换个模型，它就不存在了。**

HN 上已经有人在换了。有人说自己彻底转向自建 harness 加开放权重模型；有人说新一代模型的行为让他难以接受，回去用别家。这些人搬家的时候，能带走的只有他们写下来的那部分。

厂商锁定这件事，机制其实比“阴谋”平淡得多。没有人锁你的文件。**只是当你的 harness 越来越薄，你迁移时能带走的东西就越来越少——不是因为它被锁住了，而是因为它从来没被写下来过。**

**第二处，是半年后有人问“这段为什么这么写”。**

这个问题会以各种形式出现：code review 时对方问你、事故复盘会上有人问、新同事接手时问，或者只是三个月后的你自己翻到这段代码，完全想不起来当时为什么这么写。

如果答案是“我让它按周围代码风格来，它自己判断的”——这个回答在任何一个场合都是空的。

有人在讨论里说得很直白：推理过程被隐藏之后，你甚至不确定它是用了某段记忆，还是自己独立联想出来的。你能看到的只有结果，看不到理由。

规则的价值有一半从来不是提升产出质量，**是留下决策的痕迹。** git blame、commit message、架构决策记录、代码注释——这个行业发明了这么多东西，解决的都是同一件事：系统的寿命比人的记忆长。而“让模型自己判断”恰恰是在制造不可追溯——判断发生在权重里，不留痕迹。

**还有一层更隐蔽的：模型变强，改变的不是错误的数量，是错误的形态。**

HN 上有条实测说得最准。这位用户其实是早期就认同“少写命令式指令、多声明意图”的那批人——上一代模型的突破让他很早就把 CLAUDE.md 写得很轻。但新一代模型让他遇到了新麻烦：一旦跑偏，**更难纠正了。因为它整体是错的，却用听起来合理的论据把痕迹盖住了**，你很难指出问题具体出在哪。

从明显的低级错误，变成隐蔽的、有说服力的错误。这个变化对“该写多少规则”的影响，比“模型变强了所以少写点”要复杂得多。

## 五、控制没有减少，只是换了位置

顺着上一节往下推：事前写的规则，只能接住明显的错误。

你能预料到的失败模式，才能写成规则去防。而隐蔽错误的定义就是你预料不到——你不知道它会在哪个地方开始自我合理化，自然也就写不出对应的禁令。

能接住这类错误的只有一样东西：**事后验证。**

测试、评分标准、独立的验证流程。它们不试图预测模型会怎么错，只检查结果对不对。

有意思的是，Anthropic 的文章其实说到了这一半，只是没说透。它提到规格不一定是 markdown 文件，也可以是一套详细的测试；提到评分标准可以让模型去验证你在某个领域的品味，比如什么样的 API 设计算好设计。

但这不是“放弃控制”。这是**把控制从入口挪到了出口。**

这两件事不是替代关系。事前规则依然有用，它擅长拦住你已经知道会出问题的地方；事后验证补的是另一块——你事先根本想不到的那部分。真正变的是重心：模型越强，能被事前预料的错误越少，重量就越往出口那头压。

而且事后验证一点也不“新”，测试比提示词老得多。变的从来不是手段，是它在整套工作流里的位置。

|  | 事前控制 | 事后控制 |
|---|---|---|
| 控制点 | 写规则、下指令 | 检查产出 |
| 载体 | 自然语言规则 | 测试 / 评分标准 / 检查清单 |
| 什么时候生效 | 模型动手之前 | 模型交付之后 |
| 接得住什么错 | 你预料得到的 | 你预料不到的 |
| 怎么失效 | 规则互相冲突、被模型忽略 | 验证覆盖不全 |
| 能不能追溯 | 弱，只是一句意图声明 | 强，有明确的通过/失败记录 |

而且出口这道关**更难绕过**。测试要么过要么不过，二值的，不需要模型配合；“请遵循 X”这种话则完全可以被软性忽略——模型一边应着“好的”，一边照旧。

所以总控制量并没有减少。文章标题喊的是做减法，实际发生的是**位移**。只讲了前半句、没讲后半句，读者就容易理解成“什么都不用管了”。

## 六、该薄的和该厚的

把前面几节收成一张可操作的表。判据只有一个：**这份知识，模型能不能自己重新发现。**

| 类型 | 例子 | 能不能被重新发现 | 怎么处理 |
|---|---|---|---|
| 补丁 | 别删文件、绝不写多行注释 | 模型自己就会 | 删 |
| 环境 | 类型定义都在哪个文件 | 读一遍代码就能看出来 | 删，甚至更该删 |
| 约定 | 禁用库、发版窗口、审批流程 | 读不出来，但有文档 | 薄成一个指针，指向文档 |
| 取舍 | 术语要换白话、什么叫好设计 | 只在你脑子里 | 写厚 |

最后一类是唯一**越写越值钱**的。因为它是你和模型之间的信息差，不是模型的能力缺口——**模型再强，也不会变强出你的品味。**

而这里有个陷阱：Anthropic 的文章一边说“skill 最好是编码你、你的团队、你的产品特有的意见和知识”，一边说“避免让 skill 过度约束”。这两句话是拧着的。取舍类知识在形式上本来就是约束——你要求“术语换白话”就是在约束它。**冗余的约束和承载信息的约束，是两种东西，不能用同一句话处理。**

所以“skill 可以变薄，但不能变少”这个说法，需要再拧紧一步：

> **该薄的是公共部分，该厚的是私有部分。**

薄是压缩表达，同一份知识从三段话变成一句话，信息量不变。少是删除条目，赌模型能自己推出来。这两件事被“删了 80%”这个数字合并在了一起，但它们完全不同。

而且要小心：**薄到极致，和少，在后果上是等价的。**

“不要过度润色”这五个字，对熟悉上下文的人有效，是因为下面垫着几十轮对话。换个模型、换个人，没有这些垫底，这五个字几乎是空的——它只是一个指针，指向一份没被写下来的共识。压缩没有让知识消失，只是把它挪进了更不可靠的地方。

最后两句：

**按 token 数砍，砍掉的是最长的；按信息量砍，砍掉的是最冗余的。这两者经常正好相反。** 私有知识往往写得又长又啰嗦，因为它本来就需要长——它要解释一件模型完全不知道的事。

**没有验证的减法不是减法，是赌博。** Anthropic 敢删 80%，是因为他们有评测集，删完跑一遍，分不掉就是真冗余。而大多数人删 skill 是没有评测的，删完只能靠感觉“好像还行”。

而感觉不到问题，和没有问题，是两件事。代价都是迟到的。




Anthropic 砍掉了 Claude Code 系统提示词的 80% 以上，编码评测没有可测量的损失。

Anthropic 删了 80% 提示词，但你不能照做

人工智能

职业发展

新闻资讯

Anthropic大幅精简ClaudeCode系统提示词80%以上却未影响编码评测，揭示模型能力提升后补丁式规则已冗余。文章指出模型擅长公共知识但无法获取私有规则，强调团队应精简公共部分但保留私有约定。删除规则可能导致隐性错误和决策痕迹缺失，建议通过测试验证替代部分事前控制。关键在区分可被模型重新发现的公共知识和必须保留的私有规则，避免过度简化导致信息丢失。

上下文工程

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Anthropic大幅精简ClaudeCode系统提示词80%以上却未影响编码评测，揭示模型能力提升后补丁式规则已冗余。文章指出模型擅长公共知识但无法获取私有规则，强调团队应精简公共部分但保留私有约定。删除规则可能导致隐性错误和决策痕迹缺失，建议通过测试验证替代部分事前控制。关键在区分可被模型重新发现的公共知识和必须保...

Anthropic 删了 80% 提示词，但你不能照做-腾讯云开发者社区-腾讯云

Anthropic 删了 80% 提示词，但你不能照做

Anthropic 删了 80% 提示词，但你不能照做

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐