聚合站会存我的提示词吗？发送敏感文本前先读留存策略

为什么这个问题值得单独拿出来讲

把内部文档、客户信息、未公开的代码片段粘贴进对话框，是很多人每天都会做的事。大多数人只关心模型返回什么，很少去想这段文本在返回之后去了哪里。

在聚合站场景下，链路比直连官方 API 更长一层：你的请求先到聚合网关，再由网关转发给上游厂商。这意味着可能出现记录的环节至少多了一层。

下文按请求的生命周期，逐个环节说明「可能被记录什么」以及「怎么去核实」，不涉及任何具体厂商的当前政策数字——政策会变，方法不会。

环节一：聚合网关的请求日志

请求进入聚合站的第一站是 API 网关。网关为了做鉴权、计费、路由、限流，几乎必然会记录请求元数据：

• 时间戳、API key 标识、请求 ID
• 目标模型、token 数量
• 状态码、耗时

关键在于元数据与正文的边界。元数据本身不含提示词内容，但两类情况会让正文进入网关侧存储：

• 为了排查错误，网关把失败请求的完整 body 落盘
• 为了调试或审计，开启了请求/响应正文的采样记录

这两件事都是工程上的常见做法，不代表有恶意，但对粘贴敏感文本的人来说，风险是真实的。

环节二：上游厂商的留存策略

网关转发之后，请求到达模型厂商。这里的留存行为由厂商自己的条款决定，聚合站无法替它承诺。

需要区分几个不同的概念，它们经常被混为一谈：

• 是否用于训练：输入是否进入训练数据管道
• 是否留存：原始请求是否被保存，保存多久
• 是否可供人工审阅：是否有流程允许人员查看内容，通常与滥用检测相关
• 是否可关闭：企业级/API 类型账户往往提供不同的默认值

一个常见的误解是「API 调用默认不留存」。不同厂商、不同账户类型的默认值并不一致，而且会在版本更新中调整。必须以你实际使用的那个通道的当前条款为准。

环节三：你自己的可观测性链路

容易被忽略的一环在自己这边。很多团队会给聚合站配代理、加中间件，用于统计用量或做内容过滤。这些自建组件同样会把 prompt 写进日志系统。

同样的问题也出现在客户端的调试面板、浏览器的网络记录、以及本地开发时打印的请求对象里。这些地方不涉及第三方信任问题，纯粹是工程卫生。

怎么在发送前核实

核实留存条款是一个可以流程化的小动作，不需要读完整份法律文本。

1. 定位条款页：找聚合站与上游厂商各自的隐私政策 / 数据处理说明，注意区分「面向网页产品」与「面向 API」的条款，两者常常不同。
2. 搜索关键词：在页面内搜索 log、retention、train、review、abuse 等，直接跳到相关段落。
3. 确认版本与生效日期：记录你查阅当天的日期，政策会变动，核实结论有保质期。
4. 按数据分级决定是否发送：

• 公开信息：无需额外处理
• 内部文档：先脱敏再发送
• 个人数据、凭据、密钥、未公开代码：默认不发送

降低暴露面的具体做法

如果确实需要借助模型处理敏感文本，可以从「减少发送内容」入手，而不是只依赖对方承诺：

• 脱敏后再发送：把真实姓名、域名、账号、路径替换成占位符，本地保留映射表。
• 只发片段：定位到需要分析的那几行，而不是整份文档。
• 拆分问题：先发送结构描述，确认模型理解正确，再决定是否需要贴原文。
• 不在提示词里放凭据：API key、token、密码不应出现在 prompt 中，这与是否留存无关，是底线。
• 给团队定规则：把「哪些内容可以贴」写成检查清单，比依赖个人判断更稳定。

关于无 KYC 与匿名性的边界

无 KYC 的充值方式（例如用稳定币入金）降低的是账户身份关联，不等于内容不留存。这两件事处在不同层面：前者关乎「谁在付费」，后者关乎「发了什么」。把它们混同，容易产生错误的安心感。

真正决定内容暴露面的，仍是网关的日志配置和上游厂商的留存条款。

小结

一次请求至少经过网关、上游厂商两段链路，再加上你本地的日志与调试工具。核实留存策略的正确顺序是：先确认自己在用哪条通道，再查该通道当前的条款，最后按数据敏感度决定发送内容。条款核实是发送前的常规动作，不是一次性任务。