Opus 5 是否还需要复杂项目指令

上周，Y Combinator 发布了一段对 Boris Cherny 的访谈。Boris 是构建 Claude Code 的工程师，访谈围绕全新的 Opus 5 版本展开（完整演讲）。当时视频正在后台播放，我一直只是有一搭没一搭地听着，直到他说：

……删除你的 CLAUDE.md，删除你的 skills，删除你的 hooks……

等等！什么？！让我们倒回去……也许是我听错了：

……对于那些并不构建智能体产品、但在使用 Claude Code 的人，每隔 6 个月删除你的 CLAUDE.md，删除你的 skills，删除你的 hooks。看看模型会怎么做，它也许会让你感到惊讶。事实上，对于 Opus 5，我们确实非常建议大家试着删除所有这些东西，因为过去的模型需要的那些指令，新模型可能真的已经完全不需要了。（6:57）

好吧，那是时候从头再看一遍了。

视频里讲了什么

在同一次对话的前面，主持人用一个数字概括了 Anthropic 对自家产品所做的调整：“你们实际上删除了 Claude Code 系统提示词中超过 80% 的内容”（3:31）。Boris 紧接着给出了解释。他说，Opus 5“真的非常智能”，而且“系统提示词中的很多内容，都是在纠正那些模型本应知道如何处理、但实际上却‘不知道’的行为”。然后他说：“现在，Opus 5 自己就能做到”（4:18）。被删除的内容大多是为了支撑较弱模型而搭建的脚手架；当模型已经能够独立站稳时，这些支撑也就不再承担关键作用了。

那么，Anthropic 是如何完成这次删减的？他们在内部采用了消融实验：“你先删除整个系统提示词，然后逐行加回来，以确定每一行分别产生了什么影响”（6:03）。一次加回一行，并测量每一行加入前后的变化。等这个方法传达到现场开发者耳中时，它已经被压缩成了一句话：“直接删掉，看看会怎样。”

那么，为什么今年夏天发布的模型，会让你针对 4.x 精心调校的指令文件表现得如此不同？

Opus 5 改变了你的指令什么

我研究的是确定性指令评估，不使用 LLM-as-a-judge，因此我深入分析了目前正在发生什么、为什么会发生，以及该如何审查自己的指令，从而真正获得升级收益，而不是遭遇性能退化。这一代模型中的三种机制改变了你一年前编写的文件发挥作用的方式，而且它们的影响会相互叠加。

指令检索强度

现在，它会在更广的范围内检索指令，因此过去一直处于休眠状态的模糊、抽象规则，也会在那些原本并非为其设计的任务中被触发。而模糊规则没有指出任何可供绑定的具体对象，因此触发后，模型会用自己的判断填补空白，而不是实现你原本期望的结果。

内置的 LLM-as-a-judge

模型内置了一轮 LLM-as-a-judge；在我看来，这通常不是个好主意。默认情况下，它会评估并重新检查自己的输出。你以前写下的“验证 / 仔细检查”之类的指令会叠加在这一机制之上，导致模型过度验证；而过度验证又会把更多指令拉入当前轮次，使更广泛的检索已经引发的指令竞争进一步加剧。

如今 Opus 5 可以执行长周期任务，也就是 Boris 所说的 auto mode。把它与上面两种机制结合起来，同样的问题便再次出现：推理轨迹越长，模型自己生成的步骤和假设就越会挤占你的指令，而最薄弱的指令会最先被挤出去。

将这三点结合起来，即使你一行都没有改动，一份在 4.x 上表现正常的 CLAUDE.md，到了 5 上也可能让人感觉像是彻底失效了。删除文件后，噪声会立刻消失，这正是为什么“直接删除”看起来确实有效。

