Claude 5 时代：我们删掉了 80% 的系统提示词
The new rules of context engineering for Claude 5 generation models
在 Claude 5 代模型（如 Claude Opus 5 和 Claude Fable 5）的语境工程实践中，我们做出了一个反直觉的决定：删除了 Claude Code 系统提示词中超过 80% 的内容，而代码评测表现并未下降。过去，我们习惯用大量规则约束模型，比如禁止写注释或强制特定文档格式，但这往往导致指令冲突，迫使模型在矛盾中消耗算力。新一代模型已具备更强的判断力，不再需要事无巨细的微观管理。现在的最佳实践是：用更简洁的引导让模型发挥判断力，通过设计清晰的工具接口而非堆砌示例，并利用渐进式披露机制按需加载上下文。我们已将这套经验封装进 /doctor 命令，帮助你精简 Skills 和 CLAUDE.md 文件，释放模型真正的潜力。
我们删除了 Claude Code 系统提示词中超过 80% 的内容，针对 Claude Opus 5 和 Claude Fable 5 等更先进的模型，而在代码评估中并未观察到任何可测量的性能损失。
HN 评论区
27- nickm12
在代理式辅助（agentic assistance）兴起的这段时间里，我得到的建议是：'如果生成的代码不是你想要的，去调整引导（steering），而不是改代码'。我也被告知不要修改代理写的那些有时冗长的注释和文档，因为'这能帮它们在下次查看代码时更好地理解'。
我一直对此持怀疑态度，而这些准则也印证了我的怀疑。我继续像往常一样编写文档和规格说明。如果代理产出糟糕或产生误解，我会将其视为改进文档的机会，但改进的方向是让人类同事更容易理解，而不是迁就当前一代模型的怪癖。
- mycentstoo
我们应该设计一种特定的语言，以确保能精确编码我们想要的要求。这种语言应该只有一组有限的、明确的关键词。等等……
- firasd
我一直觉得，在上下文窗口里塞进像《威斯特伐利亚和约》那么长的指令前缀，再加上大量的废话（throat-clearing），是 unnecessarily baroque（过度繁复）的，你其实可以直接和代理对话。
我想部分原因也是我不介意做'手动编辑'，比如 LLM 总爱写'// so and so removed'这样的注释，我稍后直接手动删掉就行，而不是去命令'别注释你删了什么！11'，因为到那时你其实是在和模型行为中根深蒂固的惯性硬刚。
不过我也确实采用一种亲力亲为、人机协作（human-in-the-loop）的工作风格，所以对于那些只想说'实现 GitHub 里所有待办功能'然后就走开的人来说，可能确实需要更多这类 CLAUDE.md 的东西。
但我怀疑，设置详细的 harness 配置这种操作，从一开始就带着某种极客（gearhead）式的吸引力，其实可能是不必要的，更像是一种爱好者的瞎折腾。
- threecheese
在我看来，他们过度依赖 Claude 的 automemory 功能了，这东西在语境化记忆访问方面表现极差，经常做出毫无逻辑的巨大跳跃——除非它偶尔真的有用，但这反而让问题更糟，因为操作员再也看不到它的思考过程了。
是的，我参与过相关项目，但我可不想让你用那些记忆来做假设，进而推导出我根本不想要的决策。由于推理轨迹（reasoning traces）被隐藏了，我有时甚至不确定它到底是用到了那些记忆，还是仅仅因为 PR 里出现了'credit'这个词，就独立判定 PCI-DSS 的某个子条款与此相关。
我无法在足够细的粒度上完全配置记忆偏好，所以我继续使用上下文文件（以及其他工具，有时）来确保正确的记忆在正确的时间被存储和展示。
整个生态系统中代理记忆功能还有很大的改进空间，我认为 LLM 提供商不应该试图垄断这个垂直领域。但这永远不会发生，因为这样能让我们产生'粘性'（sticky）。
或者，也许是我用错了方法。
- Fordec
这一切给我的感觉是，他们正试图把定制 harness 的工作从易于转移的 .md 文件中剥离，转移到 Anthropic 的专用工具中，以增加用户锁定（lock in）。
我今天一直在运行 Opus 5，它已经发生了意外删除，犯下的错误比之前所有 Opus 版本加起来还多，而且经常绕过故意设置的钩子控制。另外，看起来 token 用量也增加了，因为它第一次尝试就失败的情况比 4.8 版本频繁得多。
- sothatsit
同样，我最近禁用了 Claude Code 中的自动记忆功能，性能反而提升了。
管理代理可用的上下文至关重要，绝不能交给代理自己处理。代理往往往记忆里塞太多东西，它们极不擅长精简，而且对包含什么内容的选择非常糟糕。通过禁用自动记忆，并主动塑造我的 CLAUDE.md、技能（skills）和文档，我获得了更可预测的结果。
也许有一天代理能自己管理上下文，但那一天还没到。
- orbital-decay
这篇文章的大部分观点看起来像是……常识？我不确定它跟最新一代模型有什么特别关联。我通常发现 Anthropic 关于如何提示他们自家模型的建议，与我实际观察到的情况相悖，这很令人困惑。他们的系统提示词一直过于臃肿，不知为何他们坚持把它作为一个巨大的整体，而不是拆分成若干部分。难道他们不应该更懂行吗？我怀疑他们是不是看了 Pi 在极少量干扰项下表现优异的例子，于是也缩减了自己的提示词，然后假装在最近的模型里发现了什么新东西。
> 早期的 Claude 模型有时需要重复指令，或者更倾向于听从上下文窗口末尾的指令，而不是开头的指令。
这似乎暗示他们解决了序列位置偏差，比如'迷失在中间'（lost-in-the-middle）以及近因/首因效应？听起来很可疑。Labs 早在 2025 年初就开始宣称这一点，一些基准测试也同意，但每次我在真实用例上运行评估时，这些问题依然明显存在，尤其是在长上下文场景下。
- nullbio
我们需要更多的控制权，而不是更少。
这（以及许多其他原因）是我使用 GPT 而不是 Claude 的理由。GPT 非常严格地遵循你的指令和规则。因此，你可以构建自己的工作流和系统。
Claude 不管你怎么说，它总是随心所欲。这种体验糟透了。
当你想一次性搞定一个简单、毫无细微差别的模板化产品时，你会用 Claude。而且这种产品别人也在做。
当你想要定制化的产品，并且需要对复杂代码库进行带有细微决策的引导时，你会用 ChatGPT。
Anthropic 是在为那些从未写过一行代码、甚至不知道自己想要什么的人优化。电脑转起来（Computer go brrrr）。而 OpenAI 是在为那些希望采用系统化方法的软件开发人员优化。