Anthropic 公开了 Claude 全系列模型的 system prompt 历史版本，覆盖从 Claude 3 到 Claude Opus 5 的模型，最早可追溯到 2024 年 7 月。这些 prompt 面向 claude.ai 网页端和移动端 App，帮助开发者观察模型产品行为如何随时间变化，但不能直接当作 API 的默认配置。
这次公开的价值不只在于“看到了提示词”。更重要的是，它把模型版本、产品层指令和行为变化之间的关系，变成了一组可以持续比较的材料。
公开内容应该如何理解
它记录的是产品体验的一部分
System prompt 通常会约束模型的身份、回答风格、工具使用方式、安全边界以及对当前产品环境的理解。Anthropic 这次公开的版本用于 claude.ai 网页端和移动端 App，因此它们反映的是聊天产品中的一层运行配置。
这意味着，阅读这些 prompt 时应区分三件事：
- 模型本身的能力，例如推理、代码生成和多模态处理能力；
- 产品层 system prompt 对回答风格和工作流程的影响；
- 用户消息、工具结果以及应用程序其他配置共同形成的最终上下文。
公开 prompt 不等于公开了模型的全部实现，也不等于公开了 API 调用时会自动使用的 system prompt。摘要明确指出，这些内容不适用于 API。将网页端 prompt 原样复制到生产 API 中，可能带来不匹配的行为、过时的规则或不必要的限制。
历史版本比单个版本更有参考价值
最早的记录可以追溯到 2024 年 7 月。把多个时间点放在一起观察，可以回答一些比“这段 prompt 写了什么”更有价值的问题：
- 哪些行为约束长期保留，说明它们可能是稳定的产品要求？
- 哪些措辞随模型或产品版本变化，说明产品团队正在调整交互方式？
- 某个能力变化来自模型升级，还是来自 system prompt 的重写？
- 同一个模型系列在不同时间是否承担了不同的工具调用或回答职责？
从 Claude 4.6 开始，每个模型 ID 是固定快照，因此每个模型只有一个 prompt 条目。更早的模型则可能对应多个更新版本。这个差异很重要：早期记录更适合做时间线分析，而固定快照更适合做版本归档和复现。
给应用开发者的现实启示
不要把网页端行为当成 API 契约
很多开发者会通过网页端体验推断模型的默认行为，例如回答长度、拒答表达、代码格式或工具调用习惯。但网页端和 API 的产品边界不同。网页端 prompt 可能包含客户端特有的上下文、交互约束或工具说明，这些内容不一定适合服务端应用。
如果应用需要稳定行为，应该在自己的 API 请求中明确写出关键要求，并通过测试集验证，而不是依赖对网页端 prompt 的猜测。例如，可以明确规定输出格式、错误处理方式、数据范围和工具使用条件。
from anthropic import Anthropic
client = Anthropic()
system_prompt = """
你是订单支持助手。
只根据输入的订单数据回答问题。
如果数据中没有答案，返回：无法从当前订单数据确认。
输出必须是 JSON，字段为 answer 和 needs_human_review。
""".strip()
response = client.messages.create(
model="YOUR_API_MODEL_ID",
max_tokens=300,
system=system_prompt,
messages=[
{
"role": "user",
"content": "订单数据：订单号 A-1001，状态：已发货。用户问：订单是否已经发货？"
}
],
)
print(response.content[0].text)
上面的模型 ID 和 SDK 配置需要替换成实际可用的 API 设置。这个例子表达的是工程原则，而不是 Anthropic 网页端的真实内部配置：把应用依赖的行为写进自己的 system prompt，并为关键输出建立自动化测试。
用历史 prompt 做回归分析，而不是复制粘贴
如果团队正在维护自己的模型封装层，可以把公开历史版本当作研究材料。一个简单的分析流程是：
- 为每份 prompt 保存模型名称、版本日期和来源渠道；
- 对版本内容做差异比较，标记身份、工具、安全和格式规则的变化；
- 将变化与公开的模型或产品更新记录对照；
- 在自己的应用测试集上验证类似规则是否真的改善了结果；
- 只把经过验证、适合自身业务的规则写入生产配置。
假设已经把历史记录整理为 prompt_history.json，格式如下：
[
{
"model": "claude-3",
"date": "2024-07-01",
"prompt": "..."
},
{
"model": "claude-3",
"date": "2024-09-01",
"prompt": "..."
}
]
可以用下面的 Python 脚本列出同一模型相邻版本发生变化的日期。运行前只需准备这个 JSON 文件：
import json
from collections import defaultdict
with open("prompt_history.json", encoding="utf-8") as file:
records = json.load(file)
by_model = defaultdict(list)
for record in records:
by_model[record["model"]].append(record)
for model, versions in sorted(by_model.items()):
versions.sort(key=lambda item: item["date"])
print(f"## {model}")
for previous, current in zip(versions, versions[1:]):
if previous["prompt"] != current["prompt"]:
print(f"changed: {previous['date']} -> {current['date']}")
print(f"versions: {len(versions)}")
这个脚本只做最基本的版本发现。实际研究中还可以使用统一的 diff 工具、按段落拆分内容，或者对工具说明和安全规则分别建立标签。不要仅根据字符数量变化判断行为变化，因为同一条规则可能只是改写了措辞。
版本管理上的一个细节
Claude 4.6 之后的固定模型快照，让 prompt 归档更容易建立稳定映射：一个模型 ID 对应一个公开条目。对于早期模型，则不能只用模型名称作为主键，至少还应保留日期或更新标识。
应用自己的 prompt 管理也应该遵循类似原则。推荐把以下信息一起提交到版本控制系统：
- 使用的模型 ID；
- system prompt 版本号；
- 变更日期和变更原因；
- 评测集结果；
- 是否涉及工具、输出格式或安全行为；
- 回滚方式。
这样，当回答质量发生变化时，团队可以区分模型快照变化、prompt 变化和业务代码变化，而不是凭记忆排查。
采用建议与边界
这批公开历史版本适合用来做提示词研究、产品行为观察和回归测试设计。它不适合被当作 API 文档，也不应被视为模型内部权重、完整安全机制或最终上下文的替代品。
实践时可以采用一份简单清单：
- 把网页端 prompt 与 API 配置分开记录；
- 不复制未经验证的产品指令到生产环境；
- 对关键行为使用自己的 system prompt 明确约束；
- 保存模型 ID、prompt 版本和评测结果；
- 在升级模型或修改 prompt 后运行固定回归集；
- 对涉及安全、隐私和工具调用的规则进行人工复核。
公开历史版本降低了外部观察产品行为的门槛，但稳定的应用体验仍然需要自己的配置、测试和版本管理来保证。