“删除臃肿内容”是合理的建议，因为你的指令文件里，大部分内容从来都不是真正的指令。我们使用一个确定性分析器分析了大约 30,000 个包含智能体指令文件的公开代码仓库，以完全相同的方式读取每个文件，全程没有模型参与，因此同一个文件每次都会得到相同的结果。那份报告最重要的结论是：“你的指令文件中，只有 27% 的内容发挥着你以为它会发挥的作用。另外 73% 都是脚手架”（《AI 指令质量现状》）。这些内容包括标题、重复陈述的上下文、示例，以及只负责组织文件、却从未告诉模型该做什么的文字。苏黎世联邦理工学院一项针对代码仓库上下文文件的独立研究也得出了相同的界限：指令会得到遵循，而描述性的概述——也就是我们所说的脚手架——并不能改善结果，反而会使推理成本增加 20% 以上（《评估 AGENTS.md》）。Boris 删除了 Claude Code 自身系统提示词的 80%，那是他的模型已经不再需要的脚手架。我们的数据表明，普通开发者的 CLAUDE.md 中大约四分之三的内容同样是无用负担，而且早在 Opus 5 发布之前，它们就已经毫无作用了。

剩余 27% 的实际状况，比这一比例所暗示的还要糟糕。在同一个语料库中，89.9% 的智能体配置至少包含一条从未明确指出其所指对象的指令（《未被诊断的输入问题》），例如“保持代码整洁”这样的规则：对人来说读起来很正常，但在模型中却无法绑定任何具体内容。几乎每个人都有这个问题。这些数字来自 2026 年第二季度的分析；第三季度报告正在编写中。

删除是一种粗暴的工具

Boris 的方法是消融实验，也就是 Anthropic 在自己的提示词上采用的同一种手段：先删除整个文件，只有在某种故障反复出现时才把对应的一行加回来，绝不基于猜测预先添加。在时间和 token 不受限制的情况下，这是一种合理的方法。对你而言，它之所以不是正确答案，是因为它存在无法观察到的问题，而且运行成本很高。

先看看这种逐步加回的循环能带来什么：它能找出哪些规则承担着关键作用。但这其实已经是文件本身可以直接读出的属性。一条明确指出其所针对具体构造的指令，相比将同一规则表述为某个宽泛类别，被遵循的优势比大约高出 10.9 倍；当两条规则互相矛盾时，模型会坚定地选择其中一条并放弃另一条；而某条规则是否会在适用场景中被加载，也是文本本身决定的事实。通过“删除并观察”来学习这些信息，意味着你要先让生产环境出现一次故障，而静态阅读本可以免费告诉你答案。

而且，这种方法只能了解到部分情况。只有当某种故障再次出现、且你能够追踪到它时，这个循环才会恢复对应规则；但三种缺陷中的两种，并不会如此清晰地引发故障。低具体性的规则不会直接导致系统崩溃，而是会悄无声息地降低表现：有时被遵循，有时不被遵循。冲突同样会被静默解决：Opus 5 会遵循指令集合中最新的那条，而落败的规则则表现得像是“被忽略”了。这看起来更像是随机波动，而不是一次可以诊断的失误。因此，重建过程会悄悄把模糊和相互冲突的规则重新加回来，因为“删除—观察—添加”循环并没有衡量它们的质量。删除所能触及的，始终只有第三种缺陷：臃肿。

删除清单中还存在一个类别错误，因为它不只包含 CLAUDE.md，还延伸到了 skills 和 hooks。hook 是确定性的关卡：它会直接拒绝某个操作，而不是要求模型权衡一句话。拒绝规则、破坏性命令拦截或合规检查，并不会因为模型能力增强而变得不再必要。强制执行从一开始就不依赖模型的判断，因此模型升级并不会让它过时；而且，它的缺失不会表现为逐步加回循环能够捕捉到的轻微失误，而会直接表现为破坏性命令被成功执行。删掉模型已经不再需要的文字，但要保留关卡。我在另一篇文章中更完整地论述了这种区分：提示词负责引导，hooks 负责强制执行。

当你不受时间或 token 限制时，通过删除规则、任由模型出错，再重新弄清哪些规则真正重要，这算是一种公平的权衡。对于预算几乎不受限的 Anthropic 重度用户来说，这种“通过失败重新发现”的循环不过是背景噪声。但对于预算正常的开发者来说，情况并非如此，而且代价绝不只是一份文件。想象一下：你要在自己参与的每个项目中，逐一对每条 memory.md 引用、每份 CLAUDE.md，以及每条规则、每项技能和每个智能体执行消融测试。删除一条规则，然后等待模型失足，就意味着通过眼看自己的工作一次次出问题，重新了解当初为何要写下那些指令。最终，你只是重新学会了自己本来就有的那份文件，只不过还遗漏了测试期间碰巧没有引发故障的内容。静态阅读则能直接告诉你哪些规则真正具有约束力，完全不必为了找出答案而让任何一次失败进入实际工作。

