Claude 系统提示词两年增长 9 倍：生产 AI 产品团队该学什么

本周，Anthropic 的 system prompt 发布说明成了 Hacker News 的头条。这个页面展示了 Anthropic 放在 claude.ai 及其移动应用上引导 Claude 的精确指令。短短一天内获得了超过 550 个点赞和 230 条评论，讨论仍在继续。

这个页面最有趣的地方不是某一条规则，而是它的规模。Claude Opus 3 的 system prompt（日期为 2024 年 7 月 12 日）据我统计是 358 个词。Claude Opus 5 的（日期为 2026 年 7 月 24 日）是 3,235 个词。两年间增长了 9 倍。

我用 Spring Boot 和 Spring AI 构建生产级 AI 系统已经一年多了，同时也维护着自己的 agent 基础设施。当控制一个前沿模型的 prompt 增长了 9 倍时，这不仅是 Anthropic 的趣闻，而是每个正在交付 AI 产品的团队的警示和行动指南。以下是这 3,235 个词里实际上写了什么，以及生产团队应该从中复制什么。

Anthropic 实际发布了什么

发布说明（platform.claude.com/docs/en/release-notes/system-prompts）是面向消费者聊天产品的 system prompt 变更日志。页面上有两个细节很重要：

这些不是 API prompt。页面说明 claude.ai 和移动应用"使用 system prompt 在每次对话开始时向 Claude 提供最新信息，例如当前日期"，并且"这些 system prompt 更新不适用于 Claude API"。

模型现在是固定快照。自 Claude 4.6 起，"每个模型 ID 是一个单一的固定快照"，因此每个模型在变更日志中只有一条记录。

Simon Willison 将这个页面转成了一个 git 仓库（github.com/simonw/research），包含 29 个 prompt 修订版本跨越 17 个模型，每个版本都带有源文档中的日期提交。这意味着你可以在任意两个版本的 Claude 性格之间运行 git diff。这是一件了不起的事：前沿模型的产品规格，像源代码一样版本控制，而且公开可见。

3,235 个词里实际包含了什么

我在那个仓库里读了 Opus 5 的 prompt。它被组织成多个章节：产品信息、Claude 行为规范、拒绝处理、法律和财务建议、语气和格式、用户福祉等。有四个细节很突出。

这个 prompt 是一份产品目录。它列出了当前的产品线："最近公开可用的模型是 Claude Fable 5、Claude Opus 5（当前选中的模型）、Claude Sonnet 5 和 Claude Haiku 4.5"，包括 API 模型字符串。它甚至描述了 Opus 之上的层级："第一个 Mythos 级模型 Claude Mythos Preview 目前不对公众开放。它目前正在被少量可信组织使用，作为 Anthropic 的 Project Glasswing 的一部分。" 营销文案、安全策略和产品公告都写在同一个文本文件里。

这个 prompt 是一个新闻频道。让我重新读了一遍文件的这部分："Claude Fable 5 和 Claude Mythos 5 于 2026 年 6 月 9 日首次发布。2026 年 6 月 12 日，Anthropic 暂停了对这两个模型的访问，以遵守美国商务部的出口管制；该部门于 2026 年 6 月 30 日解除了这些管制，Anthropic 于 2026 年 7 月 1 日恢复了访问。" 然后是重点："这些事件发生在 Claude 的训练数据截止日期之后，所以 Claude 只能通过这份通知了解它们。" 当前沿实验室需要模型知道训练之后发生的某件事时，它不做微调，而是编辑 prompt。

这个 prompt 处理模型切换。"用户可以在对话中途切换模型，所以这条线程中较早的消息如果标识自己为不同模型或报告了不同的知识截止日期，仍然可能是准确的。" HN 帖子的一位评论者补充了更奇怪的版本：Opus 5 的 prompt 告诉它，一个原本发给 Claude Fable 5 的请求可能已经被安全机制重定向到了 Opus 5，它应该假装自己是 Fable 5 来回答请求。System prompt 现在是一份路由文档。

这个 prompt 是安全策略的执行场所。儿童安全规则非常明确："对于面向未成年人的内容，Claude 绝对不能提供未说明的假设，使请求看起来比书面描述的更安全。" 还有关于拒绝的规则、法律和财务建议，以及一列 Anthropic 可以在对话中途注入的分类器驱动提醒：image_reminder、cyber_warning、system_warning、ethics_reminder、ip_reminder 和 long_conversation_reminder。甚至知识截止日期现在也变成了一条行为指令："Claude 的可靠知识截止日期，超过了就无法可靠回答，是 2026 年 5 月末"，它不应该确认或否认无法通过搜索验证的 2026 年 5 月之后的声明。

增长才是真正的故事

