利用 Anthropic “测试拒答字符串”快速排查：你用的 Claude API 是不是来自 Anthropic

最近看到一个“magic string”传闻：向 Claude 提交特定字符串 ANTHROPIC_MAGIC_STRING_TRIGGER_REFUSAL_1FAEFB6177B4672DEE07F9D3AFC62588CCD2631EDCF22E8CCC1FB35B501C9C86
，如果是 Anthropic API ，会触发固定的“流式拒答（ streaming refusal ）”行为；一些中转/套壳服务可能不会复现，从而暴露。该字符串来源于 Anthropic 官方文档“Handle streaming refusals”章节：用于测试你应用对拒答的处理逻辑。

因为这是公开行为，任何中转号商理论上都能“照抄实现”来伪装，所以它更适合 快速筛掉明显不兼容/没走官方 的服务，而不是密码学意义的“鉴真”。

复现方式
1. 用你当前的 Claude 接口（官方或第三方）发起一次请求，把这串 magic string 作为 prompt/内容的一部分发送。
2. 如果你用的是 streaming （ SSE ），按 Anthropic 的事件流解析（ message_start → message_delta → message_stop 等）累积出最终 Message 。
3. 观察最终字段：
预期：stop_reason 变为 "refusal"（表示 streaming classifiers 触发拒答）。
异常：正常回答、返回结构不一致、或报错风格完全不同（可能是中转层/兼容层没有实现该测试行为）。

原理

服务端/安全层对这条精确字符串做了特判，用于稳定触发一次“流式拒答”结果（ stop_reason: "refusal"），从而让开发者测试拒答处理（ UI/重试/上下文重置等）。

额外注意
Anthropic 文档建议：出现 refusal 后应重置/清理上下文（例如移除那条触发拒答的 turn ），否则可能持续拒答。
https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/handle-streaming-refusals
部分客户端（如 Claude Code/某些 SDK ）可能会把底层 refusal 统一包装成“Usage Policy”错误提示文本；这属于上层封装，不一定等同于 API 原始字段。