所以，阅读文件，不要缩减它。Opus 5 遇到错误指令时会带来更严重的后果，因此这里的工作是诊断：修复会误触发的规则，把其余规则改写到连最字面化的读者都不可能误解，然后重复这个过程。

修复你正在看到的问题

下面每一项都是你可以观察到的故障，旁边给出了相应的解决办法：

回答冗长，为琐碎步骤写出大段文字。针对不同输出界面分别规定简洁程度：为聊天回复写一条规则，为逐步过程说明写一条规则，再为写入磁盘的文件写一条规则——文件内容本身往往就会比较长。effort 改变的是思考深度，而不是输出长度，因此降低它不会让这些内容中的任何一种变短。

范围蔓延，做了超出要求的事情。用一行说明范围，并让它自行完成常规决策；只有当两种理解会导致实质上不同的工作时，才要求它回来确认。范围属于判断问题，因此只能起引导作用，不能构成硬性门禁；其中唯一可以强制执行的部分，是设置写入路径允许列表，拒绝修改任务所指定文件之外的任何内容。

过度遵守限制条件。从 4.x 文件继承下来的保守措辞，如今会被严格按字面执行，从而导致少报。Anthropic 特别针对 Opus 5 提醒了这一点：如果代码审查提示词使用“只报告高严重性问题”或“保持保守”之类的限制性措辞，模型就会严格照做，报告更少的问题。先要求它找出所有问题，再进行第二轮筛选。

强迫式自检，做出你没有要求的修正。删除诸如 double-check your answer 或 use a subagent to verify 这样的语句。Anthropic 也表达了同样的观点：Opus 5 会在没有收到要求的情况下自行验证工作，而这些指令只会导致过度验证。不过，不要因此认为它的自我验证值得信任；它的检查只是叙述性的（参见最后一项）。

旧的 4.x 指令发生误触发。不要仅仅因为版本年代而清除它们，因为你无法从表面判断一条规则的年龄，而盲目删除正是整篇文章所反对的条件反射。应该针对 Opus 5 已经反转行为的规则类别：验证提示词、be conservative 式的保守限制、do not think 规则以及 effort 默认值。逐一测试，并保留仍然具有约束力的规则。

面对相互冲突的规则时反复摇摆。发生矛盾时，Opus 5 会遵循位置更靠后的规则并放弃另一条，而由位置决定遵循哪一条，因此无法通过重新排序来修复。找出矛盾并将其消除；查找矛盾时，应检查主题相同的规则对能否“同时成立”，而不是从头到尾逐行扫描文件。

模糊规则在不相关任务上误触发。更广泛的检索现在会激活过去一直处于休眠状态的规则。明确写出规则针对的具体构造，或者将其限定到某个路径，使它不再在每轮对话中加载。

过度积极地使用子智能体。限制其使用。这是成本问题，而不是质量问题。只把规模较大、确实可以独立开展的工作轨道委派出去，绝不要为了验证自己的工作而启动子智能体。

自信地做出错误假设，在尚未完成时声称“done”。引导它明确陈述假设并指出信息缺口，然后不要轻信它所说的“done”。在结束时，用一项它从未见过且无法修改的留出检查重新验证目标；当它无法确认结果时，允许它拒绝并上报。

沿用了 4.8 时代的 effort 使用习惯。Opus 5 默认使用 high，并在其上增加了 xhigh 层级。如果你曾为 4.8 显式设置 effort，Opus 5 会保持该设置不变，而不会替换成自己的默认值，因此你为 4.8 调优的值会一直生效，直到主动修改它。重新进行一轮 effort 扫描：对于大多数工作，low 和 medium 都能维持质量，而 xhigh 只有在要求很高的智能体运行中才对得起它的成本。

编写它能够遵循的规则

你留下的解释空间越多，Opus 5 就越会用自己的判断填补空白，而且它会带着让你走到今天这一步的那种自信和质量去做判断。因此，要具体、使用祈使句，并且每行只放一条指令。在一项受控实验中，明确指出规则针对的具体构造，正是 Format with ruff format before committing 与 keep the code clean 之间的关键区别：在人类看来是同一条规则，模型的遵循程度却天差地别。