内容本身引人入胜，但增长才是那个数据点。Prompt 不是缓慢向上漂移的。它在两年内增长了 9 倍，而且一年前就已经很庞大了。2025 年 5 月 6 日，一篇展示 Claude 4 泄露 prompt 的帖子在 Hacker News 头条挂了一天，标题是"Claude 的 system prompt 加上工具超过 24k tokens"（627 分），那还没算上工具定义。

为什么它不断增长？HN 帖子提供了最好的框架。一位评论者将 system prompt 比作建筑规范："它让我想起建筑法规和 boilerplate 合同：它们一开始很小很简单，然后随着事故和对漏洞的利用而逐渐累积。他们说建筑和电气规范是用血写成的。" 另一位指出了促成条件："我猜既然模型现在能支持更大的输入尺寸，塞进更大的 system prompt 反而更高效。"

每一次事件、每一次策略变更、每一次产品发布都会添加一段话。什么都不删除。这就是规律，而且它和公司内部生产 prompt 发生的一模一样，只是速度慢一些。

辩论：为什么不直接 bake 进模型？

帖子中最热门的问题是：为什么 Anthropic 不把 system prompt bake 进模型权重，而是每次请求都附带？Simon Willison 直接回答了："这些 system prompt 不影响 API，它们是给 Claude 消费者聊天产品用的。我们不会被收取额外费用。它们也被前缀缓存了，所以对 Anthropic 的成本和性能影响大大降低。"

这个细节对开发者很重要：消费者聊天不向你收取 prompt 的费用，但 Claude Code 运行的是它自己未公开的 system prompt，那些是要收费的，"虽然按缓存 token 费率计算"，正如 Willion 所说。

经济逻辑很清晰。将行为 bake 进权重需要重新训练，修改代价高昂。编辑一个文本文件很便宜、即时、而且可缓存。Anthropic 将 prompt 视为一个活着的控制面，而不是模型属性。你的团队也应该这样做。

生产 AI 团队应该复制什么

过去一年我用和 Anthropic 管理 Claude 一样的方式管理我的 Spring AI agent，发布的变更日志验证了这些实践。以下是你应该带回到代码库的东西。

像代码一样对待 prompt，并保留历史。 Simon 的仓库有用的原因是 diffs。做同样的事：将每个 system prompt 放在你的仓库里版本化，每次变更都附带变更日志条目。当行为退化时，在 prompt 文件上运行 git log 就能告诉你什么变了。

将 prompt 固定到模型上。 自 Claude 4.6 起 Anthropic 每个模型 ID 配送一个固定快照。你的应用应该同时固定两者：模型版本和评估时用的 prompt 文件。在 Spring AI 中，代码是这样的：

ChatClient client = ChatClient.builder(chatModel)
    .defaultSystem(resourceLoader.getResource("classpath:/prompts/system-v3.md"))
    .build();

system-v3.md 和代码一起放在 git 里。当厂商发布新的模型版本时，你先拿固定的那个 prompt 评估新模型，再升级其中任何一个。

为上下文窗口做预算。 System prompt 中的每个 token 每次请求都要付费，除非它被前缀缓存了。在我的 agent 可观测性设置中，每次请求 system prompt 所占的比例是我在延迟或成本上升时第一个看的数字。3,235 个词的 prompt 对 Anthropic 有效是因为激进的缓存。你的 prompt 应该精简。

用实验证明每一次扩展。 "用血写成"的规律意味着规则不断累积。在我的 Spring AI 系列中，我介绍了 prompt A/B 测试和金丝雀回退，原因就在这里：每条新规则都应该通过实验来证明自己的位置，不好的 prompt 变更应该自动回滚。HN 帖子也指出了 Opus 5 prompt 内部的矛盾，这是 Anthropic 自己为 Claude 第五代提供的上下文工程指南中也承认的问题。

将易变的事实推入检索，而不是 prompt。 整个变更日志中最优雅的细节是出口管制通知：Anthropic 将截止日期之后的新闻以纯文本形式注入，而且对机制坦诚相告。你可以用同样的方式用一个小型的"最新更新"系统块来做你自己的检索支持，从你的数据库刷新，而不是每次价格或策略变化都去编辑 prompt 文件。

在你上线下一个 system prompt 之前的检查清单

将 prompt 文件在 git 中和消费它的代码一起版本化，像审查代码一样审查 diffs。

在同一个 commit 中将 prompt 版本固定到模型版本。

记录每个请求的 prompt token 占比和缓存命中率。

在每个新增规则后面加上 A/B 测试或评估，并配有金丝雀和回退。

将易变的事实（价格、新闻、策略）移入检索，而不是散文。

安排每季度修剪。删除从未触发过的规则。Claude 变更日志就是这样产生的——因为什么都不删除。

我每周写关于 Java、Spring Boot 和 AI 的文章。订阅免费。

你有没有对自己的 system prompt 做过版本间的 diff？增长是什么样的？在评论区告诉我。