"直接删除你的指令"——这个建议我做不到
Claude Opus 5 是更好的模型，但在我的系统中却产生了更差的作品。共识的解决方案让我抛弃的，恰恰是这个系统真正有价值的东西。
Claude Opus 5 于 7 月 24 日发布。在所有重要的基准测试中，它都超越了 Opus 4.8。SWE-bench Pro 从 69.2% 提升到了 79.2%。Anthropic 自己的前沿编码基准测试成绩更是翻了一倍多。
我的整个业务都运行在 Claude Code 上。横跨六个领域的几十个项目，大约三十个自定技能，一个记忆系统，定时维护的 Agents，以及过去几个月里从各种问题中积累下来的硬性规则。在我打出第一个字之前，大概有 20,000 个 token 的上下文已经加载完毕。
四天时间，我发现自己根本无法用它工作。两轮完整的对话——一个客户网站和一个 SaaS 产品——产出的成果我根本不会交付。
现在，我已经读完了几乎所有关于这个问题的讨论，而共识的解决方案出奇地一致：删除你的指令框架。 Anthropic 削减了 Claude Code 约 80% 的系统提示词。Every 的 CEO 删除了他的技能，然后报告说情况"得到了戏剧性地改善"。
我并不认为这个建议适用于我，我想仔细解释一下原因，因为我觉得很多人即将删除他们之后会怀念的东西。
三个出了问题的地方
它自信地犯错。 来自 Anthropic 自己的系统卡片：
"该模型在事实性断言上的幻觉率略高于 Opus 4.8，尽管整体准确度更高。"
请把这句话读两遍。整体准确度更高，但幻觉更多。这两者并不矛盾——它们合在一起，恰好描述了日常使用中的真实感受。同一份文件指出，该模型"自信地给出了一个它其实并不确定的答案"。一个明显出错的模型成本很低。一个听起来确信无疑但实际错误的模型成本很高，因为你不会再花时间去检查了。
它在工作完成前就停止了。 Kieran Klaassen，在运行一个自动化流程时提到：
"它一直把控制权交还给用户。即使这是一个自动化流程。这非常烦人。"
这和我观察到的情况完全一致。任务被重塑而非执行，部分完成的工作被报告为已完成，而之前的模型会直接把事情做完，现在它却会推诿。
它话太多了。 这是三个问题中有据可查的一个，Anthropic 自己的迁移指南中多次承认：
"默认的可见回复和书面交付内容在 Claude Opus 5 上比之前的 Opus 模型更长，而降低努力值会减少思考量，但无法可靠地缩短可见回复。"
注意后半句。努力值参数解决不了这个问题。
大家一致认同的机制
这是让我重新理解问题的关键部分。来自 Anthropic 在 Opus 5 发布当天发布的工程博文：
"我们过去对 Claude Code 的限制过多了，无论是在系统提示词中，还是在我们的 CLAUDE.md 文件和技能里。"
他们削减了大约 80% 的系统提示词。Dan Shipper 报告说 Opus 5"与我们现有的技能和插件配合不佳"，并且删除这些技能后，情况变得"戏剧性地更好了"。João Queirós 也提到："简单的提示词比成熟的、指令密集型的工作流程产生了更有希望的结果。"
四个独立的来源，加上供应商自身，都指向了同一个变量：你积累的指令框架越多，这个模型的表现就越差。
这也解释了为什么讨论看起来是分裂的，而不是一致的。如果你的 CLAUDE.md 只有十二行，那么 Opus 5 无疑是更好的，而批评者看起来像是在小题大做。但如果你花了几个月构建一个系统，你完全处于另一个不同的对话中。
共识建议的不足之处
那就删掉它们吧，大家都这么说。但问题在于：我的指令并非单一的东西。它们是两种不同的东西，在文本文件中看起来一模一样，但本质上完全不同。
补偿性指令。 旨在抵消模型弱点的指令。"仔细检查你的工作。""默认委派任务"——这是我在之前的模型委派不足时写的。"在继续之前先总结。"这些是字面意义上的脚手架：围绕建筑物漏洞的临时结构。
补偿性指令是可以安全删除的，Opus 5 确实让其中许多变得过时了。它现在会主动自我验证。它会主动委派。很好，删掉吧。
宪法性指令。 那些只存在于我这里的客观事实和标准。比如，一次绿色的构建曾经欺骗过我，所以"证明"意味着真正的 WebKit 和 HTML 中的标记字符串，而不是一个 HTTP 200 状态码。哪个主机对应哪个项目。哪个客户有访问限制，哪个没有。这个品牌的排版规则是什么。哪种失败模式让我损失最大，以及具体用什么来防范它。
这不是唠叨。这是信息。 而且无论模型质量多高，都无法推断出来，因为它不是一个推理问题——它只存在于我的业务中，是独有的知识。一个更聪明的模型并不能更好地猜出它。它只会更自信地猜错。
共识的建议没有区分这两者。它只说"删除你的指令"，人们就会把两者都删了，因为在一个 Markdown 文件中，它们看起来一模一样。
我知道这一点，因为我就是这么做的。按照迁移指南，我从完成关卡中删除了验证指令。指南说"检查你的工作"现在确实是多余的，这是对的。但我也删除了定义在我的技术栈中什么才算证明的部分——而验证幻觉，是我最昂贵、最反复出现的失败模式。我删除了专门用来防范我最糟糕的失败模式的护栏，只因为一条通用的建议告诉我要精简。
又试了两轮之后，我撤销了所有更改。
我真正想表达的观点
到处都是关于 Opus 5 需要更少指令的说法。我认为这并非对正在发生的事情的正确描述。
Opus 5 在执行指令方面的表现更差。 而且，对于一整类用户来说，执行指令并非额外的负担——这恰恰是他们的全部工作。
我付钱不是为了得到一个能写出好的通用代码的模型。现在这种模型到处都是。我付钱是为了得到一个能写出符合特定系统要求的代码的模型——这个系统有约定、合规要求、品牌规则、客户特定的约束，以及一份记录了这里过去所有失败历史的文档。剥离了这些约束，你并没有改进我的输出。你只是让模型感觉更舒服，而让我的输出变得更平庸了。
所以，当我读到"删除你的技能，它就能工作得更好"时——更好的定义是什么？大概是在无约束的编码流畅性方面。但绝不是产出符合我系统要求的工作，因为让工作符合我系统要求的东西，恰恰就是被删除的那些。
我大约有 90% 的把握，没有我的指令框架，Opus 5 永远达不到我现有系统所能产生的质量。不是因为模型弱，而是因为缺失的成分不是智能。而是对我业务的了解，没有任何数量的原始能力可以替代它。
我现在的做法，以及我的建议
我现在退回到了 Opus 4.8，并完全恢复了之前的一套设置，字节级完全相同。这不是一种抗议——而是因为它有效，而且我有截止日期要赶。
我并非声称 Opus 5 是更差的模型。基准测试是真实的，我尊敬的人也报告了实实在在的收益，而且我一次改变了两个变量——模型和设置，同一天——所以我无法干净地归因于自己的结果。这是我证据的一个真实局限，而不是修辞上的缓和。
我的主张更窄：一个更好的模型，在一个成熟的系统中，可能产生更差的工作，而且这种失败是无声的。 没有报错。没有警告。你的指令只是不再像以前那样被理解了。
如果你遇到了这个问题，我建议你按以下顺序处理：
- 先分类，再删减。 检查你的每条指令，并标记：这是为了补偿模型的弱点，还是只有我知道的东西？仅仅这一遍分类，就比任何删减启发式方法更有价值。
- 自由地删除补偿性指令。 特别是那些告诉模型去验证、委派或总结的指令。这个建议是可靠的。
- 保护你的宪法性指令。 领域知识、证明定义、品牌标准、客户约束。如果删除一行会让一个称职的新员工做出错误的工作，那就保留它。
- 一次只改变一个变量。 模型或设置，不要同时改变。我违反了这条，导致我无法归因任何东西。
- 确保可以回滚。 提交一次，这样回滚就是精确的，而不是近似的。
- 你自己记录下来的失败模式，优先级高于任何供应商的通用建议。 这是我最想强调的一点。
令人不舒服的地方在于，当你写下它们时，补偿性指令和宪法性指令感觉完全一样。我系统中的每一条规则都存在，是因为曾经出过问题。事后把它们区分开来才是真正的工作——而"直接删掉"这个建议，悄悄地假设了没有人拥有任何值得保留的东西。
来源：Claude Opus 5 系统卡片和迁移指南 (Anthropic, 2026 年 7 月)；Anthropic 工程博客，2026 年 7 月 24 日；Dan Shipper 和 Kieran Klaassen 通过 X (Twitter) 发表，2026 年 7 月；João Queirós，2026 年 7 月。