编写约束时，要安排好顺序。首先给出指令，并明确指定要使用的具体构造。再添加一行能够强化该指令的理由，同时避免在这一行中再次提及你要禁止的东西。把禁止性要求放在最后，并从类别层面表述：在一份拥挤的指令文件中，点名被禁用的 API 反而会让模型注意并锚定它，使禁令适得其反，而这种问题在 Opus 5 上更加严重。顺序应该是：一条祈使指令、一行背景说明、一条限制：

• 每次回复都以结果开头：在第一句话中给出答案或发现。 > - 读者先看到结果便能立刻采取行动，并将后续内容作为支撑信息阅读。 > - 不要以铺垫、对请求的复述或状态说明开头。

值得保留的规则具有一些无需运行模型哪怕一次就能检查的共同属性：

它们明确指出具体构造。写 Format with ruff format before committing，而不是 keep the code clean。

它们彼此不矛盾。两条相互冲突的规则不会折中生效；模型会遵循其中一条并放弃另一条，而你无法决定它选择哪一条。

它们在适用的位置加载。与 src/payments/ 有关的规则应放在作用域限定为 src/payments/ 的文件中，而不是放在始终加载的界面上，让每个不相关的对话轮次都为它付出成本。

它们描述的是你希望强制执行的行为，而不是模型可以直接从代码库中读出的文档信息。

请注意，“有多少条规则”并不在这个列表中。一份包含四十条规则的文件，只要每条都点明具体构造、彼此没有冲突，并且各自在适用的位置生效，就总会胜过一份只有八条模糊规则的文件。数量是质量的下游结果。

审查它，不要让它给自己打分

Anthropic 提出了同样的观点，并为此提供了一项工具。他们针对 Claude 5 这一代模型的上下文工程指南指出，他们发现自己通过系统提示词、CLAUDE.md 文件和技能对 Claude Code 添加了过多约束，因此可以删除其中许多指令，让模型自行运用判断力。他们把由此总结出的最佳实践做成了一个命令：Claude Code 中的 /doctor，用于合理调整技能和 CLAUDE.md。运行它。它会删除 Claude 能从代码库、目录布局、依赖列表和架构概览中自行推导出的内容，保留容易踩坑的地方以及不同于工具默认行为的约定，并将其余内容移入按需加载的文件。

/doctor 调整的是冗余程度和放置位置。它不会为保留下来的规则评分。一条规则是否点明具体构造、是否与另一条规则冲突、是否在适用的位置加载，都是文本本身具有确定答案的属性，可以通过阅读计算出来；而这三项都不是精简冗余所衡量的内容。陷阱在于试图借助模型补上这一缺口。让 Claude 给自己的规则打分，会直接掉进 LLM-as-a-judge 和自我验证循环；Opus 5 已经会对自己的输出执行这种循环，但这只是在一个答案确定的问题上进行随机猜测。对于一份 200 行的文件，这个裁判要做出 200 次这样的判断，而它正确处理整份文件的概率会随着规则数量增加不断下降——恰恰是在你最想借助它的时候。

因此，先运行 /doctor，再衡量它保留的内容。针对 CLAUDE.md 和规则运行一个确定性检查器，为它们评分，并修复模糊和相互冲突的规则。我构建了一个这样的工具；任何 AST 或确定性指令检查器都能找出这些缺陷。

阅读文件，不要猜测

真正删除冗余内容。然后，在你凭感觉添加任何内容回来之前，先衡量剩余内容：每条规则是否准确表达了自己的含义，是否与另一条规则冲突，是否在正确的位置加载。这三点都可以直接从文件中读出来，而它们恰恰是盲目删除无法看到的。这样，你可以保留真正具有约束力的内容，删掉从未发挥作用的文本，并且明确说出两者分别是什么，而不是靠猜。

我在开发 Reporails，这是一个面向指令文件、规则和提示词的确定性诊断与治理工具，而这些内容正是引导编程智能体的关键。它会读取你编写的引导层，并通过量化证据告诉你：哪些指令与行为相关联，哪些只是模型可以忽略的文本。它不会运行你的模型，也不会进行投票；它衡量的是文件本身。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。